BLOG POST

One of the best things you can do is take time to understand how the authentication system works on your target site. How is the session stored? In a cookie? In the URL? What happens when you fuzz or substitute random values for the session ID value? How does the application react in different scenarios? That's what we're going to talk about in-depth with some actual steps on how to find out.

You're reading: Part 2: Recon. Visit Part 1: Intro and Part 3: Exploitation.

A few notes on getting to know your target:

1. Spend some time analyzing the URLs that are involved in the authentication process. Note any redirects that occur and if there are any interesting GET and POST parameters being passed. The goal is to understand what is taking place server-side to authenticate the user.
2. Identify all cookies, deleting them one by one (you can delete and flag if you are using the chrome plugin edit this cookie, until you know which contains the session key. Also analyze the URLs for authenticated users and be able to identify what exactly is identifying the user.
3. Note all cookies and their values--you may need them later.
4. Validate that the secure flag is set on all session cookies. I.e Any cookie with the "session" flag must also have the "secure flag".
5. Check for the persistence of cookies. If you have visited the target, delete all cookies for the site and then close the browser. Proceed with the following steps, noting the session cookie value at each step

After each of the steps below, note the session value and label it accordingly so you can see how it is handled.

1. open browser and visit the target
2. login
3. logout
4. login again
5. log out again
6. close browser
7. open browser and visit site
8. login again
9. logout again

Compare cookie values from the above steps. Note any issues with the following best practices:

1. 'logged out' cookie values should not persist and become 'logged in' cookie values after authentication.
   • Why this is bad: If your logged out cookie value is re-used when you are authenticated then two things can go wrong:
   • if your logged out cookie value was at any point compromised, all the attacker has to do is programmaitcally check an authenticated page to see if passing that compromised value allows access. If the session is only identified using that cookie value (VERY common) they can then hijack your session.
   • If the logged out (unauthenticated) value is re-used and has no association with a particular user account, the attacker can provide an unauthenticated cookie value to a user and prompt them to log in (using a phishing or browser hijack or malicious iframe attack) and achieve the same goals of account compromise.
2. 'logged in' cookies should be destroyed when the browser is closed so that re-opening the browser does not give you a logged-in session.
   • Why this is bad: If a user closes the browser without logging out, that authenticated cookie value may be compromised, especially if no session activity timeout has been implemented. This is somewhat harder to implement, but a requisite session activity timeout can effectively mitigate this problem.
3. The same 'logged in' cookie value should not be given every time you authenticate.
   • Why this is bad: Anytime an authentication system identifier is re-used bad things can happen. They become a more attractive target for attackers because they know that the upside potential is higher that once compromised, the identifier has a longer useful life.
4. The 'logged out' cookie value should not determine what 'logged in' cookie value you will be issued after authentication. The 'logged in' cookie received should be random.
   • Why this is bad: If the session identifier (the session cookie value) is not random and difficult to guess the mechanism for generating that token can be reverse engineered and implemented in an attack. Think cryptographically secure.
   • The 'logged in' cookie value should not become the 'logged out' cookie value after logout.
5. Why this is bad: This situation introduces a couple of issues. It allows information to be le-aked on what an authenticated cookie value looks like, as well as perhaps creating enough data to engineer a hash collision condition.

A few questions to answer as a result of your testing:

1. Are session cookies protected? Session cookies should be treated like all other user input and be validated by the web application server, never client-side. Best practice is to hash the session cookie so that session manipulation and hijacking attempts are much more difficult.
2. Is the session cookie encoded? Sometimes decoding a session cookie can reveal additional items that are bundled with the session ID that may be interesting. One will need to figure out how to decode encoded cookies so that session ID values from different cookeis and users can be compared to look for vulnerabilities.
   • For example, ruby on rails has the capability to encode rails objects into the session cookie value. Handled properly this can be a convenient way for the developer to store items that are useful to display (language preference, themes, colors, etc). Handled improperly or including interesting information that should be considered sensitive (account numbers, PII data, etc) can be decoded trivially and disclosed to anyone that captures the session cookie (via network traffic sniffing, browser attacks, etc.).
   • Here is a little code that can be used to decode a rails cookie written by our own Jeff Stiles.
3. Is the session ID bound to any other attributes? With a logged in account, change your IP address and then check if you are still authenticated. Do the same with the user-agent (and client certificates if you received one). If altering these attribtues does not affect your authentication status, the session ID is not bound to any additional user property. While best practice is to bind the session to another property, the absense of this does not necessarily indicate a vulnerability, however, the more attributes you can incorporate the better as it will deter session hijacking.
4. How are logins from different browsers instances for the same un/pw treated? Do they receive the same session ID? If one logs out, is the other logged out?
5. Does logging out really log you out? Record the cookie for a logged in user and log out. Update the session cookie to the previous 'logged in' cookie value and attempt to visit a restricted/authenticated web page.
6. Attempt to understand any single sign-on (SSO) systems and look for weaknesses. Oauth has many implementation difficulties.

This is Part 2: recon. Visit Part 1: Intro and Part 3: Exploitation