Logical Attacks(Vulnerability Research)


Published on

Hi Everyone,

This presentation is on Logical Attacks it can be helpful in Bug Bounties while doing Bug Hunting, Vulnerability Research in web applications, mobiles(andriod, ios, win), webservices, apis etc and for making a career in information security domain.

Its 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”

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Logical Attacks(Vulnerability Research)

  1. 1. A Web App Hacker’s Bag O’ Tricks Logical Attacks Vulnerability Research
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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.
  18. 18. 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
  19. 19. 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.
  20. 20. Demo • Time for few quick demos
  21. 21. Questions? • Any Questions or Feedbacks are Welcome
  22. 22. Thanks! • For more details: http://www.websecresearch.com • https://www.facebook.com/groups/webappsecresearch • https://www.facebook.com/webappsecresearch • https://twitter.com/WebSecResearch