AdmirerToo is a hard rated machine on HackTheBox created by polarbearer. For the user part we will abuse a SSRF on an adminer installation. This results in access to a vulnerable OpenTSDB installation we are able to abuse to obtain a reverse shell. Finding database credentials for adminer we are able to grab the first flag. Finally we will combine the file write, achieved abusing a deserialization CVE in opencats, with a CVE in the installed fail2ban version to fully compromise the machine.
User
Nmap
As usual we start our enumeration with a nmap scan again all ports followed script and version detection scan against the open ones to get an initial overview of the attack surface.
All ports
1 |
|
Script and version
1 |
|
Vhost discovery
The filtered ports look interesting but we aren’t able to do anything about those yet. Going over to port 80 and doing a directory brute force with gobuster it looks like an ordinary webpage.
1 |
|
Opening a directory in our brower we see that listing is enabled and a hostname is leaked through an email address in the mailto href.
Bruteforcing for additional vhosts using ffuf we find db so we add db.admirer-gallery.htb and admirer-gallery.htb to our /etc/hosts file and continue from there.
1 |
|
SSRF
Going to db.admirer-gallery.htb we see the landing page of adminer which also includes the current version.
This version seems to be vulnerable to CVE-2021-21311 but the login page looks different from the PoC. The reason for this can be found doing another directory brute force with gobuster which finds a plugins dir.
1 |
|
Directory listing is also enabled here and we see that the one-click-login plugin is the reason for the different landing page. The plugin allows for quicker authentication by already providing everything needed to connect to a database.
To test the SSRF we first point the PoC at localhost port 80 which we know exists.
1 |
|
We press enter on the only connection on the landing page and intercept the request.
Like in the PoC we change the driver to elastic and set the server to our tun0 ip.
Forwarding this request we get a hit on the python webserver which get’s redirected in turn.
1 |
|
Looking at the initial browser page the source of http://admirer-gallery.htb got retrieved meaning our SSRF exploit is working and we even get the output of the request.
To partially automate the intercepting, changing and filtering of the retrieved content we can use a small python script which makes our life easier. All it does is to perform the request like we did in burp using a session, extracts only the response from the SSRF and decodes the html entities.
ssrf.py
1 |
|
We saw earlier that there were filtered ports. Since we are now requesting from the inside we might be able to retrieve information from them. Checking for the application on port 4242 there seems to be an OpenTSDB installation running.
1 |
|
1 |
|
Opentsdb
Referencing the documentation we retrieve the api version in the next request.
1 |
|
1 |
|
Looking up the version number we are able to find that it might be vulnerable to CVE-2020-35476. Searching further this github issue mentions how to exploit it. To test it we request the same query as in the issue.
1 |
|
Next we set up a python webserver to serve a shell file containing a reverse shell that connects back to the ncat listener we also start.
1 |
|
shell
1 |
|
1 |
|
Sending the payload does however not result in a shell but a rather long stack trace. Taking a closer look at it the sys.cpu.nice metric mentioned in the issue does not exist in the installation.
1 |
|
Retrieving the available metrics in the next request by querying the api we see that only http.stats.web.hits is available.
1 |
|
1 |
|
Changing the metric in the url we try our luck again. Running ssrf.py this time we get no immediate response and it hangs.
1 |
|
1 |
|
1 |
|
Our webserver got a hit for the reverse shell.
1 |
|
And our listener got a connection back as the user opentsdb which we upgrade to a full tty using python.
1 |
|
Db credentials
Checking the source code of server.php in the earlier discovered plugins directory. We find credentials for another database user next to the ones we already have.
1 |
|
The only other real user next to root is jennifer and trying the password for her over ssh we are able to log into the machine and grab the user flag.
1 |
|
Root
Intended
For the root part we will go over the intended method and an alternative method that involved abusing the misconfigured ACL on the /opt directory.
Opencats deserialization
Enumerating the machine as jennifer we see that port 8080 is listening on localhost.
1 |
|
To take a close look at it we forward the port to us using the ssh-console. To enter the console enter ~C on a new line.
1 |
|
Opening the forwarded port in our browser we see the login page of an opencats installation which also leaks the installed version.
Checking google for known vulnerabilities in opencats there is this blogpost showing a way to exploit insecure deserialization to achive filewrite on the system (CVE-2021-25294 and CVE-2021-25295).
Testing the credentials we found so far against the login page we have success with the combination jennifer:bQ3u7^AxzcB7qAsxE3
The blogpost performs the exploitation as administrator user. Since we can read the source code of the application we might be able to access the databse and escalate to an administrative user aswell.
Looking at the config.php reveals the database name , the user and the db password.
1 |
|
Using this credentials we are now able to log into mysql.
1 |
|
From all the tables the user table sounds most interesting in our quest to become administrator.
1 |
|
Describing the table the two fields involved in authentication seem to be user_name and password.
1 |
|
Retrieving the values from the table we get the hash for the admin user.
1 |
|
Instead of cracking it we can just update the hashes of the other users to be the same as the hash of jennifer.
1 |
|
Now we are able to log into opencats as admin user using jennifer’s password bQ3u7^AxzcB7qAsxE3
To test the filewrite we create a small testfile on our local system which we want to write on the remote end.
1 |
|
To create the payload we use phpggc(exists in kali repo) as mentioned in the blogpost. Since we don’t know which user the web application is running as we need to use one generally everyone has write access to. Sometimes users have their own /tmp directory so we will use /dev/shm in this case to test it.
1 |
|
Following the PoC we intercept a page refresh on opencats and send it to repeater for a request with admin cookies. Then we replace the path and query with the one in the blog and finally the last parameter with the payload generated by phpggc.
After sending the request in burp and checking inside /dev/shm as jenny we see our file got created by the user devel.
1 |
|
Furthermore the file got written as the dump of a cookie array as the blog describes it.
1 |
|
Checking for other directories devel can write to, we find an interesting looking one in /usr/local/etc.
1 |
|
Fail2ban
This seems like we might be able to overwrite configuration files for certain applications on the system. Enumerating the system further another interesting find is that a vulnerable version of fail2ban is installed on the system.
1 |
|
This github issue mentiones that fail2ban can be exploited if we are able to point the whois query to a server under our control. Whois can have a configuration file whois.conf which lists which server to query for certain domains.
We already have write access in the directory we need the only problem now is the format of the file we are able to write.
Looking at the source code of whois, the buffer for a single line is only 512 bytes long and additional whitespaces are being ignored. This means we might be able to close the charset inside [] complete our config entry and fill the rest of the line buffer with whitespaces, effectivly removing all the bad characters.
whois.c
1 |
|
This explains the general approach on how to build the payload.
1 |
|
Building our payload file with python and phpggc we send it in burp using an autenticated admin session.
1 |
|
1 |
|
Checking /usr/local/etc/whois.conf the file got created.
1 |
|
Performing a whois query it now reaches out to our machine.
1 |
|
The thing that is left to do now is to create the payload like mentioned in the steps of the github issue and host it on port 43 using nc.
1 |
|
1 |
|
We also set up our nc listener to catch the reverse shell if the exploit is successful.
1 |
|
Next we need a way to trigger fail2ban. Taking a look at its config files we see that it is enabled for ssh (/etc/fail2ban/filter.d/sshd.conf, meaning we can easily trigger it with a quick hydra brute force.
1 |
|
After a few second whois reached out to our machine, the payload gets sent and we recieve a reverse shell on our other listener.
1 |
|
Now we can grab the root flag.
1 |
|
Unintended
There was also an unintended method that skipped accessing the database and performing the deserialization exploit.
Folder permissions
Looking at the ACL of /opt every user has write access to it.
1 |
|
This means we can simply move the opencats folder somewhere else and copy it back to the location.
1 |
|
This way we took ownership of the application.
1 |
|
Now we can simply write a small php web shell in the root of the web app.
1 |
|
Accessing the shell from inside or outside doesn’t really matter but we use ssh to forward it to our machine.
1 |
|
Now we can use curl to achieve RCE as the user devel.
1 |
|
To get a persistent shell we set up a ncat listener and curl our shell file from earlier which we pass to sh.
1 |
|
1 |
|
After it connects back we upgrade it to a full tty using python.
1 |
|
Being devel we can now simply write the whois.conf in /usr/local/etc/
1 |
|
The other steps of the fail2ban exploit stay the same. We create our payload, serve it on port 43 using ncat and trigger it using hydra with a bruteforce against ssh.