“Senda” is the second Boot2Root in the Hackfest 2016 series by Viper . This one was a bit more difficult and in the end the box ended up tanking. I was still pretty happy with the progress I got on it though and it’s always good to work on my privilege escalation skills.
Let’s Get To It
I downloaded the .ova and spun it up in VMware. Looked similar to the last one in that it just gives you the IP right off the bat.
Kicked off an Nmap scan to see what I’ve got. The results again seemed just like the last one; an apache server, a mail server, and Samba. The only addition of note was the Tomcat server sitting on port 8080.
I take note of everything, but continue with the same methodology that worked for me on the last one. I browse on over to the web server on port 80 and am met with pretty much the same stuff from Quaoar. Checking the robots.txt this time though doesn’t yield anything of interest.
Since I’m not getting anything easy, I start a Nikto scan and see if I can find anything worth pursuing. The results yield two things of interest; /files and /license. I browse over to both and check them out.
Well there’s something! Looks like it’s running BuilderEngine. I do a quick search for any good looking exploits. I find one that allows arbitrary file uploads; I’m immediately thinking of a php reverse shell like I used last time. The exploit is a simple HTML page; you just need to change the URL to point to your target box and voila, you can upload files!
I tried using a PHP web-shell that I’ve used previously, but it didn’t want to work for me. Thought about it for a second and decided to use the PHP shell available from Pentestmonkey. Uploaded the new shell through the same HTML page exploiting BuilderEngine and I was able to get a working shell!
I leveraged this shell for what I could get out of it; some digging around the file system (to what I could access) found me the first flag in /var/www.
Sweetness, so we’ve got our shell and our first flag. I don’t have Root access though so I need a way to escalate my privileges. Taking a note from my previous post on enumeration and escalation, I start to enumerate the system as much as I can (limited since I can’t access everything with my current permissions).
No easy kills… Damn. I spent about an hour digging through some of the services I saw and still wasn’t coming up with much. I did get a bite with the Linux version though, since it was a bit outdated. I came across a local privilege exploit leveraging CVE-2015-1328 (overlayfs). I spent another hour on this one trying to get it to work and came up empty; so back to google it was.
Seems like other folks had similar issues and I found a forum post that discussed a newer privilege escalation exploit that seemed promising. I copy it over and get to work on it. To get it over to my target box I spun up a SimpleHTTPserver on Kali and tried to wget it from my target shell.
Well crap… I had to spend a minute on this one to figure out what the problem was. The connection was fine, it just seemed like a permissions issue. After taking a break for a while and coming back to it, I realized what the problem was. I was trying to write a file to a directory that I didn’t have permissions for; I needed to be downloading it to a place I had permissions to write to! I CD’d over to /tmp and tried again… Success!
*I also forgot to elevate out of the jail-shell, so I used python -c ‘import pty; pty.spawn(“/bin/sh”)’
Once I had dirty.c on the target machine I needed to compile and run it. With my elevated shell I didn’t have any issues getting that part out of the way, but this is where the easy part ended…
So a little background on this exploit (CVE-2016-5195); it’s a race condition that basically writes to a copy of a file that root owns (aka one we don’t have permissions for). In this case, we’re writing a new entry to /etc/shadow in order to add a new root user.
Without getting super into the technical details, the basic thing I want you to understand is that we’re messing with memory is a weird way. That’s important to know because doing weird things to memory is a surefire way to make the system start doing weird stuff.
So with that in mind, I did manage to get the exploit to work, add a new root user to the target system, and connect via SSH as that new root user.
…as you can see I started to type a command once I had my shell. I got stopped because the target box got bricked. I thought to myself “oh well this is probably just a one-off. Exploits can cause all kinds of weird stuff to happen“. I restarted the boxes and went through the process again; same result. A few tries later, still no dice, and now on top of that, networking services on both the target box and my Kali machine have stopped working…
So I’m starting to think that the problem is part exploit related but also part VMware related. I’ve seen some of the CTF VMs that get a little touchy when ran on VMware rather than VirtualBox, so that might have something to do with it.
Either way, I feel pretty good about how far I got with this thing. The exploit for BuilderEngine was done in a way I’ve never seen before and getting the DirtyCOW exploit working was a lot of fun. It required more thinking than just “find an exploit, run the exploit“. I’m bummed the system wasn’t stable enough to continue, but I was able to get multiple shells and eventually create a root user. Not bad!
If I get some time later I might give Orcus a shot. It seems these VMs might be a little temperamental on VMware so we’ll see. If not though there are still a myriad of options available, so I won’t have to look very hard for the next challenge.
Thanks for reading!