In this post, I will be doing the walkthrough of the vulnhub machine Blogger 1. Please follow this writeup till the end to boot to root. Also, this machine works well in virtualbox.
Link to the machine: https://www.vulnhub.com/entry/blogger-1,675/
Identify the target
Firstly, I had to identify the IP address of the target.
sudo netdiscover -i eth0 -r 10.0.2.0/24
As the instruction says, we have to add the IP in the /etc/hosts file.
sudo vi /etc/hosts
Scan open ports
Then, I had to scan for the open ports on the target.
nmap -T4 -sC -sV -p- --min-rate=1000 10.0.2.28 -oN blogger1.nmap
Enumerate webserver
Since port 80 is open, I had to enumerate more on the web server.
dirb http://10.0.2.28 -w
In a directory inside assets/fonts we have an installation of wordpress blog.
Enumerate wordpress
Then, I used wpscan to identify vulnerable plugins.
wpscan --api-token=$WPSCAN_KEY --url http://blogger.thm/assets/fonts/blog --plugins-detection mixed -e
Here, we got an unauthenticated arbitrary file upload vulnerability in a plugin wpDiscuz. Hence, I followed the links to find the proper payload.
Uploading shell using the vulnerability
The vulnerability allowed to upload any file type regardless of the restrictions to upload the image files only. So, to do that, I opened a post where we could use comments section to invoke the vulnerability. Before that, I opened burpsuite which listens on port 8080 for proxy. Similarly, on my browser, I chose my proxy on the port 8080. For that, I use foxy proxy extension. Then, I uploaded a normal png file that is of less size.
Next, I chose a PNG file. As soon as I selected the file, the browser sent the request to the burp suite proxy. Here, I had to inject the web shell inside the PNG’s data. Also, I had to change the extension to PHP so that I could execute it from the browser. Also, in the webshell I have used my usual port 4444. Thus, I will be listening on the port first.
nc -nlvp 4444Now, back to burpsuite.
Here, you can see that I have changed the filename to shell.php because I had originally downloaded a png file. Next, I have injected the shell in between the code, because the application validates EXIF headers first. Finally, I forwarded the request and checked the last post request.
If you see above, the upload is successful and we got a URL that we can visit to spawn a reverse shell.
curl http:\/\/blogger.thm\/assets\/fonts\/blog\/wp-content\/uploads\/2021\/06\/shell-1623416616.8045.phpAfter this, I got the reverse shell.
Then, I did the regular task to spawn a pty shell.
After that I sent the shell to background and used stty commands to get the complete shell.
# Ctrl + Z
stty raw -echo;fg
reset
stty cols 173 rows 43Getting user’s flag
Now that we have a proper reverse shell, we can try to get access to a user. Hence, I decided to look for the users.
cat /etc/passwd | grep bash
Then, I took a visit to the users’ home directories and found out that we have to get the flag from the user james. Likewise, I did Linux enumeration and also ran pspy to inspect any cron jobs. However, nothing worked. I will provide a summary of the rabbit holes.
There is a file .creds in /opt directory which is simply a gibberish data. To verify it, I pasted the data in the cyber chef application.
From the results above, it doesn’t look like there is a hidden message on that text. Likewise, there was a file which was showing a possibility of tar wildcard exploit. However, we didn’t have access to write to the directory.
As you can see, the script will first change the working directory to james and creates a backup from all files of that directory. Since, the directory is not writeable by www-data, we couldn’t exploit it.
Now, I tried guessing the password. So, while doing that, the user vagrant had the same name as his password.
su vagrant
When I looked at sudo permissions of the user vagrant, I found out that the user doesn’t require password to execute anything on anyone.
sudo -l
Hence, to get the flag I used the following command.
sudo su - james # just to get the shell of james
cd
ls -al
cat user.txt && echo
cat user.txt | base64 -d && echo
Privilege escalation to root
Finally, I could use the same technique to get the root shell.
sudo su
cd /root
ls -al
cat root.txt && echo
cat root.txt | base64 -d && echo
Conclusion
I particularly don’t like to guess things because when it comes to guessing there are innumerous possibilities. Suppose, if the author decided to have used an extra letter beside ‘vagrant’, then it would have been impossible to guess. However, this one wasn’t bad because he used a common mistake that most users commit. However, I think it would have been better if he had provided some encrypted message to crack the code. A machine for beginners shouldn’t have rabbit holes.
