Featured Post, HTB

HTB Blunder Writeup

Introduction

This is my second writeup for a HackTheBox machine. The machine is called ‘blunder’ and the name gives a clue that a blunder could have happened. This box is an easy machine and should be solvable within a reasonable amount of time.

Nmap

As always, we start with a port scan using Nmap. The result of this port scan is:

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

We first see port 21, which is an FTP server. However, the port is closed. The next port is 80, which is an Apache HTTP server.

Webserver

The webserver reveals that there is a website running on port 80. Scanning the website manually did not result in anything interesting. Therefore, we decided to run dirbuster onto the webserver. The directory/file scan revealed that there was an ‘/admin’ page available. The other interesting thing we found is the todo.txt file which contains a line: ‘-Inform fergus that the new blog needs images – PENDING‘. Which might mean that ‘fergus’ is a potential username.

The ‘/admin‘ page consists of a log in form and it displays that it is using the BLUDIT CMS. Googling for default credentials of the BLUDIT CMS we found out that the default username is admin, but there is no default password. We tried to log in manually using admin:admin as a credential for example, but it did not succeed.

Next we looked into the source code of the web page and we found out that there is some sort of version=3.9.2 extension added to some URLs. Googling on BLUDIT CMS 3.9.2 exploit and we found out that there is a brute-force exploit. Normally, the CMS blocks a user after 10 invalid tries, however it is possible to perform a brute-force attack when we manually change the X-Forwarded-For header type.

The exploit contains a Python script which performs the brute-force attack. We first needed a wordlist. We decided to use cewl to generate a wordlist based on the webpages on the webserver. Running the Python script using the generated wordlist, we found out that the username was fergus and the password was RolandDeschain.

We logged into the portal using the previously described credentials. We found some noticing pages and one of them was an image upload page. Googling about this image upload page we found a vulnerability: CVE-2019-16113. Abusing this resulted in a reverse shell as the www user.

When we had the reverse shell as the www user, we found out that the server consists of two versions of BLUDIT. On both versions we went to the database folder and looked into the users.php file. On version 3.9.2 we found this:

{
    "admin": {
        "nickname": "Admin",
        "firstName": "Administrator",
        "lastName": "",
        "role": "admin",
        "password": "bfcc887f62e36ea019e3295aafb8a3885966e265",
        "salt": "5dde2887e7aca",
        "email": "",
        "registered": "2019-11-27 07:40:55",
        "tokenRemember": "",
        "tokenAuth": "b380cb62057e9da47afce66b4615107d",
        "tokenAuthTTL": "2009-03-15 14:00",
        "twitter": "",
        "facebook": "",
        "instagram": "",
        "codepen": "",
        "linkedin": "",
        "github": "",
        "gitlab": ""
    },
    "fergus": {
        "firstName": "",
        "lastName": "",
        "nickname": "",
        "description": "",
        "role": "author",
        "password": "be5e169cdf51bd4c878ae89a0a89de9cc0c9d8c7",
        "salt": "jqxpjfnv",
        "email": "",
        "registered": "2019-11-27 13:26:44",
        "tokenRemember": "589552f4a62750326616c47e450ce96d",
        "tokenAuth": "0e8011811356c0c5bd2211cba8c50471",
        "tokenAuthTTL": "2009-03-15 14:00",
        "twitter": "",
        "facebook": "",
        "codepen": "",
        "instagram": "",
        "github": "",
        "gitlab": "",
        "linkedin": "",
        "mastodon": ""
    }
}

While on the newer version 10 we found this:

{
    "admin": {
        "nickname": "Hugo",
        "firstName": "Hugo",
        "lastName": "",
        "role": "User",
        "password": "faca404fd5c0a31cf1897b823c695c85cffeb98d",
        "email": "",
        "registered": "2019-11-27 07:40:55",
        "tokenRemember": "",
        "tokenAuth": "b380cb62057e9da47afce66b4615107d",
        "tokenAuthTTL": "2009-03-15 14:00",
        "twitter": "",
        "facebook": "",
        "instagram": "",
        "codepen": "",
        "linkedin": "",
        "github": "",
        "gitlab": ""}
}

What we see is that the old version contains two accounts using a password and a salt, while the newer version contains a password of the user Hugo. This is one of the users we saw when we went to the Home directory. We looked at the hash and it seemed like it was a SHA1 hash. So we used an online decryptor and found out that the dehashed result was Password120. So we used the “su – hugo” command to switch to the user Hugo and retrieved therefore the user.txt file.

Root

Root was much easier than expected. Analysing the box revealed that the current user (Hugo) is allowed to spawn a bash shell as sudo. Therefore, we used the command “sudo -u#-1 /bin/bash” to spawn a shell as root and retrieved the root flag.

Summary

Overall, this box was easier than expected. However, we still learned a lot. One of the things I learned was how to generate a custom password list based on the content of the webpages of the webserver. Next, I also learned how to perform a privilege escalation using the “sudo -u#-1 /bin/bash” command. I hope to finish a new (medium) box later this week.