ATTACKING JWT’S WITH A CUSTOM SQLMAP TAMPER SCRIPT
First look
I know the challenge is a website so open up the IP:Port address in a browser. It forwards to /auth:
http://192.168.100.1:1337/auth
I’m given a simple login screen (user and password) with two buttons, “Login” and “Register”. First, lets see how it is supposed to work and then move to seeing how to find the holes.
Register a User
I enter in some values and click Register. It forwards to the URL:
http://192.168.100.1:1337/auth?error=Registered%20successfully&type=success
There is a message on the screen saying “Registered successfully”.
Log in the new user
Re-enter the user and password and click Login. It forwards me to the URL:
http://192.168.100.1:1337/
A logged in user is given a blank site with a “Message from the developers”. Nothing else is on the page, other than a Logout button. I noticed that the Message is addressed directly to the username that I registered.
Test some false entries
This is standard QA stuff. When you’re developing a product or website, any feature added to the product gets a series of tests that are run to validate that they work as expected. There are a few combinations of data I can try to see how the site will handle input.
- correct username, empty password
- correct username, wrong password
- random username, empty password
- random username, random string for the password
- re-register a user.
- REALLY long username or password
- quote marks (‘). We’ll get to the reason for this in a bit.
These give out some standard responses as you’d expect. Like the Registered User message, they redirect to URL’s like:
http://192.168.100.1:1337/auth?error=Invalid%20username%20or%20password
http://192.168.100.1:1337/auth?error=Username%20already%20existsWhat I have already learned
I know the site is vulnerable to something, so where is it? Maybe I’m supposed to log into the site as an existing admin type user. Here’s what I’m thinking at this point. There are already some things that jump out to me as red flags:
- The only data input are username/password fields. The hole in the wall could be in the fields accepting something it shouldn’t.
- Notice that the message displayed on the page for “Registered successfully”, “Invalid username” and others comes from the URL. If that’s the case, It looks like I can get the website to say anything I want:
http://192.168.100.1:1337/auth?error=I%20can%20get%20this%20message%20to%20say%20anything%20I%20want
3.
This vulnerability is called a Client side Reflected XSS (Cross Site Scripting). It means I can change the data on the website. It’s not a permanent change (that’s a Stored XSS). The next test is to see if the browser will interpret HTML or JavaScript commands:
4. After a successful registration, the URL had another parameter: &type=success. Does the website code use this to validate a user? Can I trick the site into thinking that something worked, when it didn’t? Load the URL:
http://192.168.100.1:1337/auth?error=%3Cdiv%20onclick=%22alert(1)%22%3Etest%3C/div%3E
5.
This time the message on the screen does not have a red background. It looks like the type variable only changes the colour of the background–kind of like the type of message.
type=successgoes green.type=**anything_else**is white.- Without
typedeclared is like the default giving the message a red background. This won’t be very helpful.
This was just surface test of the site. In the next post, I’ll dig deeper into the code and use various tools to look for vulnerabilities.
