032#:HTB - Mirai
Today we will be tackling Mirai on Hack the Box. I’m going to take a wild guess and assume this may involve the Mirai botnet? Just a heads up, I got pretty off track with this one trying things that didn’t end up working. If you happen to be following along, you may benefit from reading ahead first.
I left this in because when I first started learning I felt overwhelmed reading walkthroughs and feeling like everyone knows exactly where to look for everything. Some people do, but they didn’t always and I needed help learning to move like a hacker would. Hacking will usually require a lot of prodding and testing things that don’t end up working. I got some good practice in this room, even though what I practiced didn’t necessarily help me solve it.
Anyway, let’s dive in with nmap.
They have some interesting ports open that we will want to check out. But for now, I will just run gobuster and poke around the website.
The IP didn’t resolve a home site, but when I navigated to /admin I discovered we are attacking a Pi-Hole device.
At the bottom of the page I found the version numbers for the Pi-Hole (Pi-hole Version v3.1.4, Web Interface Version v3.1, FTL Version v2.10). I’ll run a quick searchsploit query against these.
Cool, this seems promising. I noticed once I started reading the exploit code that it is actually requires an authenticated session. Still promising, but I don’t think we will use this yet. I tried looking for a default Pi-Hole password but that doesn’t appear to be a thing. Plex is offering HTTP so I pulled that up.
There doesn’t seem to be a standard set of credentials for Plex. Checking searchsploit only had a couple options, one of which is a txt file I started to read over.
This exploit isn’t going to work for us. Time to loop back to the nmap results.
I checked searchsploit for lighttpd 1.4 and OpenSSH 6.7. OpenSSH has a user enum exploit we may try to use, but I’d like to avoid blindly brute forcing logon attempts at this point. Searchsploit has some potentially interesting results for dnsmasq though.
I don’t know what they do so I just start going down the list and inspecting the payloads. First one needed some tweaking but didn’t end up working.
Looking at the contents of the payload there is actually a bit more I need to do to make this work.
Looks fairly straight forward. One thing I noticed was that in step 5 it mentions crashing the target system. If this is denial of service then its not going to help us, so I clicking on the google link they included at the top of the payload to read more about it. There I confirmed that this is actually an RCE vulnerability and probably worth going through the steps for.
I’m not super versed with docker so there was a bit of trial and error here. The commands right out of the box give me an error because it can’t find dnsmasq. Looking up dnsmasq docker images led me to this github link (use at your own risk).
I ran into some issues using that docker image because I am virtualizing my kali machine on a mac. This image wont work for me so I had to hunt down an image that was for arm64. That landed me here.
I’ve used docker a little bit before, but this has really been a crash course for me. I slowly worked through the docker setup steps. This required some googling and tweaking of the commands but I think we are getting there. I couldn’t use the commands exactly as the exploit presented them for docker, but google and claude.ai helped me fill in the gaps.
My docker image didn’t have python so I had to install that. I also ended up installing vim and deleting the entire comment section out of the poc.py payload. I probably could have just updated the comments but that’s okay.
Cool, making progress. Now we need to open another terminal window and another shell to the docker container. The more I played with this, the less it felt like this was the correct path though. This is just seeming more complicated than I would expect for one of the most defeated hack the box rooms.
It’s a new day and I need to recalibrate. I did some guided mode questions to get me back on track. This helped, but I am kicking myself right now. The guided questions have us trying the default raspberry pi credentials to get access. I was frustrated to see this as I had tried to log into /admin using this already. When I tried this again it still didn’t work.
That’s when I realized what I did wrong. This device is a pi-hole, which means it is likely running on a raspberry pi. I don’t need to log into pi-hole, I needed to use the default credentials to ssh into the pi.
I really should have gotten that on my own, but it’s moments like these that stick with you. I updated my personal notes to mention checking for default ssh credentials to things like pi’s. In hindsight, this should have been obvious given that Mirai took advantage of IoT devices using default credentials.
Checking the sudo rights for our pi user shows that we can run anything as root. That’s seems too easy, and looking for our root flag proves that to be true.
We found the location of the USB but still no luck.
We now need to find a backup of root.txt it seems. I first checked cron jobs to see if there was a task backing this file up somewhere. Looking at the drive info, I see mention of a SquashFS. I’ve never heard of it, but FS could mean File System so I gave it a google.
Thanks google, lets see how we can make use of this SquashFS file and see if it contains our final flag. This folder is already mounted so we can view the files as is. I’m running into permission issues when trying to access /root though and chmod seems to not work. I then tried to change the file permissions using unsquashfs, but its not installed. It then occurred to me I could change root’s password, switch to root, then view the files I don’t have access to!
While that got me access to /root, it didn’t have the flag. Maybe the USB was backed up too though? Nope, nothing in /media either. I started poking around some more and found another filesystem.squashfs file, so I think I need to get this to my machine and try to view the contents.
I don’t fully know what I’m doing so I am just googling any questions I have as I try to access the squashfs file.
After a bit more poking around I decided I needed to refer to the guided mode questions again. Catching up to where we are, they are saying to run strings against the mount point of the drive. I hadn’t know this was possible before now. I knew the concept of files not being immediately deleted but not that we could access in memory data for a mounted drive by reading the contents of the mount point.
This one was a whirlwind, I really went all over the place. A couple good lessons here though. First, I should have tried those default ssh credentials against SSH and not just for the pi-hole login. Second, we can possibly recover some deleted data from memory by running strings against a drive’s mount point.
That feels a bit more obscure but this is supposed to be an easy room, so maybe not. Either way, very fun room and I even got some good docker experience out of it. Even if I didn’t end up using it haha.