SolidState Walkthrough

This is a walkthrough of the CTF machine “SolidState” (originally on HackTheBox), now on Vulnhub. There are many writeups like it, and this one is mine.

  ****Spoiler Alert****          ****Spoiler Alert****

This was a great classic CTF, with some twists and multiple ways to gain a low privilege shell. Let’s grab our nmap scan and see what our options are:

Ok, so when I see any service that looks like something other than generic (like sendmail or postfix), or bigname (like MS), I tend to think that it’s a great place to look for public exploits. This of course is not always the case, but in the case of the JAMES smtpd server it is. When I look this service up on Exploit-DB we see the following:

Right off the bat I dive into the RCE, but notice that it’s an authenticated RCE. Commands are executed in the context of a user that will already have access to the server and I do not have that access….yet.

Sometimes the best way is the way of patience, and learning (in fact it’s usually the best way) and here that means perusing the paper “Exploiting Apache James Server 2.3.2”. By looking at this we see that the Apache James server also has a remote administration port (TCP/4555). Hmm. I didn’t see that on my initial nmap scan. Let’s run an extended TCP scan…

Nice, hunches do pay off! Using NetCat to connect I was able to confirm that the default password was still set as well. Now let’s view the available users configured and change their passwords so we can read their mail:

Reading these emails for each user can be done fairly easily using NetCat, Telnet or other similar methods, but is clunky. Python POP scripts are a-plenty and one good one is available here. Using this I was able to cycle through the different users emails until I hit paydirt on Mindy’s account (a new employee):

Perfect, so now we have a password! And we can login! Hey, there’s a user flag, cool!

….And we’re hit with a restricted shell. Not surprising considering this is a new employee account.

So after clunking around for a bit in the shell trying a couple of different escape attempts, there was no joy. I ended up coming across this slide from SecTalks Melbourne 2016 that detailed using the -t switch to execute commands before the restricted shell is set on the account. Using this method I was able to execute a vi session on the mindy account, set the shell using :set shell=/bin/bash then :shell and I was freeeeeeeeeeee!!

After completing this CTF I looked at a couple of walkthroughs and noticed that some others took the more-or-less obvious route of going back to the JAMES smtpd RCE from earlier (now that we have credentials it makes execution of commands much easier, this a new shell could be spawned using that method), but either method works.

PrivEsc took to turning over rocks, and rocks of rocks, but not finding much. After some time I thought about focusing on JAMES smtpd again. Where was it executing from, taking a look through those directories etc. I found it by looking at the processes running under root (one of my privesc steps from earlier), and went to those locations to analyze further.

What I found was a tmp.py file that was owned by root and looked like it’s function was to clean out /tmp. I had noticed before that one of my /tmp files was missing, but thought that it was my imagination. Now it looked like I had the culprit! After some failed attempts at a simple bash-based reverse shell, and other methods I upped my game and converted to one more Python-friendly:

Finally, fairly straight-forward, but I learn so much from each of these that none are a gimme.