Jump Ahead: Enum – User – Root – Resources
TL;DR;
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.
Enumeration
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.
Index page tells there is DDoS protection in place /robots.txt gives us a directory to check out
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.
Source of the writeup directory index page
Getting User
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
Exploited CMS Made Simple to dump credentials
Using these credentials, we are able to SSH into the machine as user jkr
, and retrieve user.txt
Logged in and got user.txt
Getting Root
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 jkr
user).
pspy running
Looking into /etc/update-motd.d/10-uname
, we see that all it does is run uname.
Script that is run
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 where uname is located
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.
Hijacking the uname script, and getting access to root.txt
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!