Recently I took a seminar on CSRF in which I had described most of the basic exploit techniques and various other points related to CSRF. If you are new to CSRF, then I would request you to check my slides
here
This post will cover how we can bypass CSRF tokens, So lets begin..
Anti-CSRF token bypass techniques :-
If in any request, you are observing a CSRF token, then the challenge for attacker is to execute the CSRF attack by bypassing the Anti-CSRF token validation. If Anti-CSRF Token was getting validated on the server-side, then we have to find the weakness in its validation.
I have collected all the ways by which we can bypass Anti-CSRF tokens. Also, I have added few real-time scenarios for better understanding of how we can apply the below checks :-
Check 1:- Try to re-use one user Anti-CSRF Token on another user account
Check 2:- Try to use the already used token
Check 3:- Try to check whether token is getting validated or not
Check 4:- Try to check that the token validation is based on partial length check or full length check
If none of them worked that means the token was getting validated on server-side.
Note:- Always try to analyze the token pattern, randomness, complexity, full length and partial length based validation etc
Now, lets try to exploit and see how this anti-CSRF token validation can be by-passed, To demonstrate this, I have collected some real time scenarios where security researchers have been able to bypass by just analyzing the token pattern.
=> Real Case Scenario 1(Yahoo) (ISSUE IS FIXED):-
In this scenario each users accounts anti-csrf tokens full length was 90 characters thats means it was constant and first 20 Chars of the anti-csrf token were same for each users accounts and the remaining 70 Chars were different for all users accounts.
So attacker have created a new CSRF payload as first 20 chars constant and remaining 70 Chars as a random value, So the Crafted Anti-CSRF token was having a full length of 90 Chars.
i.e Crafted Anti-CSRF token of 90 Chars(which contains 20 Chars as same for all users accounts and remaining 70 Chars as any random value) and then the request got executed as the Anti-CSRF Token got validated on server-side and this worked on all user account
Steps to execute this attack are as following:
1. First copy the actual form submission request.
Actual Form Submission Request with Original Anti-CSRF Token Parameter Value:
2. After that change the same Anti-CSRF Token parameter Csrf_token values from Ddmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj7dnd74fbf730md8anaur to Ddmur8483dnd4836f4djanm8OOhAMn37dnZtFzziOqhflM423Z345KkVPciRopfgcPau5tj7dnd74fbf730md8an54 were 1st 20 Chars value is constant and reusable for any other users account and remaining 70 Chars are any random value so the tokens full length is 90 Chars and this crafted token value will be used as an Anti-CSRF Token.
Account Compromise & Anti CSRF Token Bypass(Modified Form Submission Request after changing the Anti-CSRF Token Parameter Value to 20 Chars Constant, Reusable & 70 Chars are Random Value):
3. Then send this crafted CSRF payload code as a link to the victim.
4. As the victim executes that CSRF payload containing link the victims account email id will be changed and the attack will receive an email to confirm his email after confirming it, the attacker can use the forget password option to reset the and compromise the victims account.
Rootcause:
Anti-CSRF Token Parameter Csrf_Token and its values dmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj7dnd74fbf730md8anaur validation was based on Partial Length Token(20 Chars Constant & Reusable) Plus Full Length Token(70 Chars Random Value) Based Validation (i.e Anti-CSRF Token 1st 20 Chars were Constant & Reusable and remaining 70 Chars were random values so the Tokens Full Length 90 Chars & Partial Length of 20 Reusable & Constant Chars were only getting checked or validated on Server-Side). So we can simply say that the Token which the system (ie app) generated Token was not reusable for other users account but the user generated (ie crafted) Token can be used on victims account as valid CSRF token.
=> Real Case Scenario 2 (Microsoft IIS.net):- (ISSUE IS FIXED)
It has been found that we can bypass Anti-CSRF token validation even when it is getting validated on the server-side and can execute CSRF. And after that using the CSRF we can compromise the victims account by change email id of any users account on that site to the attackers email id an then we can use the forget password option to reset the victims account password.
So for that create 2 dummy account for testing purpose on IIS.net and then craft a CSRF payload as mentioned below which is containing a random value as Anti-CSRF token which is having a length(70 Chars) as the current Anti-CSRF Token.
Then continuously send the CSRF request with the random values of 70 Chars as Anti-CSRF Token in decreasing order.
So 1st CSRF request was containing Anti-CSRF Token value of 70 Chars next will 69 then 68 so like that I tried approx 40 Requests which all failed as the token was not getting validated on server-side but as I sent the 41th Request with the random value as Anti-CSRF Token with the length of 30 Chars then the request got executed as the Anti-CSRF Token got validated on server-side and guess what it worked :D.
Steps:-
Change the same Anti-CSRF Token parameter __RequestVerificationToken values from CIhXcKin7XcwYn8Y1hNVgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj to ovomyQnYPxvPXfdxrjO1JEce3zPvGn with 30 Chars length this modified value will be used as an Anti-CSRF Token.
Account Compromise & Anti CSRF Token Bypass(Modified Form Submission Request after changing the Anti-CSRF Token Parameter Value to 30 Chars Random Value):
As the victim executes that CSRF payload containing link the victims account email id will be changed and the attack will receive an email to confirm his email after confirming it the attacker can use the forget password option to reset the and compromise the victims account
Rootcause:
Anti-CSRF Token __RequestVerificationToken and its values CIhXcKin7XcwYn8Y1hNVgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj validation was based on Partial Length based validation(i.e Anti-CSRF Token 1st 30 Chars Length was only getting checked on Server-Side).
Real Case Scenario 3(Microsoft ASP.net):-
How it bypassed: - Account Compromise & Anti CSRF Token Bypass(Modified Form Submission Request after changing the Anti-CSRF Token Parameter Value to 70 Chars Random Value
And there are many more real case scenario for bypassing CSRF tokens which you can find at the end of
my slides
Thank you for reading. If you like my blog then do subscribe for new updates.
