Web
Nmap discovered a web server on the target port 80
The running service is nginx 1.14.2
Webroot
The web server appears to be providing a service related to email
This turns out to be a button that leads to a sub-domain; helpdesk.delivery.htb
The CONTACT US button opens up a windows with some information.
It says to reach out to the helpdesk.delivery.htb domain for unregistered users.
It points out that MatterMost server becomes accessible with an email address, @delivery.htb
The MatterMost server button points to the web server running on the target port 8065
The domain information has been appended to the /etc/hosts file on Kali for local DNS resolution
Fuzzing
┌──(kali㉿kali)-[~/archive/htb/labs/delivery]
└─$ ffuf -c -w /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u http://delivery.htb/FUZZ -ic -e .php,.txt,.html
________________________________________________
:: Method : GET
:: URL : http://delivery.htb/FUZZ
:: Wordlist : FUZZ: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
:: Extensions : .php .txt .html
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200,204,301,302,307,401,403,405,500
________________________________________________
images [Status: 301, Size: 185, Words: 6, Lines: 8, Duration: 95ms]
index.html [Status: 200, Size: 10850, Words: 486, Lines: 312, Duration: 97ms]
assets [Status: 301, Size: 185, Words: 6, Lines: 8, Duration: 95ms]
error [Status: 301, Size: 185, Words: 6, Lines: 8, Duration: 93ms]
:: Progress: [882188/882188] :: Job [1/1] :: 429 req/sec :: Duration: [0:34:45] :: Errors: 0 ::Nothing useful found
Sub-domain discovery
┌──(kali㉿kali)-[~/archive/htb/labs/delivery]
└─$ ffuf -c -w /usr/share/wordlists/seclists/discovery/dns/subdomains-top1million-110000.txt -u http://$IP/ -H 'Host: FUZZ.delivery.htb' -fs 10850
________________________________________________
:: Method : GET
:: URL : http://10.10.10.222/
:: Wordlist : FUZZ: /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt
:: Header : Host: FUZZ.delivery.htb
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200,204,301,302,307,401,403,405,500
:: Filter : Response size: 10850
________________________________________________
helpdesk [status: 200, Size: 4933, Words: 781, Lines: 103, Duration: 111ms]
:: Progress: [114441/114441] :: Job [1/1] :: 426 req/sec :: Duration: [0:04:33] :: Errors: 0 ::Since the web server points to a sub-domain, I thought that there might be other sub-domains/virtual hosts that I am unaware of.
Fuzzing the web server resulted nothing. As far as the wordlist covered, there isn’t any. Except for helpdesk.delivery.htb
helpdesk.delivery.htb
Webroot of the helpdesk.delivery.htb sub-domain / virtual host
This is the support center with a ticketing system, powered by osTicket as shown in the footer
Authentication
While it appears that I am able to sign-up and sign-in through the /login.php file, there is an interesting button for “Agent”
Agent
Clicking into the Sign in here button for “Agent”, I get re-directed to a login page located at /scp/login.php
I am assuming that this is like the administrative login page for the support center application
It is confirmed that the /scp/ directory is used for Staff Control Panel in osTicket
The default credential shown in the official documentation of the osTicket Docker image doesn’t work; ostadmin:Admin1
It also appears that there is anti brute-force measure in place
Additionally, I tried some other weak credentials and basic injection techniques. None of them worked.
Sign-up
After several trials and errors to work with the authentication at the /login.php file, I decided to just create a testing account to see how the application behaves. I remembered the note that I saw earlier. It specifically mentioned that the @delivery.htb address is required to access MatterMost server
Sign-in
Attempting to sign-in with the newly created testing account fails as account confirmation is required
Ticket
It seems that opening a ticket does not require authentication
The ticket has been assigned an ID along with a temporary email to modify the ticket
This is rather interesting as it might be vulnerable to XSS
Using the information provided by the application, I got the “access denied” error
This is due to the registered email address that I provided (test@delivery.htb) being already present as a signed-up email prior that has NOT been “confirmed”
2nd Attempt
If I open up another ticket and register an email address that has never been “signed-up” (test2@delivery.htb)
I am authenticated as “Guest User”, and able to view the ticket that I opened up. Here I seem to be able to communicate with whoever is taking care of the ticket by posting a reply
The Post a Reply section supports file upload
I tried several XSS payloads to see if whoever on the other side would take the bait, but nothing happens. That would be too easy
Version
osTicket usually shows the version information in the footer, but this one appears to have it disabled.