Learn from Okta's 2023 breach—stolen session tokens exposed in HAR files. Lessons on JWTs, session cookie security, and vital config changes for Okta, Keycloak, and AWS Cognito. Dive into defense in depth with CoGuard for configurations across your infrastructure layers.
In October 2023, Okta reported a breach of their support system:
This breach contains lessons for system administrators and a reminder about the shared-responsibility policy for cloud vendors that we already touched on in Shared Responsibility for PaaS configuration.
The bad actor in the Okta breach compromised user sessions by capturing session tokens from customer’s administrators accounts. The credentials were accessed by stealing HTTP Response Archive (HAR) files, the most common mechanism for troubleshooting, on Okta’s customer support system. HAR files contain a record of a user’s browser session, a step-by-step audit that a user can share with the help desk to debug or diagnose an issue. HAR file captures can contain a lot of information including: request and response headers, payload content, timing information and within this information they contain session cookies. Session cookies allow web applications to maintain stateful information across web sessions, like how you’re able to stay logged in for a period of time even if you close the page. HAR files are an incredibly useful tool for developers, support teams and administrators providing a common one-click solution to share diagnostic information between an end user and the team.
Where it gets really interesting is these HAR Files contained JSON Web Tokens (JWT). A lot of web applications use JWTs to manage user sessions, authentication, authorization and single sign on. JWTs are a convenient, structured way to transmit data securely over the web. A JWT consists of three parts – header, payload and a signature. JWTs are stateless and can contain user data directly. And it’s really, really bad if someone steals your JWT. JWTs are used to identify users and if an attacker has stolen the JWTs they have access to the accounts and services in the same way as the user. The attacker can make service changes, account updates, access sensitive information, etc. The only real protection is that JWT can be configured to automatically expire.
We were surprised that the session tokens were in the HAR files and that the tokens were still valid.
There are 2 quick changes to the support team and infrastructure as a result of this breach.
Not all of the authentication systems support an inactivity policy, despite it being defined in the OAuth2 standard (it is currently not supported by Cognito).
Okta settings must be reviewed via their Web UI and you need to have API access. The Okta access policies apply to a particular OpenID Connect application and can define different access and refresh token lifetimes.
These settings are very permissive. They leave open the exact opportunity that was exploited in the breach at Okta. We recommend shorter token expirations (see above).
Keycloak allows the configuration of these settings in the Sessions and Tokens tabs in the Realm settings menu.
Much more secure by default, but you are allowed to shoot yourself into the knee and create less secure configurations.
The default access token expiry and refresh token expiry are:
These settings are what we would call dangerous defaults, basically, please, please, please don’t do this. You need to update the AWS default settings to something that is more secure. .
For Keycloak and AWS Cognito, the access token expiry settings can be managed via configuration files (Keycloak) or cloud orchestration tools like CloudFormation/TF/Ansible (Cognito). All of these settings can be extracted and evaluated using CoGuard.
Defense in depth is a security strategy that employs multiple layers of protection to safeguard systems. It involves a combination of technical measures, such as access limitation by VPN or IP address along with procedural controls. This multi-layered approach aims to mitigate the impact of a security breach by creating obstacles at various levels, making it harder for adversaries to compromise the entire system. It's like having a series of locked doors—each providing a barrier, enhancing overall security.
At CoGuard, we believe that the configuration of the authentication system can include these additional protections of robust authentication mechanisms across all layers of the infrastructure.
The first step is to uncover any blind spots in your configurations of your infrastructure, containers and applications. CoGuard uses your existing configuration files or cloud configurations to evaluate the state of your infrastructure including your authentication system.
Get started today by scanning your cloud configurations in 2 quick steps:
(Or switch aws for gcp or azure as your situation requires.)
