Overview
This machine features an IT departments ticketing system that allows you to gain access by registering for a new account out of order. From here we find SSH credentials and connect as user. Following this we are able to locate credentials' of the CRM config.json file that provide the SQL credentials, that allow us to enumerate the back end SQL server for root credentials. This was fairly straight forward and fun machine.
Tools used
Linpeas
SQL Map
Burp Suite
Recon
Initial recon with NMAP showed just two ports. One for an SSH connection and another for a website.
-sV to get versions of service
-sC run common scripts
The scan found two services running:
22: SSH; Generally just hear for access after acquiring credentials in the environment.
80: Web Server; This is the clearest attack vector at this point, without scanning hirgher ports.
Enumeration: Web Site
Looking at the website initially shows a contact form and a HelpDesk link which already has me thinking this could be some type of form or POST manipulation.
http://helpdesk.delivery.htb/
http://delivery.htb:8065/
Browsing to the website resolved in a reverse look up name instead of the usual forward lookup. Initially this struck me as odd and I proceeded to burp the request to look for any redirection. When nothing was found here I moved on to DNS digging with the dig command and found nothing out of the usual. Then it occurred to me to update my /etc/hosts file.
127.0.0.1 localhost
127.0.1.1 kali
10.129.162.56 helpdesk.delivery.htb
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allroutersAfter updating the /etc/hosts file we are able to view the website properly. I try to always start a directory buster was OWASP Zap to check for additional content. I then use burpsuite to perform a subdomain enumeration, and finally start a website crawl with Owasp Zap. This all runs in the background simultaneously while I manually enumerate the web site.
Enumeration: Help Desk
We have found that the website appears to be a ticketing system run by osTicket
s Support Ticket System. This is a well known and widely adopted open source ticketing system. Looking around did not sure any active exploits for this ticketing system which lead me to start enumerating the web app.
Here I fire up Burp Suite and start going through the registration process.
Upon registering I noticed we are granted an @delivery.htb email. This initially strikes me as an opportunity for stored cookie stealing XSS attacks.
Back to the drawing board
I got absolutely nowhere trying all kinds of stored XSS attacks, that frankly I could not verify were even valid as there was no sign of an administrator or other user reviewing our post.
I proceeded to run a high port scan while I was testing XSS payloads and I found another port/service.
Enumeration: Mattermost
Matter most is a newer in the software market developed in the Go Language. There was initially nothing online about exploitation.
Reviewing the Mattermost website initially provides 2 URL's and nothing reported from directory busting or webpage crawling.
I decided it would be best process to fire up burpsuite and go through the registration process.
From here I had created an account but it had to be verified before I could login. There is really nothing we can do without a login at this point. I proceeded to check the ticket that referenced the ticket specific email ID, and found the verification email using my initial apples@apples.com email.
Copying the URL initially provided me with a 404 page and I was able to make no progression. But it dawned on me the domain was separate from the FQDN so I updated /etc/hosts/.
127.0.0.1 localhost
127.0.1.1 kali
10.129.162.56 helpdesk.delivery.htb
10.129.162.56 delivery.htb
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Upon gaining access to the webpage there is a user root and suggested credentials followed up a note about preventing the re-use of these credentials. Followed by comments about "PleaseSubscribe!" variants and hashcat.
We connect in with these credentials over SSH and gain the user flag.
Privilege Escalation
I did the usual when it comes to privilege escalation and by usual I mean the normal step in my process. This step is linpeas, and I uploaded it with SCP. From here it showed me several application config files were on the device including one for the mattermost application. Unfortunately I acted in haste when reviewing this folder and missed the credentials, which lead me down a a rabbit hole of several hours looking elsewhere. It was not until I had a third look over, I realized I had missed the credentials in plain sight.
Boom boom we are in the local SQL DB
After running these hashes through hashcat, johnny, JTR and such it became clear something was up. I recall the not we found earlier about not using iterations for our please subscribe password.
Also please create a program to help us stop re-using the same passwords everywhere…. Especially those that are a variant of “PleaseSubscribe!”
PleaseSubscribe! may not be in RockYou but if any hacker manages to get our hashes, they can use hashcat rules to easily crack all variations of common words or phrases.
Drop these hashes into hashcat and your good to go! So it struck me that I had to create a custom word list. This had to involve iterations of PleaseSubscribe!. So I created a file and added PleaseSubscribe to the file and used bash to append each line with a number at the end. I did exactly that with PleaseSubscribe!1-100.
Johnny had identified the hash as bcrypt but I ran it through hashcat just to be sure.
hashid
$2a$10$VM6EeymRxJ29r8Wjkr8Dtev0O.1STWb4.4ScG.anuu7v0EFJwgjjO
Analyzing '$2a$10$VM6EeymRxJ29r8Wjkr8Dtev0O.1STWb4.4ScG.anuu7v0EFJwgjjO'
[+] Blowfish(OpenBSD)
[+] Woltlab Burning Board 4.x
[+] bcryptI then ran my custom word list against the hases and cracked it with
PleaseSubscribe!21.
