Mirai — Hackthebox
Let's take a run at the Mirai machine at Hackthebox. To begin with, I'll scan the box with nmap 10.10.10.48 -A -T4 -p-.
Here I go pokin' ports again...
There are six open ports and a few services I've never heard of and they've got a website up. While we have Dirb working in the background to enumerate the subdomains of port 80 and port 32400, I'll explore the website on port 80.
It comes back with nothing. Hopefully Dirb will come back with some directories that I can poke around in. In the meantime, let's use the tried and true /admin subdomain.
It's a Pi-hole! After a quick search for Pi-hole default credentials, I learn that they're pi:raspberry. I throw the password at the login screen for the webpage. No dice.
I'll make a note of those credentials. Moving right along to the Plex server on port 32400. There's a login page for the server. Of course, I search for any default creds but that doesn't turn up anything. Trying the ol' standbys of admin:admin and admin:password doesn't produce results. Let's just sign up and see if we can mess around.
Wellllp. There's nothing here that's too interesting. There is a log file that I can access that gives me some information that could be a report finding, but outside of that I don't see anything that I can use to get access. What has Dirb turned up?
But wait, there's less.
I mean, mathematically speaking, it was a good choice to go for the box. Missed out on the red snapper, though.
I am undaunted! Dauntless, even! Let's go poke SSH with a stick.
I tried some more default creds but they didn't work. I'm not surprised. Then I had an idea: why not log in with the Pi-hole's default credentials?
Now that I'm in, it's trivial to navigate to the Desktop to snag the user.txt flag.
Just for fun, let's probe our privileges. I'll start by attempting to cat out the shadow file with sudo.
I didn't expect to have sudo privileges, honestly. That makes this next part simple—changing the root password to something ridiculous and then becoming root.
I'll just mosey on over to the root.txt file in /root and...
Looks like the Princess is in another castle. Let's search around for the USB.
With some research, I learn that a USB will show up in both the media directory (of course) and I can also go looking for it with the mount command.
I'll go for the low hanging fruit first by checking out the /media directory.
Okay... so, it looks like I'm going to have to try to recover some deleted files from the USB stick. But how? Oh and by the way, this one's for you James:
Dammit, Jim.
More research! The most common solutions I see to file recovery have to do with external programs such as Testdisk and Ext4magic. That isn't helpful considering that I can't have the remote system call out to install them (I tried). Could debugfs be a solution?
No. No, it is not.
There's only one thing to do...
I still have some plays to make. Poking around in the /dev/bus/usb directory yielded some interesting results. Namely, I couldn't cat out the files contained within. Or rather, I could but they were garbage. What kind of garbage is it?
Investigating the file type on /dev/sdb also yielded similar results.
Even more research reveals this nice little tidbit (thirdhand from Wikipedia):
"Block special files or block devices provide buffered access to hardware devices, and provide some abstraction from their specifics. Unlike character devices, block devices will always allow the programmer to read or write a block of any size (including single characters/bytes) and any alignment. The downside is that because block devices are buffered, the programmer does not know how long it will take before written data is passed from the kernel's buffers to the actual device, or indeed in what order two separate writes will arrive at the physical device..."
"Block special files or block devices provide buffered access to hardware devices, and provide some abstraction from their specifics. Unlike character devices, block devices will always allow the programmer to read or write a block of any size (including single characters/bytes) and any alignment. The downside is that because block devices are buffered, the programmer does not know how long it will take before written data is passed from the kernel's buffers to the actual device, or indeed in what order two separate writes will arrive at the physical device..."
So, ideally, sdb should still contain portions of the deleted data.
What'll happen if I just try to cat sdb file?
That's a ton of garbage! But it also contains our root flag right there at the bottom. Just for being complete, let's use strings on sdb.
Got it! This was a fun and easy box. I learned a ton about external devices and deleted files. I should remind myself to mess around with Testdisk and Ext4magic on some test files in the future.
See you Space Cowboy...
