Hack The Box: Devzat

Jump Ahead: EnumFootholdUserRootResources


To solve this machine, we begin by enumerating open ports using nmap – finding ports 22, 80, and 8000 open. From the web server, we find a git repo and download it. Looking through the downloaded source code, we find a command injection vulnerability in the website. Exploiting the vulnerability, we get a reverse shell on the machine as patrick. After port forwarding a local service to be externally accessible, we are able to connect to a database and retrieve credentials for catherine. Using the credentials, we are able to log in and read user.txt. As catherine, we connect to another locally running service, and get information about a new feature in development for the service. After exploiting the new feature, we are able to get a shell on the machine as root, and read root.txt.


Like all machines, we begin by enumerating open ports using nmap. From our scans, we find ports 22, 80, and 8000 open.

$ sudo nmap -v -p- --min-rate 3000 $RHOST
$ sudo  nmap -sV -A -p 22,80,8000 -oA enum/nmap/tcp-scripts $RHOST
# Nmap 7.91 scan initiated Sat Oct 16 17:20:40 2021 as: nmap -sV -A -p 22,80,8000 -oA enum/nmap/tcp-scripts
Nmap scan report for
Host is up (0.14s latency).

22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 c2:5f:fb:de:32:ff:44:bf:08:f5:ca:49:d4:42:1a:06 (RSA)
|   256 bc:cd:e8:ee:0a:a9:15:76:52:bc:19:a4:a3:b2:ba:ff (ECDSA)
|_  256 62:ef:72:52:4f:19:53:8b:f2:9b:be:46:88:4b:c3:d0 (ED25519)
80/tcp   open  http    Apache httpd 2.4.41
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Did not follow redirect to http://devzat.htb/
8000/tcp open  ssh     (protocol 2.0)
| fingerprint-strings: 
|   NULL: 
|_    SSH-2.0-Go
| ssh-hostkey: 
|_  3072 6a:ee:db:90:a6:10:30:9f:94:ff:bf:61:95:2a:20:63 (RSA)
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 4.15 - 5.6 (95%), Linux 5.3 - 5.4 (95%), Linux 2.6.32 (95%), Linux 5.0 - 5.3 (95%), Linux 3.1 (95%), Linux 3.2 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), ASUS RT-N56U WAP (Linux 3.4) (93%), Linux 3.16 (93%), Linux 5.0 (93%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: Host: devzat.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 80/tcp)
1   134.42 ms
2   134.58 ms

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Oct 16 17:21:27 2021 -- 1 IP address (1 host up) scanned in 47.61 seconds

Since we see a webserver running on port 80, we begin enumerating the port with nikto and gobuster. From nikto, we get a redirect to devzat.htb, so we add the FQDN to our /etc/hosts file. When we attempt the enumerate port 80 by IP using gobuster, we get a wildcard response. Using the FQDN, we get results, however, they are not super valuable. Since we got a domain name, we attempt to enumerate subdomains using gobuster. Doing so, we get pets.devzat.htb.

Next, we attempt to enumerate pets.devzat.htb using gobuster, however, we get a wildcard response once again. Instead, we use wfuzz to enumerate the subdomain for files and directories, and interestingly, we find a .git/ directory.

Going to the webserver in a browser, we are presented with a webpage for an ssh based chat application.

Following the “Where” link, we are told the application is hosted on port 8000 of the server (which banner was “SSH-20-Go” from our nmap results), and given the command to connect. Additionally, we find the username “patrick” in the contact information of the page.

Going to pets.devzat.htb in the browser, we are presented with a site for a pet inventory. We are allowed to add and remove pets.

Checking the .git/ directory, we see that it is valid.

Lastly, we connect to port 8000 using the command and username we found from the main webpage. Unfortunately, “patrick” is a reserved username, so we have to choose another to gain access. After we connect, we learn the service is a chat app with a few commands implemented.

Getting a Foothold

From our initial enumeration of pets.devzat.htb, we found a /.git directory. Since this directory indicates version control is in use for the site, we can wget to download the directory, so we may look through the source code.

$ wget -r http://pets.devzat.htb/.git/ # recursively download the .git directory 

For information on enumerating the .git folder, we Google “how to enumerate a .git”, and find this article. Following the article, we are able to get the object hashes of the files hosted on the website.

Using git cat-file, we are able to look through the objects to analyze the source code. In the main.go object, we find potential command injection in the “loadCharacter()” function. It receives unsanitized user input from the “addPet()” function, specifically in the “species” parameter.

To test this out, we set tcpdump to listen for ICMP packets, and attempt to ping our host via the “species” parameter. Doing so, we indeed receive the pings.

Lastly, we exploit the vulnerability to get a reverse shell on the machine as patrick.

Getting User

Having gotten a reverse shell on the machine as patrick, we begin our initial local enumeration. First thing we check, is if the user has an SSH private key. Since the user does, we download it, and use it to get a better shell on the machine. Checking for services running on the machine, we see 2 services running locally on ports 8086 and 8443.

Attempting to fingerprint the services with curl, we see port 8086 is hosting influxdb. Lastly, we attempt to connect to port 8443 using telnet, and learn it is hosting another SSH application similar to external port 8000 (based on the banner).

Using SSH to connect to port 8443 on the local machine, we get access to a chat service as patrick. From the conversation log, we learn influxdb (port 8086) is running version 1.7.5.

Next, we research “influxdb 1.7.5 vulnerabilities”, and find this article that reveals an authentication bypass vulnerability for InfluxDB – assigned “CVE-2019-20933”. Pivoting our research to “CVE-2019-20933” we find this page, that links to a GitHub repository for an exploitation script. To be able to run the exploit script, we use SSH to create a local port forward.

$ ssh -i ./patrick-id_rsa -L8086:localhost:8086 patrick@$RHOST

Once the port forward is created, we run the exploit script to start dumping the database(s). First we learn there is a database named “devzat”. Next, we learn it has a “user” measurement (table). Lastly, we dump the contents of the “user” measurement, and get several credentials.

Since catherine is a valid system user, we attempt to use the credentials for the user using su (on the target machine), and get a shell as catherine. We are now able to read user.txt.

Getting Root

Now that we have access to the machine as catherine, we begin looking for ways to privilege escalate. First thing we check is if we can run commands as other users using sudo -l. Unfortunately, we are not permitted to do so. Since connecting to the local chat service was previously fruitful, we do so again. This time, we see talks of a new feature being implemented, and that credentials are in the source code in the default backup location.

When we run the /commands command, we see a new “file” command that previously was not there. Based on its description, it will allow us to paste file contents directly into chat. When we attempt to use the command, we are told we need to provide the correct password.

Navigating to /var/backups/, we find the backups the chat was referring to. We copy them to /dev/shm, and unzip them so we may inspect them for the password.

Next, we use diff against each archive’s commands.go file, and are able to retrieve the password.

Going back to the chat application, we attempt to proof-of-concept the /file command to read /etc/passwd. Doing so, we indeed get the contents of the file.

Lastly, we use the command to get root‘s private SSH key. After we save it to our local machine, and set the proper permissions on it, we are able to SSH into the machine as root, and read root.txt.

Alternatively, we can just use the /file command to read root.txt in the chat.

Thank you for taking the time to read my write-up. I am interested in other ways this machine has been solved. Feel free to reach out to me and we can discuss it. Thanks!