HTB Reports: Writeup

Writeup

High-Level Summary

Walkthrough

A quick scan with nmap will tell us that there is a web server running and an ssh server:

Starting Nmap 7.80 ( https://nmap.org ) at 2019-10-13 10:00 CEST
Nmap scan report for 10.10.10.138
Host is up (0.030s latency).
Not shown: 998 filtered ports
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 5.82 seconds

So, we navigate to the webserver and find this page:

No Bruteforce

A warning at the top of the page informs us that it’s not a good idea to try to bruteforce directories with dirbuster, gobuster or similar because we will be banned.

Luckily, this is not needed. A more accurate scan with nmap will show us that there’s a robots.txt file in the root directory of the website:

Robots.txt found

If we navigate to the file, as nmap already found for us, we are told there’s a /writeup/ folder available:

Robots entries

We navigate to the folder and we find a page with some links to uncomplete HTB writeups. If we look at the source of any of this pages, we can immediately recognise what software is running:

Writeup generator

Or, we can find the same result by using the Firefox plugin called Wappalizer:

Writeup wappalizer

Now that we know what software is running, we can see that there are a lot of known vulnerabilities and public exploit for it. Let’s try to find out which CMS Made Simple version is running on the website.

Usually, I’d start a scan with dirbuster looking for folders or .txt files, but in this case we will get banned. So, I looked at the source code of the application on this page.

This way, I could see if any of the files shipped with the application could be of use to determine its version number. After some browsing, I decided to try if the /doc/CHANGELOG.txt file was present on Writeup and I got lucky:

Changelog file

We are running version 2.2.9.1. Lucky us, there’s a public exploit for versions up to 2.2.10.

The script, as it is, required some fixing in my Kali machine. The module termcolor was missing, you can either install it or just change the script in order to not use this module, and this is the path I went for.

So, we run the script with the following command:

./cmsms-dbenum-edb46635.py -u http://10.10.10.138 --crack -w /usr/share/wordlists/rockyou.txt

The database extraction will not take much, despite it being a time based SQL injection. But the cracking of the password might require sometime. At the end of it, anyway, we will have our ssh credentials:

Writeup password

Now we can log in trough ssh and get our user flag.

Once we are inside, we collect some information running LinEnum.sh. Once we run it, we go trough its output and we don’t find anything particularly strange, apart from the fact that our current user is part of the group staff, which is not a standard group:

jkr in staff

If we are in this weird group, there must be a reason. In order to see what is owned by this group, we can search for files and folders owned by it with the following command:

find / -group staff -ls 2>/dev/null

This is what we find:

Staff owned

Looks like everything in /usr/local is set to have group staff and its SGID. We can switch to /usr/local to confirm it:

/usr/local

This is important, because it means we can write in the default PATH. We need to have a look at what is running on the machine, to see if we can hijack the execution. In order to do so, we can use pspy

Now, this is where Writeup becomes a little bit complicated if you are on a VIP server and you’re the only one working with the machine. In fact, it’s much easier to spot the vulnerability on a server with a lot of people working on it.

But let’s say that after running pspy, you want to open another shell on the machine to continue your investigations while the monitor is running. You log in with ssh again while pspy is running in your terminal, and this is what you’ll see:

pspy finds run-parts

Bingo. Do you see it? There’s a call to run-parts, called with relative path, the process is owned by root and the PATH variable is set so that /usr/local/sbin is checked first. If we run which run-parts, turns out it’s on /usr/bin. If we create a malicious /usr/local/sbin/run-parts, it will be executed instead of the original one.

We open with nano /usr/local/sbin/run-parts and save the file with the following content:

evil run-parts

Now we need the file to be executable:

chmod +x /usr/local/sbin/run-parts

And we’re done. We setup our netcat listener, we log in with ssh again and we get root:

Root shell