Mesh Security Uncovers Broad MFA\SSO Bypass and Impersonation Risks in Okta and Other 100 Vendors

Trust No One? Always Verify?

Mesh Security emerges from stealth today with $4.5 million seed funding to help companies drive Zero Trust in the cloud and reveals a broad security risk called “Cookeys” in Okta (and over 100 different vendors), exposing organizations to potential breach.

Modern enterprises are shifting from perimeter-centric architecture to an identity-centric framework called “Zero Trust”. The new architecture comprises newly-introduced environments, mechanisms, processes, and technologies, including IdP, network access, micro-segmentation, SSO, MFA, and more. 

As part of our quest to empower cloud-first enterprises to implement Zero Trust architectures in the cloud, we have been conducting thorough research on how improper implementations of Zero Trust principles might expose enterprises to potential breaches and discovered design flaws in Okta and over 100 other vendors.

Upon discovering these security issues, our research team took the responsible action of sharing our findings with the relevant vendors’ security teams.

From Okta, for example, we were notified that this security issue is not considered an Okta service-specific vulnerability, claiming that their web-application validation mechanisms are properly functioning, claiming that “As a web application, Okta relies on the security of the browser and operating system environment to protect against endpoint attacks such as malicious browser plugins or cookie stealing.”

However, whether recognized as vulnerable or not – threat actors are ruthlessly taking advantage of any exploitable environment; they are indifferent regarding improper implementations or who is in charge. They will take advantage if they have not done so already. 

We believe (and so does OWASP) that this type of security issue deserves to be shared with the community, and encourage organizations to take the proper measures and controls to prevent significant business disruptions.

Security Risk Overview:

The security risk includes:

1. MFA/SSO Bypass and Impersonation 
2. Lateral movement
3. Eavesdropping
4. Unauthorized access to corporate resources (SaaS, IaaS, and data)

What is the major new security flaw that Mesh has uncovered?

The major new security flaw that we have uncovered in Okta and 100 other vendors contains two main aspects: (1) lack of cookie session validation mechanism in internet-facing & mission-critical systems and (2) inability to monitor users’ activities post-authentication inside organizations’ cloud networks. These systems serve as the core network of enterprises nowadays.

This security flaw allows any attacker from anywhere to abuse an active validated session in order to simultaneously and stealthily access corporate assets and data impersonating the victim’s identity.

This security flaw becomes substantially more critical when it comes to Okta and other ZTNA/SSE/SASE providers, as it serves as a “one-to-one-to-MANY” security hole.

OWASP introduced its recommendations on Web Authentication, Session Management, and Access Control, stating that “Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation.”

To put things straight, every vendor who intensively promotes the ‘verify explicitly’ fundamental principle should embed it in their own system. The whole idea of Zero Trust is to always explicitly verify every single digital interaction and never to trust, especially in the Cookyes security issue.

To illustrate, let’s assume that a guest comes for a visit at your headquarters. First, he gets stopped by the receptionist. They check his ID, verify that he’s on the guest list, and then supply him with a badge granting him full access for the entire day. One minute later, a different person appears, using a copy of the same badge. Should the receptionist stop him or let him in?

IdP and ZTNA vendors are the hub connecting employees and resources in the form of customized browser-based portals to access different SaaS apps, IaaS workloads, and data.

Once this security flaw is exploited, in addition to the inherent MFA bypass, it also inherits the SSO certifications, with protocols such as SAML and more.

The Likelihood of Session Cookie Theft & Reuse

Cookie theft is not a newly observed technique. Nevertheless, recently, following the global shift from “Defense-in-depth” into a distributed edge and Zero Trust identity-first framework that utilizes both MFA/SSO and web browser as the primary components to deliver ‘supervised’ user access to corporate resources, threat actors appear to focus their malicious activities mainly on these components, knowing that if they overcome these controls, they will be able to take over trusted accounts (ATO) and breach into the organization. 

Malicious actors can easily achieve session cookies through web browsing traps, common malware, or phishing campaigns.

For example, in April 2022, threat intelligence leader “Recorded Future” published that they identified 14,905 references of criminal underground posts in which the keyword “cookies” appeared.

This month, Microsoft published a study indicating that 10,000 organizations were targeted in an attempt to bypass MFA by stealing cookies. In addition, the notorious Emotet (the most prolific malware in the world today) was recently reported to be leveraging cookie-theft as part of its newest offensive tools, among many others.

RISK1: MFA/SSO Bypass and Impersonation 

Description

Adversaries can use stolen session cookies to log into different victims’ resources, including the Okta web application, and to perform an account takeover.

