Attacking Session Management

The Need for State

  • HTTP protocol is stateless, and yet maintaining state is an essential part of modern web-applications. It normally only allows a basic request-response model.
  • To implement most any functionality of today's applications, sessions are required.
  • Even some sites without login functionality still use sessions. For instance, shopping websites might maintain a session to link a 'cart' to a user.

  • Common implementations:

    • Use a session token or identifier.

      • Weaknesses.

        • Bad generation of session tokens
        • Bad handling of session tokens in their life cycle

      • Client Requests: Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55

      • Server Response: Set-Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55

Alternatives to Sessions

  • HTTP Authentication
    • Using basic, digest, or NTLM authentication technologies can sometimes avoid the need for sessions.
    • Using HTTP headers, the client can interact with the authentication mechanism. They are resubmitted with each request.
    • This is rarely used on web applications.
  • Sessionless state mechanisms
    • Done without session tokens, the state is still maintained by the client application.
    • The client application must be sufficiently protected using encryption or signing using a recognized algorithm.

Weaknesses in Token Generation

  • Tokens are often generated in unsafe manners, allowing an attacker to predict the token values for other users.

Meaningful Tokens

  • Session tokens may be generated using a user's username or email address. The information is then encoded or obfuscated.
    • e.g. Using name-value pairs, a username, role, and date may be concatenated and encoded in base-64. Then, this encoded string can be used as a session token.
  • If the token is extremely easy to decode, an attacker can just alter the values and encode them again.
  • Potential information that can be used in session tokens and lead to vulnerabilities:
    • Usernames
    • Unique Identifiers
    • First and last names
    • E-mail addresses
    • Group or role
    • Date/time stamp
    • incremented or predictable number
    • IP address
  • Process:
    1. Obtain a valid token, then modify it systematically.
      • Is it validated? Are some components ignored?
    2. Login as multiple different users at different times, recording the tokens sent back as responses from the server.
    3. Analyze the tokens for correlations that may relate to username or user-controllable data.

Predictable Tokens

  • Tokens might not be meaningful, but they can still be predictable in some way.
  • Three different attributes leading to predictable session tokens:
    1. Concealed Sequences
      • These are not easily predictable without sufficient decoding and unpacking.
      • Often, these take multiple stages of decoding and unpacking to make any sense or reason of their generation.
        • e.g. One may need to decode a base-64 encoded token, then render the data as hexadecimal then subtract each number by the previous number to generate a concealed pattern.
    2. Time Dependency
      • Tokens might be generated based upon times. For instance, each subsequent token issues by a server might just be incremented by the amount of time passed between the previous and the new token.
      • Process:
        1. Continue polling the server to get new session tokens quickly.
        2. Monitor how the first substring might increment.
        3. When the first sub-string increments, the upper and lower bounds of the second number are now known.
        4. Due to this, a small number of guesses can be done to find the second sub-string value corresponding to the session token of the newly logged-in user.
        5. With each increment of the first sub-string, the second sub-string can be easily brute-forced.
        6. By repeating this method, each newly logged in user can be obtained.
    3. Weak Random Number Generation
      • Predictable pseudorandom number generation can be employed to generate session tokens.
      • If a server uses java.util.Random to generate session tokens, a "linear congruential generator" generates the next number.
        • Last number * Constant-A + Constant-B
      • By obtaining a single session token, current and future session tokens may be discerned if the random number generation is poorly implemented.
      • Other solutions might combine this tactic with a known bit of data, such as an IP address, and using a common piece of data, such as epoch time.
Testing the Quality of Randomness
  • Process:
    1. Start with hypothesis that tokens are randomly generated
    2. Apply many tests to observe specific properties of the sample
    3. Calculate the probability of certain observed characteristics appearing
    4. If the probability fails below a certain level of significance, reject the hypothesis and conclude that tokens are not randomly generated

Encrypted Tokens

ECB Ciphers
  • "Electronic codebook" ciphers.
  • These are used by some symmetric encryption algorithms.
  • Divides plaintext into equal-sized blocks and encrypts each block using a secret key.
  • Patterns in the plaintext can appear in the ciphertext.
  • This encryption method is vulnerable to injections of ciphertext replacing other blocks of code, as the replacing block can just be encrypted with the same block size and placed in the middle of known ciphertext.
