attacking session management

Chapter.07 Attacking Session Management

KoreaTechWeb Application Hacking & Security Study

Presenter : Alchemic

(SoftTrack Administrator)(KoreaTech Information Security Researcher)

(NLP Practitioner)

Index

0x01. The Need for State1) Alternatives to Sessions

0x02. Weaknesses in Token Generation1) Meaningful Tokens2) Predictable Tokens3) Encrypted Tokens

0x03. Weaknesses in Session Token Handling1) Disclosure of Tokens on the Network2) Disclosure of Tokens in Logs3) Vulnerable Mapping of Tokens to Sessions4) Vulnerable Session Termination5) Client Exposure to Token Hijacking6) Liberal Cookie Scope

212/15/2015 SoftTrack

0x04. Securing Session Management1) Generate Strong Tokens2) Protect Tokens Throughout Their Life Cycle3) Log, Monitor, and Alert

Ch 7. Attacking Session Management

The session management mechanism is a fundamental security componentin the majority of web applications.

It is what enables the application to uniquely identify a given user across anumber of different requests and to handle the data that it accumulates aboutthe state of that user’s interaction with the application.


If an attacker can break an application’s session management, she can effect-tively bypass its authentication controls and masquerade as other applicationusers without knowing their credentials.

0x01. The Need for State


12/15/2015 SoftTrack 5


The majority of web “sites” are in fact web applications.

They allow you to register and log in.

They let you buy and sell goods.

They remember your preferences the next time you visit.

They deliver rich multimedia experiences with content created dynamicallybased on what you click and type.

To implement any of this functionality, web applications need to use theconcept of a session.



The simplest and still most common means of implementing sessions is toissue each user a unique session token or identifier.

In most cases, applications use HTTP cookies as the transmission mechanismfor passing these session tokens between server and client.

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

and subsequent requests from the client contain this header:



This standard session management mechanism is inherently vulnerable tovarious categories of attack.

An attacker’s primary objective in targeting the mechanism is to somehowhijack the session of a legitimate user and thereby masquerade as that person.

If the user has been authenticated to the application, the attakcer may be ableto access private data belonging to the user or carry out unauthorized actionson that person’s behalf.

If the user is unauthenticated the attacker may still be able to view sensitiveinformation submitted by the user during her session.



The vulnerabilities that exist in session management mechanisms largely fallinto tow categories:

■ Weaknesses in the generation of session tokens

■ Weaknesses in the handling of session tokens throughout their life cycle



Alternatives to Sessions

■ HTTP authenticationApplications using the various HTTP-based authentication technologies(basic, digest, NTLM) sometimes avoid the need to use sessions.

12/15/2015 SoftTrack 10


Alternatives to Sessions

■ Sessionless state mechanismsSome applications do not issue session tokens to manage the state of auser’s interaction with the application.

Instead, they transmit all data required to manage that state via the client,usually in a cookie or a hidden form field.

In effect, this mechanism uses sessionless state much like the ASP.NETViewState does.

For this type of mechanism to be secure, the data transmitted via the clientmust be properly protected.

12/15/2015 SoftTrack 11

0x02. Weaknesses in Token Generation

12/15/2015 SoftTrack 12


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

★ NOTEThere are numerous locations where an application’s security depends onthe unpredictability of tokens it generates. Here are som examples :

■ Password recovery tokens sent to the user’s registered e-mail address

■ Tokens placed in hidden form fields to prevent CSRF 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 useauthentication to retrieve the current status of an existing order

12/15/2015 SoftTrack 13


Meaningful Tokens

Some session tokens are created using a transformation of the user’s usernameor e-mail address, or other information associated with that person.For example, the following token may initially appear to be a long random string:

However, on closer inspection, you can see that it contains only hexadecimalcharacters.

Decoding…

12/15/2015 SoftTrack 14


Meaningful Tokens

Tokens that contain meaningful data often exhibit a structure.In other words, they contain serveral components, often separated bya delimiter, that can be extracted and analyzed separately to allow anattacker to understand their function and means of generation.

■ The Account username

■ The numeric identifier that the application uses to distinguish betweenaccounts

■ The user’s first and last names

■ The user’s e-mail address

■ The user’s group or role within the application

■ A date/time stamp

■ An incrementing or predictable number

■ The client IP address

12/15/2015 SoftTrack 15


Meaningful Tokens

