MIRAI

SUMMARY

Content of a sensitive file is still on disk i.e. not overwritten, despite the file itself got deleted. Such content is viewable by user root. User pi can run all commands as root.

Pi as part of a default Raspbian install, does not have its password changed. Such password is the only auth required to ssh in as pi, and ssh is available to everyone.

REFERENCE

Pi-hole Userspace
Whitelist pre-populated on install?

WALKTHROUGH

Skip to accidentally obtaining foothold!
Skip to obtaining root!

Surface check.
nmap -p- mirai.htb | awk -F/ '/^[[:digit:]]/ {ports=ports$1","} END{print ports}' | xargs -I{} nmap -sV -sC -p{} mirai.htb -oA tcp_all
[Skid found awk and about to shop options at nmap docs to make this line less stupid.]

Scan result.

Host is up (0.79s latency).
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: Website Blocked
1244/tcp  closed isbconference1
32400/tcp open   http           Plex Media Server httpd
| http-auth: 
| HTTP/1.1 401 Unauthorized\x0D
|_  Server returned status 401 but no WWW-Authenticate header.
|_http-cors: HEAD GET POST PUT DELETE OPTIONS
|_http-favicon: Plex
|_http-title: Unauthorized
32469/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

Per nmap, ssh is open on port 22, domain service is open on port 53, and http is open on port 80 with “http-title: Website Blocked”. searchsploit: nothing interesting.

Maybe the virtual host if any is not mirai.htb and this causes blocking. Scan again but with ip supplied. nmap -sV -sC -p80 10.10.10.48, still “http-title: Website Blocked”. Decide to manual check.
curl 10.10.10.48 -v response contains header “X-Pi-hole: A black hole for Internet advertisements”. [Thought it was a firewall with troll built in for a moment but.] Need to unhole our target.

Visit Pi-hole website, right on the frontpage: “Our Web interface offers control of your Pi-hole and a central place to view statistics”. Actually prefer “Our Web interface offers statistics of your Pi-hole and a central place to control it”. Could waste time trying to log into this web thing, if unblock functionality is not even part of it.
Fail to locate relevant info in documentation. Decide to dig in discourse. Go through postings and unexpected enough: different discourse accounts but in their screenshots, web interface all have the same url, pi.hole. A public DNS server couldn’t possibly know out of all the Pi-hole instances which one to point to right. Resolving such domain sure can rely on users manually config their local DNS cache, but for an application proudly claim offering “network-wide” protection? Ehh. Also, wouldn’t it be weird if such domain is up to users to set up and multiple cute home users in a roll all come up with this boring ass name pi.hole?
Chances are this Pi-hole thing comes with its own DNS server and users only need to adjust some router settings to achieve “network-wide” typing in the given pi.hole and getting the web console page experience. Anyways, if a DNS server has record for pi.hole, this DNS server almost certainly belongs to a Pi-hole itself.
Recall that per nmap, there is one domain service open on port 53, might as well test it. If it leads to the Pi-hole, need to search for exploits despite searchsploit says nothing, maybe then we get to unblock target somehow; if not, can only download Pi-hole and check out web interface that way, should be faster now that no luck at discourse.

dig pi.hole @10.10.10.48

;; QUESTION SECTION:
;pi.hole.			IN	A
;; ANSWER SECTION:
pi.hole.		300	IN	A	192.168.204.129

[I know nothing about network if you haven’t noticed, but why the ip is not 10.10.10.48?]
ping 192.168.204.129 hangs.
dig -x 192.168.204.129 @10.10.10.48

;; QUESTION SECTION:
;129.204.168.192.in-addr.arpa.	IN	PTR
;; ANSWER SECTION:
129.204.168.192.in-addr.arpa. 300 IN	PTR	raspberrypi.

[I know nothing about network if you haven’t noticed, but why the name is not pi.hole?]
The returned host name of that Pi-hole thing is raspberrypi. According to Pi-hole documentation: “Despite the name, you are not limited to running Pi-hole on a Raspberry Pi. Any hardware that runs one of the supported operating systems will do”. But now it seems to really be a Raspbian, yeee.
No idea if the ssh open on port 22 belongs to this Raspbian as well, but decide to test ssh in with default cred pi:raspberry real quick before searching exploits for the domain service.

Greeted.

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.

pihole status

::: DNS service is running
::: Pi-hole blocking is Enabled

pihole -b -l

Displaying domains caught in the sinkhole:
/opt/pihole/list.sh: line 184: /etc/pihole/blacklist.txt: No such file or directory

pihole -w -l

Displaying gravity resistant domains:
raw.githubusercontent.com
mirror1.malwaredomains.com
sysctl.org
zeustracker.abuse.ch
s3.amazonaws.com
hosts-file.net

According to this reddit thread, a default whitelist contains all the above entries.
[I essentially blue-screened at this result for quite some time.]
cd /home/pi; ls

background.jpg  Desktop  Documents  Downloads  Music  oldconffiles  Pictures  Public  python_games  Templates  Videos

cd Desktop; ls

Plex  user.txt

[Target is a lie!]

Hats, hats time (it is sudo -l that worked).

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

sudo cat /root/root.txt

I lost my original root.txt! I think I may have a backup on my USB stick...

df | grep sd contains mount point /media/usbstick.
cd /media/usbstick; ls

damnit.txt  lost+found

lost+found empty, content of damnit.txt pretty much foreseeable.

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

[Probably not after you wrote a new file, James.]
[Better grep for that MD5, but I want to test something.]

debugfs:  blocks damnit.txt
8235 
debugfs:  block_dump 8234
0000  3364 3365 3438 3331 3433 6666 3132 6563  3d3e483143ff12ec
0020  3530 3564 3032 3666 6131 3365 3032 3062  505d026fa13e020b
0040  0a00 0000 0000 0000 0000 0000 0000 0000  ................
0060  0000 0000 0000 0000 0000 0000 0000 0000  ................
*

That’s it for the box.