secnigma posted: " Unicode was an intermediate machine developed by wh0am1root. This was a pretty interesting machine and it is all about bypassing filters. It had a cool initial foothold vector involving crafting a custom JWT, by using an open redirect vulnerability to "
Unicode was an intermediate machine developed by wh0am1root. This was a pretty interesting machine and it is all about bypassing filters. It had a cool initial foothold vector involving crafting a custom JWT, by using an open redirect vulnerability to bypass a JWK URL filter. After that, we could exploit an LFI to get a shell on the box bypassing the LFI filter using unicode characters.
To get root, we again bypass blacklist filter in a python compiled binary application, that can be run as root.
Let me elaborate on how I solved this box.
Exploitation
Nmap returned the following results.
Nmap scan report for 10.10.11.126 Host is up (0.061s latency). Not shown: 998 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 3072 fd:a0:f7:93:9e:d3:cc:bd:c2:3c:7f:92:35:70:d7:77 (RSA) | 256 8b:b6:98:2d:fa:00:e5:e2:9c:8f:af:0f:44:99:03:b1 (ECDSA) |_ 256 c9:89:27:3e:91:cb:51:27:6f:39:89:36:10:41:df:7c (ED25519) 80/tcp open http nginx 1.18.0 (Ubuntu) |_http-favicon: Unknown favicon MD5: E06EE2ACCCCCD12A0FD09983B44FE9D9 |_http-title: 503 |_http-server-header: nginx/1.18.0 (Ubuntu) | http-methods: |_ Supported Methods: GET HEAD OPTIONS Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
I've navigated to port 80 and found the following site.
Right off the bat, I saw an open redirection in the site, from the Google about us button.
Open Redirection means that a web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. Open Redirect cannot be considered as a vulnerability by itself. But, this can be used efficiently for phishing attacks and bypass some filters.
So as of right now, this is just an interesting find, and we have to keep digging to find any meaningful vulnerabilities.
So I've started gobuster and...
Oh, forgot to tell you all that I've shifted to Feroxbuster, after seeing it on an Ippsec video.
It's like gobuster, but with pretty colors, have almost the same syntax as gobuster and have recursive brute forcing. It's like mashing dirbuster and gobuster together and I love it!
I've feroxbuster-ed (Feels pretty weird, but I'll allow it!) the site and found a login page.
There was also a registration page. So, I've registered using that form and got logged in.
It had a form to upload threat reports in PDF format.
I've tried different exploits, but none of them worked.
That's when I noticed the JWT token in the target and I've shifted the focus to it.
I've decoded the JWT token and found that the token uses JKU header and it contained a URL, pointing to the JSON formatted JWK file.
A JKU header (JWK Set URL) in a JWT token refers to a JWK (JSON Web Key) object that is JSON encoded, which is used to verify the JWT.
The JSON Web Key (JWK) is a JSON object that contains a well-known public key which can be be used to validate the signature of a JWT signed with the corresponding private key.
So this means that, if the target performs improper JKU header validation, then we can host our own JWK file and thereby craft a valid JWT token. This is explained very well in this blog post.
I've used token.dev to generate the JWT interactively. ( JWT.io doesn't allow modifying the JWT interactively)
I've tried to modify the JKU header and changed the URL to my IP address, to see if I get a call back. But it didn't work. It showed the following error.
This means that there's some sort of validation of the JKU header in place.
That's when I remembered about the Open redirection I've found ealier.
With the help of some nudge and some trial and error method, I've found a valid bypass and got a connection back from the server!
The target validates the JKU header by checking if the URL starts with http://hackmedia.htb/static/ . So, if we go up one directory and use /redirect to point the target to my web server, then we can bypass the filter.
Now we need to craft a valid JWK in JSON format. Following is the jwks.json file's contents.
I'm going to change the username from secnigma to admin and validate it using my own jwks.json file.
To do this, we first need to generate a public and private key pair, extract the n and e values from the public key, update it to the jwks.json file and host the file in our web server.
Now, we need to paste the contents of publickey.crt file into token.dev 's Public key section and the contents of pkcs8.key file into token.dev 's Private key section.
Following was the private key I've genereated (pkcs8.key).
Following was the public key I've genereated (publickey.crt).
-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAscWmsvHj1sgQTxfBvUBc /oJXVS4Epo2+7kL7ayP/Z/FhxJXtkL/gcdkEXincvlhpStnf22rN+COUKhc6TWv4 qv9iS+J9uYoBiORGbVG0l9NZ6o+Tz//Jm9SJZDKsa0sNxrLBUHAQa2mPOKTMqB/P AG94muuXKU6wbB+lkTl/VDBToZCc+85W8CuLYd97DQZ+XebzRP4hFDaYMLVvJQNY feIUIZkuP+51WTwMLG/bxckF6zcm/I0Er53wc/NW23utzfk8SO/FhooEQkGbD9Rg 2saPmIn7wI3Ggpcfjbmhgl5VQOl5j4kgg4B81nrpjef5CUoCG34/Kmb31XlHfXyJ 1wIDAQAB -----END PUBLIC KEY-----
If everything went right, token.dev will display Verified in green color.
My JWT is now signed using the private key I've generated.
Now I need to find the n and e values from the public key and update it to the jwks.json file.
There was a python script provided in the given post, which will generate the required values from the public key in hex format.
So I did all of that and tried to login to the website, but it failed.
After some time and with the help of some nudges, I've found my mistake. The original jwks.json file had the n and e values in Base64 encoded format; not Hex format.
I've used the following python script to extract n and e values in a base64 encoded format.
# Generating n and e paramaeters from Crypto.PublicKey import RSA from base64 import b64encode as b64 def int2bytes(number): return number.to_bytes((number.bit_length() + 7) // 8, byteorder="big") fp = open("publickey.crt", "r") key = RSA.importKey(fp.read()) fp.close() n = b64(int2bytes(key.n)).decode() e = b64(int2bytes(key.e)).decode() print("n:", n.replace('+', '-').replace('/', '_')) print("e:", e)
And I've updated the jwks.json file with the base64 encoded n and e values.
The admin dashboard had some links to reports. If we click the link, it will direct us to a website with a URL, that takes the PDF file names of the report as the GET parameter.
Naturally I've suspected LFI.
So, I've tried the good old ../../../../../etc/passwd payload, but it showed a peculiar output.
So, there's some sort of filtering in place to prevent LFI. But can we bypass it? If yes, then how?
The answer lies in the name of this machine. Unicode!
This blog post does a great job at explaining about bypassing WAFs, using Unicode characters.
In short, this is a lot like URL parsing vulnerabilities mentioned in Orange Tsai's presentation called Breaking Parsing Logic.
We could use Unicode Compatibility of the WAF, to normalize unicode characters into ASCII; so that we could bypass any filters in place that checks only ASCII characters.
As mentioned in the post, we could use this site to convert ASCII values to it's unicode representaion.
I've used the unicode equivalent of ../ to test this bypass technique. The unicode payload is given below.
I've used this payload to succesfully bypass the WAF and include the /etc/passwd file.
Here, we are passing {‥ (U+2025)} character and the Flask web server is normalising it to ASCII's .. {Double dots}, thereby bypassing the filter.
After that, I've started manual enumeration of files using LFI.
Manual enumeration using LFI
I've found the Home directory of a user named code by requesting /proc/self/environ file.
Then confirmed the directory's existence using /home/code/.bashrc
And got user.txt this way.
Then I requested the file /etc/nginx/sites-enabled/default and got a very intersting file and it's possible location.
From this, we know that the web root is /home/code/coder and we need to find a file named db.yaml I requested /home/code/coder/db.yaml and found the password.
I've used the password B3stC0d3r2021@@! to login as code via SSH.
That was a loooong user pwn!
Privilege Escalation
Ran sudo -l and found that code can run a binary named treport as root.
The file had three functionalities.
Create, Read, and Download a threat report.
I've tried some common exploits and the program generated a familiar error message.
This looks a lot like Python error! So, this binary is compiled from a python script.
I've searched for Python disassembly and found some cool tools.
To disassemble python binaries, we first have to disassemble it into a .pyc file, which is the compiled bytecode. After that, we can convert it to a human readable .py script.
After reading the source code, noticed that there's a blacklist to filter input when downloading the report.
It blocks the user from accessing files with the protocoles file, gopher or mysql. However, it only checks the input if the string has the protocol specified in lowercase. This means that we can bypass this blacklist, by specifying the file protocol specifier as File.
I've used the following payload to extract the root flag using the follwoing payload.
File:///root/root.txt
I've tried SSH-ing into the box using the Private key, but couldn't.
Errm.. Kinda w00t?
Then I've found out about a way to execute commands in bash, without using white space.
No comments:
Post a Comment