Sessions - MFA Caveat

Most, if not all, within the security community know that we should leverage multi-factor authentication (MFA) wherever possible. This ensures that attackers will have an exceedingly tough time accessing your account. They have multiple barriers to overcome to access (log into) your account. However, there is a significant caveat to this, user sessions. With the recent Okta breach, this highlights the shortcoming of this.

Sessions Overview

What are sessions? Why do we need them? HTTP is a stateless protocol. This means that the server doesn't know who a request is coming from just by using the protocol. To get around this problem, a notion of a session was introduced. This is a piece of data that allows a request to be associated with a specific user. This data typically can come in two flavours:

• Session Cookies
• Session Tokens

Session Cookies

In this scenario the user's browser leverages cookies, along with the server to store data associate with the current user. Typically for session cookies this is a random string that is set by the server once a user has successfully authenticated.

Session Tokens

This is typical with modern single-page applications. This is where the web interface is dynamically generated from a JavaScript framework such as Angular or React. In this case cookies typically don't work all that well (much of the calls are API calls), so a different type of data structure is typically used, JSON Web Tokens (JWT). These are then stored to the browser's local storage, or session storage.

The Problem

So now that we have a better picture of what a session is and why it's needed, what's the problem? Well, if we follow the sequence of authentication:

1. The user navigates to the site.
2. No session information is associated with the user.
3. The user is prompted for authentication by the server.
4. The user enters their MFA credentials and token.
5. The server generates a session token (JWT) or session cookie and returns this to the user's browser.
6. Subsequent requests from the user's browser to the server send this session token or cookie to sever, and the server can associate that request to the logged in user.

This is all well and good. We have a robust and secure means of obtaining the token (via MFA). But what happens if someone or something obtains this token? Well, if they do, they now have access to the user's session! So, you could have all the multiple authentication factors in place, the most robust authentication steps required (take blood, fingerprints, DNA, etc), but unless you protect that session token or cookie, they are irrelevant. This is known as session hijacking, and has been around for quite some time.

This is exactly what happened in the Okta incident. As part of the support process, clients sent in HAR files when raising a support ticket with the Okta team. The problem is that these files contained ALL information regarding interactions with the Okta service (both requests and responses). This meant if you had access to these HAR files, you were able to obtain the session token or cookie! The attackers managed to gain access to Oktas systems and then obtain these files.

So, while we focus on MFA, as we should, we haven't focused on the elephant in the room, session management. Technically this is a form of single factor authentication since you only need to provide the session token or cookie to "authenticate" to the server for your request.

Now in the past this might not have been such an issue since we had short lifespans associated with these cookies or tokens. It typically was around 30 minutes of inactivity. After this the token or cookie would be invalidated and no longer valid. In the case of Okta, if this were the case, the attackers would have been able to obtain the session token or cookie, but it would have been no use to them since it would have been invalid. But unfortunately, with modern web apps, this is no longer quite the case. Session cookies and tokens are now valid for hours, days, weeks or even in some cases they don't expire at all. Most often this was done to improve usability of the application (to avoid having to login into the application all the time).

What we need to start doing is looking at our session management and start putting stricter controls and checks on these session cookies and tokens. Once such approach that we should leverage is associating sessions tokens and cookies with IP addresses. Or even better associate them with specific devices!

This will help limit the possibility of an attacker being able to use these session tokens or cookies should they get their hands on them. The other option is setting session timeouts, but there is the usability aspect to consider. Another option is also to periodically change the value of the session token or cookie, so you could maintain the usability aspect, but reduce the risk of this token or cookie being re-played by an attacker.

Ultimately, security is only as strong as your weakest link. This is why it's so important to carry out exercises such as threat modelling as well ensuring that your employees have the appropriate training and knowledge. Finally for organisations that have support systems, work with your customers to ensure that any data is appropriately protected and where possible scrubbed of all sensitive data before it is stored.