Okta Post-Exploitation Method Exposes User Passwords

A post-exploitation attack method has been uncovered that allows adversaries to read cleartext user passwords for Okta, the identity access and management (IAM) provider — and gain far-ranging access into a corporate environment.

Researchers from Mitiga discovered that the IAM system saves Okta user passwords to audit logs if a user accidentally types them in the "username" field when logging in. Threat actors who have gained access to a company's system can then easily harvest them, elevate privileges, and gain access across multiple enterprise assets that use Okta, the researchers said.

"In our research, we could easily use the logs to match the password with the valid user, resulting in gaining credentials to the Okta user account," Okta senior security researcher Doron Karmi and principal security researcher and developer Or Aspir wrote in the post. When adversaries login to Okta as those users, it "expands the blast radius of the attack to the many platforms that Okta secures, and gaining further access to systems," they wrote.

The vulnerability exists because Okta audit logs supply detailed information about user activity, including usernames, IP addresses, and login timestamps. The logs also provide insights into successful and unsuccessful login attempts and whether they were performed via Web browser or mobile app.

In Defense of Okta Features

Okta is a cloud-based enterprise-grade IAM service that connects enterprise users across applications and devices and is used by more than 17,000 customers globally. While it was built for cloud-based systems, it also is compatible with many on-premises applications.

Representatives from Okta confirm that saving cleartext passwords in audit logs is "expected behavior when users mistakenly enter their password in the username field," according to a statement by the company provided by Mitiga. They also said that only platform administrators — the most privileged users in the system — have access to audit logs that save cleartext passwords, and those users "should be trusted not to engage in malicious activities."

It's not the first time the company has had to defend a built-in feature of the platform's regarding how it handles user passwords. The company posted a blog post last July in response to a report by Authomize researchers that Okta's architecture for password synching allows malicious actors signed on as an app administrator of a downstream app to access passwords in plaintext, including admin credentials, even over encrypted channels.

That report came after threat group Lapsus$ claimed to have breached Okta with "superuser" account credentials, posting screenshots they claimed to have grabbed from internal systems. It was determined that 366 Okta customers were potentially impacted in that incident, though Okta later said it determined only two actual breaches.

What Happens if Untrusted Users Gain Access

Mitiga's research is relevant if someone other than a trusted administrator gains access to these logs and can access the data, which can happen in a number of ways, the researchers said.

One way would be if an attacker has permission to read the logs in an organization's SIEM solution such as Splunk, as the logs are saved in this solution, they said. Moreover, in such a scenario, every user with read-only access to the SIEM solution potentially could have access the passwords, including Okta admins.

Attackers also could gain access to the logs and thus user passwords through third party-services that have permissions to read Okta configurations, such as cloud security posture management (CSPM) products that request a "read-only" admin role, the researchers said. "The role includes the ability to read the audit logs, which means those products/services could read users' credentials," they said.

Once attackers have gained access to user credentials, they can try to log in as those users to any of the organization's different platforms that use Okta single sign-on. This data also could be used to escalate privileges in the case of exposed administrator' passwords, the researchers said.

Avoid Leaking Okta Passwords

Both Mitiga researchers and Okta provided recommendations for how enterprises can avoid inadvertently exposing Okta credentials to threat actors, with the latter also advising how platform users can avoid typing their password in the username field in the first place.

Mitiga advised enterprises to use an SQL query, which can be found on Mitiga's GitHub, to detect potential users that enter their password by mistake, and also consider rotating user passwords. They also should train employees to avoid entering passwords in the username field on the Okta login page, and continuously monitor Okta audit logs for suspicious activities, including failed login attempts, following up with investigations if necessary.

Implementing multifactor authentication (MFA) also can prevent unauthorized access even if attackers obtain users' credentials, according to Mitiga, a feature that Okta said is enforced by default when accessing the Okta admin console.

"Similarly, admins can set up an Authentication Policy that requires additional MFA when logging in to specific applications, which would further restrict what actions a bad actor can perform," according to Okta.

To avoid inadvertently logging passwords in the username field, Okta users should implement field validation to check that the input in each field matches the expected format. They can also implement Okta's FastPass feature that uses biometric features or device activation to allow users to sign in with a single click or tap without even entering a username or password at all. Clearly labeling the "username" and "password" fields in Okta with placeholder text within each field, the company said, can also help users avoid this mistake.