Mr. Robot
https://tryhackme.com/room/mrrobot
Last updated
https://tryhackme.com/room/mrrobot
Last updated
By Jacvbtaylor
The goal of this challenge is to find three hidden keys on this machine.
Using my nmap script I see a webserver running with a secure and unsecure connection.
I pulled up the webpage to find an interactive interface. Each command you input seems to request a video from the /video/ folder. Knowing there is a video folder, I can only assume there is even more to the web structure.
I initiated a dirb attack against the IP and instantly discovered a directory called /0/ which pulled up an empty WordPress blog. This gave me a clue that I would be needing to break into this, but I let dirb continue so I could find a proper login and other (Open Source Intelligence) OSINT first.
Something I always like to check is if there is a robots.txt file. This is a file I saw often when I worked in webhosting and they sometimes give up important information about the site. This happened to be one of those cases:
This lead me to the first key and a dictionary file, which I'll save for later in case I need it.
Dirb discovered a login directory which redirects us to /wp-login.php
This seemed like a good place to use that dictionary file. Although the WP site seemed pretty empty, it was still connected to the server. If I get access to the WP CMS dashboard, I can probably get a reverse shell set up. I used hydra to start a bruteforce attack in attempt to find a username for the WP login.
hydra -L fsocity.dic -p password 10.10.52.92 http-post-form '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In:Invalid username.' -vV -t 60 -F
While this ran, I looked through more of dirb's discoveries to try and gather more information. It seems to have found the robots.txt file as well, among other things that may or may not help us.
Hydra was able to detect a valid username! It says "password" is the password but this is a false positive. Hydra simply no longer received a "Invalid username" response. This will trigger a success alert since the server sent my host a different sized packet when it tried "Elliot" for the username. I can now try this username and see if the fsocity.dic file also has the password.
Here are the new parameters being sent:
hydra -l Elliot -P fsocity.dic 10.10.52.92 http-post-form '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In:ERROR' -vV -t 60 -F
Using hyrda, I found a valid username and password from the dictionary file and was able to log into the wordpress from the Elliot user. I checked the users tab in the dashboard and saw that Elliot was an administrator. This means I can edit files, add plugins, etc.
With the knowledge of WordPress using PHP, I know I can set up a PHP reverse shell. I have 2 options
Add the WP File Manager plugin
Add PHP code to an existing file
I decided to try adding reverse shell code to an existing file first. To do this I need to navigate to Appearance > Editor From here I will able to edit certain files. I am going to opt for the top file, 404.php, as it would be less suspected from the perspective of the website owner and wouldn't add any new files to the site or ruin the site functionality. All I would need to do is request that file from the server each time I wanted to connect to it. This is considered a backdoor.
I set up a ufw allow rule and started listening on my port and instantly established a connection, without even requesting the 404.php file from my browser. This could of been because of my interaction with it inside the WP dashboard, but I wasn't too sure.
I was excited to be where I was, and to be so close to the 2nd key - but I didn't have permissions to view it. I needed to find out my user's capabilities and see if I can get better access, or try spawning this shell differently so that I am not stuck at the daemon user.
Still stuck as the daemon user, I was able to see the users from /etc/passwd and confirm that password authentication is turned on in /etc/ssh/ssh_config but SSH wasn't open, according to my nmap scan. I was at a bit of a loss as to what to do from here, so I had to step back and brainstorm.
I checked which files may be shared between root and the daemon using find / -perm -u=s -type f 2>/dev/null
Once I saw nmap, I referenced GTFO bins to see if I could give myself sudo privileges.
I tried running these commands but had no luck giving adding myself to the /etc/sudoers file
TF=$(mktemp)
echo 'local f=io.open("/etc/sudoers", "wb"); f:write("daemon ALL=(ALL) NOPASSWD:ALL"); io.close(f);' > $TF
./nmap --script=$TF
&
HACK=/etc/sudoers
./nmap -oG=$HACK echo "daemon ALL=(ALL) NOPASSWD:ALL"
I looked back at the output from nmap and saw --interactive at the bottom
I recalled there being a way to use an nmap shell, and in some cases being able to escalate your privileges this way. I ran ./nmap --interactive then !bash and was still the daemon user. but when I tried !sh ....
I became root. I successfully gained access to the webserver as the WP admin user using open source intelligence, added a backdoor to the website by changing the integrity of the 404.php file, and exploited the confidentiality of the server content, ultimately finding an exploit within the nmap ELF file which allowed me to become the root user with full system access.