Encoding schemes that are commonly encountered include XOR, Base64, andhexadecimal representation using ASCII characters.

It may be necessary to rest varous decodings on each component of astructured token to unpack it to its original form.

12/15/2015 SoftTrack 16


Predictable Tokens

Some session tokens do not contain any meaningful data associating themwith a particular user. Nevertheless, they can be guessed because they containsequences or patterns that allow an attacker to extrapolate from a sample oftokens to fi nd other valid tokens recently issued by the application.

In the simplest and most brazenly vulnerable cases, an application may usea simple sequential number as the session token.

Predictable session tokens commonly arise from three different sources:

■ Concealed sequences

■ Time dependency

■ Weak random number generation

12/15/2015 SoftTrack 17


Predictable Tokens

12/15/2015 SoftTrack 18


Predictable Tokens

■ Concealed sequencesIt is common to encounter session tokens that cannot be easily predictedwhen analyzed in their raw form but that contain sequences that revealthemselves when the tokens are suitably decoded or unpacked.

Consider the following series of values, which form one component of astructured session token:

12/15/2015 SoftTrack 19


Predictable Tokens

■ Concealed sequencesNo immediate pattern is discernible; however, a cursory inspection indicatesthat the tokens may contain Base64-encoded data.In addition to the mixed-case alphabetic and numeric characters, there is a+ character, which is also valid in a Base64-encoded string.Running the tokens a Base64 decoder reveals the following:

12/15/2015 SoftTrack 20


Predictable Tokens

■ Concealed sequencesThese strings appear to be gibberish and also contain nonprinting characters.This normally indicates that you are dealing with binary data rather thanASCII text.Rendering the decoded data as hexadecimal numbers gives you the following:

12/15/2015 SoftTrack 21


Predictable Tokens

■ Concealed sequencesThere is still no visible pattern.However, if you subtract each number from the previous one, you arriveat the following:

which immediately reveals the concealed pattern.

12/15/2015 SoftTrack 22


Predictable Tokens

■ Concealed sequences

The algorithm used to generate tokens adds 0x97C4EB6A to the previousvalue, truncates the result to a 32-bit number, and Base64-encodes thisbinary data to allow it to be transported using the text-based protocolHTTP.

Value+ 0x97C4EB6A

ValueDividing… (32bit)

Value

Base64 Encoding…

Final Value

12/15/2015 SoftTrack 23


Predictable Tokens

■ Time DependencySome web servers and applications employ algorithms to generatesession tokens that use the time of generation as an input to thetoken’s value.

If insuffi cient other entropy is incorporated into the algorithm, youmay be able to predict other users’ tokens.

In a busy application with a large number of sessions being createdeach second, a scripted attack may succeed in identifying large numbersof other users’ tokens.

12/15/2015 SoftTrack 24


Predictable Tokens

■ Time Dependency

Each token is clearly composed of two separate numeric components.The first number follows a simple incrementing sequence and is easyto predict.The second number increases by a varying amount each time.

12/15/2015 SoftTrack 25


Predictable Tokens

■ Time DependencyCalculating the differences between its value in each successive tokenreveals the following:

12/15/2015 SoftTrack 26


Predictable Tokens

■ Time Dependency

Comparing this second sequence of tokens with the fi rst, two points areimmediately obvious:

12/15/2015 SoftTrack 27


Predictable Tokens

■ Time Dependency

1) The fi rst numeric sequence continues to progress incrementally;however, five values have been skipped since the end of the firstsequence. This is presumably because the missing values have beenissued to other users who logged in to the application in the windowbetween the two tests.

2) The second numeric sequence continues to progress by similarintervals as before; however, the first value we obtain is a massive539,578 greater than the previous value.

This second observation immediately alerts us to the role played bytime in generating session tokens.

12/15/2015 SoftTrack 28


Predictable Tokens

■ Time DependencyIndeed, our hunch is correct. In a subsequent phase of our testing weperform a code review, which reveals the following token-generationalgorithm:

12/15/2015 SoftTrack 29


Predictable Tokens

■ Weak Random Number Generation

Very little that occurs inside a computer is random.

Therefore, when randomness is required for some purpose, software usesvarious techniques to generate numbers in a pseudorandom manner.

An attacker who obtains a single session token from the server can obtainthe tokens of all current and future sessions.

12/15/2015 SoftTrack 30


Predictable Tokens

■ Testing the Quality of Randomness

