Attacking & Securing Session Management

by Vry4n_ | Jan 14, 2020 | Web Exploitation

I am writing this based on OWASP and the book “The Web Application Hacker’s Handbook”.

https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

Introduction

The HTTP protocol is essentially stateless. It is based on a simple request-response model, in which each pair of messages represents an independent transaction.

applications use HTTP cookies as the transmission mechanism for passing these session tokens between server and client.

The server’s first response to a new client contains an HTTP header like the following:

• Set-Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55

Subsequent requests from the client contain this header:

• Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55

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

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

A web session is a sequence of network HTTP request and response transactions associated to the same user.

Sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.

Web applications can create sessions to keep track of anonymous users after the very first user request.

Session ID

The session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina).

Session ID Properties

In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a name=value pair.

• The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.
• The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.
• The session ID length must be at least 128 bits (16 bytes)
• The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used.
• The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.
• In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is essential to use an encrypted HTTPS (TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged.
• The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID

Secure

HttpOnly

SameSite

Domain

Path

Expire

Max-age

Testing Steps

1. The application may often employ several different items of data collectively as a token, including cookies, URL parameters, and hidden form fields. Some of these items may be used to maintain session state on different back-end components. Do not assume that a particular parameter is the session token without proving it, or that sessions are being tracked using only one item.

2. Sometimes, items that appear to be the application’s session token may not be. In particular, the standard session cookie generated by the web server or application platform may be present but not actually used by the application.

3. Observe which new items are passed to the browser after authentication. Often, new session tokens are created after a user authenticates herself.

4. To 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. If removing an item causes the session-dependent page not to be returned, this may confirm that the item is a session token. Burp Repeater is a useful tool for performing these tests.

Weaknesses in Token Generation

• Password recovery tokens sent to the user’s registered e-mail address
• Tokens placed in hidden form fields to prevent cross-site request forgery attacks
• Tokens used to give one-time access to protected resources
• Persistent tokens used in “remember me” functions
• Tokens allowing customers of a shopping application that does not use authentication to retrieve the current status of an existing order

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

• The account username
• The numeric identifier that the application uses to distinguish between accounts
• The user’s first and last names
• The user’s e-mail address
• The user’s group or role within the application n A date/time stamp
• An incrementing or predictable number
• The client IP address

Hacking Steps

1. Try changing the token’s value one byte at a time (or even one bit at a time) and resubmitting the modified token to the application to determine whether it is still accepted. You can use the “char frobber” payload type in Burp Intruder to modify a token’s value in one character position at a time, to help with this task.

HTTP history -> right click the request (send to intruder) -> Payloads -> Payload 1 (Character frobber)

Start Attack

It tested and came across with some 200 OK

2. Log in as several different users at different times, and record the tokens received from the server. If self-registration is available and you can choose your username, log in with a series of similar usernames containing small variations between them, such as A, AA, AAA, AAAA, AAAB, AAAC, AABA

Analyze the tokens for any correlations that appear to be related to the username and other user-controllable data.

Analyze the tokens for any detectable encoding or obfuscation. Where the username contains a sequence of the same character, look for a corresponding character sequence in the token, which may indicate the use of XOR obfuscation.

3. If any meaning can be reverse-engineered from the sample of session tokens, consider whether you have sufficient information to attempt to guess the tokens recently issued to other application users

Predictable Tokens

Vulnerabilities relating to predictable token generation may be much easier to discover in commercial implementations of session management

• We continue polling the server to obtain new session tokens in quick succession.
• We monitor the increments in the first number. When this increases by more than 1, we know that a token has been issued to another user.
• Weak Random Number Generation

Testing Randomness with Burp Sequencer

Send to sequencer -> Live Capture Request -> Start live capture

Check the results: Analyze now

The overall results show “extremely poor”

Hacking steps

1. Determine when and how session tokens are issued by walking through the application from the first application page through any login functions. Two behaviors are common:

• The application creates a new session anytime a request is received that does not submit a token.
• The application creates a new session following a successful login.

To harvest large numbers of tokens in an automated way, ideally identify a single request (typically either GET / or a login submission) that causes a new token to be issued.

2. In Burp Suite, send the request that creates a new session to Burp Sequencer, and configure the token’s location. Then start a live capture to gather as many tokens as is feasible. If a custom session management mechanism is in use, and you only have remote access to the application, gather the tokens as quickly as possible to minimize the loss of tokens issued to other users and reduce the influence of any time dependency.

3. If a commercial session management mechanism is in use and/or you have local access to the application, you can obtain indefinitely large sequences of session tokens in controlled conditions.

4. While Burp Sequencer is capturing tokens, enable the “auto analyze” setting so that Burp automatically performs the statistical analysis periodically. Collect at least 500 tokens before reviewing the results in any detail. If a sufficient number of bits within the token have passed the tests, continue gathering tokens for as long as is feasible, reviewing the analysis results as further tokens are captured.

5. If the tokens fail the randomness tests and appear to contain patterns that could be exploited to predict future tokens, re-perform the exercise from a different IP address and (if relevant) a different username. This will help you identify whether the same pattern is detected and whether tokens received in the first exercise could be extrapolated to identify tokens received in the second. Sometimes the sequence of tokens captured by one user manifests a pattern. But this will not allow straightforward extrapolation to the tokens issued to other users, because information such as source IP is used as a source of entropy (such as a seed to a random number generator).

6. If you believe you have enough insight into the token generation algorithm to mount an automated attack against other users’ sessions, it is likely that the best means of achieving this is via a customized script. This can generate tokens using the specific patterns you have observed and apply any necessary encoding to this type of problem.

7. If source code is available, closely review the code responsible for generating session tokens to understand the mechanism used and determine whether it is vulnerable to prediction. If entropy is drawn from data that can be determined within the application within a brute-forcible range, consider the practical number of requests that would be needed to bruteforce an application token.

Testing encoding with Burp bit flipper

Send to intruder -> Attack type “sniper” -> select the variable

Payloads -> Bit flipper

Start attack

As you can see it starts playing bit by bit

Hacking steps:

1. Unless the session token is obviously meaningful or sequential in itself, always consider the possibility that it might be encrypted.

You can often identify that a block-based cipher is being used by registering several different usernames and adding one character in length each time.

If you find a point where adding one character results in your session token jumping in length by 8 or 16 bytes, then a block cipher is probably being used. You can confirm this by continuing to add bytes to your username, and looking for the same jump occurring 8 or 16 bytes later.

2. ECB cipher manipulation vulnerabilities are normally difficult to identify and exploit in a purely black-box context. You can try blindly duplicating and moving the ciphertext blocks within your token, and reviewing whether you remain logged in to the application within your own user context, or that of another user, or none at all.

3. You can test for CBC cipher manipulation vulnerabilities by running a Burp Intruder attack over the whole token, using the “bit flipping” payload source. If the bit flipping attack identifies a section within the token, the manipulation of which causes you to remain in a valid session, but as a different or nonexistent user, perform a more focused attack on just this section, trying a wider range of values at each position.

4. During both attacks, monitor the application’s responses to identify the user associated with your session following each request, and try to exploit any opportunities for privilege escalation that may result.

5. If your attacks are unsuccessful, but it appears from step 1 that variable length input that you control is being incorporated into the token, you should try generating a series of tokens by adding one character at a time, at least up to the size of blocks being used. For each resulting token, you should reperform steps 2 and 3. This will increase the chance that the data you need to modify is suitably aligned with block boundaries for your attack to succeed.

Some Weaknesses

• Disclosure of Tokens on the Network, Some applications elect to use HTTPS to protect the user’s credentials during login but then revert to HTTP for the remainder of the user’s session.
• Disclosure of Tokens in Logs

Securing session management

• Generate Strong Token
• Protect Tokens Throughout Their Life Cycle
• Session Termination
• Session Timeout
• TLS Sessions