pwn0sv2 is version two in the pwn0s series (?), and can be found here at our good friend g0tmi1k’s pentest page. I previously did a write up on the first version of pwn0s and enjoyed it, so I was excited to see there was another version available. Forewarning: obvious spoilers.
The zip comes packaged with a README with your standard disclaimer/info affair, along with the static IP. 10.10.10.100 is the set IP address. I set my BT5 onto the 10.10.10.1/24 subnet and did a quick scan of the box:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
There’s that pesky OpenSSH Debian build; we could try hunting for weak keys, but that looks to be a newer version of OpenSSH and likely not to be susceptible to that vulnerability. Nonetheless, it may be worth keeping in mind as we move forward. Here’s a link to the old advisory for the curious.
There also appears to be an HTTP website up. Browsing around that gives us a couple of forms; /login.php and /register.php. With so few services open, I’m given the impression that this is going to be a web vulnerability. First thing I do in almost every registration field:
And low and behold, we’re vulnerable to SQLi. And away we go.
After playing around with the UNION SELECT’s, it finally settled on 8 columns and 4 being the displayed one. So
' UNION SELECT 1,2,3,user(), 4,5,6,7,8;-- -
If you try that, you’ll notice you can’t actually stick the entire thing into the login box. Busting Burp open will fix that:
Which gives us:
Fantastic! This means that the mysql daemon is running as root user. That makes our SQLi attacks much more dangerous; UDF is now available to us. Lets explore the system a bit more.
1 2 3 4 5 6
Looks like they’re at the very least escaping slashes. No problem:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Hm, looks like we can’t hit /etc/shadow. Weird. Lets move on to rapidly enumerating the back end. I switched over to sqlmap to give more info on the backend. We already know the vulnerable form, we know the POST format (from our Burp session), and we know the database (from UNION queries above) so lets plug that in for some interesting stuff.
1 2 3
One table. Let’s check it out:
This gave me a single user, ‘Dan’, with a user level 0 and his hash:
I let sqlmap run its own cracker against the hash, then dumped it into oclHashCat:
cudaHashCat-plus64 -m 300 -a 3 -n 50 --gpu-watchdog=100 --force hash.txt ?l?l?l?l?l?l?l?l
I then dumped database users to see what was there, and what the hashes were (assumed sha1(sha1(pass)), but you never know)
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Pretty much what I expected. At this point I figured the next best thing to try, with my root privileges and all, is UDF injection. If you’re unfamiliar with UDF’s, here’s a very brief breakdown: a user defined function is a way to extend the functionality of a database by providing a function that’s able to be evaluated by the backend database server. In our case, we want something akin to an eval() or exec(). This can be done with the lib_mysqludf_sys library. If you want more information on UDF injection, read this fantastic paper from BlackHat 2009 by Damele.
Our attack method is then this: upload the precompiled library into the MySQL plugin directory, create our custom function, and execute some good stuff (passwd, addusr, whatever). I first needed to know where the plugin directory was. A quick google of MySQL system variables gives us an answer:
Now we just need to write our library there and create the functions:
1 2 3
The final SELECT there does not return our newly created function. According to MySQL documentation, we need INSERT privileges. Do we have them?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
It appears we do. In fact, it doesn’t seem we have write access to anything; we can’t even INSERT into any tables. We’ll come back to why this doesn’t work in a bit. For now, I threw a reverse PHP shell on the box for more control. I used pentestmonkey’s great php-reverse-shell, and soon enough had a prompt:
I’m going to cut out a lot of my trial/error in finding some of this stuff, but note that there is a blog in /var/www. This provides Simple PHP Blog, which just so happens to be vulnerable to LFI; so there’s another attack vector for the reverse PHP shell. Also note the mysqld is listening on 127.0.0.1, which rules out that complex exploit David Kennedy wrote. Not to mention we’re not in a real term.
Note that there are no privilege escalation vulnerabilities for that kernel or for that Ubuntu distribution. MySQL does not appear to be UDF-injectable, and even though it’s telling us we’re root@localhost, we simply don’t have it. It is also worth nothing that an attempt to drop a shell script in /etc/cron.d/ and adding a cron entry got AppArmor a bit upset.
My next step was to see if there were any vulnerable binaries uploaded.
This dumped modified files by date, so newest at the top, oldest at the bottom. After getting through all the modified /proc’s, I noticed this monster: fakeroot. Essentially this emulates a root environment but only allows certain file manipulations. It can be used to run daemons in an environment that’s root-like, but not. This had to be why my MySQL UDF attempts were not working. Moving on down the list, I noticed another file: /var/mysqli_connect.php. Weird, what’s a PHP file doing in var?
1 2 3 4 5 6 7 8
Oh. That’s…it? Really? Knowing that root was permitted to ssh in, I quickly gave it a shot:
Yup. That was it. I suppose the idea here is that incompetent developers can hard code root passwords into arbitrary PHP files laying around the system, but it just seems like more of a scavenger hunt in the end. I was really hoping there was some obscure vulnerability in a binary, or some fun MySQL UDF injection I could’ve done.
All in all, fun, but once you’ve got a shell its an exercise in frustration. Can’t say I didn’t learn anything though.
Note: If you’re running BackTrack5 and need certain VirtualBox features (bidirectional clipboard, shared folders, etc.), you’ll need to prepare kernel headers first. Follow these instructions before installing Guest Additions. If you’ve got it installed, just reinstall them. You’ll know it’s successful if you don’t get ‘could not find kernel headers’ errors.