ATTACKING JWT’S WITH A CUSTOM SQLMAP TAMPER SCRIPT
Digging Deeper into the Code
Lets start to look under the hood of the site some more. Maybe the developers left a comment in the website code pointing to a hole. Maybe some JavaScript gets loaded that holds the vulnerability. Whatever it is, I have to look deeper.
The best tool for this job is called Burp. Burp works as a man-in-the-middle intercepting requests and responses from your browser to the website server. It holds a history of all transactions. The data can be analyzed further in Burp or even changed mid-transit.
Aside
Somewhere at this point I decided to go the easy route and test the site with some automated tools. I say “easy” because if the vulnerability is found this quickly, then it wasn’t much of a challenge. I tested the site with four tools:
- sqlmap: Test for SQL injection vulnerabilities in a number of places like the user/password form, the HTML Headers, and cookies. It found nothing.
- ZAP: Zed Attack Proxy is like Burp and used for finding vulnerabilities in web applications. ZAP is an open source program from OWASP while Burp has free, Professional and Enterprise releases. ZAP does not restrict many of Burp’s “professional” scanning tools. It found nothing
- XSStrike: I wanted to see if there was more to the XSS that I found earlier. It found nothing.
- XSSer: I still wasn’t satisfied and was determined to go down the XSS route. This tool also found nothing.
I was still convinced I was missing something to do with XSS. Anyways, back to Burp…
Burp Suite
Using Burp I capture a series of HTML transactions: 1. Register a user. 2. Login with the user.
- Notice on the bottom left, the HTTP Request, the password is sent to the site in clear text and I clicked the
loginbutton. - Notice on the bottom right, the HTTP Response, that a cookie is set. The site redirects to
/as seen in the next screenshot. - What I also learned from this is that the Response names the Server in the header
X-Powered-ByasExpress. This is the name of the NodeJS server.
This ones is getting much more interesting. This screenshot shows the redirect to ‘/’. This time I noticed that the cookie is quite large. I’ll have to find a way to decipher the values. Again, Burp has some built in tools to try out. Highlight the cookie value and then “Send to Decoder“.
OK. This is a type of token called a JSON Web Token (JWT). The giveaway is that it says "typ":"JWT". It also puts the username in as "username":"test". Some questions I start asking myself: How are they created? What do they store? What’s their syntax? How are they validated? And, most importantly as an attacker, how is it used in the site? Is there a known vulnerability? Maybe the site developer poorly implemented it and left a hole.
Another Aside: JWT Resources
As an attacker I’m looking for holes in the target. That means quite a bit of reading up on the various technologies that are found. Here’s were I looked for JWT’s.
- Start with the official docs at https://jwt.io/
- Programming documentation at a module for NodeJS and the python PyJWT library. I already learned that the website server is NodeJS Express. That means that the NodeJS module is likely used on the server to sign and verify JWT’s.
JWT Overview
Before I continue, it’s important to know a few things about JWT’s. These are the things that a hacker digs into in order to find the holes. JWT’s have three sections:
- Header – At a minimum, it declares the type (
typ) and algorithm (alg) for signing. In our token, you can see:
{"alg":"RS256","typ":"JWT"}
2. Payload – This section holds “claims”. There is some formality, but it could be anything to pass data. In our token:
{"username":"test","pk":"-----BEGIN PUBLIC KEY-----\nMIIBIjA.....","iat":1603605136}
- Signature – The signature is used to verify the Integrity of the Header and Payload. In our token it is binary data.
These three sections are separated by a ‘.’ and encoded according to a few accepted algorithms. That’s what we see in the screenshot above.
Coming up…
Now that I’ve discovered that the site uses JWT’s in the cookies to transfer information, I can start to work on them. I don’t yet know if they’re vulnerable so I’ll first have to put together a proof of concept to demonstrate that it’s possible. Then comes the real attack… which ended up being against the database. Stay tuned.