Surprisingly, although these attempts are expected to be blocked, the technique allows the attacker to bypass active MFA mechanisms since the session has already been verified.For example, this technique has been used lately by the APT29 attributed to Russia’s Foreign Intelligence. According to MITRE, “This attack targets the reuse of valid session ID to spoof the target system to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.”

Impact

Cookie reuse without proper validation results in an adversary that can impersonate another user to perform business functions on their behalf. This threat can lead to internal phishing, fraud, data theft, and ransomware.

After exploiting the Cookeys flaw, the threat actors gain unsupervised free access for as long as the session is valid. Based on our experience, in most cases, sessions’ time windows are longer than recommended by OWASP, which is  4-8 hours at most.

Attack Scenario

1. The user is logged into their Okta account
2. The attacker gains the user’s session cookies
3. The attacker abuses the session cookies to leverage a verified session to log into the same account from a different browser and location
4. Now, the attacker can use the user’s Okta web application account simultaneously
5. The attacker can access any authorized resources available to the user at a click of a button

Conclusion

Cookie theft is a common technique that is likely to happen in the wild, and any web application should be ready to handle a cookie reuse attack with a proper session validation mechanism. 

All a threat actor needs to do in order to gain access to a company’s assets is to gain any of its active session cookies.

RISK2: Lateral Movement

Description

Lateral Movement consists of techniques adversaries are using to hack into and control remote systems on a network. Ironically, in the old perimeter-centric world, threat actors were more challenged, as they first needed to explore the network to find their target and gain access. Potentially, when a threat actor exploits the Cookeys security flaw, they can directly reach resources at a click of a button, which doesn’t require pivoting through multiple systems and accounts. Adversaries might abuse the Cookeys issue to conduct a stealth Lateral Movement by using legitimate and verified resources to conduct their malicious activity undisturbed. 

Impact

When attackers gain the cookies of a verified session, they can access different corporate resources such as privileged accounts, SaaS applications, sensitive data, workloads, and critical-mission networks. The impact of such a scenario might disrupt business continuity due to data theft, Denial of Service, and ransomware. 

Attack Scenario

1. An attacker uses the stolen cookies to access Okta’s web console
2. Now, the attacker can access any authorized application from the Okta catalog, such as AWS Console, Salesforce, and more, at a click of a button.
3. The attacker leverages SSO and SAML to move laterally into SaaS or cloud workloads 
4. The attacker can escalate its privileges across environments and even gain persistence

Conclusion

The lack of proper session validation makes organizations susceptible to malicious players and might result in devastating implications.Threat actors who gain initial access to a victim’s account can potentially move laterally unsupervised in their quest to reveal more data, get their hands on the “vault”, or gain persistence. This security flaw serves as a “one-to-one-to-MANY” security holes.

RISK3: SaaS Eavesdropping 

Description

Once an attacker gains access to one of the SaaS application accounts via cookie reuse, they are connected and thus can be exposed to real-time changes without interference. Eavesdropping, also known as sniffing or snooping, relies on unsecured network communications to access data in transit between identities.

Impact

A traditional eavesdropping attack occurs when a hacker intercepts a session. In the new era, SaaS applications allow simultaneous connection of the same person or additional collaborators. When exploiting the Cookyes security flaw, attackers are stealthily exposed to data and can copy or use the company’s internal business information to conduct espionage, sabotage, or data theft.

Context

SaaS application adaption is booming. Large organizations use an average of 177 SaaS applications. These applications were designed for multi-user collaboration; thus, it’s almost impossible to track every SaaS usage or anomalous activity. This is why the Cookeys security flaw could be devastating. SaaS applications hold sensitive information such as PIIs, Intellectual-property, business data, and more.

Attack Scenario

1. An attacker uses the stolen cookies to simultaneously access a SaaS with a validated session.
2. The attacker stealthily observes all SaaS live activities undisturbed
3. The attacker can gather additional intelligence 
4. The attacker can copy, edit, delete, and corrupt the data.

Conclusion

SaaS applications have become the central productivity estate in modern enterprises, serving as the center of communication, data exchange, and collaboration.

An attacker with access to one of the SaaS applications could eavesdrop on a user’s activity and data undetected. In some cases, sessions remain active for weeks, so the attacker has an open channel to the company’s assets for a long period of time.

RISK4: Unauthorized access & control to corporate resources (SaaS, IaaS, and data)

Description

The Cookyes security issue opens the door to unauthorized and unsupervised access to a corporate’s most sensitive assets. Moreover, in addition to the authentication bypass, the actor “enjoys” acting as one of the company’s employees. According to Verizon, 80% of data breaches involve trusted identities. That emphasizes the importance of an identity-centric information security posture.

Impact