Please read the book…

Next…

12/15/2015 SoftTrack 31


Encrypted Tokens

In some situations, depending on the encryption algorithm used and themanner in which the application processes the tokens, it may nonetheless bepossible for users to tamper with the tokens’ meaningful contents withoutactually decrypting them.

Bizarre as it may sound, these are actually viable attacks that are sometimeseasy to deliver, and numerous real-world applications have proven vulnerableto them.

The kinds of attacks that are applicable depend on the exact cryptographicalgorithm that is being used.

12/15/2015 SoftTrack 32


Encrypted Tokens

■ ECB CiphersApplications that employ encrypted tokens use a symmetric encryptionalgorithm so that tokens received from users can be decrypted to recovertheir meaningful contents.Some symmetric encryption algorithms use an “electronic codebook”(ECB) cipher.

Consider an application whose tokens contain several different meaningfulcomponents, including a numeric user identifier:

12/15/2015 SoftTrack 33


Encrypted Tokens

■ ECB CiphersWhen this token is encrypted, it is apparently meaningless and is likely topass all standard statistical tests for randomness:

The ECB cipher being employed operates on 8-byte blocks of data, andthe blocks of plaintext map to the corresponding blocks of ciphertext asfollows:

12/15/2015 SoftTrack 34


Encrypted Tokens

■ ECB CiphersNow, because each block of ciphertext will always decrypt into the sameblock of plaintext, it is possible for an attacker to manipulate the sequenceof ciphertext blocks so as to modify the corresponding plaintext in meanin-gful ways.

For example, if the second block is duplicated following the fourth block,the sequence of blocks will be as follows:

12/15/2015 SoftTrack 35


Encrypted Tokens

■ ECB CiphersThe decrypted token now contains a modified uid value, and also aduplicated app value.

Exactly what happens depends on how the application processes thedecrypted token. Often, applications using tokens in this way inspectonly certain parts of the decrypted token, such as the user identifier.

If the application behaves like this, then it will process the request in thecontext of the user who has a uid of 992, rather than the original 218.

12/15/2015 SoftTrack 36


Encrypted Tokens

■ ECB CiphersSuppose you register the username daf1, and are issued with thefollowing token:

The blocks of plaintext and ciphertext for this token are as follows:

12/15/2015 SoftTrack 37


Encrypted Tokens

■ ECB CiphersIf you then duplicate the seventh block following the fourth block, yourdecrypted token will contain a uid value of 1:

12/15/2015 SoftTrack 38


Encrypted Tokens

■ ECB CiphersBy registering a suitable range of usernames and reperforming this attack,you could potentially cycle through the entire range of valid uid values, andso masquerade as every user of the application.

12/15/2015 SoftTrack 39


Encrypted Tokens

■ CBC Ciphers

The way in which CBC-encrypted tokens are often employed in webapplications means that an attacker may be able to manipulate parts ofthe decrypted tokens without knowing the secret key.

12/15/2015 SoftTrack 40


Encrypted Tokens

■ CBC CiphersConsider a variation on the preceding application whose tokens containseveral different meaningful components, including a numeric user identifier:

As before, when this information is encrypted, it results in an apparentlymeaningless token:

By manipulating a single individual block of the token, the attacker cansystematically modify the decrypted contents of the block that follows it.

Depending on how the application processes the resulting decrypted token,this may enable the attacker to switch to a different user or escalateprivileges.

12/15/2015 SoftTrack 41


Encrypted Tokens

■ CBC CiphersLet’s see how.The attacker works through the encrypted token, changing one characterat a time in arbitrary ways and sending each modifi ed token to theapplication.This involves a large number of requests.The following is a selection of the values that result when the applicationdecrypts each modifi ed token:

12/15/2015 SoftTrack 42


Encrypted Tokens

■ CBC CiphersIn each case, the block that the attacker has modifi ed decrypts into junk,as expected (indicated by ????????).

However, the following block decrypts into meaningful text that differsslightly from the original token.

Although the attacker does not see the decrypted values, the applicationattempts to process them, and the attacker sees the results in theapplication’s responses.

Often applications using tokens in this way inspect only certain parts ofthe decrypted token, such as the user identifi er. If the application behaveslike this, then the eighth example shown in the preceding list succeeds, andthe application processes the request in the context of the user who has auid of 226, rather than the original 216.

12/15/2015 SoftTrack 43


