To solve this machine, we exploit an SQLi vulnerability on the CMS-created website hosted at
/writeup to dump and crack credentials. Using the credentials, we are able to SSH into the machine, where we then get user.txt. Observing processes, we see that each time someone SSH into the machine, a script is ran. This script changes the environment PATH, introducing a PATH vulnerability that we are able to exploit. Exploiting the vulnerability allows use to run commands as root, giving us access to root.txt.
Like all machines, we start by enumerating services using nmap. We get results back that only ports 22 and 80 are open. We dig deeper into those:
nmap -A -p 22,80 -oA scans/nmap-TCPall 10.10.10.138
Taking a look at the homepage of the webserver, we are told there is DDOS protection in place, so directory bruteforcing is not easily possible. Looking at
/robots.txt, discloses there is a
/writeup directory that we may be able to look at.
Looking at the source page of
http://10.10.10.138/writeup/index.php shows that the page was created using a content management system (CMS) named CMS Made Simple.
Researching CMS Made Simple reveals there was an SQLi vulnerability we are able to exploit. Searching ExploitDB, we find a python script that is able to retrieve and crack credentials.
python 46635.py -u http://10.10.10.138/writeup/ --crack -w /opt/wordlists/rockyou.txt
Using these credentials, we are able to SSH into the machine as user
jkr, and retrieve
Normally, when we get shell access on a machine, we try to enumerate the machine using LinEnum, however, doing so doesn’t yield useful information. A good thing to try is to monitor processes to see if something is running on a schedule (which LinEnum won’t necessarily see). A good tool to do this is pspy, which we run. We observe that a script running as root is executed at what appears to be random (This is actually triggered by people logging into the machine as the
/etc/update-motd.d/10-uname, we see that all it does is run uname.
Referring back to the pspy output, we see that the environment is altered prior to running the script. We check where uname is located on the system, and attempt to see if we can write in one of the directories in the new path. If we are able to write in a directory that precedes the one housing the current one in our PATH, we can exploit this to write our own script.
Checking each directory in the new PATH, we see that we have access to write to
/usr/local/bin, which proceeds
/bin. Writing our own uname script in this directory, we are able to hijack the intended script execution.
echo -e '#!/bin/bash\ncat /root/root.txt > /home/jkr/root.txt' > /usr/local/bin/uname && chmod +x /usr/local/bin/uname
To get the script to execute, we just need to log out, and log back into the machine. Once we log in, we will have
root.txt in jkr’s home directory.
Thank you for taking the time to read my write-up. I am interested in other ways this machine has been solved. Feel free to reach out to me and we can discuss it. Thanks!