Okta Customers Exposed to Risk of Password Theft and Impersonation in PassBleed Attacks

Originally published by Authomize here.

Written by Gabriel Avner, Authomize.

Authomize’s Security Research Lab has uncovered a set of inherent risks in the popular Identity Provider Okta that put users at risk of potential compromise and exploitation.

According to Authomize’s CTO and Co-founder Gal Diskin, the risky security exposure is a flawed yet intentional design that opens the door to exploitation, and not simply a coding mistake.

“Our team discovered this risky architecture during the course of our research into Identity Providers,” says Diskin. “Following the news of the Okta breach earlier this year, we focused our efforts on understanding what sorts of actions a malicious actor could do if they achieved even a minimal level of access within the Okta platform.”

“As we laid out in our technical write up of these major operational risks,” he says, “We were very surprised to find that Okta’s architecture for password synching creates a situation where an actor can simply pull out passwords in clear text, even over unencrypted channels (HTTP), and including the passwords of more senior admins.”

Authomize has disclosed all of our findings to Okta and are working with their team to help resolve these security concerns.

In their response to Authomize’s responsible disclosure, Okta has stated that they do not believe these security issues to be vulnerabilities, but functions working according to their intended design and expected inherent risks.

Our Findings

1. Extract clear text passwords of all employees in the organization

Okta makes it very easy to manage passwords across their platform. Unfortunately in this case, their focus on usability appears to have negative security implications.

Authomize’s researchers have documented that a malicious actor with app admin privileges, defined as a delegated person responsible for managing single applications, can extract the passwords of any user in the organization. This includes super-admins which can lead to escalation of privileges.

All in clear text.

The key feature at issue here is in Okta’s password synchronization where an attacker can redirect the syncing of the passwords, which are stored and shared in clear text, to their SCIM server.

2. Passwords and Sensitive Data Shared Over Unencrypted Channels (HTTP)

While not the focus of our initial research following the breach, Diskin’s team quickly discovered Okta is sending sensitive data, including passwords, over the insecure HTTP channel.

If exploited, an attacker could “sniff” a wide range of data that is being transferred. Unlike the previous example though, the attacker would get the full firehose of data being sent over the channel, and not just specific targeted bits and bytes.

Best practices calls for using encrypted channels like HTTPS that make it harder for an attacker to carry out a Man in the Middle attack.

3. Hub & Spoke Configuration Allows Sub-org Admins to Compromise Accounts in the Hub or Other Spokes Downstream

Okta offers a useful Hub and Spoke architecture that makes it easy to scale up control of your organization from the hub by adding spokes for smaller segments or departments while ideally keeping them securely separated from one another.

However, according to Diskin’s research, when using the default configuration, an attacker can impersonate any downstream user in the downstream application(s) that they administer with their minimal level of app admin privileges. They can also impersonate users from other spokes, circumventing the intended protections of the hub and spoke architecture.

Furthermore, a malicious actor can add spokes by impersonating a compromised admin, giving them persistence. This activity is difficult to detect as no traces of the impersonation are left in the downstream application and you need to know what to look for in Okta during a deeper forensic dive to uncover evidence.

4. Mutable Identity Log Spoofing

Most of the logging features in Okta are vulnerable to mutable identity techniques, enabling attackers to appear to be another user, doing mischief and having someone else take the blame unless a deeper investigation is performed.

Taken as a stand alone issue, this log spoofing is not dangerous on its own. However, when used to cover up the evidence of malicious actions, it can make it more difficult for investigators to identify wrong doing. Note also that app admin privileges are not required for this activity.

Conclusions

Following our research, we have come to the following conclusions:

• These design issues put users at a high level of risk of:
  • Having their passwords compromised and used to escalate privileges
  • An attacker achieving persistence
  • Making it difficult to trace impersonations
• Exploiting these security risks requires only a medium level of difficulty
  • Can be executed remotely
  • Application admins and Hub and Spoke configurations are very common, especially in the larger enterprises, statistically raising the probability of a successful compromise
  • The mutable identity attack is accessible to any user

For a full breakdown of all the details of our research with more in-depth analysis, please read our technical post here.

Our Solution

Authomize will be offering a free assessment tool that will allow companies to determine whether their Okta is misconfigured, leaving them exposed to these security risks.

The tool will also detect whether an attacker utilized these risks in an attempt to exploit the organization.