A data breach exposes confidential, sensitive, or protected information to an unauthorized person. When an attacker manages to exploit the Cookyes security flaw, they gain direct access to a variety of XaaS resources and data. In that case, the newly-adopted XaaS estate is security immature and prone to exploitation. This threat can result in espionage, sabotage, data theft, and ransomware.

Context

Most cyberattacks nowadays are in quest for corporate data; Data is the new currency for attackers.For malicious actors to gain possession of companies’ sensitive data would be considered an enormous success as they can manipulate it for extortion or profit purposes. Zero Trust is a model for information security that is designed around data protection. The Cookeys security issue illustrates how improper implementation of Zero Trust architecture might cause devastating results. 80% of organizations that use the cloud store sensitive data there.

Attack Scenario

1. An attacker uses the stolen session cookies to access any XaaS resource
2. The XaaS resource contains sensitive corporate data 
3. The attacker can now access data and perform malicious actions such as stealing, deleting, corrupting, encrypting, and more.

Conclusion

Leveraging trusted identities is one of the biggest threats to organizations today. Although Zero Trust is an information security model that denies access to applications and data by default, it still grants some access and permission to users. In case of a breach, threat actors can “enjoy” provisioned access and permissions of employees to leverage it to their own benefit.

How can Mesh Security help with the Cookeys security risk

Mesh Security ZTPM (Zero Trust Posture Management) is the only solution that meshes all parts into a unified ‘Zero-Trust’ cockpit and helps organizations have complete real-time visibility, control, and protection across their Everywhere Enterprise to continuously maintain Zero Trust Architecture with confidence.

For #Cookeys, Mesh’s ZTPM enumerates, detects, and prioritizes all suspicious activities, following various risk factors, allowing security teams to automate or take immediate actions. Mesh’s ZTPM can also anticipate and harden the blast of every identity that might be compromised and thus help implement adaptive and unified explicit verification and drive least privilege access under the assumption of a breach.

Okta’s Response and Recommendations

“As a web application, Okta relies on the security of the browser and operating system environment to protect against endpoint attacks such as malicious browser plugins or cookie stealing. If an attacker were to have a foothold on your endpoint that allowed them access to user cookies, they would typically already have the ability to deploy malware or other methods to compromise the downstream applications. We recommend using fleet management tools to help ensure your endpoints are protected and hardened.

In addition to the primary way to protect session cookies, by protecting the endpoint, Okta offers a number of additional mitigations related specific to session protection. 

1. Okta Admins can clear a user’s sessions in the UI. (People > Select Person > More Actions > Clear User Sessions)
2. Okta Admins can also clear user sessions by using Okta’s API. Details on Okta’s API for session management can be found here: https://developer.okta.com/docs/reference/api/sessions/  
3. Session time-out is configurable in the Okta Admin console. The timeout can be set from 1 minute to 90 days. Once a session has expired, any copied sessions will also expire. 
4. If the session cookie is used in isolation for login (bypassing typical authentication), the Okta System Log will log the authorization, which can be observed by Okta Admins. 
5. Per OWASP best practices, Okta enables both HTTPOnly and Secure attributes on the session cookie. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it). The purpose of the Secure attribute is to help prevent cookies from being observed by unauthorized parties due to the transmission of the cookie in clear text. Okta also implements HSTS to ensure that all communication to Okta is over a secured channel. 

It is important to note a session is invalidated when a user logs out of the application. Any copied session cookie will not be valid for subsequent sessions.

Customers can also follow additional steps using Okta to minimize the risk if a session cookie is copied.

1. App specific policies – for downstream applications, Okta admins can configure additional sign-on policies, such as requiring MFA before launching a downstream application. For more on Authentication Policies see: https://help.okta.com/oie/en-us/Content/Topics/identity-engine/policies/about-app-sign-on-policies.htm?cshid=csh-about-asop  
2. Enable Device Trust – tying a session to registered or managed devices reduces the risk of a session being established via an attacker’s proxy. See: https://help.okta.com/en-us/Content/Topics/device-trust/device-trust-landing.htm

https://help.okta.com/oie/en-us/Content/Topics/identity-engine/devices/devices-main.htm

3. Okta administrators can define a dynamic network perimeter to reduce the risk of a session being established via an attacker’s proxy. See:  https://help.okta.com/en/prod/Content/Topics/Security/Security_Network.htm 
4. Customers can implement Endpoint Security Integrations, which allow Okta to work with endpoint detection software to prevent logins from a compromised device. See: https://help.okta.com/oie/en-us/Content/Topics/identity-engine/devices/edr-integration-main.htm  

Okta’s Product team is actively exploring additional roadmap items to help protect end-users from post-authentication attacks. If you’d like to learn more, please reach out to your account manager to coordinate a meeting.”