Pit

Completed on September 21, 2021

Overview

Pit is a Linux based HTB machine that in some ways relies on the typical, and that is relying on SSH and HTTP to get into the system. The twist on it is the use of another service which quite frankly I had barely relied until now. It just emphasizes that you should never stop learning.

As a spoiler, the name of this box related to Cockpit. I would Google that if I were you!

Resources:

  1. https://github.com/dheiland-r7/snmp

  2. https://www.exploit-db.com/exploits/47022

  3. https://mogwailabs.de/en/blog/2019/10/abusing-linux-snmp-for-rce/

Initial Enumeration: Footprinting and Scanning

As we need to know exactly what we are dealing with in terms of services available, we first run nmap, but in a way at first that will give us only the open ports.

NMAP

As mentioned in the overview, we have SSH and HTTP accessible, but we also have TCP 9090. To make it easier on ourselves, we can create a variable from what the 'open port' log file contains.

When we browse to http://pit.htb we get what looks to be a default nginx page running on version 1.14.1 and running on Redhat! The NGinx information was first provided by nmap.

CURL

When we go to http://pit.htb:9090, not only we get redirected to an https site, but we also find a CentOS related login page. From what nmap gave us, you can see the service is http-related but also shows a bad request followed by the use of SSL. If we want to confirm the redirection to https:

Let's retrieve the certificate content by using curl:

We see there is another site listed as the CN of this site, something we saw from nmap:

Let's add this to our hosts file and retest against both TCP 80 and 9090.

Example:

TCP 9090 sent us to the same page, BUT TCP 80 gave us a 403 error. Let's see what we can find there:

DIRB

So we get nowhere. Every attempt gives us a 403. Given NGinx 1.14.1 has some vulnerabilities and one relates it to UDP DNS traffic, let's try and find any UDP ports this host might be listening to. For this, we will use masscan against all ports (both TCP and UDP) to get something quick.

MASSCAN

The above does not confirm out hunch from the NGinx 1.14.1 vulnerability and UDP DNS, but we did uncover SNMP is accessible.

SNMP-CHECK

Let's now use snmp-check against UDP 161 (snmp).

Even though the process list was truncated, it gave us some good information on what is going on in this box.

While doing some searches on how to pull more data from snmp, we come up with these perl scripts which gave us more information (https://github.com/dheiland-r7/snmp). The following allow us to do a bulk walk on snmp.

SNMPBW

This gives a lead. If we test this against the domains we know, only http://dms-pit.htb responds and redirect us to a login page.

And we seem to be hitting the login page of Seeddms, an open-source document management system.

Since we have no credentials, we go back to the SNMP dump and we only find the user 'michelle', but no password.

We can try to access it by using michelle:michelle to start. Let's try to login and see what happens:

And looks like we can get in (yes, I truncated the HTML code as we can't do anything with it at the moment).

Exploitation and Gaining Access

With valid credentials, we can now attempt to to use the authenticated RCE exploit available (https://www.exploit-db.com/exploits/47022).

We have to upload a document with a backdoor or a reverse shell. For this, we got to find a place to upload and looks like each user has its own folder.

Example of a "backdoor" to upload:

After many attempts we get to find out php reverse shells do not work well here.

This is why we end up using the PHP exploit in the example above to do some command injection. Once we upload, we should be able to access the page and send our OS command by using http://<host>/data/1048576/<doc_id>/<filename>.php?cmd=<command>.

Now, let's see what we can do here. We can use this to check on files we have access to, like SeedDMS's settings.xml file as it contains the SeedDMS configurations including how to authenticate to it.

And we in fact found some database credentials, but we have no way to test these at the moment as MySQL is not accessible but only to localhost.

At the moment, we have a confirmed user in the host, 'michelle', and a password in cleartext. We can test and see if the password was used on the database following the lazy admin approach against https://pit.htb:9090 as it has a login page found earlier. Since this application is Cockpit, a server administration tool sponsored by Red Hat, we can try these credentials there.

Once we do, we are able to login. This is the attempt we decided to go for as the credentials cannot be used in SSH as it requires the use of SSH keys. While digging through Cockpit, each user can add their own SSH key, so we must do that unless we decide to rely on the web-based terminal Cockpit provides.

Finally we are in and we got user!

Privilege Escalation

At the moment, let's remember we have the following credentials: michelle:ied^ieY6xoquu

Let's try to check the system and use linPEAS:

LINPEAS

After inspecting what linPEAS found, we notice /usr/local/monitoring has an ACL set where michelle only has write and execute rights.

If we recall when we inspected the SNMP dump it gives us something that might be related: .1.3.6.1.4.1.8072.1.3.2.2.1.2.10.109.111.110.105.116.111.114.105.110.103 = STRING: "/usr/bin/monitor"

Let's see what both the monitoring directory and monitor are about:

Looks like /usr/bin/monitor checks for scripts in the monitoring directory and runs each one. This means we can create a script in this directory and try to run it, but the problem is we cannot as monitor can be execute by root. If we create a script, how can we get it to run if we cannot use /usr/bin/monitor?

According to https://mogwailabs.de/en/blog/2019/10/abusing-linux-snmp-for-rce/, there are ways to abuse snmp. After looking at the system and what we can do with the user, we can only think of going back at snmp since it showed us /usr/bin/monitor.

Let's insert our private key into a check*.sh script for monitor to run and trigger the script using snmpwalk. First, we must install snmp-mibs-downloader so it looks at all the local mibs and uses them.

SNMPWALK

Now let's try to SSH as root.

AND we are in!! Let's get the flag!

PreviousOpenKeySNextIntelligence

Last updated

Was this helpful?