This VM is based off of the TV show Mr.Robot and features a cool website and an overall fun VM. I actually spent more time on this VM than any other one so far just because of the multiple avenues there were to exploit this machine. After reading other write-ups I found out I did it a different way than most people. Here’s how I solved Mr.Robot:
A scan of it shows port 40 and 443 open.
Going to the site shows a really cool interactive site but nothing comes out of it.
Viewing the source shows a message saying “You are not alone”
I then checked for a /robots.txt and found directories that had files: fsocity.dic and the first key (out of 3) in a .txt doc.
I downloaded fsocity.dic and then the key.
When going to the fsocity.dic page I made a typo and correctly spelled fsociety.dic which led me to a wordpress page.
Running WPScan showed several vulnerabilities (mostly XSS), including a privilege escalation exploit and information disclosure.
I kept that in my back pocket and then tried a Nikto and dirbuster scan to see if there were any more flaws in the site or hidden directories.
The only thing of interest was the WordPress login page.
This version of WordPress was susceptible to a bit a of username fuzzing. When entering a username and password, it will tell you if your username does not exist or not. Example: Logging in with the username ‘mrrobot’ and password of ‘a’ says invalid username.
If this application were secure, it would say invalid username or password, not just username, as now we can enter in possible usernames and it will tell us if they exist or not. After a few tries of entering usernames, I tried elliot (the name of the main character on the show) which gave back the message saying invalid password.
So elliot is a confirmed user. I then threw the dictionary at it with the dictionary file ‘fsocity.dic’ I downloaded. WPScan has a brute forcing feature that allows you to brute force passwords on the WP login page. The command I used was this
wpscan -u http://192.168.1.180 --wordlist /root/Downloads/fsocity.dic --username elliot
I stepped away for a bit to let that run and came back to see it successfully found the password!
Next is to pop a shell on the box. So I had an idea of what I wanted to try and when I tried it, it failed and after working tirelessly to try and get any exploit to work to pop a shell, it would not work. It turns out my ESXI Firewall was blocking the port I was trying to communicate over! Stupid mistake, I know, but just a reminder that if you’re using ESXI to host your VMs like I am, to turn off the firewall or open up the ports.
So my idea was to download any vulnerable plugin (which can be found via searchsploit WordPress | grep plugin), in my case I downloaded slideshow-gallery version 1.4.6, and just add a directory with a .php shell. The .php shell I used was the one found here. Make sure you open it up and edit the port and IP address to your machines IP and whatever port is, like mine show below.
The reason I downloaded a vulnerable plugin, because this can be done with just any plugin, was that I wanted a fallback exploit in case this didn’t work.
With the plugin downloaded, I unzipped it and added my .php shell to the folder.
I then zipped the folder back up, uploaded it, and activated it.
With is successfully uploaded, now I had to start the ncat listener on my machine via
ncat -lvp 8888
Then I browsed to the directory that had the .php file.
Now it was time to escalate my privileges.
First things first, let’s check a few things.
So I know the kernel version and that gcc is installed, meaning if there’s a kernel or OS exploit, I could compile code and run it. I decided to explore a little more, which I then found a username and hashed password in the home/robot directory
I then tried to switch to robot but wasn’t in a TTY shell, so I used python to spawn one
python -c 'import pty; pty.spawn("/bin/sh")'
Next I navigated back to the home directory and read the second key (I couldn’t read it before as daemon)
service apache2 restart
to start the apache web server. It looks like this now when I go to my machine’s IP.
From my shell on the target machine, I then fetched the script via wget from the /tmp directory
I then compiled the exploit (it gives some errors when compiling but it still worked)
gcc -o dirtycow 40616.c -pthread
and then ran it
It worked almost immediately. After that I tried to go to the /root directory but the system crashed. That is the nature of the dirtycow exploit — it’s very unstable. So after doing that all over again, I attempted to move to the /root directory
And I was done!
So after I went back and tried dirtycow just as daemon and it worked as well, but it was key to spawn the TTY shell via Python, otherwise it wouldn’t work. I actually spent more time on this VM than I did the other ones I’ve done so far just because of the amount of exploits that the kernel and OS were susceptible too, I made it difficult on myself by jumping straight to those instead of just doing simpler things first.