Attacking Session Management | Part 06 | What To Do After Choosing a Target

10 months ago 75

BOOK THIS SPACE FOR AD

ARTICLE AD

Hello Everyone,

This is the Part 06 of the series, in the last part we discussed about Authentication Bypass.

In this Part we are going to learn about Attacking Session Management.

Session management mechanism is a fundamental security component in the majority of web applications. It is what enables the application to uniquely identify a given user across a number of different requests and to handle the data that it accumulates about the state of that user’s interaction with the application.

Because of the key role played by session management mechanisms, they are a prime target for malicious attacks against the application

Let’s Begin The Testing !

How does a session works ?

The majority of the websites allow you to register and login, they let you buy and sell things. They remember your preferences for the next time you visit. To implement this functionality, web sites use the concept of a session.

Once you login into a website, you can use it with that account until you logout or the session expires due to inactivity. Without a session you would have to reenter your password every time you visit the website.

Note: Some websites that do not have a login functions also need to use session management, to know which series of requests it receives originated from the same user.

The Most common means of implementing sessions is to issue each user a unique session token or identifier. In most cases the applications use HTTP cookies as the transmission mechanism for passing these tokens between server and client. The servers first response to a new client looks something like this

Set-Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55

and the other requests looks like:

Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55

This standard session management is inherently vulnerable to various attacks. The primary objective of the attacker is to hijack the users session and access private data.

The vulnerabilities that exist in session management mechanisms largely fall into two categories:

Weaknesses in the generation of session tokensWeaknesses in the handling of session tokens throughout their life cycle

How to identify which Item of data contains the token?

Observe which new items are passed to the browser after authentication. Often, new session tokens are created after a user authenticates themselvesTo verify which items are actually being employed as tokens, find a page that is definitely session-dependent (such as a user-specific “my details” page). Make several requests for it, systematically removing each item that you suspect is being used as a token.

Session management mechanisms are often vulnerable to attack because tokens are generated in an unsafe manner that enables an attacker to identify the values of tokens that have been issued to other users.

There are many locations where an applications security depends on the token it generates, for example -:

Password recovery tokensTokens used to give one time access to protected resourcesTokens used in Remember me functions

Meaningful Tokens

Some session tokens are created using transformation of users data like username or email addresses, this information may be encoded in some way or may be combined with other data.

For example the following token may look like a long random string

757365723d6461663b6170703d61646d696e3b646174653d30312f31322f3131

But on closer inspection you can see it only contains hexadecimal characters. So you can try using a decoder

This is a very good tool for decoding

Attackers can exploit this and attempt to guess the sessions of other application users.

Here are some components that may be encountered within structured tokens:

The account usernameThe numeric identifier that the application uses to distinguish between accountsThe user’s first and last namesThe user’s e-mail addressThe user’s group or role within the applicationA date/time stampAn incrementing or predictable numberThe client IP address

Steps to test:

Login into the website as several different users at different timesRecord the tokens each timeLogin with a series of similar usernames like A, AA, AAA, AAABAnalyze the tokens for any correlations that appear to be related to the username or user controlled dataThen analyze it for any encoding

Example Report:

We are going to use this report: https://hackerone.com/reports/672623

Submitted by,
jannikg to Nextcloud on August 13, 2019, 7:37pm UTC

In this report the when the attacker logins in to the owncloud instance with the username and password and then receives a token.

On decoding the token he finds out that it is the username and password encoded in base64

No matter how effective the web site is at ensuring that their tokens does not contain any meaningful information, it will be wide open for attack if the tokens are not handled carefully after generation.

For example, if tokens are disclosed to an attacker via some means, the attacker can hijack user sessions even if predicting the tokens is impossible.

1. Disclosure of Tokens on the Network

This area of vulnerability arises when the session token is transmitted across the network in unencrypted form, enabling an attacker to obtain the token.

In the simplest case where an application uses an unencrypted HTTP connection, an attacker can capture all data transmitted between client and server including the token.

Steps to Test

Walk through the application in the normal way from first access, through the login process, and then through all of the application’s functionality. Keep a record of every URL visited, and note every instance in which a new session token is received.If HTTP cookies are being used as the transmission mechanism for session tokens, verify whether the secure flag is set.Determine whether, in the normal use of the application, session tokens are ever transmitted over an unencrypted connection.In cases where a token for an authenticated session is transmitted to the server over HTTP, verify whether that token continues to be valid or is immediately terminated by the server

2. Vulnerable Mapping of Tokens to Sessions

The simplest weakness is to allow multiple valid tokens to be concurrently assigned to the same user account. This vulnerability arises when an application allows multiple valid tokens to be assigned to the same user account simultaneously. Normally, a user should only have one active session at a time.

Some applications use static tokens instead of dynamic session tokens. These tokens are issued to users upon login and remain the same for subsequent logins.

This approach misunderstands the concept of sessions and compromises security, especially if the tokens are vulnerable to prediction attacks.

Steps to Test

Log in to the website twice using the same account either using different browser or different devices.Check whether it runs in both the placesIf it runs in both the places check log in and log out the account multiple times.Check if the token is changed after every log out or it is the same.If it is the same check if the token has any kind of pattern or meaning and try to modify any user related components in the token.Verify whether the resulting token is accepted by the application.

3. Vulnerable Session Termination

Some applications fail to enforce effective session expiration policies. Sessions may remain valid for an extended period, even days after the last request, before the server finally expires them. In certain cases, logout functionality is either not implemented at all, leaving users with no means to invalidate their sessions.

Steps to Test

Log in to the application to obtain a valid session token.Wait for a period without using this token, and then submit a request using the token.If the page is displayed as normal, the token is still active.Use trial and error to determine how long any session expiration timeout is.Determine whether a logout function exists and is prominently made available to users.Where a logout function is provided, test its effectiveness.

Example Report:

We are going to use this report: https://hackerone.com/reports/672623

Submitted by,
saqib98 to OWOX on October 8, 2019, 5:43am UTC

Here the attacker first logged in with there account and copied the url and pasted in other tab, and then went back to the first tab and logged out the account, but when checked the url the attacker was still logged in which is an example of vulnerable session termination.