CBC Ciphers
  • Cipher block chaining ciphers
  • Issues with ECB ciphers led to this encryption method.
  • Each previous block of ciphertext is used to xor the next block of ciphertext. In decryption, the XOR operation is done in reverse.
  • By systematically changing characters, parts of the token can be altered which can cause different side effects regarding the server processing of the token.
  • Process:
    1. If the session token isn't immediately meaningful or sequential, it is probably encrypted. To identify if a block-based cipher is being used, register using multiple usernames with increasing length.
    2. If the session key size increases by 8 or 16 bytes, then it probably is using a block-based cipher.
    3. To test if it is using an ECB cipher, try blindingly duplicating blocks of ciphertext and moving them around.
    4. To test if a CBC cipher is being used, try a "bit flipping" payload approach to identify a section in the token that still allows for a valid session.
      1. Then, try different permutations based on changes to this block.

Weaknesses in Session Token Handling

  • By failing to handle session tokens correctly, an attacker can take over a session despite being unable to decrypt or deobfuscate tokens.

Disclosure of Tokens on the Network

  • Unencrypted token transmissions can allow an eavesdropper to intercept a token.
  • Examples of vulnerabilities despite HTTPS usage:
    • Reverting to HTTP during sessions
    • Issuing session tokens early using HTTP, then switching to HTTPS after initiating authentication
    • HTTP webpages in the scope of the cookie, causing it to be submitted unsecurely despite their inherent harmlessness
    • Allowing login over HTTP using certain URLs
    • Using HTTP for static content

Disclosure of Tokens in Logs

  • Logs may be found on:
    • Browsers
    • Web servers
    • Corporate or ISP proxy servers
    • Reverse proxies in the application's hosting environment
    • Referer logs

Vulnerable Mapping of Tokens to Sessions

  • Examples of vulnerabilities in session token mapping:
    • Allowing multiple valid tokens for one user account
    • Using "static" tokens. These are tokens that are reused and barely, if not at all, changed.
    • Using random values paired with user information as a session token, but not properly validating that either must be paired with each other during requests.

Vulnerable Session Termination

  • Important because...
    • it reduces the window for attacks
    • allows users to invalidate an existing session that they are done with
  • Examples of vulnerabilities:
    • Failing to logout at all due to..
      • Lack of functionality
      • Extremely poor implementation
    • Failing to invalidate sessions after logout
    • Lack of communication between logout components and the server.

Client Exposure to Token Hijacking

  • Examples of token hijacking:
    • Cross-site scripting that queries the user's cookies for a session token
    • Feeding a token to a user, then using that same token post-authentication.
  • Cookies can have a domain and path specified during the Set-cookie instruction.
  • Cookies will only be submitted to the subdomain that the cookie was set from by default.
  • Although, this can be changed by setting the domain attribute of the Set-cookie instruction. If this is set too liberally, the application can be vulnerable.
  • Solution: scope the cookie to a domain that is dedicated only to that one application.
  • If an application is at a particular path, the cookie is by default only resubmitted to that path and its sub-directories. Just like the domain, the path can also be changed to better define the cookie scope of use.

Secure Session Management

Generate Strong Tokens

  • Use a large set of possible values
  • Use strong pseudo-randomness
    • Include some information as a seed or part of the algorithm to add entropy to the algorithmic generation of tokens:
      • User-Agent
      • Time of the request
      • Source IP and port number
  • Sufficient length and complexity should make it extremely difficult to brute force.
  • Use only an identifier issued by the server.
  • Do not use any meaning or structure in the tokens.

Protect Tokens Throughout Their Life Cycle

  • Transmit tokens over HTTPS.
  • Only accept encrypted tokens.
  • Flag HTTP cookies, if used, as secure. Prevents transmission over HTTP.
  • Try to use HTTPS on every page of the application.
  • Never transmit session tokens in the URL.
  • Implement proper logout functionality
  • Prevent concurrent logins.
  • Use a minimal scope for domain and path scopes of the cookie.
Per-Page Tokens
  • In this, every new request results in a new page token.
  • Every subsequent request validates the last page token value that was issued.

Log, Monitor, and Alert

  • Monitor requests using invalid tokens
  • Prevent or mitigate brute-force attacks in some extent.
    • One possibility is to block source IP addresses for limited periods of time
  • Keep detailed logs and alert on anomalies
Reactive Session Termination
  • Terminate session on anomalous requests
    • Modified HTML form fields
    • Modified query string parameters
    • Strings associated with SQLi and Cross-site Scripting

results matching ""

    No results matching ""