Showing posts with label Rate Limiting Bypass. Show all posts
Showing posts with label Rate Limiting Bypass. Show all posts

Monday, May 19, 2014

A Way to Bypass Rate Limiting


Another Way to Bypass Rate Limiting




I want to share one of my finding on account.99designs.com which I have reported to them on 5th May 2014.









I have found that site.com

following Url https://account.99designs.com/sso/1.0.0/login?site=contests&locale=en-us&return=https://99designs.com/sso/login&rd=lNFC-iNCgY5Xnzsq6UvI_ykRl__KUS2MzzhB_Alu5LA= was vulnerable to
Bruteforce attacks even when the Rate-Limting is implement for all the site.com users account and the server is disabling the requests.





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





Then
I tried to do the User-Agent based bruteforce attack by changing the
user-agent to known and anonymous user-agent in header of the each
request but it also failed and then after further more Deep Analysis I
found that there was a parameter named browser was sent using post
method in each request with Wrong or Right Password and this parameter
was containing a value which was the currently used browsers name i.e.
internet+explorer. So, that means the server was checking the User-Agent
using header and also using the browser name parameter and its value
internet+explorer.





So

to find weakness in the Rate Limiting countermeasure 1st sent more then
60 Wrong Password requests using  the browser parameter with the value
internet+explorer as the 60 Wrong Password requests sent the the Rate
Limiting got enabled and it started blocking the wrong or right password
request and was sending the response code and length code
as 200 for all Right & Wrong Password
attempts also the error message was generic for all Right & Wrong
Password Attempts so again it failed. 




After
that I started sending each request with the browser named parameter
value which I changed to any known and also any unknown value as browser
name value. So, then I observed that after more then 60 Wrong Password
Attempts and also even after more then 10000 Wrong Passwords Attempts
the Rate Limiting didn't got enabled nor the
Status Code Value or
Response Code Value, Length Code values changed to 200. Instead for
Right Password it was 302 and for Wrong Pass it was 200.



So,
in this way I was able to Bypass the site.com Rate Limting by changing the browser parameter value in each request and by analyzing
the Status Code Value or Response Code Value, Length Code values
differences.



Original Request:



POST
/sso/1.0.0/login?site=contests&locale=en-us&return=https://99designs.com/sso/login&target=http://99designs.com/&rd=lNFC-iNCgY5Xnzsq6UvI_ykRl__KUS2MzzhB_Alu5LA=
HTTP/1.1
Accept: text/html, application/xhtml+xml, /
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
DNT: 1
Cookie:
__iswl_account99designscom=0;
sp_id..cf43=f48faee182ec56ef.1399262073.1.1399262078.1399262073;
sp_ses..cf43=*; _msuuid_75mlvfed70=937C0A8D-BDBA-40E7-9632-AA2BB97F051F;
__ssid=69a7009e-a365-4481-87e3-60620271c47d;
CookiedSession=P90fAidSF8hdgPCKZkgn2KdK7sAj0imf4TLPMLiyKU=.K-FAwEBC3Nlc3Npb25EYXRhAf-GAAECAQJJZAEMAAEFU3RvcmUB_4gAAAAh_4cEAQERbWFwW3N0cmluZ11zdHJpbmcB_4gAAQwBDAAAKv-GARZhWW1qc2tlbHo5SVM3UWozamtGeE9IAQEGbG9jYWxlBWVuLXVzAA==
Host: account.99designs.com
Content-Length: 202
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)

username=victimemailid@gmail.com&password=shssjssjs&browser=Internet+Explorer&browserversion=10.0&screenresolution=1422x889&operatingsystem=Windows&timezoneoffset=420&csrf_token=aYmjskelz9IS7Qj3jkFxOH




Modified Request:



POST
/sso/1.0.0/login?site=contests&locale=en-us&return=https://99designs.com/sso/login&target=http://99designs.com/&rd=lNFC-iNCgY5Xnzsq6UvI_ykRl__KUS2MzzhB_Alu5LA=
HTTP/1.1
Accept: text/html, application/xhtml+xml, /
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
DNT: 1
Cookie:
__iswl_account99designscom=0;
sp_id..cf43=f48faee182ec56ef.1399262073.1.1399262078.1399262073;
sp_ses..cf43=*; _msuuid_75mlvfed70=937C0A8D-BDBA-40E7-9632-AA2BB97F051F;
__ssid=69a7009e-a365-4481-87e3-60620271c47d;
CookiedSession=P90fAidSF8hdgPCKZkgn2KdK7sAj0imf4TLPMLiyKU=.K-FAwEBC3Nlc3Npb25EYXRhAf-GAAECAQJJZAEMAAEFU3RvcmUB_4gAAAAh_4cEAQERbWFwW3N0cmluZ11zdHJpbmcB_4gAAQwBDAAAKv-GARZhWW1qc2tlbHo5SVM3UWozamtGeE9IAQEGbG9jYWxlBWVuLXVzAA==
Host: account.99designs.com
Content-Length: 202
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)

username=
victimemailid@gmail.com&password=shssjssjs&browser=test+test&browserversion=10.0&screenresolution=1422x889&operatingsystem=Windows&timezoneoffset=420&csrf_token=aYmjskelz9IS7Qj3jkFxOH



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





Impact:





The attacker can
successfully bruteforce the passwords on any users account 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.



Instead of user-agent based validation for enabling the rate limiting user id shall be checked for numbers of wrong password attempts.





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







The vulnerability was mitigated by 99designs Security Team.



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



Suggestions and Feedback's are welcome.


Saturday, September 7, 2013

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.

Wednesday, August 21, 2013

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.