HTB Reports: Writeup
- OS: Linux
- Level: Easy
- IP: 10.10.10.138
- User access: an outdated version of CMSMS is installed in the webserver, and SQL injection vulnerability allows to enumerate the database and find SSH credentials for the user.
- Root access: upon SSH login, run-parts is run with relative path and a misconfiguration in folder permission allows the user to ovveride the executable with a custom script.
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:
A warning at the top of the page informs us that it’s not a good idea to try to bruteforce directories with
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:
If we navigate to the file, as
nmap already found for us, we are told there’s a
/writeup/ folder available:
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:
Or, we can find the same result by using the Firefox plugin called
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:
We are running version 22.214.171.124. 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:
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:
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:
Looks like everything in
/usr/local is set to have group
staff and its
SGID. We can switch to
/usr/local to confirm it:
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
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:
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:
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: