Nmap scan:
We can add interface.htb to our /etc/hosts file.
The web application reveals this:
We can start with a simple gobuster scan to enumerate the possible endpoints in both directories and subdomains. However, the weird part is that there was nothing to be found from these.
We can try to see the HTTP requests that are being sent and received using Burpsuite. When sending a GET request, this is what we see in return:
There was a Content-Security-Policy (CSP), which is something I don't see often on HTB. Specifically, we can see that the unsafe-inline and unsafe-eval options are set. This is a security misconfiguration that is probably the foothold.
Within that field, we can also see a prd.m.rendering-api.interface.htb domain. We can add that to the hosts file, and go to it.
So this endpoint accepts a file of some kind. This, combined with the CSP configurations tells me that we are allowed to execute Javascript code on the machine somehow. Anyways, I still ran a gobuster on the domain just in case. Immediately, we would find quite a /vendor directory, which has more directories behind it.
/composer did not have anything I could make use of. I decided to check whether a /api endpoint existed because the URL had API in it, and it did.
Some JSON was returned, and there's mentionf of a 'route not defined' error.
I ran another gobuster search with a larger wordlist and the php,html,txt extensions to fully find all the stuff I can, and still found nothing. Only when I ran a ffuf scan using POST requests, did I find one interesting /api/html2pdf endpoint.
I did the same scan on the /vendor endpoint and found this:
Dompdf is a HTML to PDF converter for PHP. The exploit path is a bit clearer now.
dompdf has recentyl reported some RCE exploits using CSS File Inclusion.
The PoC states that by creating a CSS file that redirects the server to a PHP file, we can execute PHP code, which can be used to easily gain a shell. The PoC requires us to somehow generate a PDF, and I think that the html2pdf endpoint we found on API should work.
Now, we need to find out how to send HTML data into that API. Based on the PoC, we should be sending some HTML frames into this API. After some testing, it seems that the variable is html.
Now we can attempt to gain a shell. First, we need to create a PHP reverse shell one-liner and a malicious CSS file, then host them both on a Python HTTP server (hosting them on a PHP server does not work for some reason).
Take note that the PHP file has to be a legit CSS file, and we just need to change the extension to PHP. We can grab such a file from the Github PoC link I put earlier. Then, we can use vim to write this extra line:
Then, we need to find the SHA1 hash of the link to our server, in this case mine is http://10.10.14.22/exploit_font.php, which becomes a9e48a0532165b117a0ca8132955581e.
Then, we need to send this HTTP POST request to the API:
This would make the server send a GET request for both files:
On the machine, our file is now saved in the fonts directory as exploitfont_normal_d2706fefee906d9288c3b6c4bcddfe5a.php. After this, all we need to do is send a GET request to this URL: curl http://prd.m.rendering-api.interface.htb/vendor/dompdf/dompdf/lib/fonts/exploitfont_normal_a9e48a0532165b117a0ca8132955581e.php.
This would give us a reverse shell.
We can capture the user flag from this.
Finding the PE for this was rather challenging. I downloaded pspy64 to the machine to view it's processes and found an interesting cronjob running.
Here's the cleancache.sh script that is running:
This is running Exiftool 12.55, which does not have any glaring RCE exploits. The command run seems to only print out the Producer field from a file.
From this, we have to somehow include a reverse shell or something using escape characters. I notice that the Producer variable within the exiftool output is unquoted.
In Bash, a single quote would treat all characters within the quotes as strings and not process it. If it is in double quotes, variables and expressions will be processed.
So, in this case, we need to find a way to inject commands into the Producer variable in Bash. Here are some resources I've found when researching this:
The second one was the most interesting. Through naming a file a specific thing, we are able to inject commands into it:
The Producer field of this file is the vulnerability here. I tested this out on my machine, and it works.
Now, we can exploit this by creating a simple PE bash script to make /bin/bash an SUID binary. Then, we can change the Producer field to make the machine execute our script.
Then, we wait till it executes our script.
Interesting foothold, weird enumeration and really interesting PE through the unquoted variables.
