Hey Everyone,
Hope you’re doing well. It’s been a While since my first write-up, I hope you learn something new from this one and enjoy it.
This post presents a new technique to exploit a bad implementation of JWT under specific circumstances, which allowed me to perform an Account Takeover attack and score a nice $3000 bounty. This is a simple yet very interesting thing I found, that’s why I believe it’s worth sharing.
Note: Before You start reading this write-up, you will need to have a basic understanding of what JWT is and how it’s being implemented as an authentication mechanism. Here are some awesome posts to get you caught up:
Digging In
The story begins when I was testing a web application listed in the scope of a private program hosted on HackerOne platform. At first, I started to look for common vulnerabilities, but with no results. The application is well secured and it’s been a while since the program started, so it’s highly likely that other hackers already found those kinds of bugs.
Then I decided to look closer at how the authentication process works. which is my favorite part whenever pretesting a web app.
The authentication is based on a JWT token, and the JWT token’s structure is very minimalist and simple, as described below:
JWT token Encoded:
1
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MTAzMDcsImlhdCI6MTY0NjIxOTU0NiwiZXhwIjoxNjgwNDMzOTQ2fQ.C6g3y48Q8ZFvElOtTwZ5NckObGXY5aX-Xn-7w-G3
JWT token Decoded:
1
2
3
4
5
6
7
8
9
10
{
“alg”: “HS256”,
“typ”: “JWT”
}.
{
“**id**”: 10307,
“iat”: 1646219546,
“exp”: 1680433946
}.
C6g3y48Q8ZFvElOtTwZ5NckObGXY5aX-Xn-7w-G3
Notice the “id” value, which represents to user’s account id. This thing immediately caught my attention, because if I found a way to change the “id” to a value associated with another user account, I can authenticate as that user, and takeover his account.
So, I started the figure out a way to perform such action, I tried all the common JWT vulnerabilities, such as the None algorithm, and Algorithm confusion techniques, I even tried to crack the secret key, but without success.
By the way, if you are a Burp user. then check @thehackerish tutorial on how to use Burp at full potential to find such bugs: https://www.youtube.com/watch?v=SuDN35-aefY&ab_channel=thehackerish
Never Give Up
Even, after too many hours spent on too many attempts to find a way to manipulate the “id” value, I had this strong feeling that it can still be exploited, not sure if it’s based on my experience or just a hunch, But I refused to give up.
Then, I took some time to rest and plan for the next step, That’s when I decide to return to the basics, and I started the recon process to gather subdomains all over again.
The Bad Twin
That’s when I noticed, that there is a staging subdomain hosting the same web App. For privacy reasons and the responsible disclosure policy, let’s assume that the main web application is hosted on: “www.redacted.com”, the staging web app is hosted on: “staging.redacted.com”.
So I tried to sign-in in “staging.redacted.com” using the account created in the main App on “www.redacted.com”, but with no success. So I created a new one. The JWT token structure is the same but with a different “id” value.
JWT token Decoded:
1
2
3
4
5
6
7
8
9
10
{
“alg”: “HS256”,
“typ”: “JWT”
}.
{
“**id**”: 512,
“iat”: 1646219546,
“exp”: 1680433946
}.
58bkoGTGO6lnZbcO-k7v4NgQXaX5ZC-Y3-w3yxwtF8E
This indicates that both web apps are using different databases to store the data, which is normal since one is used for prod while to other for staging.
That’s when it hit me, Do you think as I think! If so, you’re awesome!
What will happen if I tried to login into the main app using the JWT token from the staging app?
And Boom. It worked! This time, I’m logging-in in as the user with account id=512, in the main web app on “www.redacted.com”.
It seems that even if both the web apps are using different databases to store data, they are based on the same code, and using the same secret key for signing JWT tokens. Thus the name “The Bad Twin”.
Account Takeover
So, all an attacker needs to do, is to create users on “staging.redacted.com”, grab their JWT tokens, then use those JWT tokens to log in on “www.redacted.com” as the users with the associated “id” values.
Basically, an attacker could takeover 10307–512=9795 accounts, taking into consideration, that new accounts are being created on “www.redacted.com”
Takeaway
I’m sure that a lot of you had already experienced this kind of situation, when you get stuck on a problem, and even after trying every possible solution to solve it, with no success, you still have this strong feeling that it can be solved. It’s just a matter of finding the correct way to do it.
The lesson here is to keep trusting your inner feeling, take a rest, return to the basics, and of course, never give up.
Thanks for reading. Hope you enjoyed it, and feel free to follow me on Twitter https://twitter.com/sandh0t
Happy Hunting.