Bashed HTB Write-Up

Lets start with an Nmap Scan:

The Nmap Scan shows us that there is only one port open, Port 80.

so lets go visit the website:

So we have a pretty standard web application, and after enumerating the web page, there is not much to be found.

Lets try Directory Busting and performing a Nikto scan:

Above is the output from a Go Buster scan (the Nikto scan failed to identify anything interesting).

Here we can see 8 results, with the most interesting result being /dev. So lets go take a look at it.

We have 2 php scripts, and clicking on them reveals a backup command line interface.

We can see on the terminal that we are the user www-data, and we can grab the user flag in /home/arrexel.

After looking around this environment, the terminal is limited in some ways, so lets see if we can get a reverse shell on there and get a shell back on our own environment.

Placing a reverse shell on the php terminal failed, however I noticed in the GoBuster results that there was an /uploads directory. If we can upload a reverse shell onto this directory and then visit it, we could pop a shell, lets try.

I grabbed a PHP reverse shell from https://github.com/pentestmonkey/php-reverse-shell, hosted the directory using Python, and then used the wget command to transfer this file to the /var/www/html/uploads directory.

Now we can set up a listener on our Kali machine, and then visit the URL, http://10.10.14.15/uploads/x.php.

This gave us a shell, now lets improve it with, python -c 'import pty; pty.spawn("/bin/bash")'

Privilege Escalation:

Before running any PE scripts, lets first enter sudo -l to see if we can get an easy win.

Doing this command gave us the output:

This tells us that we can switch to user 'scriptmanager' using sudo. The command for this would be the following:

After enumerating the machine manually, I couldn't find much, so lets host linpeas.sh from our kali machine, and use the same wget command as earlier to transfer it over to the victim machine (I placed this in the /tmp directory).

Then we can use the command, chmod +x linpeas.sh to make it an executable, then run it, ./linpeas.sh

Within the output we can see a very interesting file called test.txt:

Lets cd over into /scripts, and ls -la to look deeper into the files in that directory.

Here we can see that test.txt was run not long ago, we can confirm this with entering ls -la again, and notice that the overwrite time has changed.

If we look at the file we own 'test.py', it has the following contents:

So here we can see that this had been run to write to test.txt, and so this cronjob must be being run as root, or else this file would not have permission to write to a root owned file. And we can determine that the whole of the directory is being run as a cronjob, and as root.

With this in mind we can create our own file in this directory, and because the cronjob is being run by root, the malicious file we create will also be run as root, hopefully giving us a shell as root (mentioned root a lot there aha).

I'm going to overwrite the test.py file, as I know for sure that this has worked in the past (as the test.txt file had been overwritten at some point). Lets first create a malicious Python program on our Kali machine, I grabbed one from https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md#python

I then indented accordingly (this is important as other attempts failed before doing this), and named the file test.py:

I first removed the original test.py file from the victim machine (using 'rm test.py'), and then used the same wget command as earlier to transfer it onto the victim.

Then I set the new file with executable rights, chmod +x test.py.

All that was left to do was set up a listener on our Kali machine and wait around a minute:

BOOM! We got a shell as root, we can confirm this with the 'whoami' command.

Now you can grab the root flag in /root.

Congratulations, you have pwned this box!!