Jump Ahead: Enum – User – Root – Resources

TL;DR;

To solve this machine, we begin by enumerating open ports – finding TCP ports 22, 80, and 9090 open, and UDP port 161 open. From the webserver on port 9090, we find a FQDN that gives us a different website reachable via port 80. While enumerating port 161, we find potential usernames, a web directory, and an interesting command being run. After navigating to the discovered web directory via the discovered FQDN, we are able to gain access by guessing login credentials. From here, we are able to upload a web shell, and use it to grab database credentials. Using the captured database password and a username we previously found, we are able to get system access via the system management interface located on port 9090. With this, we are able to read user.txt. Looking more into the findings we had from port 161, we find the a script is ran every time we read data from the port. With this knowledge, and a permission misconfiguration, we are able to exploit this to upload our SSH public key, and gain SSH access – allowing access to root.txt.

Enumeration

Like all machines, we begin by enumerating open ports with nmap – finding TCP ports 22, 80, and 9090 open.

Additionally, we enumerate UDP ports, and find port 161 is open.

Starting with the TCP ports, we begin by enumerating the webserver on port 80 with nikto and gobuster. These tools did not yield many results, so we move on to port 9090. Based on the nmap results, port 9090 is also hosting a webserver, so we use the same tools. Nikto did not give any interesting results, and gobuster received responses for wildcard requests – meaning directory and file bruteforcing could be difficult. From the nmap results, we see this port uses TLS, which means we will also need to specify that in our enumeration tools, however, the results are the same. Going to the port using HTTPS protocol, we are able to view the TLS certificate, which reveals the FQDN dms-pit.htb. Additionally, under the login form, we find another potential FQDN – pit.htb.

• 

• 

Since we obtained 2 new FQDNs, we check both web servers for different responses using them. The only difference we see is that dms-pit.htb gives a different response on port 80. Although the webserver gives a 403 response, this is different than the response using the IP.

• 

• 

Having received a different response using the FQDN, we try to enumerate port 80 again using nikto and gobuster as before. Unfortunately, this does not give us any additional threads to pull on, so we move to SNMP enumeration on UDP port 161. For this, we use onesixtyone and snmpwalk.

From the snmpwalk output, we get several possible findings. We learn of 2 potential usernames – root and michelle, a possible web directory located at /var/www/html/seeddms51x/seeddms, and a command that appears to be executed on SNMP read access – located at /usr/bin/monitor.

Getting User

Since we found a potential web directory, we attempt to access it by going to http://dms-pit.htb/seeddms51x/seeddms. Fortunately, we are redirected to a login page for something called “SeedDMS”.

• 

Since we already have possible usernames, we attempt to guess simple passwords for them, and find Michelle‘s password. After logging in, we are presented with a dashboard that shows several folders under “Folder Contents”.

• 

By navigating to “Docs -> Users -> Michelle”, we see that we are given an option to add a document.

• 

Clicking this link, we are able to upload a webshell. Unfortunately, when we attempt to dowload the file, the webserver does not execute it.

• 

• 

Since the platform does not allow us to execute our webshell via the “Download” option, we will need to find where the file is being stored on the webserver. Once we have the location, we can try to access it directly and cause the webserver to execute it. For this, we will need to do more research on the application. As GitHub is a good resource for source code, we search it for “SeedDMS” and find this repository that includes an explanation of the data storage. The explanation details the storage location, and changes done to the file name. In short, uploaded documents should be located at http://dms-pit.htb/seeddms51x/data/1048576/<document id>/<version>.<extension>.

• 

To get the document ID and version, we open the document information page. The document id is located in the URL as a parameter, and the version is listed under the filename. We know we uploaded a php file, so the extension will be “.php”. Going to http://dms-pit.htb/seeddms51x/data/1048576/33/1.php, we are able to access our webshell. To run commands, we supply the “cmd” parameter, and view the source code of the page for better formatting. One such file we should immediately read is the configuration file for SeedDMS, which is located at /var/www/html/seeddms51x/conf/settings.xml. In it, we find database credentials.

• 

• 

Since we had potential system usernames, and now a password, it’s a good idea to try to authenticate using them. Since SSH is hosted on the machine, we attempt to login as root and michelle using the database password, however, we are not permitted to login. Next, if we remember correctly, port 9090 is running what appears to be a system web interface. We attempt to login here, and are given access as michelle.

• 

• 

On the left navigation bar, we see there is a terminal. Clicking it, we are given an emulated terminal shell as michelle, and can now read user.txt.

• 

Getting Root

Having gained access to a system shell as michelle, we begin looking for an avenue to privilege escalate to root. From our initial enumeration of SNMP, we observed that a command is potentially being run every time SNMP is being queried. The command was located at /usr/bin/monitor.

• 

Looking into the command, we learn it is a script that executes other scripts in the /usr/local/monitoring directory which names begin with “check” and end with “sh”. If we have access to write to the directory, we should be able to upload our SSH key to root‘s directory, and get access to the machine as root. To attempt this, we echo our SSH public key into a file located at /usr/local/monitoring/check-Khaotic.sh. Next, to execute the script, we run snmpwalk again. Once the command completes, we attempt to log into the machine as root via SSH. We are success, and given a shell as root – now allowing us to read root.txt.

• 

• 

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!

Khaotic Pro Hacker

Rank: 882 2 47

hackthebox.com

Resources

• OneSixtyOne – Fast SNMP Scanner
• SeedDMS Data Storage Information