Security Hole #12 Lviv SoftServe-Symphony Solutions "Lockpicking Authentication"


Published on

Security Hole #12 OWASP Lviv SoftServe-Symphony Solutions
Topic - "Lockpicking Authentication"

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

No notes for slide
  • Zitmo and Zeus bank trojan
  • Security Hole #12 Lviv SoftServe-Symphony Solutions "Lockpicking Authentication"

    1. 1. Authentication Lock-piking by Nazar Tymoshyk, SoftServe & Bohdan Serednyskyj,, SoftServe @Symphony-Solutions
    2. 2. This is more educational topic, not motivational
    3. 3. About me
    4. 4. Feel free to ask me anything :)
    5. 5. Best SoftServe Team – R&D
    6. 6. Security Team Nazar Tymoshyk CEH, HP FSTS, CIW WSS, Cisco SS, ZSS, CLE, DCTS, DCATS,NAI,CLP,NLTS,CNA, NCLA,MCTS Bohdan Serednytskyi CEH, MSTC Security, ZSS
    7. 7. Certifications Ph.D in Security Identity & Security SoftServe experts are certified in HP Fortify Security Testing solution
    8. 8. QA Engineer Security Analyst In functional and performance testing, the expected results are documented before the test begins, and the quality assurance team looks at how well the expected results match the actual results In security testing, security analysts team is concerned only with unexpected results and testing for the unknown and looking for weaknesses. VS.
    9. 9. Time for fun. Just relax
    10. 10. Target – Authentication
    11. 11. Key authentication problems • Authentication Technologies • Design Flaws in Authentication Mechanisms • Bad Passwords • Brute-Forcible Login • Verbose Failure Messages • Vulnerable Transmission of Credentials • Password Change Functionality • Forgotten Password Functionality • “Remember Me” Functionality • User Impersonation Functionality • Incomplete Validation of Credentials • Non-unique Usernames • Predictable Usernames • Predictable Initial Passwords • Insecure Distribution of Credentials • Implementation Flaws in Authentication • Fail-Open Login Mechanisms • Defects in Multistage Login Mechanisms • Insecure Storage of Credentials
    12. 12. Authentication Technologies • HTML forms-based authentication • Multifactor mechanisms, such as those combining passwords and physical • tokens • Client SSL certificates and/or smartcards • HTTP basic and digest authentication • Windows-integrated authentication using NTLM or Kerberos • Authentication services
    13. 13. Findings
    14. 14. Brute-Forcible Login • Login functionality presents an open invitation for an attacker to try to guess usernames and passwords and therefore gain unauthorized access to the application. • If the application allows an attacker to make repeated login attempts with different passwords until he guesses the correct one, it is highly vulnerable even to an amateur attacker who manually enters some common usernames and passwords into his browser. Many authentication mechanisms disclose usernames either implicitly or explicitly. In a web mail account, the username is often the e-mail address, which is common knowledge by design.
    15. 15. Password problem Administrative passwords may in fact be weaker than the password policy allows. They may have been set before the policy was in force, or they may have been set up through a different application or interface
    16. 16. User enumeration Severity: Critical (C )/P1 Issue detail: In current login mechanisms, where an application requires the user to submit several pieces of information, or proceed through several stages, verbose failure messages or other discriminators can enable an attacker to target each stage of the login process in turn, increasing the likelihood that he will gain unauthorized access. Even if the error messages returned in response to a valid and invalid username are superficially similar, there may be small differences between them that can be used to enumerate valid usernames. Even if an application’s responses to login attempts containing valid and invalid usernames are identical in every intrinsic respect, it may still be possible to enumerate usernames based on the time taken for the application to respond to the login request. Applications often perform very different back-end processing on a login request, depending on whether it contains a valid username Recommendation: Report Authentication failure – not Invalid Username. Add additional field to enter some SMS/CVV code. Verbose error log
    17. 17. Recommended error messages by OWASP Incorrect Response Examples "Login for User foo: invalid password" "Login failed, invalid user ID" "Login failed; account disabled" "Login failed; this user is not active" Correct Response Example "Login failed; Invalid userID or password"
    18. 18. Verbose Failure Messages Identifying subtle differences in application responses using Burp Comparer
    19. 19. Username enumeration demo
    20. 20. Same JSESSIONID and Cookie for different sessions mobiledemo demomob
    21. 21. Password brute force Demo
    22. 22. Password guessing attack Password limit: 10 alpha-numeric symbols Window limit: 13 alpha-numeric symbols Required: 4 alpha-numeric symbols 1, 727 604 combination Bruteforce - up to 5 minutes No brute force prevention. Positions for 4 elements of simple alpha-numeric password if password was wrong remain the same! Recommendation: Change password input approach. Or server should send new position to device if wrong part of password was submitted. Use more symbols than 4. Use 2 factor authentication as Google use (SMS to account owner with temporary access code).
    23. 23. WEAK PASSWORDS Severity: Critical (C )/P1 Business impact: Critical (C )/P1
    24. 24. Developer team face palm v v v Login:***dev pass: ***123
    25. 25. Cookie testing 
    26. 26. Why so simple?
    27. 27. Weak password reset Password reset implemented here is weak as it has questions with information that can be easily obtained by 3rd party side
    28. 28. WEAK CHANGE USER PASSWORD MECHANISM Severity: Critical (C )/P1 Business impact: Critical
    29. 29. Password change functionality If the password change form is accessible only by authenticated users and does not contain a username field, it may still be possible to supply an arbitrary username. The form may store the username in a hidden field, which can easily be modified. If not, try supplying an additional parameter containing the username, using the same parameter name as is used in the main login form. This trick sometimes succeeds in overriding the username of the current user, enabling you to brute-force the credentials of other users even when this is not possible at the main login. Tricks
    30. 30. Weak password reset – clear text
    31. 31. Insecure Storage of Credentials It is common to encounter web applications in which user credentials are stored insecurely within the database. This may involve passwords being stored in clear text. But if passwords are being hashed using a standard algorithm such as MD5 or SHA-1, this still allows an attacker to simply look up observed hashes against a pre-computed database of hash values. Some online databases of common hashing functions are available here: md5.php
    32. 32. Securing Authentication • Use Strong Credentials • Handle Credentials Secretively • Validate Credentials Properly • Prevent Information Leakage • Prevent Brute-Force Attacks • Prevent Misuse of the Password Change Function • Prevent Misuse of the Account Recovery Function
    33. 33. Recommended Book
    34. 34. OWASP WebGoat, DVWA - Train yourself in Security
    35. 35. Hope you like it!
    36. 36. Now ask! Thank You! Email: Skype: root_nt
    37. 37. Now attention
    38. 38. More complex authentication In more complex login mechanisms, where an application requires the user to submit several pieces of information, or proceed through several stages, verbose failure messages or other discriminators can enable an attacker to target each stage of the login process in turn, increasing the likelihood that he will gain unauthorized access.
    39. 39. Step 1
    40. 40. Step 2
    41. 41. DEMO
    42. 42. Shodan – camera scanner  Try this too:
    43. 43. THIS IS More COOL
    44. 44. Big Boss is Watching you 
    45. 45. Consequences • Stolen Developer Cloud access Certificates • Malware and Spyware on PC and mobile • Key loggers • Money Lost – Paypal, webmoney, etc. • Email – recovery and steal accounts • SHAME!
    46. 46. Recommendations • Up to date JAVA and all other software • Antivirus – Kasper rocks! • Encrypted keys to infrastructure • 2 factor authentication everywhere (email first) • Verify yourself and your browser on … •Attention
    47. 47. adasdasd
    48. 48. Attempt to discover any rules regarding password quality: 1. Review the website for any description of the rules. 2. If self-registration is possible, attempt to register several accounts with different kinds of weak passwords to discover what rules are in place. 3. If you control a single account and password change is possible, attempt to change your password to various weak values.