In the current cyber threat landscape, where online security is paramount, the threat of session cookie replay attacks looms large. These attacks sidestep the conventional need for credentials and aim to hijack your online sessions, potentially compromising sensitive data and taking over user accounts. This blog post delves into the intricacies of session cookie replay attacks, shedding light on what they are, how they work, and the potential consequences they can unleash. Understanding these attacks is the first step in fortifying your online presence and ensuring the safety of your organization’s digital identity.
Understanding session cookie replay attacks
A session cookie replay attack is a cyber-attack that attempts to take over a particular user account without the need for the credentials associated with that account. That sounds pretty scary – how can that be? While identity-based attacks typically involve trying to validate or steal credentials, session cookie replay attacks focus on maliciously replaying a session cookie to a targeted web service. To fully comprehend the workings of this type of attack, it’s essential to have a solid grasp of how session cookies function.
A session cookie is a small digital marker stored in your web browser, allowing a website to customize the content it shows you. To give you a clear example of this customization, think of a scenario where a website serves specific content only after verifying your session, which is typically established during the user authentication process.
Now, imagine an attack that aims to acquire this session cookie and then use it to impersonate you on the targeted website, all from a different computer controlled by the attacker. This action of replaying the session cookie isn’t particularly complex and can be accomplished by importing the cookie into most popular web browsers using simple browser extensions. It is important to note that this doesn’t require sophisticated nation-state-level hacking tools.
Attackers employ several methods to acquire these valuable cookies. They may deploy malware on infected machines to collect cookies directly from web browsers. Alternatively, they might execute Man-in-the-Middle attacks, intercepting cookies from users by using a malicious server that sits between the user’s browser and the target service. Lately, we’ve also seen attackers compromise technical support systems, which conveniently contain recently-exported session cookies from users, originally intended for legitimate troubleshooting purposes.
How damaging can these types of attacks be?
In the simplest case, the user’s account in the targeted service can be taken over by the attacker, the user may lose access to that web service, and their sensitive data may be compromised. So that’s bad, but the blast radius from this kind of attack gets much larger if the targeted service is actually an Access Management solution providing single sign-on (SSO) access to multiple integrated services. That one session cookie can be the only thing needed to access hundreds, if not thousands, of systems integrated to trust the Access Management solution.
The blast radius can be even worse if that session cookie is associated with a user that has some type of administrative privilege on the targeted Access Management solution. In that situation, the attacker has the potential to not just overtake the user account associated with the cookie, but ultimately the entire Access Management system. At the same time, it can be used to impersonate any of the organization’s users in any of the integrated systems.
If I’m using FIDO2 MFA, I’m safe right?
Well, unfortunately, not quite. This attack relies on replaying a session cookie that’s already stored in the user’s browser. This means that the entire authentication process has already been successfully completed, and it doesn’t matter which type of MFA was used in that process. The authentication is essentially a thing of the past at this point.
Securing your Access Management solution
The key measures to defend against such attacks primarily focus on preventing the session cookie from falling into the wrong hands initially. These steps encompass security-awareness training, using endpoint protection software, implementing FIDO2-compliant Authentication Factors, controlling access to MDM-managed devices, implementing Adaptive Authentication, conducting security monitoring, and ensuring the safe handling of sensitive data, such as session cookies, when shared during technical support processes.
Once an attacker has acquired and replayed a session cookie against your Access Management solution, your focus should shift to detection and swift responses. It’s crucial to have a well-established response plan in place, particularly when there are signs of privilege associated with the targeted account within the Access Management solution.
For detection, your organization should set up rules within your SIEM (Security Information and Event Management) environment to identify irregularities, such as disparities between login events and suspicious post-login patterns for the same account. This can include unusual IP addresses, locations, or activity patterns.
When responding to such incidents, the minimum actions should involve disabling the compromised account to terminate all active sessions. Additionally, a thorough forensic examination of the activities conducted by the attacker with the stolen session cookie is essential. Engaging with your Access Management vendor for support can be valuable, as they may provide further information to aid your investigation and ongoing response efforts. Having a well-documented run book to follow during such incidents is vital for a timely and effective response.
How can organizations using OneLogin Access Management solutions protect themselves against session cookie replay attacks?
- Never assign privilege in your OneLogin production environment to standard/daily use user accounts. To put it simply, the more often you use an account, the higher the likelihood of it being abused by a session cookie replay attack. Reduce your risk exposure by allocating privilege to separate accounts, typically used less often than standard accounts, and thus lowering the chances of a session cookie with admin rights falling into the wrong hands. By providing separate accounts, this also allows you to assign more stringent security policies to these accounts, without impacting the day-to-day user experience of your Admins who also need to use the platform’s SSO capabilities.
- Automate the allocation of OneLogin user security policies to your separate Admin accounts using our Mappings capability by assigning groups (which have user security policies attached) based on conditions you define and maintain in your Mappings rule base. Ensure that session lifetime settings for high value admin accounts are configured to terminate after a maximum of 30 minutes. This change increases the difficulty for attackers in two ways: first, they must quickly obtain and transfer the session cookie to their attack machine, and second, they have limited time to maintain access with the stolen session cookie, if they can successfully replay it.
- Make certain you have a strongly controlled authentication factor registration process for Admin accounts and require at least two FIDO2 compliant factors to be registered for each admin account. Define a process to control how and when authentication factors can be registered by your users to their admin accounts. Furthermore, require admins to register two separate authentication factors against their admin accounts so in the situation where access to one authentication factors is lost, they can still access the OneLogin platform.
- Consider using our app policy “forced authentication” capability to break the SSO experience into specific high value applications just for your separated admin accounts. Should an attacker somehow acquire a valid session cookie for one of your isolated admin accounts and attempt to access an integrated application through the OneLogin portal, they will be forced to re-authenticate in order to access the target application. Their attempt to use the existing single sign-on (SSO) session will be unsuccessful. The stolen session cookie cannot be reused to bypass this request for a fresh authentication, as it is required in order to fulfil the application policy requirements.
- Maintain at least two “break-glass” accounts (the Account Owner User and one Super User account) which are tied to a corporate-owned group mailbox owned by the IAM team. These two accounts are the key components needed in any recovery plan in the event of a significant security or BCM incident. To safeguard the authentication factors linked to these critical accounts, often referred to as the “keys to the kingdom,” it is advisable to store them offline within a physical safe. This practice guarantees protection against online attacks, and it assures a reliable means of regaining access to your OneLogin environment, should you lose standard administrative access.
- Reduce the number of “ClickOps” admins who require access to your OneLogin production environment by leveraging IaC (infrastructure as code) approaches to configure and manage this environment. For example, a great way to achieve this is through using IaC approaches where the configuration for the most important components of your OneLogin service are stored as code in a secured GIT repository. Using this approach also allows an organization to reduce configuration drift between Production and Non-Production environments. This means that changes can be carried out first in a Dev/Test environment using an account with admin rights in that environment (via the admin console) to manually apply the change. Taking this approach also brings the added benefit of significantly reducing the number of admin accounts needed on Production as most changes will be applied programmatically to the environment via the OneLogin Admin API and in a controlled manner (e.g. once a week during a planned change window).
- For the remaining users still requiring admin privileges on your Production environment, leverage OneLogin’s fine-grained Delegated Administration capability to only allocate the exact privilege the user needs and nothing more. By adhering to the principle of least privilege, you can reduce the level of admin privileges granted to the account in question, minimizing the impact if a session cookie replay attack were to occur.
- Ensure the lifecycle for managing your separate OneLogin administrative accounts is tied to your current JML process for standard accounts. You do not want separate admin accounts associated to an employee that has left the organization or changed roles lingering around in your environment. As a standard, these should be disabled and removed during any JML events.
- Automate the allocation of OneLogin privileges to your separate Admin accounts using the OneLogin Mappings capability by assigning roles (which have delegated admin privileges attached) based on conditions you define and maintain in your mappings rule base. Our Mappings capability should be ideally managed and maintained by Terraform. With this approach you can ensure your mappings rule base always meets your desired state as defined in your configuration code in your GIT repository. Any mappings changes made directly to your environment via the Admin console (for example, by an attacker) will be automatically reconfigured to your desired state by scheduled Terraform runs.
- Configure a Passwordless policy and require FIDO2 compliant authentication factors at all times for all Admin accounts. Supplement this with Device Trust and IP address-based controls to further secure how and where admins can sign into the OneLogin platform. By implementing FIDO2 authentication factors, the risk of session cookie theft is minimized, as users won’t be able to complete the authentication process necessary to obtain session cookies when they are unwittingly directed to the OneLogin service via a malicious proxy. To strengthen security even more, consider limiting admin account access to specific locations, such as only allowing it from managed devices, dedicated management servers within your network, or through PAM Isolated browser environments.
- Enable Adaptive Authentication and, in particular, Smart Access on the user security polices allocated to all Admin accounts. With Adaptive Authentication in place and finely tuned for your admin users, you can reduce the attack vectors that can be leveraged by attackers to steal session cookies.
- Do not associate your Admin accounts with AD or any on-prem IdP in any way. With the ever-expanding array of attacks directed at Active Directory it makes perfect sense not to involve AD in your separated Admin accounts either from an authentication or directory sync perspective. This also aligns with Microsoft’s own advice on how to secure a Hybrid Cloud identity solution.
- Stream all OneLogin events to your SIEM/CASB platform using our webhooks capabilities or use our events API to periodically pull events in. Ensure events indicating privileged admin activity which are performed from unusual IP addresses outside of your organizations network boundaries are alerted upon and investigated immediately.
- Enable custom email notifications to be sent to users when privileged activities have been performed on your OneLogin environment from their respective admin user accounts. If users receive email notifications indicating activities performed which they do not recognize, they can immediately alert your security team to investigate and respond accordingly.
Final Thoughts
Session cookie replay attacks pose a considerable risk to digital security, allowing cybercriminals to exploit an unsuspecting user’s session information to impersonate them on a targeted website. The potential consequences are far-reaching, from compromising individual accounts to potentially gaining control over an entire Access Management system. While no security measure can be foolproof, a multi-faceted approach that combines strong user authentication, privilege management, monitoring, and rapid response can significantly reduce the vulnerability to session cookie replay attacks. Organizations must adapt and evolve their security strategies to stay one step ahead of these threats, ensuring the integrity and safety of their digital ecosystems.
Stay tuned for the second blog in this series where we will discuss how to supplement all of the controls outlined here with additional capabilities from One Identity Safeguard (PAM) and Identity Manager (IGA) solutions.
