SlideShare a Scribd company logo
A Web App Hacker’s Bag O’ Tricks
Logical Attacks
Vulnerability Research
About Me
• Team Lead at iViZ Techno Solutions Pvt. Ltd.
• Passionate in finding New Ways to Exploit the
Vulnerabilities.
• Member of OWASP, n|u community & G4H.
• Contact me: http://www.twitter.com/ajaysinghnegi
This talk is
• Not an introduction to Web Application Security
• A talk about some new ideas and cool/obscure
things in Web Application Security
– More like “Unusual Bugs”
Some Ways to Find Logical Vulnerabilities
• Exploring Functionality & their Weaknesses
• Understanding Filterations, Validation, Countermeasures
Implementations, Misconfigurations & Developer’s Logic
• Chaining of Different Vulnerabilities
• Using One Technique For Different Vulnerabilities
Exploitation
• Reversing Vulnerability Exploitation Techniques
• Out of the Box Thinking & Experimentation
Agenda
• Login Bypass
• Exploiting Password Reset Vulnerabilities
• Bypassing CSRF Protection
• Exploiting Multi-Stage CSRF
• Stealth CSRF Via Stored HPP
• Rate Limiting Bypass
• Captcha Bypass
• Compromising Servers by FTP Password Change Using
Insecure Direct Object Reference
• Chaining Multiple Vulnerabilities
• Exploiting Self XSS
• Logical Dos
Login Bypass
• Using Arbitrary or Anonymous HTTP Method like HEAD
or ABCD
• Response Code Tampering
like 200 ok to 302
• In Response Change Set Cookie Value to Victims Email
ID like Set Cookie: User=attackeremailid@gmail.com to
Set Cookie: User=victimsemailid@gmail.com also
sometimes it is required to change the json based
response which contains status: failure for wrong
password change it to status:success
• Combination to all the Above mentioned ways
Exploiting Password Reset Vulnerabilities
• Use your Password Reset Url to Reset Other Users
Password by Changing email id parameter or email id
hash value with victims email id hash value
• Check the Response after sending forget password
request
• Check the password which is sent in the email in
plaintext sometimes can be default for all accounts
Exploiting Password Reset Vulnerabilities
• Send continuous forget password requests sometimes
you will receive limited number of passwords so same
passwords will work on any other users ac as default
passwords if you send the forgot password request
• Send continuous forget password requests sometimes it
sends someone else email id embedded in the password
reset link
• Send continuous forget password requests sometimes it
sends the reset token in sequential way
Bypassing CSRF Protection
• Anti-CSRF token its partially validated on server-side i.e.
few chars
• Anti-CSRF token length based validation
• Anti-CSRF token validation is based on user agents
detection
• Anti-CSRF token validation is based on the http method
type and request type
• Anti-CSRF token partially reusable & length based
validation
• Reflected HPP vulnerability can be used to bypass Anti-
CSRF token validation
Bypassing CSRF Protection
<html>
<head>
</head>
<body onload=document.forms[0].submit();>
<form action="https://www.site.com/profile/account_information/edit.htm"
method="POST" enctype="multipart/form-data">
<input type="hidden" name="CSRF_Token"
value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta111" />
<input type="hidden" name="CSRF_Token"
value="absbsbssgsgsgsgg1g1g1g11g1g12g2g2g2g1gg1g1g1g1gh1hhg1h" />
<input type="hidden" name="firstname" value="ajay" />
<input type="hidden" name="lastname" value="negi" />
<input type="hidden" name="EmailID" value="attackertesting@gmail.com" />
</form>
</body>
</html>
<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="Ddmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfg
cPau5tj7dnd74fbf730md8anaur" />
<input type="hidden" name="Submit" value="Change Email" />
<input type="submit" value="Submit form" />
</form>
</body>
</html>
Bypassing CSRF Protection
Exploiting Multi-Stage CSRF
• Sometimes multiple form submissions are required to
exploit the CSRF then combined all the steps form
parameters values in the same form submission if the Url
is same for all the forms then this will work
• Sometimes after successfully changing the victims Email
ID Via CSRF the confirmation link is sent to you but it
need to be confirmed while the victim is logged into his
account so again you have to do CSRF but instead of
that check the confirmation link using your own or
dummy account or without login it can work
Stealth CSRF Via Stored HPP
• Sometimes stored HPP can be used to change the
victims email id but the change will not reflect in the
victims actual account but instead another duplicate(i.e
cloned) account will be created in the vul web
applications database(i.e backend) with the attacker
desired changes but th changes will not reflect in the
victims account as two accounts will be present now, so
now the attacker can compromise the victims account
silently in a stealth way
Rate Limiting Bypass
• Mobile or Anonymous User Agents can be used to
bypass rate limiting
• Length Code Response Analysis can be used to Bypass
rate limiting as the length code is same for any account
right password
• Cookie Response Analysis can be used to Bypass rate
limiting as the cookie and its value will be same for any
account right password or the cookie will be only created
for the right password
• Subdomains can be used to bypass rate limiting of the
main domain
• Admin Login link can be used to bypass rate limiting on
main domain
Logical Attacks(Vulnerability Research)
Logical Attacks(Vulnerability Research)
Logical Attacks(Vulnerability Research)
Captcha Bypass
• Sometimes cookies header values are used to validate
captcha
• Sometimes due to non generic message on right and
wrong passwords submission without Captcha filling can
be used to bypass the Captcha
• Sometimes time based Captcha is used so if you
continuously send the request without letting the captcha
expire then you can reuse captcha and bypass it
Logical Attacks(Vulnerability Research)
Logical Attacks(Vulnerability Research)
Compromising Servers by FTP Password
Change Using Insecure Direct Object Reference
• Sometimes the all FTP users accounts can be accessed
& compromised using insecure direct object reference
vulnerability the by decoding the base 64 encoded data
parameter value and then by manipulating the
store_ftp_account_id in incremental or decremental order
after that by again encoding it to base 64 you can access
and change the password or email id of the victims FTP
server account and even the FTP account can be deleted
also the shell can be uploaded on the server and the
whole server can be compromised
Logical Attacks(Vulnerability Research)
Logical Attacks(Vulnerability Research)
Logical Attacks(Vulnerability Research)
Logical Attacks(Vulnerability Research)
Logical Attacks(Vulnerability Research)
Chaining Multiple Vulnerabilities
• Using Reflected HTTP Parameter Pollution vulnerability
we can bypass Anti-CSRF token validation and can
execute CSRF and after that using the CSRF we can
execute the Stored HPP vulnerability and can
compromise any victims account if that site is vulnerable
to all these attacks.
Exploiting Self-XSS
• If no CSRF or Click Jacking is present then following
other vulnerabilities can be used to exploit the Self-XSS
• Privilege Escalation Vulnerability can be used to exploit
the Self-XSS
• Failure to Restrict Url Access Vulnerability can be used to
exploit the Self-XSS
• Insecure Direct Object Reference Vulnerability can be
used to exploit the Self-XSS
Logical Dos
• Logical Dos Vulnerability as if the attacker has the victim
user’s email id then he uses the forget password Url to
send the reset mail to the victim’s email id as the reset
mail is sent on the victim’s email id with a new
password(which is in plaintext) the victims actual
password automatically gets resett with a new password
without the victims knowledge and permission and his
previous password stops working and then the victim
can't access his own account. So if the attacker
continuously sends the password reset request then the
victims can't change his password nor he can access his
account also the password is going in plaintext and this
attack can be done manually or by tools.
Demo
• Time for few quick demos
Questions?
• Any Questions or Feedbacks are Welcome
Thanks!
• For more details: http://www.websecresearch.com
• https://www.facebook.com/groups/webappsecresearch
• https://www.facebook.com/webappsecresearch
• https://twitter.com/WebSecResearch

