What is Cross-Tenant Impersonation?

This post is in response to a recent article published by OKTA Security, ‘Cross-Tenant Impersonation: Prevention and Detection’ (dated Aug 31). 

Before we get stuck into this topic, it is important to highlight that we have great respect for Okta, as we do any vendor trying to combat the ever-increasing threats to business when it comes to cyber security. It is also our opinion, that it is equally as important to have these discussions when things go wrong. We must consistently evaluate the threat landscape as well as making sure the right information is available to the IT professionals and organizations that reply upon sound and robust advice from the industry. 

So, with that said, let’s take a look at what happened, how and where the risks may still exist and most importantly the solutions. 

What is ‘cross-tenant impersonation’? 

As the name might suggest, this is an attack vector where the impersonation of a highly privileged user or admin takes place. It is ‘cross tenant’ because it is a security vulnerability that occurs in multi-tenant environments such as cloud-based services, for example AWS (Amazon Web Services), MS Azure or Google Cloud Platform (GCP). 

Cross-tenant impersonation refers to a situation where a user or entity from one tenant gains unauthorized access to resources or data belonging to another tenant. This can allow an attacker to exploit stolen data to pose as a user or administrator and carry out further nefarious ‘insider’ activities. 

What happened in the case of Okta Security?

"Threat actors appeared to either have a) passwords to privileged user accounts or b) be able to manipulate the delegated authentication flow via Active Directory (AD) prior to calling the IT service desk at a targeted org, requesting a reset of all MFA (Multi Factor Authentication) factors in the target account," according to Okta's Defensive Cyber Operations. The hackers were able to gain access to compromised accounts and impersonate users, assigning higher privileges and resetting, and/or removing MFA factors. 

The most interesting aspect of this attack is the initial access. This is something that is very often, not explored in enough detail. According to Okta, it was social engineering. They state, “a threat actor used social engineering to attain a highly privileged role in an Okta customer Organization (tenant).”

Social engineering is a tactic used by cybercriminals to obtain information from people under false pretences.

It is our understanding that the main vulnerability was a reliance on passwords and an insecure recovery process. The hackers were able to compromise super admin passwords and then leverage the human element to exploit a recovery process that relies on their ability to convince the help-desk to reset and/or totally remove super admin authentication factors.

Once the attacker is in control of the super admin accounts; they can exploit inherent weakness of “inbound federation.” Inbound federation is an Okta feature that allows access to applications in a target Identity Provider (IdP) if the user has successfully authenticated to a source IdP. In simple terms, the inbound federation feature allowed the hackers to SSO to different tenants. Hence the term “Cross-tenant impersonation.” 

Could this cyber attack be repeated elsewhere? 

Since the vulnerability seems to have been compromised credentials (passwords and MFA) in the case of the Okta attacks, one might automatically assume that passwordless MFA would have helped prevent initial access, but this is not entirely true. The answer has more to do with the technology’s overall architecture. This issue is not exclusive. Indeed, many MFA solutions (passwordless or not) are built on similar architectures, relying upon centralized credentials, used for other aspects of the identity lifecycle, such as registering a device, account recovery or the onboarding or off-boarding of new users and/or devices. 

For example, Okta advises the use of phishing resistant MFA such as WebAuthN and using its strongest authentication method “currently Okta Verify or Google Authenticator” for self-service recovery. Both Okta Verify and Google Authenticator use PUSH or OTP (One Time Password) for MFA. Push-based MFA and OTP have been demonstrated to be vulnerable to MFA fatigue (prompt bombing) and adversary-in-the-middle attacks. WebAuthN is phishing-resistant, but it will not solve the problem in the account recovery process. WebAuthN (passkeys) recovery relies on weaker authentication factors, usually passwords and OTP. If organizations continue to rely on the human element (help-desk personnel), passwords and OTPs (One Time Password), similar attacks will only persist. 

Solutions & best practice

IT leaders should look for technologies that include features such as identity binding, and transitive trust. They should also look towards technology with architecture that is zero trust, zero knowledge and zero PII (Personal Identifiable Information). 

Leveraging Zero-Trust concepts such as transitive trust and identity proofing allows for self-service while ensuring that the complete user identity life cycle is immune to phishing, provable and cannot be subverted by a privileged insider.

To trust authentication, the provenance, authenticity, integrity, and identity of the authentication origin (device) must be assured and coupled with the user identity. The authenticator device, and the user identity should be inseparable. As a result, an explicit transitive trust between the device and the user identity must be established via identity binding. This ensures that only the real user can access a service by authenticating with the trusted device and that an attacker cannot spoof and/or copy a user’s identity.

Transitive Trust ensures that an authentication is not trusted merely because it came from a user and/or a user’s device. There must be a verifiable assurance that a transaction was carried out on a “trusted service” tied to a “trusted device” coupled to that “specific user” and authorized under the “user’s total control.” This should form the basis of any zero-trust security journey.

Conclusion

Ultimately, we believe that the solutions can be found in a better knowledge and understanding of the problems (as outlined above). Practitioners need to be empowered to make well-informed decisions. This includes educating the industry on existing technologies along with the weaknesses and how to overcome these challenges. 

If you would like further information on this issue, the AuthN by IDEE MFA solution, or anything else related to your use case, please get in touch.

‍