tryhackme - mr robot ctf

https://tryhackme.com/room/mrrobot

This challenge was a lot of fun despite the fact that I don’t really care for the TV show; I made it to the beginning of the second season before losing interest.

¯\_(ツ)_/¯

Scanning

The first thing to do is scan the remote host. First, a basic scan of all ports and then a second, more detailed scan of the results from the first.

Knowing what web server application is running is an important tidbit of info though it didn’t come into play with this particular challenge.

Now that we know the target is running a web server we should do a directory brute force scan to see what’s available. You can use dirbuster or dirb but I like to use gobuster.

Similar in concept to password brute forcing we are taking a list of words contained in a file and using them as search queries against the web server. If it returns a 20x or 30x status code then we know something is there.

Below is a breakdown of the syntax:

gobuster: launches the app

dir: tells the app to use directory scanning mode

-u: the url to scan

-w: the particular wordlist to use for scanning

The results highlighted in red are worth checking out first, though some of the other ones were…entertaining

The Happy Path

While we are waiting for gobuster to do it’s thing we can browse the site and check it out for ourselves. Our goal here is not a deep technical analysis but more what’s known as “walking the happy path”. Basically we just explore the site, visit pages, click on buttons, menus, whatever we can find to try and understand the “normal” function of the various pages.

The home page is simply a menu system for showing content from the show.

Feel free to enter any of these commands - they will take you to various clips or images from the show but they will not help you with the ctf challenge itself.

As you dig a little deeper, using results from gobuster as they come in, you mostly hit dead ends. They are occasionally funny but keep in mind that as you are browsing you should still be checking the source code of each page to look for clues, intentionally placed or not, that could help you.

After we’ve poked around a bit we can settle in and start following the progression that the challenge creator clearly had in mind.

The robots file has two leads, one that takes you straight to the first flag and another that leads you deeper into the challenge.

When you browse to http://<ip-address>/fsocity.dic you are prompted to open/download a file. Keep this in your back pocket as we will use it in just a bit.

One of the results from our gobuster scan was /wp-admin so that should definitely be in our list of things to check out.

As part of our enumeration methodology we try something like username admin and password admin to see what happens. — As part of our enumeration methodology we try something like username **admin** and password **admin** to see what happens.

So “admin/admin” doesn’t work, no surprise, but notice what the error message says - “invalid username”.

A more secure application would obfuscate which part of the login didn’t work by saying something like “username or password was incorrect”. By telling us that the username is invalid the application is inadvertently giving us a thread to pull ourselves along.

So what is a valid username? The CTF itself is inspired by the TV show “Mr Robot” and the main character’s name is Elliot (even if I didn’t know that already from watching the show it is easy to search on the internet) so let’s try it.

The goal here is to enumerate the username specifically so go ahead and use any password you like.

Bingo! The application confirms that it has an account named elliot but we didn’t give it the right password. That’s ok, we have ways of dealing with that particular problem 😉

Password Brute Forcing

There are several tools to use for this kind of thing and I will go over two of them here - the one that got me in and one that is equally effective but takes much longer and thus I cut it short.

Do you remember that file called fsocity.dic that we downloaded earlier? If you take a look at it in a text editor (or the command line) you will find that it is simply a wordlist. Presumably one of the words in this file is the password to Elliot’s wordpress account.

If each word is on a line by itself and you do a line count of the file you will see that there are 858,160 words.

That’s a big file and there are probably duplicates in there so let’s see if we can trim it down some.

You can use the sort and uniq commands to…sort and remove duplicates.

Side note: in order for the ‘uniq’ command to detect duplicates in a file they must be adjacent to each other which is why the ‘sort’ command comes first.

(Also, be aware that there are different ways to do this)

Much better!

WPScan

There is a useful tool that comes bundled with Kali called WPScan. It is primarily a vulnerability scanner for WordPress sites but it also happens to include password brute forcing functionality.

Here is the syntax breakdown:

wpscan: launches the app

—url: specifies the full URL that you want to scan (dont forget the ‘http’)

-t: the number of simultaneous threads to use, I chose 50 in this case

-U: the username to use (good thing we enumerated that earlier, eh?)

-P: the password file to use

It took less than a minute to crack but would have taken longer had we not trimmed the duplicates out of the password file.

Burp Suite (the slower way)

I’m assuming you already have a passing familiarity with Burp Suite, if not then please see their documentation here.

The primary reason this method is slower is because I am using the Community version of Burp. This version is free for all to use but has it’s performance throttled as a result.

Before you start make sure you have your proxy settings in place. Launch Burp, making sure that intercept is turned on, and then refresh the WordPress login page.

On the Proxy tab in Burp you should see the login request…

…so right click on the page and send the request to Intruder.

Click on Intruder -> Target and verify that the IP address for the remote target is correct

