Earlier this week, the criminal hacker gang Lapsus$ updated its Telegram feed with screenshots claiming the group gained administrative access to Okta. Over the course of several hours of vendor frenzy, every security shop in business had a chance to advise that the world revert to ink stamped credentials – Okta CSO David Bradbury confidently reported:

“The Okta service has not been breached and remains fully operations. There are no corrective actions that need to be taken by our customers”

The Infosec community has seen similar warnings of impending doom long before security certifications became the focus of CISO new-year’s resolutions. When Krebsonsecurity covered the Onelogin breach in 2017, Gartner analyst Avivah Litan proclaimed:

“..This breach shows that other [cloud-based single sign-on] services are vulnerable, too. This is a big deal and it’s disruptive for victim customers”

When a Gartner analyst publicly admits a particular vulnerability is a "big deal", everyone pays attention. Does that mean that one cloud service can become a single point of failure compromising access to any other cloud service?

Unfortunately, some organizations are still approaching security much like they did in 2019. If you haven’t been rotating credentials and closely monitoring your authorization telemetry across user accounts and machine identities to dynamically assess posture, it’s high time to cover the basics. Ironically though, when it comes to SaaS applications, a seemingly trivial task can escalate in complexity quite quickly. Simply put, if an access token is compromised, changing passwords is not going to make much difference. The reality is that most human accounts come with a trail of multiple nonhuman identities that are often dynamically generated.   The challenge is to review a comprehensive inventory of users, apps, and respective nonhuman identities, investigate the scope of credentials, and assess the security posture and resulting blast radius of a potential compromise.

So what does identity access actually mean ?

Let's take a closer look at what identity access actually means in this “New Normal”. Okta, like any of the hundreds of third-party apps & integrations (a conservative estimate) connects to your IT-approved infrastructure. Facilitated by the OAuth authorization protocol, it makes use of API access to drive user provisioning, administration and management ( System for Cross-domain Identity Management - SCIM).

The Okta Integration Network promises “Deep, pre-built integrations to securely connect to everything”.  Other than the thousands of connected apps that enable user authentication using Okta, their portfolio of applications also facilitates access to your tenant’s data directly.

What is your exposure in case of
a successful supply chain attack?

In the recent case of the Okta breach, the obvious assumption is that an attacker who compromised the Okta login app which customers connect and integrate (Supply chain compromise), can also log in with existing user credentials to exfiltrate data. Hence the knee-jerk call for rotating credentials. But in such a compromise, the attacker can actually exploit the supply chain entry point to steal third-party secrets, connecting directly to your tenant data, without impersonating a human user’s identity.

A compromised app can have direct access to your tenant data without delegating a user, in effect bypassing the MFA controls - either when it is granted application permissions by an administrator on Microsoft Azure, or if it’s integrated as a Google Service Account.

Generally speaking, apps that are delegated to act by user impersonation can be compromised by an attacker from within the supply chain , which could expose a user’s active OAuth tokens, and invariably persist even if you rotate the credentials. If the app has offline scope, attackers can use the refresh token to establish persistence and even generate new OAuth tokens rendering credential rotation ineffective.

To mitigate the risk of stolen tokens, it's a good idea to revoke the app and reinstall it, which would also revoke the compromised tokens. Note this will likely impact workforce productivity spanning all services and users who depend on the app.

What should we look for to identify compromised third-party apps in our tenant?

As is the case with compromised users, best practices apply to nonhuman identities including third-party apps. Monitor their IP for consistency and reputation, and then rule out foul play with standard device fingerprinting.

We also advise customers to monitor the activities of the apps for a change in behavior, and review the audit logs for evidence of persistence keeping activities (e.g. new user additions, forwarding rule generation, infecting cloud documents with malicious macro scripting or sending phishing emails).

Although a single data point is rarely enough to suggest a breach, a privately registered publisher email is a telltale red flag that often correlates to insecure activity. At best, it is a careless app security oversight. Very often, the app registration email domain is beyond the control of the publishing organization. Developers should keep in mind that most malicious apps tend to be registered with private addresses.

Analyzing third-party apps and integrations:

Head over to apptotal.io and enter “Okta” or the full app client ID 912948636335.apps.googleusercontent.com

Based on data sourced from our community sandbox offering - while none of the below “Okta” apps is flagged as a high-risk app, the scope of granted permissions could have a far-reaching blast radius if indeed access is confirmed to be compromised. The apps can add new users they control or update a user's MFA   password restoration handles, effectively enabling attack persistence using these fresh footholds.

Consider the below (non-exhaustive) list of OKTA apps you can review on aptotal.io

When it comes to third-party supply chain access, the blast radius is not often easy to contain - especially if dwell time is measured in several weeks as the threat actors claim in this case. Security teams can go beyond conventional wisdom to investigate the tangible assets that a successful attack would target. Even in the absence of tangible evidence of foul play, establishing a measurable benchmark for acceptable risk can provide a solid foundation for responsible risk management.