6 min to read

HackTheBox - Mirai

Featured image

This IoT themed HackTheBox challenge shines a light on the problems associated with a rapid explosion of internet connected devices.

As cheap mini-computers such as the RaspberryPi become easily accessible to consumers, it’s clear that securing these devices can be easily overlooked.

This challenge was pretty simple and straightforward with only a single curve ball thrown in at the end.

Recon

A common theme amongst the HackTheBox.eu challenges are that the name of the machine often serves as a clue to what the challenge is all about.

I did some research on Mirai and discovered that it is a malware variant that is designed to infect Linux based IoT devices by using their default credentials and turns them into remotely controlled botnets. Pretty interesting stuff!

Enumeration

nmap

Starting out with a standard nmap scan, I see that it’s got a few open ports.

nmap -sC -sV -oA mirai.nmap 10.10.10.48

htb-mirai-01

I hit the IP in a browser to see what’s being served over HTTP - nothing.

I run gobuster to see if there are any other directories I could access over HTTP.

gobuster -u http://10.10.10.48 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

htb-mirai-02

That unveils the /admin directory that looks like it’s worth investigating. I go to that URL in my browser and am presented with the Pi-Hole administration page.

htb-mirai-03

Pi-Hole is DNS black hole software that is designed to run on a RaspberryPi. I’ve had some experience using this before personally, as I run one in my home to block ads and trackers on on all my internet connected devices.

Exploitation

Combining what I learned in the recon phase with what I already know about the RaspberryPi/PiHole, I try to SSH over with the default RaspberryPi credentials pi:raspberry and am logged in successfully.

htb-mirai-04

Privilege escalation

Simple as:

sudo su

But the challenge isn’t over yet! When I got the root flag, the contents are not what I expected …

root@raspberrypi:~# cat root.txt
I lost my original root.txt! I think I may have a backup on my USB stick...

I query the system devices and see that /media/usbstick is mounted to /dev/sdb.

htb-mirai-05

Listing the contents of /media/usbstick reveals another interesting file damnit.txt

htb-mirai-06

I cat the contents.

htb-mirai-07

Damn it, James!

When a file is deleted, it’s not actually gone. The system essentially marks the location on the disk where data is stored as free space, so it can be overwritten by new data.

To recover the contents of the deleted file, I simply do a text search with grep on the entire contents of the USB stick’s file system (including the free space!).

Using a little regex trickery, I can limit the results of grep to a 32 character hash that makes up the flag.

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

The result displays my sweet root hash bounty.

Deconstructing the hack

The Mirai machine isn’t the typical exploit and escalate scenario commonly found on HTB. Although themed around the Mirai malware, the information on this topic plays only a minor role in the recon phase of this challenge to obtain the credentials. Instead, this box tests your knowledge and understanding of system fundamentals.

Mirai malware

The Mirai malware (Japanese for “the future”) infects IoT devices (such as IP cameras, home routers etc) using their default credentials, and executes code to make them part of an ever-growing botnet.

The nodes of the botnet can be ordered to execute devastating attacks, such as a Distributed Denial of Service (DDoS), against a target.

When you consider the number of Internet-connected consumer devices hitting the market today with the boom of the modern ‘smart home’, the number of possible hosts for malware such as Mirai is starting to grow at an alarming rate.

The significant issue I see is that even when a vulnerability in an IoT device is found/reported to a vendor and they do the right thing and provide a fix through a software update, how many consumers are going to patch all their devices to mitigate the risk?

Take your average tech-savvy consumer as an example. They may have one or more of these common internet-connected devices.

That’s a lot of devices! And these are just the common ones that have already made their ways into the average consumer home.

With IoT being all the rage it seems that as a vendor, you’re just not cool unless your product has an IP address. Here’s a tip: just because you can connect your product to the internet, it doesn’t make it a good idea.

To prove my point, here’s an example of a ‘smart toilet’ that was very easily compromised by the same kind of method that Mirai demonstrates.

The toilet allows you to pair an application on your mobile phone via Bluetooth to control the toilet’s features. (I won’t try to understand why anyone would want that functionality built into their porcelain throne, so let’s keep moving ..) The manufacture hardcoded the default Bluetooth pairing code ‘0000’ into the toilet’s software, allowing anyone with a mobile phone and the companion application installed to ‘cause discomfort and distress to the user’.

Now think about someone that may own this device. Assuming the manufacturer releases an update that fixes the vulnerability, it’s the responsibility of the consumer to patch the device. Realistically, who in their right mind is going to monitoring the release notes of their toilet to see if they need to take action?

With so many disjointed and unrelated internet-connected devices, the burden put on consumers to keep the firmware updated is simply too overwhelming. When was the last time you thought to yourself “I think it’s about time to check the patch level on my light bulbs”.

For reasons such as this, these vulnerabilities will always exist and malware like Marai will always be a threat. And you thought the only thing you had to worry about was dropping your phone into the toilet.