The Rabbit hole has you...

HTB: Writeup

Write-up was a fun box. Admittedly it did take me longer than it should have. Technically speaking, obtaining user is harder than obtaining root. For user, we had to exploit a pretty well known and documented CMS Made Simple blind SQL vulnerability which discloses critical information about the application. Then once we find that info, we can ssh into the box and upon normal Linux enumeration tactics find a process which allows us to exploit a PATH hijacking for a script that always runs immediately after a successfully ssh session is established for the low-priv user. This box definitely help me to understand PATH hijacking much better and also helped to sharpen my Linux enumeration skills. But enough chat-chit, let’s get into it!


As with all things we’ll start with our initial nmap scan here…

And right away we can see we don’t have much to work with here. Just port 22 and 80, which apparently is more than enough. So let’s jump right in. One of the first things you should do and try to get in the habit of doing when you see a machine with a web server is to go ahead and look at that robots.txt file to see what the site doesn’t want crawlers to look at. In this case, we’re the rebels so we’re going to go straight for that page they don’t want search engines to see…

Upon visiting the /writeup page we can see a simple site, with a few links sprinkled around. We can hit each one, read up a little bit and do our enumeration to see if anything of importance is provided. Since I’ve already done the hard work, I can tell you that we next are going to focus on trying to learn what type of site this is built upon, and what technologies such as php or asp or whatever. Finding this out earlier in the game can help us know which direction to take upon exploitation. I learned about a really quick Firefox plugin called “Wappalyzer” that can tell you real quick things about a particular site. It’s a relatively quick enumeration tool, nothing really fancy. After installing, I was able to determine the site is built upon a content management system called “CMS Made Simple” (they really thought hard about the name), and it’s built using php on an Apache web server on a Debian system.

Now, as usual, this is where many hours of enumerating and trying different things to the site can occur. (and it did… for me, anyway). But fast forwarding to when I finally found something that made sense, I was able to find a CMS Made Simple python script which claimed to be able to exploit a vulnerability in CMS Made Simple version 2.2.9 and below. I’ll be honest, I couldn’t find a way to find out the version that was being used on this system. If someone out there knew of a way before hand before please inform me in the comments below. But anyway, I found this python script and felt it couldn’t hurt to give it a go.

I downloaded the script, ran it against the IP and watched as fireworks erupted on the screen. It did take a little bit of time. Essentially, all you had to do was throw it a password file to use to crack the md5 hash of the user password. Upon further inspection of the script, this exploit was using blind SQL injection methods to determine the username, salt, email address and hashed password for the admin account of the CMS application. After the exploit finished, it provided all this information along with the cracked password.

After we found a username and a password, the next obvious step was to try it against the ssh port and obtain the user proof.



Moving onto root. I must give credit to the HTB member “Keresh” for his help on this one. Just a reminder, HTB is for learning and hacking on systems without fear of breaking laws and/or getting in major trouble. So if you ever get stuck there is absolutely no shame in hitting up the HTB forums for hints. But it should be used as an “almost” last resort. Try not to run to the forums right out the gate. Thank You Keresh for the push.

Cutting to the chase, I used a tool called pspy which allows a low-priv user to monitor running linux processes without root permissions in real time. Yes, there is also the command “ps aux”, however to my understanding that won’t show you what you need to see in real time as it happens. This tool can be found at github at “”. Download the 64 bit version to your attacking machine, and then upload it to the home directory of the user jkr. I like to use python’s simple HTTP server script and wget from the victim machine to pull all my files.

After we have pspy64 on the victim, we’ll have to modify permissions to allow it to run and then run it. It will fire-up and this is where we would watch for processes and anything specific that we could use to escalate our privileges. This part took the bulk of my time, because obviously you have to try different things and make many mistakes and hit a plethora of brick walls. After much time, you can see an interesting process running, but you can only see it occur when you establish another ssh session with the user jkr, which naturally you would have to do in order to continue to enumerate the box, because you can’t necessarily kill pspy64 on the session you’re currently on. I believe this was the intent of the box-creator. So, after establishing a new ssh session with jkr, you can see this line here:

And after a few more tests, you can see it pops up EVERYTIME a new jkr ssh session is established. Upon further investigation, it seems this is a pretty simple script that doesnt do anything special, but it executes as root. Which is what we ultimately care about. There’s also the interesting PATH that’s displayed which shows you the order of locations the system will look for the command “run-parts” in. Using the which command, we can find where “run-parts” is actually located and see if PATH hijacking is a possible avenue of exploitation for this command.

The run-parts command being executed is in the very last location of this PATH variable. So this means if we can create our own “run-parts” script and place it in any of the locations previous to the /bin run-parts, we may be able to execute our own code with root privileges. First thing to do is see if we can actually write to any of these directories.

The above screenshot shows us that we can indeed WRITE to /usr/local/sbin, but we can’t read it, which is fine, we don’t need to read what we put here, we just need to write into it and execute it. We’ll write a reverse python script called “run-parts” that can call back to our attacking machine, place it in this directory, and then establish a new ssh session and it “SHOULD” execute. I like to keep things simple and use what I know, so I looked to see if python was on the machine and it was. Let’s give it a try.

I made the python script above to call back to my attacking machine. Renamed it “run-parts”, gave it execution rights and moved it to /usr/local/sbin. All we had to do next is establish another ssh session and see if our listener was able to pick up the call….