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

1. Authentication
Lock-piking
by Nazar Tymoshyk, SoftServe
& Bohdan Serednyskyj,,
SoftServe
@Symphony-Solutions

2. This is more educational topic,
not motivational

3. About me

4. Feel free to ask me anything :)

5. Best SoftServe Team – R&D

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. Certifications
Ph.D in Security
Identity & Security
SoftServe experts are certified in
HP Fortify Security Testing solution

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. Time for fun. Just relax

10. Target – Authentication

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. 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. Findings

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. 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. 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. 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"
https://www.owasp.org/index.php/Authentication_Cheat_Sheet

18. Verbose Failure Messages
Identifying subtle differences in application
responses using Burp Comparer

19. Username enumeration demo

20. Same JSESSIONID and Cookie for different sessions
mobiledemo demomob

21. Password brute force Demo

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. WEAK PASSWORDS
Severity: Critical (C )/P1
Business impact: Critical (C )/P1

24. Developer team face
palm
v
v v
Login:***dev
pass: ***123

25. Cookie testing 

26. Why so simple?

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. WEAK CHANGE USER PASSWORD MECHANISM
Severity: Critical (C )/P1
Business impact: Critical

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. Weak password reset – clear text

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:
http://passcracking.com/index.php
http://authsecu.com/decrypter-dechiffrer-cracker-hash-md5/script-hash-
md5.php

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. Recommended Book

34. OWASP WebGoat, DVWA -
Train yourself in Security

35. Hope you like it!

37. Now ask!
Thank You!
Email: root.nt@gmail.com
Skype: root_nt

38. Now attention

39. 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.

40. Step 1

41. Step 2

42. DEMO

43. Shodan – camera scanner 
Try this too:
http://178.165.59.13/

44. THIS IS More COOL
http://77.52.149.88:8080/

45. Big Boss is Watching you 
http://82.144.209.95/

46. 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!

47. 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

48. adasdasd

49. 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.