Next go to Intruder -> Positions. See all the fields highlighted in green? We need to clear those out so look to the right hand side of the screen and click the Clear button.

See where is says pwd=password (it might be different for you depending on what word you made up when you were enumerating the username a minute ago). Select whatever word you put in for the password and click on the Add button.

The password should now be highlighted in green and bracketed by two section signs.

Next go to Intruder -> Payloads and scroll down to Payload Options.

Select the file you want to load…

Make sure you choose the sorted file, NOT the original

All the words in the file will get loaded and you will be able to see how many total will be used for the attack.

When you are ready go ahead and click the ‘Start attack’ button on the right side of the screen.

If you are using the Community version of Burp you will get a pop-up letting you know that your punishment is to get your attack speed throttled.

I’m joking here 😉

Burp is a fantastic tool and I don’t begrudge the developer in the slightest for nudging people to the paid version - especially when the free version is still so great.

What we’ve done is configured Burp to use the wordlist we gave it as input and to automatically resubmit login requests to the WordPress site as it iterates through all the passwords.

If you click on one of the requests you can see how the payload is substituted in the client request…

…as well as the subsequent server response (click the ‘Response’ tab).

Notice how the status shows a 200 OK?

That’s because technically the request succeeded…it’s just that the server rejected the password as incorrect. It sends back a legitimate response letting the client know that the login request didn’t work.

So how do we tell if/when our attack actually works?

The most straightforward way is to compare the length of a failed request to one that succeeds. See how all the failed requests have the same length of 4112? If you click on the Length column you can sort it by ascending and have the successful request show at the top of the list (this assumes a successful request would have a different length than a failed one).

Another way is to configure Intruder to grep for particular words or phrases in the server response and display those in the results.

Since I already got access via the WPScan method I didn’t bother to finish the Burp attack and canceled it.

We now have access to the admin dashboard!

Getting a shell

The question now becomes, “how do we leverage our access to the web application to gain access to the underlying server?”.

One solution is to hack the application to send us a webshell when we browse to a particular page, in this case the default 404 Not Found response page. To do this we need two things:

Knowledge of how to set up and/or modify a 404 response page in WordPress
Webshell code that can be served from said page

A bit of quick searching turns up this helpful article on how to edit or create the default 404 page in WordPress.

As it happens, Kali conveniently includes code for several different webshells based on the platform. We pick the one we want and make a copy so we can customize it for our purposes.

If you want a bit more of a deep dive into how to use this particular script you can go here.

We aren’t doing anything fancy, we just want to point the reverse shell to our local machine.

After we customize our webshell with our local IP address we copy all of the code and paste it over top of the WordPress code and update the file.

Next we set up our local listener to catch the webshell…

We browse to a non-existent page on the website…

Nothing happened?

Check your local listener.

We now have a raw shell on the target server.

Raw shells are gross and we want to get out of them ASAP so we use python to switch into a proper terminal.

Looking Around

A lot of Linux systems are configured to display the current working directory at the terminal prompt and based on ours we can see that we are in the ‘/’ root directory. Not to be confused with the /root directory which is the home directory for the root user.

If we peek into /home we can see there is a local user account called ‘robot’. If we peek further we can see two files in that user’s home directory with one of them being the next flag. Unfortunately it seems that only the user ‘robot’ has permissions to read that file.

What to do?

The second file is interesting not only because it’s called ‘password’ but also appears to be world-readable. If we take the filename at face value it looks like it is an md5 hash of the user’s password 🤔

Hash Cracking

In another blog post I covered in detail some different hashing schemes and how to crack them so go ahead and check that out if you are interested.

Md5 hashes are trivial to crack.

Now that we have the password we can su to the robot user and grab the next flag.

Flag #2 hint: After finding the actual flag I still do not understand the reference here.

Privilege Escalation

The last flag for most CTFs is almost always in the /root directory but only the root user has access to that directory. A very common way of escalating privileges on a Linux system is to look for binaries that have the SUID bit set and abusing them.

Identifying which one to use generally comes down to experience and practice. In this case one of the challenge hints tersely says ‘nmap’ and lo and behold one of the binaries with a SUID bit is nmap.

A simple search of ‘nmap suid’ brings us to this article on how to abuse nmap to gain access to root.

From there we are able to open the file and get the last flag.

Killchain Summary

Enumerated target with Nmap to identify open ports
- Revealed web services for further enumeration
Brute forced web directories using Gobuster
- Revealed robots.txt which contained “sensitive” information including the first flag as well as a password file
- Revealed admin login page for underlying WordPress application
Enumerated login page to reveal legitimate user account (Elliot)
Brute forced a successful login using WPScan
Gained a webshell via hacking the default 404 response page
Used weak permissions to gain access to the password hash of the user ‘robot’
- Captured the second flag in robot’s home directory
Abused a local binary that had the SUID bit set in order to escalate privileges to root and capture the last flag