A2 Broken Authentication and Session Management

Authentication and session (is a connective duration between a computer and a user) management includes all aspects of handling user authentication and managing active sessions.

'Broken' refers to a flaw in authentication and session management mechanisms. They are two separate entities to be discussed.

Application functions related to authentication and session management are often not implemented correctly, hence allowing attackers to compromise passwords, keys, session tokens or to exploit other implementation flaws to access user identities.

To establish a connection between the user and web application, the user must get authenticated by providing essential account credentials (login/password). This generates a unique "session ID" and authenticates a session to the user. If the session ID generated is weak and an attacker is able to guess the session ID of an authenticated user, fraudulent activity is possible.

Attack Motives and Procedure

Usually, the motive of this attack is to gain unauthorized access to some or even all the accounts (especially privileged accounts like admin accounts) or for impersonation (an act of pretending to be another person for the purpose of fraud).

Procedure of the Attack

Attackers compromise passwords, keys, session tokens, or exploit other implementation flaws to access user identities. The attacker tries to predict the user credentials or session values for performing this attack.

Explanation/More Details of the Attack

Attacker will gain access to accounts by using techniques to impersonate a session or user.

Common Flaws Leading to Broken Authentication

Following are common flaws that result in broken authentication:

• Username Enumeration
• Allows Brute Force
• Use of Weak Passwords
• Weak Password Reset Mechanism

Understanding Username Enumeration through a Demo

Highlights:

• Understand User Enumeration Flaw
• Mitigation Strategies for Solving User Enumeration Flaw

Demosteps:

In WeakApp, the login utility verifies the username and the password provided by the end user against the data stored in the database. If both username and password are correct, it allows the user to login to the application. If either username or password is incorrect, it displays an error message.

Method 1 - Incorrect Username with Incorrect Password

Step 1: Input the following credentials:

Username: vvg1
Password: 1234

Step 2: It will result in an output as shown below.

Image showing snapshot of WeakApp Login page, when we provide Incorrect Username with incorrect password.

Method 2 - Correct Username with Incorrect Password

Step 1: Input the following credentials:

Username: vvg
Password: 1234

Step 2: It will result in output as shown below:

Image showing snapshot of WeakApp Login page, when we provide Correct Username with incorrect password.

Method 3 - Incorrect Username with Correct Password

Step 1: Input the following credentials:

Username: vvg1
Password: vvg!123

Step 2: It will result in an output as shown below:

Image showing snapshot of WeakApp Login page, when we provide Incorrect Username with correct password.

Method 4 - Correct Username with Correct Password

Step 1: Input the following credentials:

Username: vvg
Password: vvg!123

Step 2: It will result in an output as shown below:

Image showing snapshot of WeakApp Login page, when we provide Correct Username and password.

From the above cases, the hacker can conclude that there exists a user in the database with the name vvg. Also, he knows that there is no user with the name vvg1.

With this information, the hacker can build a database of all the names that exist in the database. He will apply brute force technique - trying one name at a time, by attempting with the most common usernames. Such tasks cannot be completed in a day, these activities are planned by hackers for several days. Also, he might be using automated tools to do this task.

Once the hacker retrieves all the usernames of applications, he can use a strong password-cracking tool to discover their passwords.

With both usernames and passwords discovered, the hacker can perform any activity on the database.

Mitigation

• Display a generic message to the end user - “Username or Password is invalid", hence making it difficult for the hacker to intrude.
• Track brute force attempts in system logs. Block the particular IP address that is attempting it.
• Include CAPTCHA in the application, to distinguish whether it’s a human or tool trying to perform the attack.
• Use strong passwords with encryption.

Brute Force Attacks

A common threat faced by web developers is a password guessing attack known as a brute force attack. A brute force attack is an attempt to discover a password by systematically trying every possible combination of letters, numbers, and symbols until the correct combination is found. If your website requires user authentication, you are a good target for a brute-force attack.

Hackers launch brute force attacks using widely available tools that utilize wordlists and smart rulesets to intelligently and automatically guess user passwords. Although such attacks are easy to detect, they are not so easy to prevent.

Scenario: Password Reset Tokens

Password tokens are most commonly used where the "forgot password" functionality is used. A mail is sent to the user who requests a password change with a link to change his/her password.

Following is a sample password reset link:

https://EDUBank/resetPassword/61687

These links have a token that is valid for a limited period (10-15 minutes). The following code is used by a website for generation of these password tokens:

Random rand = new Random();
int low = 10000;
int high = 100000;
token = rand.nextInt(high - low) + low;

This implementation has multiple issues:

1. The range in which the token numbers are generated is very small. Such random numbers can be easily guessed.
2. Token length is very small leading to brute force attack.

In such cases, the hacker will iterate to a set of values, which he has created after prolonged observations, and will easily be able to get access to the password.

Mitigation

• The most obvious way to block brute force attacks is to simply lock out accounts after a defined number of incorrect password attempts.
• Consider locking out authentication attempts from known and unknown browsers or devices.
• Assign unique login URLs to blocks of users so that not all users can access the site from the same URL.
• Use a CAPTCHA to prevent automated attacks.
• Token generation must use secure random number generation that is difficult to predict.

Weak Passwords

In most hacking scenarios, the hacker was successful because the user passwords were the most commonly used ones. The passwords such as 1234, password, qwerty, etc. are considered to be weak passwords.

A hacker can create a list of such passwords to brute force them until the authentication gets successful.

Refer to this list for commonly used weak passwords online.

Mitigation