More Related Content

Logical Attacks(Vulnerability Research)

  • 1. A Web App Hacker’s Bag O’ Tricks Logical Attacks Vulnerability Research
  • 2. About Me • Team Lead at iViZ Techno Solutions Pvt. Ltd. • Passionate in finding New Ways to Exploit the Vulnerabilities. • Member of OWASP, n|u community & G4H. • Contact me: http://www.twitter.com/ajaysinghnegi
  • 3. This talk is • Not an introduction to Web Application Security • A talk about some new ideas and cool/obscure things in Web Application Security – More like “Unusual Bugs”
  • 4. Some Ways to Find Logical Vulnerabilities • Exploring Functionality & their Weaknesses • Understanding Filterations, Validation, Countermeasures Implementations, Misconfigurations & Developer’s Logic • Chaining of Different Vulnerabilities • Using One Technique For Different Vulnerabilities Exploitation • Reversing Vulnerability Exploitation Techniques • Out of the Box Thinking & Experimentation
  • 5. Agenda • Login Bypass • Exploiting Password Reset Vulnerabilities • Bypassing CSRF Protection • Exploiting Multi-Stage CSRF • Stealth CSRF Via Stored HPP • Rate Limiting Bypass • Captcha Bypass • Compromising Servers by FTP Password Change Using Insecure Direct Object Reference • Chaining Multiple Vulnerabilities • Exploiting Self XSS • Logical Dos
  • 6. Login Bypass • Using Arbitrary or Anonymous HTTP Method like HEAD or ABCD • Response Code Tampering like 200 ok to 302 • In Response Change Set Cookie Value to Victims Email ID like Set Cookie: User=attackeremailid@gmail.com to Set Cookie: User=victimsemailid@gmail.com also sometimes it is required to change the json based response which contains status: failure for wrong password change it to status:success • Combination to all the Above mentioned ways
  • 7. Exploiting Password Reset Vulnerabilities • Use your Password Reset Url to Reset Other Users Password by Changing email id parameter or email id hash value with victims email id hash value • Check the Response after sending forget password request • Check the password which is sent in the email in plaintext sometimes can be default for all accounts
  • 8. Exploiting Password Reset Vulnerabilities • Send continuous forget password requests sometimes you will receive limited number of passwords so same passwords will work on any other users ac as default passwords if you send the forgot password request • Send continuous forget password requests sometimes it sends someone else email id embedded in the password reset link • Send continuous forget password requests sometimes it sends the reset token in sequential way
  • 9. Bypassing CSRF Protection • Anti-CSRF token its partially validated on server-side i.e. few chars • Anti-CSRF token length based validation • Anti-CSRF token validation is based on user agents detection • Anti-CSRF token validation is based on the http method type and request type • Anti-CSRF token partially reusable & length based validation • Reflected HPP vulnerability can be used to bypass Anti- CSRF token validation
  • 10. Bypassing CSRF Protection <html> <head> </head> <body onload=document.forms[0].submit();> <form action="https://www.site.com/profile/account_information/edit.htm" method="POST" enctype="multipart/form-data"> <input type="hidden" name="CSRF_Token" value="l11l1m1m1n2h4n4m6n67ll8m5m43m2nb2m22b2n2babsvxcstta111" /> <input type="hidden" name="CSRF_Token" value="absbsbssgsgsgsgg1g1g1g11g1g12g2g2g2g1gg1g1g1g1gh1hhg1h" /> <input type="hidden" name="firstname" value="ajay" /> <input type="hidden" name="lastname" value="negi" /> <input type="hidden" name="EmailID" value="attackertesting@gmail.com" /> </form> </body> </html>
  • 11. <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="Ddmur8483dnd4836f4djgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfg cPau5tj7dnd74fbf730md8anaur" /> <input type="hidden" name="Submit" value="Change Email" /> <input type="submit" value="Submit form" /> </form> </body> </html> Bypassing CSRF Protection
  • 12. Exploiting Multi-Stage CSRF • Sometimes multiple form submissions are required to exploit the CSRF then combined all the steps form parameters values in the same form submission if the Url is same for all the forms then this will work • Sometimes after successfully changing the victims Email ID Via CSRF the confirmation link is sent to you but it need to be confirmed while the victim is logged into his account so again you have to do CSRF but instead of that check the confirmation link using your own or dummy account or without login it can work
  • 13. Stealth CSRF Via Stored HPP • Sometimes stored HPP can be used to change the victims email id but the change will not reflect in the victims actual account but instead another duplicate(i.e cloned) account will be created in the vul web applications database(i.e backend) with the attacker desired changes but th changes will not reflect in the victims account as two accounts will be present now, so now the attacker can compromise the victims account silently in a stealth way
  • 14. Rate Limiting Bypass • Mobile or Anonymous User Agents can be used to bypass rate limiting • Length Code Response Analysis can be used to Bypass rate limiting as the length code is same for any account right password • Cookie Response Analysis can be used to Bypass rate limiting as the cookie and its value will be same for any account right password or the cookie will be only created for the right password • Subdomains can be used to bypass rate limiting of the main domain • Admin Login link can be used to bypass rate limiting on main domain
  • 18. Captcha Bypass • Sometimes cookies header values are used to validate captcha • Sometimes due to non generic message on right and wrong passwords submission without Captcha filling can be used to bypass the Captcha • Sometimes time based Captcha is used so if you continuously send the request without letting the captcha expire then you can reuse captcha and bypass it
  • 21. Compromising Servers by FTP Password Change Using Insecure Direct Object Reference • Sometimes the all FTP users accounts can be accessed & compromised using insecure direct object reference vulnerability the by decoding the base 64 encoded data parameter value and then by manipulating the store_ftp_account_id in incremental or decremental order after that by again encoding it to base 64 you can access and change the password or email id of the victims FTP server account and even the FTP account can be deleted also the shell can be uploaded on the server and the whole server can be compromised
  • 27. Chaining Multiple Vulnerabilities • Using Reflected HTTP Parameter Pollution vulnerability we can bypass Anti-CSRF token validation and can execute CSRF and after that using the CSRF we can execute the Stored HPP vulnerability and can compromise any victims account if that site is vulnerable to all these attacks.
  • 28. Exploiting Self-XSS • If no CSRF or Click Jacking is present then following other vulnerabilities can be used to exploit the Self-XSS • Privilege Escalation Vulnerability can be used to exploit the Self-XSS • Failure to Restrict Url Access Vulnerability can be used to exploit the Self-XSS • Insecure Direct Object Reference Vulnerability can be used to exploit the Self-XSS
  • 29. Logical Dos • Logical Dos Vulnerability as if the attacker has the victim user’s email id then he uses the forget password Url to send the reset mail to the victim’s email id as the reset mail is sent on the victim’s email id with a new password(which is in plaintext) the victims actual password automatically gets resett with a new password without the victims knowledge and permission and his previous password stops working and then the victim can't access his own account. So if the attacker continuously sends the password reset request then the victims can't change his password nor he can access his account also the password is going in plaintext and this attack can be done manually or by tools.
  • 30. Demo • Time for few quick demos
  • 31. Questions? • Any Questions or Feedbacks are Welcome
  • 32. Thanks! • For more details: http://www.websecresearch.com • https://www.facebook.com/groups/webappsecresearch • https://www.facebook.com/webappsecresearch • https://twitter.com/WebSecResearch