Writeup was a box listed as “easy” on Hackthebox.eu. While it was technically easy, its use of fail2ban had the potential to slow down one’s progress toward user, and getting the root flag required careful enumeration under particular circumstances.
Hints
(highlight to reveal)
User: The root webpage makes it clear scanning is not going to be easy. Is there another way to identify potentially sensitive web server resources? Does that information ever get intentionally ‘leaked’ by the web admins themselves?
Root 1: Go a little deeper with your enumeration. Typical tools, like linenum.sh, may not show you what you need.
Root2: A key element of the exploitable vulnerability chain is triggered by a particular event. Be sure to be interacting with the box in a variety of ways while you are enumerating it.
Root3: During enumeration, pay particular attention to directory permissions, and scheduled processes and their commands.
Initial Enumeration
Per the box page, writeup is a Linux host sitting at 10.10.10.138 in the hackthebox firing range network. Initial nmap scans didn’t reveal a whole lot:
root@kali:~/htb/writeup# nmap -v -Pn -n 10.10.10.138 -p1-10000 -oG writeup.gnmap Starting Nmap 7.70 ( https://nmap.org ) at 2019-08-08 20:05 EDT Initiating SYN Stealth Scan at 20:05 Scanning 10.10.10.138 [10000 ports] Discovered open port 22/tcp on 10.10.10.138 Discovered open port 80/tcp on 10.10.10.138 Completed SYN Stealth Scan at 20:06, 24.81s elapsed (10000 total ports) Nmap scan report for 10.10.10.138 Host is up (0.031s latency). Not shown: 9998 filtered ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http Read data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 24.87 seconds
Further scanning of higher TCP ports and UDP scans reveal no other open ports.
So, I hit the web page and got a cool ASCII floppy.
Right off at the top of the page is this warning that the site is protected from DoS attacks:
Not yet live and already under attack. I found an Eeyore DoS protection script that is in place and watches for Apache 40x errors and bans bad IPs. Hope you do not get hit by false-positive drops!
This means scanning the machine is going to be a bear. I tried messing with timings in dirb, and even trying to slow-roll things with a two-second delay between requests, I was still getting blocked. This was going nowhere.
However, I’d forgotten to first go after the lowest of lowest-hanging fruit: robots.txt.
User
Going to hxxp://10.10.10.138/writeup reveals the under-construction writeups site.
jkr has working notes for ypuffy, blue, and writeup. Ypuffy and blue are complete(ish). And Ypuffy provides some credentials which were used on that box (and which prudence suggests saving for later), while blue was an EternalBlue box, of limited use here. The writeup writeup, is, well…
Yeah. Not useful. Too much to hope, really.
Anyway, meta tags in the source code for the page shows that this is built on CMS Made Simple.
Searching through ExploitDB and online, there are several authenticated RCEs, and one unauthenticated SQLi to leak the admin password. Simply plugging in hxxp://10.10.10.138/writeup/admin prompts for basic authentication, so this may be our way in. As a side note, 401 unauthorized errors trigger the DoS protection, so brute-forcing was out of the question.
The SQLi is in the CMSMS news module, and while there are no ‘news’ links on any of the exposed pages, visiting the url targeted by the script:
hxxp://10.10.10.138/writeup/moduleinterface.php?mact=News,m1_,default,0
shows that the news module is indeed installed.
The script uses time-based blind SQL injection to retrieve the site-wide password salt, admin username, admin e-mail address and admin password hash character-by-character in what I can only describe as a very pretty manner.
The hash is just an md5 hash, but CMSMS prepends a site-wide salt to its passwords, and by default, John can’t handle salted md5. I didn’t happen to have hashcat installed when I was attacking this box, so I put together a simple rule to make john prepend the hash to all my the crack attempts.
root@kali:~/htb/writeup# cat john-local.conf
[List.Rules:WriteupAppend]
A0″5a599ef579066807″
I then ran john in the same directory as the john-local.conf file with the rule enabled, like so:
john –format=raw-md5 password.txt –wordlist=/usr/share/wordlists/rockyou.txt –rules=WriteupAppend
And a short while later, I had the password:
root@kali:~/htb/writeup# john –format=raw-md5 password.txt –show ?:5a599ef579066807raykayjay9
1 password hash cracked, 0 left
Stripping off the salt (5a599ef579066807) left “raykayjay9”
That didn’t work on the CMSMS login page, but it did work via ssh. And the user flag was right there.
Root
This is where writeup got tricky and frustrating. While the ultimate exploit is technically simple, finding it was challenging and there were several rabbit holes I went down.
Upon first dropping into my user shell, I found that the box was missing (or I didn’t have access to) a handful of useful binaries, like strings and less, which was slightly annoying.
I uploaded linenum.sh and a bashed-together python version of dirbuster to run against the web server on 127.0.0.1 (under the assumption that the DoS protection, now identified as fail2ban, wouldn’t block requests coming from the local machine). Neither turned up anything interesting or useful*. The credentials harvested earlier from the ypuffy writeup and the sqli injection similarly provided no further access via SSH or su.
I finally turned to the forums for a hint, and someone suggested using pspy, which allows for detailed monitoring of processes, including commands being executed and files being accessed, without root access. This was a new tool that I’d never encountered before, but I can see its utility, and will definitely remember it for the future.
At first, this produced several more dead ends, including trying to capture ephemeral files being written to /tmp/ by a scheduled root “cleanup.pl” job which touched several interesting files. After finding another forum post which noted that the box was easier to root during its initial release, when lots of users were interacting with it, my monitoring of processes while I actively poked at the box turned up a readable apache passwords file when I tried to login to the CMSMS admin interface.
Unfortunately, while I could read the file and get the hash, it did not seem to be cracking in any reasonable amount of time.
Finally, while watching what happened when I logged in and out via SSH, I saw that /etc/motd was being updated by a process with an interesting command line.
run-parts was being executed out of a custom path including /usr/local/sbin and /usr/local/bin.
(* – full disclosure, the crontab section of linenum’s output did have the PATH variable set with /usr/local/sbin and /usr/local/bin leading, but its only reference to run-parts was an explicit call to /bin/run-parts, so the PATH didn’t look significant.)
As it happened, one of my user’s groups (staff) had write access (but not read access) to both those directories.
I put the following into a script named run-parts:
#!/bin/bash
cp /root/root.txt /home/jkr/root.txt
chown jkr /home/jkr/root.txt
Copied it into /usr/local/sbin/ then logged back into the box in a different window.
That’s it. Thanks to jkr for putting together a deceptively simple machine and teaching me a few things, and Hackthebox for hosting it!
-30-
Off-Kilter Security 