• Ensure that strong passwords are used.
• One must regularly change passwords.
• One should ensure that passwords are not reused.

Weak Password Reset Mechanism

The password change and reset function of an application is a self-service mechanism for users. This allows users to quickly change or reset their passwords without an administrator intervening.

When passwords are changed, they are typically changed within the application. When passwords are reset, they are either rendered within the application or emailed to the user. This may indicate that the passwords are stored in plain text or in a de-cryptic format.

Mitigation

• Keep changing the cryptographic keys periodically.
• Ensure that any secret key is protected from unauthorized access.
• Ensure that the cryptographic protection remains secure even if access controls fail.

Flaws in Session Management

Following are the common flaws in session management:

• Session Fixation
• Sequential or Predictable Session IDs
• Short Session IDs
• Inappropriate Session Timeout

Session Fixation

Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack is due to a limitation, the way the web application manages the session ID.

An attacker will target a vulnerable application and will learn about the application's behavior as in how it manages user session IDs. While authenticating a user, the web application might not be providing a different session ID which makes the application vulnerable.

Web applications which have session IDs visible in their URL are the most vulnerable ones as they pave way for attackers to perform hacking.

Scenario: Session Fixation

Alex got an exciting offer on a holiday package to Prague on a website, GoHoliday.com. He logs in and books a trip for himself. He shares the link, given below, with his friend Lisa:

http://GoHoliday.com/tour_package/;jsessionid=2P0OC2JDPXM0OQSNDLJUN2JV?dest=Prague

Lisa accesses the link and is able to book a trip for herself without spending a penny. How do you think, Lisa was able to book the trip?

The answer is, the active session ID. This application provided a session ID for every user. But did not change it while authenticating the user. So, when Alex logs in, the session ID got authenticated and active which enabled Lisa to book the trip using the same session ID.

Mitigation

• Different session IDs should be allocated to the user after authentication. Also, optionally one can regenerate a new session ID after the user has logged out of the session.
• Session IDs should not be visible in the URL.

Predictable/Sequential Session IDs and Short Session IDs

This is a custom method of hacking the websites which have a sequential pattern of generating session IDs.

If an attacker understands the pattern between the consecutive sessions generated by the web application, he/she could easily predict what could be the next session and hence, can gain access to an account without proper authentication.

This will be more dangerous if he gets to access the same session in which a user, having admin privilege, is working. Thus, the entire system will be compromised in such a situation.

Also, it is important to note that using very short session ID values can lead to a brute force attack which makes it easier to hack even if the values are created randomly.

Scenario: Predictable/Sequential Session IDs and Short Session IDs

A hacker wants to gain access to a web application which generates the sessions in the following manner:

http://www.localhost:8080/aviscanner.jsp?id=1234;sessionid=avis1234
http://www.localhost:8080/aviscanner.jsp?id=1234;sessionid=avis1235
http://www.localhost:8080/aviscanner.jsp?id=1234;sessionid=avis1236

He/she observes the pattern and decides to log in with the next session. Unfortunately, the next user is Alex, who is the admin of the web application. Once Alex logs in, the hacker also logs in with the same session ID and gains access to Alex's session.

Now, the hacker will get access with admin privilege and can access the application inside out.

Mitigation

• Session IDs must be long, as long as 128-bits.
• Session IDs must be unpredictable and random to prevent guessing of session IDs.

Session Timeout

There is one more way in which the session generation can be exploited by the hacker i.e. session timeout.

Scenario 1: Session Timeout

The hacker has gained access to Alex's (legitimate user) authentication credentials. The hacker logs into the application as a legitimate user using Alex's authentication credentials. Alex also logs into the application with his authentication credentials. Both of them were able to access the application at the same time.

Scenario 2: Session Timeout

Alex was accessing his Gmail account. His manager calls him for some urgent work. Being in a hurry, he left the desktop without logging off. After an hour, a colleague enters Alex's cabin and sees that his Gmail account is open. This colleague misuses the situation for his/her own benefits.

In both scenarios, the hacker was able to succeed because the session timeout feature was not implemented properly.

In the first scenario, when both the hacker and Alex logged into the application, one session got created for each of them (in total two). Ideally, only one session should have been permitted for Alex and the other should have been invalidated in order to prevent impersonation problems.

In the second scenario, the hacker was able to access the Gmail account, even though it was kept idle for an hour, because that session was not timed out. Ideally, it should have been invalidated within a few minutes of being kept idle.

The problems faced in the above scenario can be resolved by implementing appropriate session management logic.

Mitigation

• Avoid infinite session timeout.
• Session timeout value must be kept as minimum as possible which may vary from application to application.
• Multiple sessions should not be allowed.

Other Risks Associated with Broken Authentication and Session Management

Risks

Impersonation, especially gaining illegal access to privileged accounts.

Root Causes

Flaws in authentication:

• Username enumeration
• Weak passwords
• Allows brute force
• Weak Password Reset Mechanism

Flaws in session management mechanisms include:

• Session fixation
• Sequential or predictable session IDs
• Short session IDs
• Inappropriate session timeout

Mitigation

To control the attacks arising due to broken authentication and session management, the following are the countermeasures:

• Session IDs should be sufficiently lengthy to protect from brute force attacks.
• Use strong algorithms to generate session IDs that would have the following properties:
• It must be random and unpredictable.
• Appropriate session timeouts.
• Multiple sessions should not be allowed for critical transactions involving web applications such as banking websites.
• Enforce strong passwords.
• Prevent brute force login attempts.

For more details refer to Broken authentication mitigation and Session management mitigation on OWASP's official site.