To solve this machine, we begin by enumerating open ports using
nmap – finding ports
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
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
Like all machines, we begin by enumerating open ports using
nmap. From our scans, we find ports
$ 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 10.10.11.118 Nmap scan report for 10.10.11.118 Host is up (0.14s latency). PORT STATE SERVICE VERSION 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 : SF-Port8000-TCP:V=7.91%I=7%D=10/16%Time=616B503F%P=x86_64-pc-linux-gnu%r(N SF:ULL,C,"SSH-2\.0-Go\r\n"); 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) HOP RTT ADDRESS 1 134.42 ms 10.10.14.1 2 134.58 ms 10.10.11.118 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, 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
Next, we attempt to enumerate
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
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.
pets.devzat.htb in the browser, we are presented with a site for a pet inventory. We are allowed to add and remove pets.
.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.
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
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
Attempting to fingerprint the services with
curl, we see port
8086 is hosting influxdb. Lastly, we attempt to connect to port
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.
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
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.
/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
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!