XXE and JSON Web Tokens Vulnerabilities | TryHackMe ZTH: Obscure Web Vulns

Introduction

In this walkthrough, we covered the last part of TryHackMe ZTH: Obscure Web Vulns room. We went over JWT and XML External Entity Vulnerabilities.

XXE

Certain applications will occasionally have you post an XML document to do an action. Improper handling of these XML documents can lead to what’s known as XML External Entity Injection(XXE). XXE is when an attacker is able to use the ENTITY feature of XML to load resources from outside the website directory, for example XXE would allow an attack to load the contents of /etc/passwd.

Since the application doesn’t necessarily have to return data, you may not be able to get the contents of the external entity; however, that doesn’t mean all hope is lost. If you’re really lucky you may be able to use the php expect module to get RCE anyway.

JWT

certain JWT libraries have another devastating vulnerability. There is actually three possible algorithms, two of them RS256 and HS256 which we have already studied. There is a third algorithm, known as None. According to the official JWT RFC the None algorithm is used when you still want to use JWT, however there is other security in place to stop people from spoofing data.

Unfortunately certain JWT libraries clearly didn’t read the RFC, allowing a vulnerability where an attacker can switch to the None algorithm, in the same way one switches to RS256 to HS255, and have the token be completely valid without even needing to calculate a secret.

Exploiting XXE to Read Server Files

The first challenge I tackled was an XXE vulnerability. I was presented with a web application that had a registration form. Looking at the requests in Burp Suite, I noticed that the registration data was being sent in an XML format. This immediately made me think of XXE.

My goal was to see if I could inject a malicious XML payload to read files from the server. I modified the XML request, adding a DOCTYPE element and defining an entity that would attempt to read a file. My first attempt was to read the id_rsa file, which would have been a huge win, but I was denied due to file permissions.

Not discouraged, I switched my target to the /etc/passwd file, a classic target for LFI and XXE attacks. This time, it worked! The application’s response included the entire content of the /etc/passwd file.

With this information, I was able to answer the challenge questions. By counting the users in the file, I determined there were 31 users on the system. I also found the user with a UID of 1000, which was “peda“.

Cracking JWTs and Taking Control

Next up was a JWT challenge. I already knew that a JWT is made up of a header, a payload, and a signature. The signature is what keeps the token secure, ensuring that the payload hasn’t been tampered with.

In this challenge, my task was to brute-force the JWT’s signature. I used a tool called jwt-cracker to do the heavy lifting. After cloning the tool’s repository and installing it, I ran it against the JWT token provided in the challenge.

The cracker went to work, and after a short while, it found the secret: “pass“.

With the secret in hand, I could now forge my own valid JWTs. I went over to jwt.io, a fantastic online tool for working with JWTs. I pasted the original token, and then, using the secret I had found, I was able to modify the payload. I changed the “name” field in the payload, and jwt.io automatically calculated the new, correct signature. This meant I could create a valid token with any information I wanted, effectively bypassing the application’s authorization checks.

Technical Commands Used

Here are the technical commands I used on the terminal during this process:

• git clone [repository URL]
  • This command is used to download a copy of a Git repository. I used it to get the jwt_cracker tool from its online repository.
• sudo apt-get install npm
  • npm (Node Package Manager) is a package manager for JavaScript. I needed to install it to get jwt_cracker to work.
• sudo npm install -g jwt-cracker
  • This command uses npm to install the jwt_cracker tool globally on my system, making it easy to run from anywhere in the terminal.
• sudo jwt-cracker [JWT token]
  • This is the command that actually runs the jwt_cracker tool. I provided the JWT token from the challenge, and the tool began the brute-force attack to find the secret.

Room Answers

Video Walk-through