Owl Up in My Grill
So, while we were all sitting in #vulnhub (on Freenode) waiting for superkojiman to release Persistence, Swappage released OwlNest. I thought, what the hell, might as well use it to pass the time, right ? I was, however, not expecting it to take me 4 days…
Were You Born in a Barn (Owl) ?
A quick dig around using NMAP
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 |
|
Looks like there’s a banner on port 31337, might as well get all of it, and see if the service behind it is vulnerable to format string.
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 |
|
This looks like something we’ll need a username and password for. As none are known, this port is being ignored for now. Port 80’s where it’s at then.
The Register link allows us to create a new user, which we can use to log in and look around
But it seems we’re not allowed to use the Upload feature, because we’re not “admin”. An interesting point to note here is that the URL for the Upload feature is http://172.16.56.131/uploadform.php?page=forms/form.php, which means we could possibly leverage it for LFI. No other links on the site work in this way.
Looking at the source for the registration page, it seems the username is capped at 16 characters.
1 2 3 4 5 6 |
|
Could we cheat the system and register a user with the name “admin” and then add 11 spaces after it plus a random character ? We can assume that the registration form will truncate any characters over 16. Tamper data is our friend here - the form can be filled in with the username of “admin” and then intercepted with Tamper data (or Burp, if you want) to modify the username POST variable to “admin a” and submitted.
Once this malicious user is created, it is possible to then log in with the username of “admin” and the password we set for “admin a”.
Which allows access to the Upload feature (not that we’re going to use it for it’s intended use)
This is a Hoot !
The upload form posts to /application/upload
1
|
|
Which when called with no arguments shows the following
It is possible to browse to the application folder, which shows that the application is actually 601kb - a bit much just to parse an upload form.
Owls Well That Ends Well
The uploadform.php page can be used to provide us with a base64 encoded copy of the upload binary, which means it will not be parsed or executed.
With the binary now available offline, we can go about working out what it does. It’s a CGI binary, so we can interact with it via the command line using the QUERY_STRING environment value. Lets set something really simple first. I’ve purposefully not included any GDB stuff here, as an excuse for you to work it out and learn :)
1 2 3 4 5 6 |
|
It is possible to overflow this application via the email variable, which through some further investigation identifies that EIP is at offset 277.
1 2 3 4 5 6 |
|
gdb-peda can be used to find a jmp esp call, which is at 0x80c75ab9. This is what we’ll set our EIP value to, which should hopefully jump to our bind shell shellcode. This can be completely exploited as follows
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
Once a public key is added to authorized_hosts, we can SSH in and obtain a full TTY shell.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
There’s one application available in /home/rmp, and that’s the application that is listening on port 31337 (the one that requested username and password etc).
1 2 3 4 |
|
which when straced, shows that it is reading /root/password.txt to check the provided credentials.
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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
|
However, by pure chance, in this particular attempt, I tried to overflow the privs command, and as you can see, it seems the application is attempting to open AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA before the password file. Can we use this to make the application open a file containing a password we control ? Yes, yes we can…
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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
|
As you can see here, it’s cut off the first 16 characters of our priv input, and is trying to open “rd.txt”, which doesn’t exist. Therefore we have to pad the privs input by 16 characters.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
So, all we need to do now, is write a file to /home/rmp containing a password, and make the application read it instead of /root/password.txt.
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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
|