Encrypted Tokens

■ CBC Ciphers

12/15/2015 SoftTrack 44


Encrypted Tokens

■ CBC Ciphers

12/15/2015 SoftTrack 45


Encrypted Tokens

■ CBC Ciphers

12/15/2015 SoftTrack 46

0x03. Weaknesses in Session Token Handling

12/15/2015 SoftTrack 47


Disclosure of Tokens on the Network

This area of vulnerability arises when the session token is transmitted acrossthe network in unencrypted form, enabling a suitably positioned eavesdropperto obtain the token and therefore masquerade as the legitimate user.

Suitable positions for eavesdropping include the user’s local network, withinthe user’s IT department, within the user’s ISP, on the Internet backbone, withinthe application’s ISP, and within the IT department of the organization hostingthe application.

In each case, this includes both authorized personnel of the relevant organ-Ization and any external attackers who have compromised the infrastructureconcerned.

12/15/2015 SoftTrack 48



This weakness may occur in various ways, many of which can arise specificallywhen HTTP cookies are used as the transmission mechanism for session tokens:

■ Some applications elect to use HTTPS to protect the user’s credentials duringlogin but then revert to HTTP for the remainder of the user’s session.

■ Some applications use HTTP for preauthenticated areas of the site, such asthe site’s front page, but switch to HTTPS from the login page onward.

■ Even if the application issues a fresh token following successful login, anduses HTTPS from the login page onward, the token for the user’s authent-icated session may still be disclosed. This can happen if the user revisits apreauthentication page (such as Help or About), either by following linkswithin the authenticated area, by using the back button, or by typing theURL directly.

12/15/2015 SoftTrack 49



This weakness may occur in various ways, many of which can arise specificallywhen HTTP cookies are used as the transmission mechanism for session tokens:

■ In a variation on the preceding case, the application may attempt to switchto HTTPS when the user clicks the Login link.

■ Some applications use HTTP for all static content within the application, suchas images, scripts, style sheets, and page templates.

■ Even if an application uses HTTPS for every page, including unauthenticatedareas of the site and static content, there may still be circumstances in whichusers’ tokens are transmitted over HTTP.

12/15/2015 SoftTrack 50


Disclosure of Tokens in Logs

Aside from the clear-text transmission of session tokens in network communi-cations, the most common place where tokens are simply disclosed to unauth-orized view is in system logs of various kinds.

Although it is a rarer occurrence, the consequences of this kind of disclosureare usually more serious.

When applications transmit their session tokens in this way, it is likely thattheir session tokens will appear in various system logs to which unauthorizedparties may have access:

■ User’s browser logs■ Web server logs■ Losg of corporate or ISP proxy servers■ Logs of any reverse proxies employed within the application’s hosting

environment■ The Referer logs of any servers that application users visit by following off-

site links, as shown in next Figure

12/15/2015 SoftTrack 51


Disclosure of Tokens in Logs

12/15/2015 SoftTrack 52


Vulnerable Mapping of Tokens to Sessions

Base64 Decoding….

12/15/2015 SoftTrack 53


Vulnerable Session Termination

Proper termination of sessions is important for two reasons.

First, keeping the life span of a session as short as is necessary reduces thewindow of opportunity within which an attacker may capture, guess, or misusea valid session token.

Second, it provides users with a means of invalidating an existing session whenthey no longer require it.

■ In some cases, a logout function is simply not implemented. Users haveno means of causing the application to invalidate their session.

■ In some cases, the logout function does not actually cause the server toinvalidate the session. The server removes the token from the user’s browser(for example, by issuing a Set-Cookie instruction to blank the token).However, if the user continues to submit the token, the server still accepts it.

■ In the worst cases, when a user clicks Logout, this fact is not communicatedto the server, so the server performs no action.

12/15/2015 SoftTrack 54


Client Expowure to Token Hijacking

An attacker can target other users of the application in an attempt to captureor misuse the victim’s session token in various ways:

■ An obvious payload for cross-site scripting attacks is to query the user’scookies to obtain her session token, which can then be transmitted to anarbitrary server controlled by the attacker.

■ Various other attacks against users can be used to hijack the user’s sessionin different ways. With session fi xation vulnerabilities, an attacker feedsa known session token to a user, waits for her to log in, and then hijacksher session. With cross-site request forgery attacks, an attacker makesa crafted request to an application from a web site he controls, and heexploits the fact that the user’s browser automatically submits her currentcookie with this request.

