Scanning
We run nmap on all ports with scripts and software versions.
Enumeration
We access the web service.
We find a section to authenticate and others to register, we use this one and create an account.
Click on the "Upload a threat report" section and you will find a form to upload files.
Form to upload files:
It seems to let us upload the file.... But where is it?
We decode our JWT of the registered account and see that the "jku" field is calling a "jwks.json" file.
Content jwks.json file:
Exploitation
For this part, I was helped by the following article
I follow the tutorial and create one public and one private key:
Now would be the time to build our own "jwks.json" file and generate the value of "n" and the value of "e" and trick the application to load the file from a fraudulent endpoint.
We create an Python script:
!#/usr/bin/python3
from Crypto.PublicKey import RSA
fp = open("publickey.crt", "r")
key = RSA.importKey(fp.read())
fp.close()
print("n:", hex(key.n))
print("e:", hex(key.e))
We run the script and we will have the value of both letters:
We modify the file "jwks.json" with our values and raise a server with python.
Trying to enter the url again and leaving the attacker's url behind, we see that it accepts the jwt, although it redirects us to the login and we do not get the server to execute our file.
Create JWT:
Use in Burp:
If we review the fuzzing performed with the wfuzz tool, we see that we have listed some actions that we did not have authorization, I was curious about the "redirect", as it could be exploited for the server to make the communication with my attacker machine and make it load my malicious "jwks.json" file.
We create our JWT by adding the redirect to our machine.
The server has loaded our malicious file.
We change our nickname to "admin" and repeat the above process.
We change the cookie, refresh the page and log in as the "admin" user:
We see the "display" section, it seems that it loads local files.
We try to load the file "/etc/passwd", but it seems that there is some filter to bypass.
We intercept in Burp and encode in "unicode" format (the host name is the clue ;)) and we get to load the file "/etc/passwd".
We read the flag from "user.txt".
.
Viewing the headers, we load the file of available sites in nginx, we list commented information from a file "db.yaml" stored in the user's folder
We obtain some creds from the DB:
We reuse the creds via SSH and they work, we see that we can run the "treport" binary as root and with SUDO.
Privilege Escalation
It seems to allow us to create, read and download a report, this could be running some binary underneath that we have access to, or it could be abused to modify some other system file.
If we try to download, we enter our IP address and it downloads from our machine.
Result on attacker machine:
I did other tests, I saw that in one of them it makes a curl.
If we see the curl options, there is a very interesting one, since it allows us to pass by parameters a configuration file to read it
I did several tests, in one I did get it to run and read the "root.txt" file successfully.
About
David Utón is Penetration Tester and security auditor for web and mobiles applications, perimeter networks, internal and industrial corporate infrastructures, and wireless networks.
