Blunder just retired on Hackthebox, it’s an easy difficulty Linux box. This one got me a little frustrated at the beginning but in the end was quite fun and allowed me to play around with some useful tools and practice my Python coding skills. Good box if you like detective and guessing kind CTF ;)
Tl;Dr: To get the user flag you first have to find a text file containing the website CMS admin username. Then you have to bruteforce the account password using a custom word list made from the website content. Once logged you can exploit a RCE vulnerability on the CMS to get a shell as
www-data. There you find a file containing SHA-1 hashed password of
hugo user. After cracking it you can use it to pivot to
hugo user account and grab the flag.
To get the root flag you exploit a vulnerability in a specific configuration of
sudo in order to escalate your privileges and read the flag.
Alright! Let’s get into the details now!
First thing first, let’s add the box IP to the hosts file:
[[email protected] ~]$ echo "10.10.10.191 blunder.htb" >> /etc/hosts
and let’s start!
Let’s start with the classic
nmap scan to see which ports are open on the box:
[[email protected] ~]$ nmap -sV -sT -sC blunder.htb
We have a classical web app running on port 80. Port SSH 22 is closed, that’s unusual but let’s continue.
Opening http://blunder.htb display a following page:
The website seems quite basic, no images and the about page is practically empty and do not give any additional informations.
Checking the response header informs us that the website is running
[[email protected] ~]$ curl blunder.htb -I
Checking online we found out about it:
Bludit is a web application to build your own website or blog in seconds, it’s completely free and open source. Bludit uses files in JSON format to store the content, you don’t need to install or configure a database. You only need a web server with PHP support.
Looking around Bludit Github page we stumble across an Remote Code Execution vulnerability: “Bludit v3.9.2 Code Execution Vulnerability in Upload function“.
Looks pretty neat! Unfortunately this is an authenticated exploit… Let’s continue to dig.
Searching a bit more about Bludit we stumble across one interesting article:
Bludit Brute Force Mitigation Bypass
Versions prior to and including 3.9.2 of the Bludit CMS are vulnerable to a bypass of the anti-brute force mechanism that is in place to block users that have attempted to incorrectly login 10 times or more. Within the bl-kernel/security.class.php file, there is a function named getUserIp which attempts to determine the true IP address of the end user by trusting the X-Forwarded-For and Client-IP HTTP headers.
The reasoning behind the checking of these headers is to determine the IP address of end users who are accessing the website behind a proxy, however, trusting these headers allows an attacker to easily spoof the source address. Additionally, no validation is carried out to ensure they are valid IP addresses, meaning that an attacker can use any arbitrary value and not risk being locked out.
Those two articles gives a good insight of the path to follow. We should be able to brute-force the admin account and from there exploit the remote code execution vulnerability.
So our first step is to bruteforce our way to admin panel. According to Bludit documentation it can be found at
The original researcher who found the brute-force mitigation bypass provided a simple proof-of-concept. Let’s use it and adapt it to our needs:
We run it and… bummer. No password found.
When this happen it’s always good to go back at the beginning to make sure we didn’t miss any information.
Usually we would run
gobuster to see if we can come up with interesting files. Let’s give it a try now:
[[email protected] ~]$ gobuster dir -u "http://blunder.htb/" -w ~/SecLists/Discovery/Web-Content/big.txt -x php,txt,sql
todo.txt looks interesting:
[[email protected] ~]$ curl blunder.htb/todo.txt
“Inform fergus that the new blog needs images”. Looks like
fergus is very probably the admin of the blog. Let’s update our script and use
fergus as username this time.
…and no results again. What could it be now ? Maybe
fergus password is not in the old
rockyou.txt wordlist? This is where a bit of guesswork happens.
The Blunder website is having quite a lot of vocabulary, especially the Stephen King article which have a lot of names that could make a password.
Let’s try to extract long strings from the website and test them as password.
To do so we could create a Python script using BeautifulSoup. But there is a tool that can do the job perfectly called
cewl. This tool will allows us to create a wordlist from the website content:
[[email protected] ~]$ ruby cewl.rb "http://10.10.10.191/" -m 7 -w blunder.txt
Now let’s edit our script to use our newly made wordlist and run it:
[[email protected] ~]$ python bludit-bruteforce-bypass.py
Bingo! We got the credentials as
Once logged in as
fergus we access the Bludit main dashboard:
Now that we are authenticated we can take a deeper look at the vulnerability we found earlier: Bludit v3.9.2 Code Execution Vulnerability via Upload function.
We indeed have proper access to the upload function:
We now have everything need in order to exploit the vulnerability. There is even a Metasploit module available for it.
Using Metasploit is cool and all but doesn’t help to understand what’s really going on and how the vulnerability is working. So I decided to write my own script in order to better understand the problem and train my Python skills.
I ended up with the following PoC:
Let’s use it to open a reverse shell.
First we open our
[[email protected] ~]$ nc -l -vv -p 8585
Then execute our Remote Code Execution exploit:
[[email protected] ~]$ python CVE-2019-16113.py
And a new connection appear on our listener:
[[email protected] ~]$ nc -l -vv -p 8585
We now have a shell as
Looking at the
/home/ folder we can see that
Hugo hold the user flag. We need to find a way to pivot to his account:
[email protected]:/$ ls -l /home/
Hugo string returns an entry from
[email protected]:/var/www$ grep -ri "hugo"
Let’s take a look at it:
[email protected]:/var/www$ cat bludit-3.10.0a/bl-content/databases/users.php
Bingo! We have what looks like a SHA1 hashed password. Unfortunately
john can not seems to crack it:
[[email protected] ~]$ john --wordlist=~/SecLists/Passwords/Leaked-Databases/rockyou.txt hugohash
Being sure to be on the right track I checked online on
https://md5decrypt.net/en/Sha1/ website which managed to find it:
Since SSH is not open let’s try to use
su to change to
[email protected]:/var/www$ su - hugo
The first thing I like to check for privilege escalation to root is the
sudo config. It’s very often a good entry-point. This box was no exception and got an interesting config I never saw before:
[email protected]:/$ sudo -l
This configuration of
sudo is meant to allows a user to run a command as any user except root. Well that’s a bummer for what we need.
Yet it’s worth digging a bit more because after a bit of search on this configuration we stumble upon CVE-2019-14287:
A flaw was found in the way sudo implemented running commands with arbitrary user ID. If a sudoers entry is written to allow the attacker to run a command as any user except root, this flaw can be used by the attacker to bypass that restriction.
That’s exactly what we need. To summary,
sudo check user ID being passed incorrectly and convert it to
-1, or its unsigned equivalent
4294967295 user ID as
0, which is always the user ID of root user.
Let’s see if the version running on the box is vulnerable:
[email protected]:/$ sudo -u#-1 /bin/bash
That’s it folks! As always do not hesitate to contact me for any questions or feedbacks!
See you next time ;)