12/15/2015 SoftTrack 55


Liberal Cookie Scope

The usual simple summary of how cookies work is that the server issues acookie using the HTTP response header Set-cookie, and the browser thenresubmits this cookie in subsequent requests to the same server using theCookie header.

In fact, matters are rather more subtle than this.

- Cookie Domain Restrictions- Cookie Path Restrictions

Please read the book…Next…

12/15/2015 SoftTrack 56

0x04. Securing Session Management

12/15/2015 SoftTrack 57


Generate Strong Tokens

The most effective token generation mechanisms are those that:

■ Use an extremely large set of possible values■ Contain a strong source of pseudorandomness, ensuring an even and

unpredictable spread of tokens across the range of possible values

The objective of designing a mechanism to generate strong tokens is that itshould be extremely unlikely that a determined attacker with large amountsof bandwidth and processing resources should be successful in guessing asingle valid token within the life span of its validity.

Here are some examples of information that may be incorporated:

■ The source IP address and port number from which the request was received■ The User-Agent header in the request■ The time of the request in milliseconds

12/15/2015 SoftTrack 58


Generate Strong Tokens

A highly effective formula for incorporating this entropy is to construct a stringthat concatenates a pseudorandom number, a variety of request-specific data aslisted, and a secret string known only to the server and generated afresh oneach reboot.

12/15/2015 SoftTrack 59


Protect Tokens Throughout Their Life Cycle

Now that you’ve created a robust token whose value cannot be predicted, thistoken needs to be protected throughout its life cycle from creation to disposal,to ensure that it is not disclosed to anyone other than the user to whom it isissued:

■ The token should only be transmitted over HTTPS.

■ Session tokens should never be transmitted in the URL, because thisprovides a simple vehicle for session fi xation attacks and results in tokensappearing in numerous logging mechanisms.

■ Logout functionality should be implemented.

■ Session expiration should be implemented after a suitable period of inactivity(such as 10 minutes). This should result in the same behavior as if the userhad explicitly logged out.

12/15/2015 SoftTrack 60



■ Concurrent logins should be prevented. Each time a user logs in, a differentsession token should be issued, and any existing session belonging to theuser should be disposed of as if she had logged out from it.

■ If the application contains any administrative or diagnostic functionality thatenables session tokens to be viewed, this functionality should be robustlydefended against unauthorized access.

■ The domain and path scope of an application’s session cookies should beset as restrictively as possible.

Specific measures should be taken to defend the session managementmechanism against the variety of attacks that the application’s users may findthemselves targets of:

12/15/2015 SoftTrack 61



■ The application’s codebase should be rigorously audited to identify andremove any cross-site scripting vulnerabilities.

■ Arbitrary tokens submitted by users the server does not recognize shouldnot be accepted.

■ Cross-site request forgery and other session attacks can be made more diffi-cult by requiring two-step confi rmation and/or reauthentication beforecritical actions such as funds transfers are carried out.

■ Cross-site request forgery attacks can be defended against by not relyingsolely on HTTP cookies to transmit session tokens.

■ A fresh session should always be created after successful authentication, tomitigate the effects of session fi xation attacks.

12/15/2015 SoftTrack 62


Per-Page Tokens

Finer-grained control over sessions can be achieved, and many kinds of sessionattacks can be made more diffi cult or impossible, by using per-page tokens inaddition to session tokens.

12/15/2015 SoftTrack 63


Log, Monitor, and Alert

The application’s session management functionality should be closely integratedwith its mechanisms for logging, monitoring, and alerting to provide suitablerecords of anomalous activity and to enable administrators to take defensiveactions where necessary:

■ The application should monitor requests that contain invalid tokens.

■ Brute-force attacks against session tokens are diffi cult to block altogether,because no particular user account or session can be disabled to stop theattack.

■ Even if brute-force attacks against sessions cannot be effectively preventedin real time, keeping detailed logs and alerting administrators enables themto investigate the attack and take appropriate action where they can.

■ Wherever possible, users should be alerted to anomalous events relating totheir session, such as concurrent logins or apparent hijacking (detected usingper-page tokens).

Thank you !

KoreaTechWeb Application Hacking & Security Study

Presenter : Alchemic

(SoftTrack Administrator)(KoreaTech Information Security Researcher)

(NLP Practitioner)

attacking session management

Education