Devzat is a pretty easy medium linux box. It starts with a website that inform you about a chat service on the host accessible on port 8000. Some enumeration will yield a hidden subdomain that’s vulnerable to command injection. Once inside the box, there is an instance of InfluxDB running locally that’s vulnerable to CVE-2019-20933, which you can use to gain access to the box as another local user. Privesc involves exploiting a path traversal flaw in a custom code.
Info
Recon
NMAP
# Nmap 7.70 scan initiated Sun Oct 17 08:49:05 2021 as: nmap -sV -sC -oN nmap.txt 10.10.11.118
Nmap scan report for 10.10.11.118
Host is up (0.23s latency).
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
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.70%I=7%D=10/17%Time=616BD594%P=x86_64-pc-linux-gnu%r(N
SF:ULL,C,"SSH-2\.0-Go\r\n");
Service Info: Host: devzat.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Oct 17 08:50:17 2021 -- 1 IP address (1 host up) scanned in 71.63 seconds
Web
Possible username patrick?
Connecting to the SSH service on port 8000 gave the below output;
Attempts to log in as the user patrick kept failing, saying it’s reserved for local use. This may be because the user patrick is the admin.
Bruteforcing virtual hosts using ffuf discovered one;
Pets
The add pet form above is used to add an entry to the pets list. Adding a pet generated the request;
Bruteforcing the web root with ffuf kept giving 200 responses, even for invalid paths. Viewing the page source showed it is dynamically generated by a JavaScript code;
So I downloaded the file and parsed it with js-beautify for easier analysis. I found the block of code that generates the request used for adding pets, and nothing more of interest;
Newly added pet entries can be seen immediately after they have been added, but refreshing the page makes them disappear.
Fuzzing the JSON data
Deleting all the parameters doesn’t have any visible effect on the parser at first, and the web app responded with Pet was added successfully. Breaking the JSON syntax produced an error message;
Sometimes even after getting a success message from the POST request, reloading the JSON data does not show the new pet entry. However, after submitting only the name parameter, reloading the pets JSON data by sending GET request to /api/pet showed a new response;
The species parameter is not being returned in the JSON data of the pets, but appears to be used to construct the characteristics parameter that describes the species. I assumed it’s being used to load the characteristics data, which will make it an interesting target for injection attacks like LFI and SQLi.
After adding a characteristics parameter in the submitted JSON, it is overwritten in the JSON response obtained if the value given to the species parameter is valid (e.g: cat), but if it is not valid, the characteristics parameter in the JSON response gets set to exit status 1.
The message exit status 1 is very interesting because that is usually the result of a function call or some system command. Return codes that are not equal to 0 usually indicate an error. So I started fuzzing the species and characteristics parameters for Command Injection flaws, and caught a break. The parameter species is vulnerable to command injection;
I then exploited the command injection to gain access to the box as the user patrick;
Going through the source code of the web app at /home/patrick/pets, I found the vulnerable code that let me in;
It looks like the code is also vulnerable to local file inclusion (LFI).
User
The user patrick does not have the user flag, but it was found in the home of catherine.
Inside the home directory of patrick, source code for the web apps were found, including a binary named petshop in the ~/pets directory.
Using linPEAS and manual enumeration didn’t yield anything interesting. netstat idenitified a bunch of locally running services, so I setup some SSH tunnels so I can scan them from my box;
I then ran an nmap scan on the ports to identify the services they are running;
# Nmap 7.70 scan initiated Tue Oct 19 01:02:17 2021 as: nmap -sV -p6010,8443,53,8086 -oN nmap-hidden.txt localhost
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00023s latency).
Other addresses for localhost (not scanned): ::1
PORT STATE SERVICE VERSION
53/tcp closed domain
6010/tcp open x11?
8086/tcp open http InfluxDB http admin 1.7.5
8443/tcp open ssh (protocol 2.0)
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-Port8443-TCP:V=7.70%I=7%D=10/19%Time=616E0B10%P=x86_64-pc-linux-gnu%r(N
SF:ULL,C,"SSH-2\.0-Go\r\n");
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Tue Oct 19 01:03:12 2021 -- 1 IP address (1 host up) scanned in 55.43 seconds
The service on port 8086 has been identified as a HTTP service, and viewing it in a browser just give a 404 Not found. Bruteforcing with ffuf found a few paths;
Going to the /query path gave an authentication prompt;
Googling showed that the version of InfluxDB on the host is vulnerable to authentication bypass, and was exploited using a python code obtained from the repo https://github.com/LorenzoTullini/InfluxDB-Exploit-CVE-2019-20933
InfluxDB is something I have never came across before, so I had to do a lot of googling to learn about it. Using a cheatsheet I found on GitHub at https://gist.github.com/tomazursic/6cc217e2644c619ceceefb8ce824925b, I was able to enumerate the service and found a hash for the user catherine in the devzat database inside the user measurement;
The password woBeeYareedahc7Oogeephies7Aiseci does not appear to be a hash, so I just used to access the account of catherine on the host, and it worked;
PrivEsc
The user catherine does not have permission to run any command on the host using sudo. No files of interest were found in her home directory, so I ran linPEAS again in hope of finding something new, but it didn’t.
Inside /var/backups, 2 backup files belonging to catherine were found. The files were extracted, but nothing of interest was found inside at a quick glance;
Connecting to the SSH chat service locally on port 8443 as catherine showed some interesting messages from patrick;
Since the default backups directory in linux is /var/backups, and the only files of interest in the directory are the previously discovered .zip files, I extracted them again to /dev/shm, and run the diff command on their extracted files, and found a password CeilingCatStillAThingIn2021?;
Attempt to login as the root user using the password failed. In the text messages patrick talked about implementing a new feature that requires a password, so I continue to examine the output generated by the diff command, and noticed a function that appears to be used to read files from disk provided a path and a valid password were provided;
So I logged back into the chat app as catherine and listed available commands using the /help command. One entry stood out;
This is likely the command used to invoke the function used to read files using a path and a password. So I tried to read the file /etc/hostname to see if it works, which did not work because the application is prefixing /root/devzat to the filename given, as indicated by the error message. Using a simple path traversal payload, I was able to read the SSH key file of the root user;
I copied the SSH key to my attack box, and used it to access the box as the root user over SSH;
Summary
- Identified services running on the host using
nmap - Found the username patrick on the web page, which is not allowed to be used remotely on the SSH chat service.
- Found a hidden subdomain pets.devzat.htb using
ffuf- Fuzzing the JSON data submitted to the web app via POST request uncovered a command injection flaw, which was exploited to gain access to the box as the user patrick.
- Inside the box as patrick;
- Identified another user named catherine.
- Discovered a local installation of InfluxDB that is vulnerable to authentication bypass, and was enumerated to obtain a password that gave access to the account of catherine.
- Inside the box as catherine;
- Connected to the local SSH chat service on port 8443 as catherine.
- Received a chat log between patrick and catherine discussing a new feature that is password-protected, with the password obtainable from backup files in the default linux backups directory.
- Located the password inside the backups and used it to access the feature, which is used to read files from disk. I used it to load the SSH private key of the root user.