Mr. Robot:1 – Vulnhub Writeup

Source: https://www.vulnhub.com/entry/mr-robot-1,151/

After spinning up the VM I’m met with this logon prompt:

I then run “netdiscover -r 192.168.111.0/24” to find the IP assigned by the host adapter via DHCP:

A generic NMAP scan yields 3 listening services:

Browsing to the site http://192.168.111.100 yields a cool animation sequence and some interactive command options.

Running through the command options I’m presented with videos clips and other content from the show, but if there are any clues I’m not seeing them quite yet.  We’ll fire up dirbuster to see if we can find any interesting site content that isn’t obvious:

Using “directory-list-2.3-small.txt” as the wordlist and letting it run for a few minutes I can already see some interesting things to check out.

Navigating to */RSS/index.php and we can see this is “Just another WordPress site” so let’s try navigating to that wp-login.php!

I tried a few login/password combos like test/test, admin/admin, mrrobot/mrrobot, but no luck with those.  I did notice, however, that the error message is kind enough to return whether or not a login ID is valid which means we can potentially brute-force ID(s).

But while I’m here I might as well try the “Lost your password?” function too.

Appears to be a similar deal.  Can probably brute-force username or email address from the page, but not having much luck with any common user name combos I can think of.

Going back to Dirbuster I’m not seeing much else of interest I can interact with right now, so let’s do a Nikto scan of the site any see if it can spot any vulnerabilities.

Looks like a handful of good leads here.

Unfortunately also a few dead ends:

https://192.168.111.100/admin leads to a site with source code of

<!--
\   //~~\ |   |    /\  |~~\|~~  |\  | /~~\~~|~~    /\  |  /~~\ |\  ||~~
 \ /|    ||   |   /__\ |__/|--  | \ ||    | |     /__\ | |    || \ ||--
  |  \__/  \_/   /    \|  \|__  |  \| \__/  |    /    \|__\__/ |  \||__
-->

https://192.168.111.100/readme gives me:

And looking at https://192.168.111.100/license.txt I get me a little sass:

BUT heading over to https://192.168.111.100/wp-links-opml.php I do get a conveniently generated comment with WordPress version which I can hold onto for later if I need it.

<!– generator=”WordPress/4.3.1″ –>

And navigating to https://192.168.111.100/robots.txt gives me these juicy tidbits!

A simple WGET for both and I have the first flag!

073403c8a58a1f80d943455fb30724b9

Opening fsocity.dic up in Nano gives me 858160 lines.  I can only assume this is to be used with a dictionary attack against the WordPress logon!

Using this as a guide I configured my browser to use the Burp proxy and tested logging into http://192.168.111.100/wp-login.php with the user ID “testuser” and password “user” so I could easily decipher the HTTP POST request.

So let’s gather the values we need to plug into Hydra:

Username Wordlist: fsocity.dic
Password Wordlist: No list for now as we’re just bruteforcing the login ID so we’ll just use “password”
Form Type: http-post-form
Username Field used in Webform: “log”
Password Field used in Webform: “pwd”
Login Failure Message: “Invalid username” (this can be found in the “Response” returned in Burpsuite for your wp-login.php request)

hydra -L ~/fsocity.dic -p password 192.168.111.100 http-post-form “/wp-login.php:log=^USER^&pwd=^PASS^:Invalid username” -V

It’s plugging along pretty efficiently on 1 core so I check back in 15 minutes to see the results:

3 successes for what looks to be a non-case-sensitive login ID of “elliot”.  Let’s go back to the WordPress login page and try out the ID.

Now that we’ve confirmed we have a working login ID we switch our Hydra command around to now bruteforce the password.  Note the new response message of “ERROR: The password you entered for the username ELLIOT is incorrect. Lost your password?”.  We’ll truncate this down to just “The password you entered”.

New Command:

