Ethical Hacking Lessons — Bashed Writeup

This is my write-up for the hackthebox Bashed machine. This box highlights the threats exposed by using web-shells and security misconfigurations.

Let’ start with its info card.

Another Linux machine with an Easy difficulty level. The IP address of this box is 10.10.10.68. The radar-graph shows almost equal measurements across all the metrics.

Recon

Let’s start active recon with the Nmap scan using the following TCP scan command.

nmap -A -T4 -p- -oX tcp_scan_result.xml 10.10.10.68

The scan results as shown below.

I also performed a UDP scan for all ports. That scan did not report any open ports.

Recon Results Analysis

Apache HTTP service is running on port 80, its time to enumerate.

Enumeration

Let’s start by browsing to the http://10.10.10.68. It brings up the following web-page.

Looks like this site was created for pentesting on the same box. Clicking on the Arrow sign navigates to single.html page as shown below.

This page points towards a Github repo that is shown in the image below.

The documentation clearly indicates that this site offers some sort of PHP based web-shell. There are two PHP files listed in this repo that could help us to get to that shell. We now need to find a way to get to these files on the webserver. For this, we can use the OWASP dirbuster tool to try to locate these PHP or any other related directories/files on this site.

I launched dirbuster with key attributes shown in the image below.

It didn’t take too long for dirbuster to locate those two PHP files under the dev folder.

Next, I ran the phpbash.php file from the web browser and that immediately gave us a web-shell.

We can run a few basic commands through this shell quite easily to learn about the system and user.

An interesting finding here is that the logged-in user www-data has the ability to run any commands as scriptmanager without requiring to authenticate via passwords. This information was revealed by the sudo -l command that simply lists the user privileges.

The full dirbuster report is shown below. I spend some time to go through items listed in this output for any other interesting thing but did not have any luck.

DirBuster 1.0-RC1 — Report
http://www.owasp.org/index.php/Category:OWASP_DirBuster_Project
Report produced on Sat Oct 05 14:57:20 EDT 2019
— — — — — — — — — — — — — — — —

http://10.10.10.68:80
— — — — — — — — — — — — — — — —
Directories found during testing:

Dirs found with a 200 response:

/images/
/
/uploads/
/php/
/css/
/dev/
/js/
/demo-images/
/fonts/

Dirs found with a 403 response:

/icons/
/icons/small/
/server-status/

— — — — — — — — — — — — — — — —
Files found during testing:

Files found with a 200 responce:

/config.php
/js/custom_google_map_style.js
/dev/phpbash.min.php
/css/carouFredSel.css
/php/sendMail.php
/index.html
/css/clear.css
/single.html
/js/html5.js
/css/common.css
/js/jquery.js
/css/font-awesome.min.css
/js/imagesloaded.pkgd.js
/css/sm-clean.css
/js/jquery.carouFredSel-6.0.0-packed.js
/js/jquery.nicescroll.min.js
/js/jquery.easing.1.3.js
/js/jquery.smartmenus.min.js
/js/jquery.mousewheel.min.js
/js/jquery.touchSwipe.min.js
/js/main.js
/dev/phpbash.php
/fonts/FontAwesome.otf
/fonts/fontawesome-webfont.svg
/fonts/fontawesome-webfont.eot
/fonts/fontawesome-webfont.ttf
/fonts/fontawesome-webfont.woff
/fonts/fontawesome-webfont.woff2

— — — — — — — — — — — — — — — —

Enumeration Results Analysis

We are able to find a web-shell but the logged-in user attached with shell does not seem to have enough privileges. The sudo -l command revealed that www-data user can run any commands as scriptmanager without requiring any password. We can just attempt to see what type of exploitation could be performed using this web-shell.

Exploitation

It did not take much efforts to simply browse through the folders to see what directories/files can this user has permission to browser to read. Very soon, I found the /home/arrexel directory that had the user flag file.

That’s awesome. The other /home/scriptmanager folder also looks interesting. However, this folder did not contain anything useful as shown below.

Finally, during the browsing of the local file system, at the root directory, I found another folder /scripts that has permission set for the scriptmanager user we found earlier. This folder looks completely different permission wise compared to all other folders. However, when I try to look at the contents of the folder, there were few permissions error, although, it looks like there are two files present in this folder test.py and test.txt.

Even though at this point, we have a user flag, it's quite clear that we need to attempt privilege escalation as the permissions for www-data user seems limited. Also, it's important to note that so far all we are doing is with a bind-shell but this approach has its limitations, not to mention it's inconsistent and dependable. We, therefore, will try to establish a reverse-shell. Also

Establishing Reverse Shell

The pentestmonkey web-site has a useful collection of cheat sheets, scripts, etc including a script specific to reverse shell for PHP. This could be relevant to us as we are dealing with a PHP based site. The pentestmonkey page for PHP reverse shell provides the download link for the script as well as easy to follow instructions. As shown in the image below, the only thing needs to be changed in that script is the IP address of the attacker machine and the port.

I downloaded the script, made necessary changes and saved to file called bashed.php. Now we need some way to transfer this file to the victim machine. Given that we have a shell on that machine, as long as this script file can be served from somewhere, we should be able to download it to the victim machine. I used the python script to launch a web-server as shown below.

Let’s go back to the web-shell on the victim machine. I discovered that there is an upload folder there containing only one index.html file. I used wget to download the reverse shell script in that folder.

Next, we need a listener on our attack machine that I setup as shown below.

Its time to run the script we uploaded to see if that gives us a reverse-shell script.

Tada !!!! that gave us the reverse shell we were looking for.

It's obviously great to have the reverse shell. However, as you can see in the image above, we don’t get access to tty. We know at this point that we want to sudo to scriptmanager in order to get to the scripts folder contents. However, a sudo is not possible without a tty. We can upgrade to an interactive tty shell by following the steps listed below.

1. Spawn a bin bash shell using python script.
2. Background current shell using ctrl+z.
3. Change the current stty to type raw and echo input character by using stty raw -echo.
4. Lastly, bring the listener shell to foreground by type fg and then hit Enter twice.

Now that we have an interactive shell, we can try privilege escalation to get to the root flag.

Privilege Escalation

Its time to go back to sudo to scriptmanager user. With the interactive session, scriptmanager can view the contents of test.py and test.txt.

Few important observations here.

1. Code review of test.py indicates that it opens a file named test.txt and write testing123! in that file.
2. The file creation timestamp of test.txt file is quite recent.
3. test.py is owned by scriptmanager user whereas test.txt is owned by root user.

If we inspect the folder contents after few minutes again, we see that test.txt file creation time is more recent.

Based on these observations, it looks like that test.py is spawned by some type of cron/daemon process as root at regular intervals. Since scriptmanager has read/write permissions on the test.py file, if we can update the contents of the test.py file to a reverse shell, that can give us a root shell. We go back to pentestmonkey that offers the following python script that could be used to launch that reverse shell.

I launch the netcat listener on the attack machine at port 4445 and without a long wait, I got the reverse shell this time as root. This obviously led the way to capture the root flag.

Root Cause Analysis

1. Web Shells are notoriously well-known security threats, especially when exposed to the outside world. Careful design reviews may reveal that the risks of exposing a web-shell usually trumps any benefits it offers to an application.
2. Security misconfigurations, such as the ability for a less privileged user to run programs as a higher privileged user, are dangerous practices that should be avoided.