Table of contents
Step 1: Host discovery and port scanning
Step 2: SQL injection login screen
Step 3: The file contains + SQL injection to achieve unauthorized / direct unauthorized access
Step 4: File upload, file parsing exploit
Step Five: Escalation of Rights
write at the beginning
This blog is 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 replay of writeup. Readers will gain something after watching it patiently. The shooting process of this article involves SQL injection, POST file containment exploits, privilege overreach vulnerabilities, sudo privilege use and privilege escalation, etc. For the complete shooting idea, please refer to: "Red Team Notes" Target Machine Intensive Talk: Holynix - Use SQL injection skillfully without using big killers; manual interception, let Burp Suite be laid off. _哔哩哔哩_bilibili
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/holynix/holynix-v1.tar.bz2
After the download is successful, open it with vmware, and when the prompt box pops up, please select " I have moved this virtual machine ", and then set it to NAT mode, otherwise the target machine cannot be scanned!
The interface after the target machine is started is as follows:
Step 1: Host discovery and port scanning
It is still a conventional idea, and will not be explained in detail in this article. See the nmap section of my blog for details on host discovery and port scanning commands:
nmap -sn 10.10.10.0/24
nmap --min-rate 10000 -p- 10.10.10.131
nmap -sT -sV -O -p80 10.10.10.131
nmap -sU --min-rate 10000 -p- 10.10.10.131
nmap --script=vuln -p80 10.10.10.131
Scanned out my target machine ip is 10.10.10.131, the open port is only port 80 of the web
Vulnerability scanning found vulnerabilities related to SQL injection, directory enumeration, csrf, dos, etc. We focus on SQL injection, directory enumeration, etc.
Step 2: SQL injection login screen
Only port 80 is opened, then the browser accesses the IP of the target machine, and the result is a simple interface with two interfaces: home and login:
Click Login on the left to jump to the login interface:
When encountering a login box, general ideas: weak password/default password/SQL injection/CMS vulnerability exploitation/sensitive information search/dictionary blasting . This doesn't look like cms, it looks like a website built by programmers themselves, try SQL injection, first enter the user name and password in single quotes 'try
After clicking Submit, an error is reported directly, and the sql query statement is exposed. You can see that this sql query statement escapes the single quotation mark (\') of the username field, but the password part does not. Therefore, we only need to enter the username casually, and use the universal password to log in as the password:
' or 1=1 #
The login is successful, and there is a prompt after entering, which should be the user of alamo:
There are a series of columns on the left to try, first click Directory, as follows:
It is a lot of personal information of people. Pay attention to the parameter page= in the url. We can try to include the file and try to read /etc/passwd
The reading failed, and a bunch of error reports appeared. Ignore these for now, and continue to check in the left column to see if there is any place where code execution or file upload can be performed. Finally, in the Upload module, it is found that files can be uploaded:
Just upload a file and try:
Tip: For user alamo, home directory upload is not allowed. This sentence reveals two points of information. First, the upload location after the file is uploaded may be the user's home directory, that is, /home/alamo. Second, alamo's permissions are not enough, and users with higher permissions need to be found. How to log in as a user with higher authority? We can try to find the usernames of other users, and then log in to other users' accounts through SQL injection. So how do you find the username of another user? The /etc/passwd file can be read by looking for file inclusion vulnerabilities.
Step 3: The file contains + SQL injection to achieve unauthorized / direct unauthorized access
First look for the file inclusion, pay attention to the url of each page, and find that there is only the parameter page. We have also tried this briefly. Since we cannot use the parameters exposed in the url, we might as well find out whether there are POST parameters, that is, parameters with file inclusion vulnerabilities may exist in the request body . Then the page to focus on should be the page where information can be submitted, such as the Security interface:
The drop-down option in the above interface can select some text information. It is very likely that after selecting an item, clicking Display File will send a request to the background. The request body contains parameters, and the values of the parameters are the options in the figure below (/Email/Acceptable Use/Internet Use, etc.) Here, of course, you can use burpsuite to capture Take a look at the package.
However, the unruly red team note boss does not want to use graphical tools. Then we can also view the submitted parameters by pressing F12 to view the elements in the source code of the web page:
Here you can see in the source code that different Display Files can be realized by changing the value of the parameter text_file_name. For example, if we select Email and then click Display File, the request body of the sent request packet contains text_file_name=ssp/email. txt, then if we modify the front-end code and replace ssp/email.txt with the /etc/passwd we want to read, if there is a file inclusion vulnerability in the text_file_name parameter, we should be able to read /etc/passwd, try try:
As shown above, there is indeed a file inclusion vulnerability, nice! Then we can look at other accounts with bash according to the /etc/passwd file. We can find that there is a user named etenenbaum, then we try to log in with this user for SQL injection to see how his permissions are (try to read / etc/shadow file fails). Click Logout in the lower left corner to exit and go back to analyze how to inject. When we first tried to enter single quote injection, the error echoed the select query statement:
SELECT * FROM accounts WHERE username='\'' AND password='''After filtering the single quotes in username, we try to construct a closure in password, trying to make username='etenenbaum', then we only need to fill in the following information in the password to construct a closure:
' or username='etenenbaum' #
In this case, if the user name is aaa, and the password is 'or username='etenenbaum' #, the query statement is:
SELECT * FROM accounts WHERE username='aaa' AND password='' or username='etenenbaum' #'The logic is (false and false) or true = true, and sure enough, I successfully logged into etenebaum's account:
However, there is another way to log in to other accounts . Go back to the user alamo, and press F12 on any interface to view the stored information. You can find that there is a piece of information in Cookies. The name is uid, and the value is 1. It seems to be related to the user’s id. , maybe 1 corresponds to user alamo, and 2 corresponds to other users.
Then we change the position of Value to 2, click refresh, and try to see if we can exceed the authority. Discovery worked! It seems that there is an unauthorized loophole in the cookie !
Step 4: File upload, file parsing exploit
The following is to try whether this user has the upload permission, just upload a file helloworld, do not check the Enable the automatic extraction of gzip archives below. It can be found:
It seems that the user etenenbaum has permission to upload files, so we try to upload the reverse shell file of php and construct the shell first. It can be written manually, this time we directly search in kali and copy to the current directory
locate php-reverse
cp /usr/share/laudanum/php/php-reverse-shell.php .
Then we vim this file, modify the ip and port of the rebound shell, set the ip to kali's ip, and set the port to 1234:
Then try to upload the file php-reverse-shell and find that it can:
Then look for this file in etenenbaum's home directory http://10.10.10.131/~etenenbaum/ :
Perfect, the path has been found. Then we just need to start an nc in kali to listen on port 1234:
nc -lvnp 1234
Then I clicked php-reverse-shell excitedly, trying to trigger the code execution of the reverse shell:
As a result, the permissions are not enough! Failed to trigger code execution! It's too early to be happy. Then go back to the file upload page, and we check the Enable the automatic extraction of gzip archives below. Try uploading a gzip file this time, first package the php rebound shell file as gzip:
After clicking submit, go back to the home directory and find that the .gz compressed file has not been decompressed again:
After clicking, there is still no permission:
At this time, it seems to be in a stalemate. At this time, you can try to continue to exceed the authority to find an account with higher authority . However, according to the idea of the red team note boss, the gz file just uploaded should be decompressed automatically, because Enable the automatic extraction of gzip archives. means to automatically extract the source file from the gzip compressed file . However, in reality, we did not see the gz file decompressed under the http://10.10.10.131/~etenenbaum/ path, which is a bit strange. When uploading files, we can see the URL parameter page=transfer.php on the successfully uploaded page:
It may be that there is a problem with the logic of the transfer.php file. We can read this file through the file containing the text_file_name parameter just now:
It seems that the logic behind the compressed package conversion is to use tar xzf to decompress, then we can use tar czf to package the file and then upload it:
tar czf shell.tar.gz php-reverse-shell.php 
Then we try to upload this shell.tar.gz file to see if the background can automatically extract the files:
Heck, it's still a packaged file, even though it's not automatically extracted :
Then I remembered that I forgot to check Enable the automatic extraction of gzip archives. Don’t forget to check this option this time and re-upload a myshell.tar.gz file:
It seems that no new files have been seen, but it is possible that the background has decompressed php-reverse-shell.php from myshell.tar.gz and overwritten the previous files, so we click php-reverse-shell again this time .php Try to see if you can trigger code execution.
Look back at the port that nc listens to, and successfully get the rebound shell!
After some rubbish operations, I feel like a clown. Readers must pay attention to the difference in naming when operating to prevent confusion.
Step Five: Escalation of Rights
First look at who you are, www-data
Then improve interactivity with python:
python -c "import pty;pty.spawn('/bin/bash')"
Then check the current permissions:
sudo -l
It can be seen that we can execute the commands chown chgrp tar mv with sudo without secret. Then combined with the feature that mv can rename the file, we only need to choose any one of the three commands of chown chgrp tar (here, take tar as an example) and rename it to another name (tar.orgi), and then use the su command used for privilege escalation Rename to one of these three (tar), and then run the sudo command (sudo tar) to escalate privileges :
sudo mv /bin/tar /bin/tar.orgi
sudo mv /bin/su /bin/tar
sudo tar
Running sudo tar is equivalent to running sudo su, because we renamed su to tar, and then tar can be run by our sudo without password, successfully escalating privileges! As shown above, the shooting is completed.
write at the end
This target machine is not too difficult, but it is still necessary to understand the parameters contained in the POST type file, and finally when the file is uploaded, the trigger code execution is also difficult to upload a reasonable .tar.gz file. You must check Enable the automatic extraction of gzip archives. When uploading files, due to the repetition of my naming, it caused a lot of unnecessary troubles. When readers perform file upload vulnerability testing in the future, it is best to ensure that the uploaded file names are different. If the uploaded file is a compressed package, It is best to ensure that the names of the files before compression are not the same, so that there will be no confusion due to overwriting when uploading repeatedly . Finally, a summary of the shooting process:
1. Host discovery and port scanning
2. Web penetration: SQL injection login background. Get the account alamo, but this account does not have permission to upload files.
3. Use the file to read /etc/passwd to get the usernames of other users, and then log in to other accounts through SQL injection to find accounts with file upload permissions. You can also use F12 to directly override the authority by modifying the value of uid in the cookie.
4. File upload: Upload the file of the rebound shell directly, and you will find that the path does not have permission to access and cannot trigger execution. Finally, check Enable the automatic extraction of gzip archives and upload the .tar.gz file to successfully decompress in the background. After finally accessing the path Triggering code execution, the reverse shell obtains the initial www-data shell.
5. Privilege escalation: check the permissions with sudo -l, and find that there is a password-free sudo permission for the mv command, so you can use mv to rename the privilege escalation command su to any other command with sudo permissions. sudo runs the su command after renaming to escalate the privilege.
The target drone is not difficult, but it is not easy to summarize. I hope readers can like it, follow it and give it a lot of support!