OBLIGATORY ‘HELLO WORLD’ HEADER
Below is a walkthrough of the steps I took to solve the Mirai (10.10.10.48) machine on HackTheBox. In this post, I will show you the good, the bad, and the ugly. Parts where I was right and wrong. Parts where I chased the wrong thing. All of it. The process I have written out in this post is how it happened for me so it isn’t the most streamlined version of how to solve this machine. It’s sort of a mix of a technical walkthrough and a story giving you a peek into how my mind worked as I made my way through solving this. So buckle in and prepare for a journey through Mirai.
I always begin my engagements with an Nmap scan using:
$ nmap -A -sV 10.10.10.48
I do this because I want OS identification if possible (-A) and service version (-sV) if possible. I am aware that the -A option is a loud scan but since I am not in a real live production environment, I am okay with using it here. I also know some people that scan all 1-65535 ports when doing an initial scan. I do not, for time purposes, but I am aware that there may be ports and services outside of the traditional scan range that I may need to scan from time to time. Thankfully, that didn’t seem to be the case for this machine.
I ended up with the following scan results:
Nmap scan report for 10.10.10.48
Host is up (0.19s latency).
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
| 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 (EdDSA)
53/tcp open domain dnsmasq 2.76
|_ 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).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
I saw the HTTP port open, so I went to my web browser and entered the IP address right away to see what’s up. Nothing came up. Knowing HTTP had to be open for a reason, I opened dirbuster and I began trying to enumerate some directories on the web server. It didn’t take too long before, ‘BINGO’, we got a 200 response on a directory.
I navigated to http://10.10.10.48/admin to find a Pi-Hole Admin Console. I personally don’t have any experience with Pi-Hole and I still don’t actually know what it does because I didn’t look too much into it. It appears to be some kind of filtering device. Moving along. What this did teach me though was a critical piece of information about the system: we’re dealing with the Raspbian OS on a Raspberry Pi. It’s always beneficial to know the OS you’re attacking but this particular OS was helpful in a specific way that I’ll explain shortly.
At this point, I did my first internet search for the machine that I do any time I run into a new system I’m unfamiliar with: “Pi-Hole Default Login Credentials”. After sifting through a handful of articles, I wasn’t coming up with any clear solid leads on default credentials for logging into the application. I guessed: no password, admin, and password. All with no success. I did however get a pop up during this process giving me a command to run letting me know 1) that the password was definitely not a generic one and 2) I should go back and check SSH because I saw that attack vector open earlier on my Nmap scan.
THE 20 MINUTE ERROR
While Pi-Hole does not have default credentials, Raspbian most certainly does. They use the default login of ‘pi’ being the username and ‘raspberry’ as the password. I initiated an SSH connection to the address and was met with a password prompt where I made my first ‘time wasting mistake’ of the night. I attempted to use the password ‘rasberry’ on the connection and I was met with an ‘Incorrect Password’ warning. At this point, I convinced myself that the default password had been changed and I was super bummed. (The next paragraph that follows is a story of wasted effort. You can skip it if you’re looking to get to the real progress again).
Thinking that the password had been changed, I went back to the Pi-Hole interface and began looking for a new attack vector. At this point I spent at least 15 minutes looking across the internet for exploits using the version numbers at the bottom of the Pi-Hole management interface window. To my frustration, I was not yielding much. Part of what was so frustrating about this was the rating of this particular machine was overwhelmingly ‘Easy’ and it’s discouraging when you feel stuck so early on a supposedly easy machine.
THE ‘P’ IS SILENT
I eventually took a break on Pi-Hole research and I went back to Raspberry Pi. About 20 minutes after my first SSH connection attempt, I had a brief realization that I had made a crucial mistake earlier. During all the reading on Raspberry Pi, ‘Raspberry’ just happened to catch my eye. Did you catch my mistake earlier? When I first attempted to connect to SSH, I misspelled the default password! So frustrating. Surely, if it was default, I was going to kick myself for the silly oversight.
I initiate another SSH connection, this time using ‘pi’ as the user and ‘raspberry’ as the password and what do you know…. we have USER.
Now that we have user, I am focused back on this admin portal. I always take lots of notes when I’m attacking a machine and I remembered the command it told me earlier for setting the password on the Pi-Hole login. So, right there in my ssh session, I ran the command:
sudo pihole -a -p PASSWORD
It worked! I can now login to the admin console on the web with the password “PASSWORD”. I paused though. After successfully running that command and confirming the password changed, I thought to myself “Did I just sudo with no password?” I figured, why not, let’s go ahead and sudo cat the root.txt file where it normally is and see if this is all over.
404 ROOT NOT FOUND
First of all, I knew it couldn’t have been THAT easy (though inside I was secretly hopeful). Second of all, screw this guy for storing his root.txt file on his flash drive. If you lost it, how do you know it’s on your ‘USB stick’ Bradley?! Sorry, I digress. Okay, let’s find this flash drive. I ran ‘mount’ to see what’s going on with disks.
Looks like our disk is mounted at /media/usbstick. I cd’d there to see whats up. No root file but there is ‘damnit.txt’. Can I just take a second to express the brief moment of dispair I had when I saw that filename and knew what I found inside was not going to be good? (reference cat results above)
James, you’re dead to me dude. You can’t just go around using your friends flash drives and deleting important looking files called root.txt. And you’re a coward of a friend too for letting him know in a text file message where he’s expecting to come back and find his good ole’ root document to find you’ve squandered it and are probably half way to Mexico by now.
GREP > FORENSICS (AT LEAST IN THIS SCENARIO)
Okay. How do we recover a deleted text file on a USB drive? I have no idea (thanks again JAMES). This part of the problem took me over 3 hours. I scrambled through so many websites. I installed forensics programs on here to do my bidding (none of them worked by the way). Testdisk, scalpel, foremost, I installed all of them and ALL of them saw the deleted file but none recovered it. So save yourself hours of wasted time and frustration and don’t make the same mistakes I did. Each time I’d get those forensics programs to dump the file, it never had the hash, if it even successfully pulled anything at all.
After hours of searching I found this command for recovering text files and slightly modified it below:
sudo grep -i -a -B10 -A100 'root' /dev/sdb > /tmp/file.txt
I modified it to fit my needs. Personally I’m not a super linux sysadmin so I don’t actually know in depth what this command is doing. Maybe you can tell me? All I know is I made some modifications to give it a shot. This command is only supposed to work if you know a string of text in the file. Considering what I’m looking for is a hash, I have no idea what’s inside it so I just put ‘root’ in the string and crossed my fingers. Then, I had to tell it which disk to search, I used /dev/sdb/ since I knew that was the path of my flash drive. Then I had to give it an output. I try to output things in the tmp folder always. This minimizes others who are working on the system from seeing my files and getting hints or worse, cheating and stealing ideas or steps that they didn’t actually figure out themselves how to arrive at.
I opened the file and saw a bunch of jumbled text including the damnit file. However, right above that text was a series of letters and numbers that looked JUST like the hash. I copied and pasted it into the HTB site hoping for the best and:
BEFORE YOU GO
Regarding the grep command, I am confident this could have only worked on the flash drive because there were only 2 files present on it: the deleted root.txt and the damnit.txt. If you ran this against the systems primary drive, I’d be willing to bet the nasty looking, jumbled mess inside this file (as you can see above) would be much worse and possibly even have so much data it would crash if you attempted to open it. Although, that’s purely speculation because as I said before, I don’t actually know the entirety of what this grep command did, only that others on the internet had used it to recover deleted text files before.
I appreciate you taking the time out of your day to read along and hopefully walk away having learned something, even if it’s what NOT to do. There are probably more streamlined ways to go about solving this system and probably even entirely different routes to getting user and root. That’s the beauty of HackTheBox, they let you perfect the science AND art of breaking into unique machines.
If you enjoyed this post, feel free to comment and/or send me a tweet letting me know. If people enjoy this, I will make it a more regular series. Thank you again for your time, and merry hacking.