hydra -l ELLIOT -P  ~/fsocity.dic 192.168.111.100 http-post-form “/wp-login.php:log=^USER^&pwd=^PASS^:The password you entered” -V

Time to grab another cup of coffee…

And ta-da…

Let’s go ahead and log in.

Lots of pictures in the Media section, 11 installed (but inactive) plugins, and interestingly looking at the Users tab we find another user that wasn’t enumerated from the initial dictionary attack.

Let’s use our admin powers to reset the account password and see if she has anything interesting stored in her profile.

Unfortunately it appears to just be a red herring.  Not much to see here aside from some options to change her profile details.

I’ll try using Weevely to generate a simple PHP webshell to upload to the site as Elliot again:

Sadly I’m unable to upload the file through the Media Uploads screen and get an “Error saving media attachment.” or “Sorry, this file type is not permitted for security reasons.” message when attempting through single/multi-file upload options.  Checking the destination path I confirm the shell was not successfully uploaded.

Let’s see if I can upload the shell as a plugin instead.

Doesn’t look very encouraging at first until I navigate back to the Media Library and there it is!

Let’s try connecting to it with Weevely and see what we get.

And then using the built in “:audit_etcpasswd” command I get:

One by one trying the paths of interactive IDs listed I get permission denied except for the last one:

There’s the 2nd flag! But no permissions to it… we can however see the hash for robot’s password:

Using the lazy man’s password cracker we get a result right away.  The password is: abcdefghijklmnopqrstuvwxyz

Having issues with the Weevely webshell’s built in su commands (if anyone can give me tips feel free, I’m sure it’s a simple syntax problem) I ended up giving up and just using a basic netcat reverse shell instead.

Set up listener in Kali:

Navigated to /usr/share/webshells/php and made a copy of the “php-reverse-shell.php” prior to uploading the new webshell.  Edited the file to set host and listening port, then uploaded it again through the Plugins tab in WordPress.  Link generated is now http://192.168.111.100/wp-content/uploads/2017/08/php-reverse-shell.php

Navigating to the site I get the connection right away.

When trying “su robot” I’m again getting the message “must be run from terminal”. Some quick googling gives me the answer (again, no idea why this didn’t work in previous shell):

There, finally successfully logged in as robot!  Now I can dump the contents of key 2:

With no other clear clues on where to go next I’m guessing we will need to figure out a way to get root access on the server and probe around for the 3rd key.

Checking the Linux release + version I come up with this:

Some quick googling and I find a good contender for possible privilege escalation with this version: https://www.exploit-db.com/exploits/37292/

Hating myself for having to use VI I create the new file exploit.c in /tmp/ copying over the source code from the site, compile, and attempt to run it:

In the dark about what exactly went wrong….let’s try another exploit from: https://www.exploit-db.com/exploits/42275/

Copying again to /tmp/ and naming this new file exploit2.c I try to compile using GCC and get an error for one of the included libraries:

At this point I’m starting to feel like I’m spinning my wheels a little.  I check running services, I check /usr/bin and poke around there.  I do find an interesting program called “fakeroot” when I run and it gives me the root prompt but no extra privileges (sadly).  I try doing finds for any sort of key files but nothing comes up.  Interestingly netcat is installed and nano but nano is inaccessible because the author hates everyone (presumably).  Note to self: don’t run the yes application. /bin/ has some interesting things but nothing really jumps out at me yet.  Netstat doesn’t show much interesting except what is related to WordPress.  I check /usr/sbin/, I check /usr/local/bin….wait, what?  NMAP is installed?

Searching NMAP exploits I come across a tidbit partially down the page here.  By running NMAP in interactive mode if we’re lucky it’s maybe the older version that is vulnerable to this attack and lets us escalate to root.

It definitely is!  Also note the wise-ass URL modification.  🙂

Dropping into a shell I check my ID permissions and look at that, I’m at root permissions now!  Let’s naviate to /root/ and poke around.  And there’s the last key!  Had a lot of fun with this one.