Headless
Enumeration
nmap -v -A -p- -Pn -sV -sC headless.htb -oN nmapSSH 22
HTTP 5000
/
We see that backend set a cookie is_admin:
/support
/dashboard
In this case we obtain a 500 HTTP Status Code and cookie is not set as we can verify also using BurpSuite:
Instead if we modify the request to /dashboard using BurpSuite Pro and we set the value InVzZXIi.uAlmXlTvm8vyihjNaPDWnvB_Zfs as Cookie Header we obtain a different result (401 Unauthorized):
Using Decoder function we can see that the first part of Cookie value is "user":
Analyzing the website and in particular the form at /support using Wapiti we see in the report that there is no CSP configuration (probably the form is vulnerable to XSS).
Exploitation (user)
Testing for an XSS using BurpSuite on different fields of form result in a strange response HTML for the field message:
Rendering the strange response in a browser we obtain this one below:
The text of Hacking Attempt page says:
Your IP addrees has been flagged, a report with your browser information has been sent to the administrators for investigation.
This is an interesting clue, as it means that some of the malicious code we send is rendered in the administrator's browser, and if it is not properly encoded and interpreted as plain text but as HTML code, it is XSS passable and therefore we could try and steal the administrative cookie.
To obtain the administrator's cookie, we run a simple web server with Python:
that remains listening for any requests made via JavaScript injected into the administrator's browser by exploiting the XSS on the report form.
XSS on message field is not working as expected:
Since the form fields do not appear to be vulnerable to XSS, we need to try working on the HTTP request headers, which are then likely reported to the administrator for a thorough analysis of the "hacking attempt."
The XSS in the field #1 is that will trigger the theft of the administrative cookie.
The XSS in the field #2 instead, is the one to trigger the hacking attempt report and notify the administrator.
Now setting the cookie in the browser, we can finally access dashboard page:
Fuzzing for other hidden directories using administrative cookie is a fail:
Trying to intercept the "Generate Report" request and modify the POST parameter date by injecting some OS commands (Linux) return a beatiful result:
We need to obtain a reverse shell, so explore the binaries installed on victim machine that we can use:
Using python3 we will obtain a reverse shell.
On attacker machine:
On BurpSuite Repeater:
And the user flag:
Privilege Escalation
Under /appdirectory we can see some interesting files:
Do some enumeration with LinPeas:
Very good! We can run /usr/bin/syscheck as root thanks to sudoers permissions.
Exploitation (root)
Investigating the script further, we note that it is a BASH script, on which we have no editing permissions:
The vulnerability of this script lies in the execution of an initdb.sh script present in the same directory from which syscheck is invoked. Therefore, we simply place ourselves in a directory in which we have write permissions (/tmp will do just fine) and create a script with the same name but with a reverse shell to our attacking machine:
Add the permission of execution to the script (too much permissions in this case is not bad 😂 ):
Now start a listener on our attacking machine and run with SUDO the /usr/bin/syscheck script:
On our machine we obtain the reverse shell as root:
Last updated