<Introduction>
In this blog post, I will be doing a walkthrough of the OffSec Proving Grounds Blogger vulnerable host. I will provide a walkthrough of reconnaissance through post-exploitation. This will include performing port scanning, service enumeration, arbitrary file upload, 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>
Blogger is a vulnerable host created by TheHackerBrain to allow users to practice ethical hacking techniques. This vulnerable host suffers from arbitrary file upload, broken authentication, and security misconfiguration. This virtual machine is accessible from the OffSec Proving Grounds virtual training lab and VulnHub which is also owned by OffSec.
<Enumerating What is Running>
I went ahead and started my target host Blogger. As shown on the screen it now has an IP. Now that the target host has an IP, I will proceed with active information gathering. This will usually consist of port scans and service enumeration.
nmap -sS -p- -A -T4 -vv 192.168.170.217My go to for these labs tends to be Nmap for active information gathering of the target host. I’ll run the following command shown in the CLI. I will scan all 65 thousand 535 ports using the -p- switch for the purpose of looking for open ports and services that may be listening on them.
<Analyzing the Results>
The Nmap scan did not take too long. When I look at the Nmap scan results I can see that Nmap detected two open ports, port 22 (SSH) and port 80 (HTTP).
Reviewing the results of the Nmap scan and due to previous experience, it’s more likely than not that Blogger is a Linux host. Nmap detected the OS as a generic Linux distribution and ssh service running, not to mention the service banners listing Ubuntu. The first service I will look at is port 80.
Browsing to the webpage on http://192.168.170.217 it looks like the website is a personal site containing a programmers resume.
I’ll open Burpsuite, so it can capture my website traffic as I manually review the site. Then once I'm done manually reviewing the site I can review what Burpsuite detected and further investigate.
Reviewing the page source I don’t find anything useful. At this point I will need to crawl the webserver.
ffuf -u http://192.168.170.217/FUZZ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-small.txt -r trueI’ll run Ffuf using the following command shown in the CLI to crawl the webserver looking for hidden directories. The -r tells Ffuf to follow redirects.
Fuff completed its crawl and it detected a few directories including images, assets, css, and js.
I also ran Feroxbuster to see if I got different results and for the most part the directories found were the same, except Feroxbuster crawled a little deeper to find sub-directories.
Reviewing all the directories that Ffuf and Feroxbuster found were some standard directories like /images, /css, and /js directories. Feroxbuster did find something interesting in the /assets/fonts directory.
There was a /blog directory that seemed out of place. I decided to investigate further.
When I clicked on the /blog directory it loaded posts from the blogger site documenting the OWASP top 10.
Reviewing the page, I did note that there was an account named j@m3s that could be useful in the future.
Another thing I noticed is that the CMS is Wordpress and it’s using the theme ThemeZee. Something to investigate further.
When I clicked on the “login” link, I received a “server not found” error message. Looking closely I can see in the address bar it says blogger.thm.
echo "192.168.170.217 blogger.thm" >> /etc/hostsI’ll run the following command to add the hostname/IP to my Kali’s hosts file.
After adding the hostname/IP to my Kali’s hosts file, I refreshed and the Wordpress login page displayed.
wpscan -e ap --detection-mode aggressive --url http://blogger.thm/assets/fonts/blog/ -v --api-token <api token> --plugins-detection aggressiveNow that the page is displayed, I’ll run Wpscan to see if any vulnerabilities get detected. -e ap tells Wpscan to enumerate all plugins. –detection-mode aggressive performs deep rigorous scan of the website. –url is self-explanatory, -v for verbose, –api-token I added my Wpscan api token which allows Wpscan to access the Wpscan vulnerability database for more detailed assessment of the Wordpress cms, and finally –plugin-detection set to aggressive to thoroughly assess any installed plugins.
WPScan is a security tool designed specifically for WordPress sites. It is used to identify vulnerabilities in WordPress plugins, themes, and the core WordPress installation itself. You can sign up for a free account to access the WPScan API with an API key.
The results of the scan came in and the scan took about 40 minutes.
Wpscan did find issues with Wordpress, including several Wordpress vulnerabilities.
Wpscan also detected the running plugins and vulnerabilities affecting them.
The initial review of the Wpscan results shows there’s a directory called Uploads.
Browsing to /uploads/2022/08, I can see that someone was able to upload a reverse shell php script.
As noted earlier there seemed to be a reverse shell that was uploaded to the target host. Unauthenticated arbitrary file upload seems to be a good vulnerability to target based on the discovery of that reverse shell that was already uploaded.
I’ll look into the wpdiscuz plugin vulnerability to see if it is possible to upload a reverse shell.
After reviewing the Wpscan results, I want to investigate the arbitrary file upload vulnerability. I opened the link in the Wpscan reference section to read through the Wordfence writeup on the vulnerability.
Based on the writeup, it looks like the “comments - wpDiscuz” plugin is affected. The vulnerability appears to be in the “file mime type” detection functions that were used in the plugin.
Based on the writeup, the file type verification could easily be bypassed, allowing unauthenticated users the ability to upload any type of file, including PHP files.
Upon further reading, it looks like I can use the magic byte of an image file type to bypass the upload restrictions.
I needed to find the right file type magic byte number to use. I found an article by NetSPI titled Magic Bytes - Identifying Common File Formats at a Glance. The article listed the magic bytes for a variety of file types.
One of the options listed was GIF, which I will try using. If my assumption is correct, I just need to add “GIF87a” at the beginning of my reverse shell PHP script. And then I can see if it uploads successfully.
To try to bypass the file type restriction I will need to add the magic byte of an image file type based on the writeup I noted earlier. I added the GIF magic byte Mnemonic value, which is GIF87a to my reverse shell PHP script.
Based on the writeup the vulnerability is located in the comments section. I’ll click on the first post, but any post should do.
Looking at the comments section there are several areas requiring user input. The writeup discussed image files and I can see an image attachment button. I’ll try testing the upload function.
I want to upload my modified PHP script to see what response I get. I changed the “image files” option to “All files” in order to select my PHP file.
In the request I can see the GIF magic byte in mnemonic form.
In the response you can see that it looks like the request provides a URL where the reverse shell was uploaded.
If I go to the path shown in the response, I can see that my reverse shell appears to have uploaded successfully.
Now that I verified that my reverse shell uploaded successfully, I’ll run my Netcat listener using the command shown in the CLI.
When I click on my reverse shell, it looks like nothing happened, but if I look at the tab I can see a dot going side to side.
nc -lvnp 1234When I check back on my Netcat listener it looks like that worked and I was able to catch a shell.
whoami && id && pwd && ls -laI ran the following commands shown in the CLI to see what account I'm logged in as and to see the current directory I am in. Based on the output it looks like I am in the root directory.
I changed directory to /home and ran the ls -la command to view the contents. I can see 3 accounts james, Ubuntu, and Vagrant.
I changed directory to james and ran the ls -la command. I can see the local.txt file. I ran the command shown in the CLI to view the local.txt hash.
I’ll enter the hash into the Offsec PG console to get the first flag.
I changed directories to the /tmp folder. I need to do further enumeration in order to find an escalation path.
I downloaded Linpeas from PEASS-NG Github page using the Wget command shown in the CLI. Based on the output it looks like Linpeas downloaded successfully.
I ran the ls -la command to verify that Linpeas downloaded successfully and it did. I also noticed Ill need to run chmod on Linpeas because it is not executable.
I ran the chmod command on Linpeas as shown in the CLI to make Linpeas executable.
I ran ls -la to verify Linpeas is executable, and as can be seen in the CLI it shows Linpeas is now executable.
./linpeas.sh -a -eI’ll run the following command shown in the CLI. The -a performs all checks and -e performs extra enumeration. Linpeas will help me find possible escalation paths that I could use to escalate my privileges.
Reviewing the Linux exploit suggester section it looks like there are several possible exploitable vulnerabilities.
Under the Users with console and All users & groups I can see that the three standard user accounts james, Vagrant, and Ubuntu with UID numbers starting at 1000.
Looking at the last logons section and Last time logon each user section, the vagrant account appears to have been logged into remotely, based on the pts/0. The difference between TTY and PTS is the type of connection to the host. TTY ports are direct connections to the host such as a keyboard/mouse or a serial connection. PTS connections are SSH or telnet connections. I’ll have to investigate the vagrant account further once I am done reviewing the Linpeas output.
It looks like there is a script that is scheduled to run called backup.sh. This may be something to look at later.
Linpeas also listed several programs that have the SUID bit enabled. Something to look at later as well.
Linpeas also noted that Mysql service is running locally on port 3306.
Linpeas also found what may be database credentials to the Wordpress db.
The first thing I will do is to see if I can find low hanging fruit. Based on the information gathered by Linpeas, I’ll work on the vagrant account and see if it’s using default credentials. Based on the Vagrant documentation, the default credential is username vagrant password vagrant.
When I tried to switch user to Vagrant, I got an error that the su cant be run from the terminal. So I need to change the terminal before I can try to run su.
Reviewing the output from Linpeas under useful software section I did find that python3 and Perl were installed. Ill try spawning a TTY shell with python3.
Reviewing the output from Linpeas under useful software section I did find that Python3 and Perl were installed. Ill try spawning a TTY shell with python3. If you need to figure out the command needed to spawn a TTY shell you can visit the Payload All the Things Github page. Under Methodology and Resouces / Reverse Shell Cheatsheet.md it list several options to spawn a TTY shell.
I first ran bash -i for interactive just more for cosmetics, I want to be able to see the user and hostname in the prompt.
python3 -c 'import pty; pty.spawn("/bin/sh")'I then ran the Python3 command I got from Payload All the Things and I received no errors. To verify it worked, I ran su vagrant and I got prompted for a password, which is a good sign, as I didn't get an error like I did earlier. Sure enough, it looks like the vagrant account used the default credential of vagrant, as is found in the vagrant documentation I found earlier.
I ran sudo -l to see if the vagrant account has sudo privileges and it looks like it has sudo privileges for all.
I figured I’ll see if I could change the root account password, by running the sudo passwd root command. I got prompted to enter a new password, I entered vagrant. I get prompted to retype it. I got a message that the password was changed successfully.
To verify I run su root to switch users to root. I get prompted for a password and I enter vagrant. Sure enough, I now am root.
I changed directory to /root.
I run the ls -la command to view the contents of the directory and I can see the proof.txt file.
I cat the proof.txt file to get the hash.
I entered the hash into the Offsec PG console and I have completed this host.
<CONCLUSION>
In conclusion, using a variety of techniques I was able to go from reconnaissance to gaining root privileges on the target host. Performing these steps allowed me to gather the information I needed in order to gain a foothold on the target host through the use of arbitrary file upload on the web application. Upon gaining access, performing further enumeration allowed me to find a workable escalation path to root by abusing default account credentials and security misconfiguration in sudo, in order to gain the final flag.
Thank you for checking out my blog post demonstrating the exploitation of OffSec Proving Grounds Blogger 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
Comments