A common user mistake can lead to compromised Okta login credentials
Logged failed logins into a company’s Okta domain could be used by threat actors to discover access credentials of valid accounts, Mitiga researchers have found.
Those credentials can then be used log in to any of the organization’s platforms that use Okta single sign-on (SSO) or – if the login credentials belong to an administrator – to gain privileged access to other systems or restricted network areas.
How to discover valid Okta credentials in logs
“When logging in to their organization’s Okta domain, it is quite common for a user to mistakenly enter their password in the username field on the login page. This results in login failure. However, the unfortunate consequence of that action is that the failed login request is recorded in Okta audit logs,” Mitiga researchers Doron Karmi and Or Aspir explained.
A failed login due to the password having been entered in the username field – as seen in an Okta log (Source: Mitiga)
The password entered as username is included in the logs in plain text, which means that anyone who has access to the logs can read it and match the password with the correct username.
“In most cases, users will subsequently do a successful login, registering the actual correct username in the log file,” they noted.
This method for finding valid Okta credentials hinges on attackers’ ability to access and/or read Okta audit logs.
“These logs are only accessible to Okta administrators, who are the most privileged users in Okta and should be trusted not to engage in malicious activities,” Okta told the researchers.
But what if the audit logs are saved in an organization’s security information and event management (SIEM) solution? Also, the company may be using third-party products and services that integrate with Okta, and those products may request permissions to read environment information, which also means the ability to view Okta logs.
“We confirmed with Okta that if the logs from Okta are shipped to the company SIEM solution or if third-party services integrate with Okta with some administrative permissions, the logs can be seen by people that are not Okta administrators,” Karmi and Aspir told Help Net Security.
That means the company’s SOC analysts have access to that info, but also that a supply chain attack resulting in the compromise of the integrated third-party services may allow attackers to grab the failed login information and (consequently) discover valid credentials.
Risk mitigation
Configuring multifactor authentication (MFA) at the organization or application level can help prevent unauthorized access even if attackers obtain users’ credentials, but there are ways around that added protection (as recent successful attacks have demonstrated).
Okta also advises administrators to:
- Create custom character restrictions for the username field to prevent passwords from being entered
- Put placeholder text in the username and password fields to provide a visual cue to the user on what type of input is required
- Consider implementing Okta FastPass passwordless authentication
Organizations should also train their employees to be careful and avoid entering passwords in the username field on the Okta login page and monitor audit logs for failed login attempts and other suspicious activities.
The researchers have created a SQL query for SIEM solutions that matches failed login attempts with a password pattern to subsequent successful login attempts, and can be used to detect users credentials accidentally stored in Okta audit logs.
“Using this method, we were able to find hundreds of potential passwords in our customers’ data, including for administrator-level users,” they noted, and pointed out that all passwords discovered in Okta logs should be changed.
Finally, organizations should make sure to use third-party SIEM solutions securely. “It is crucial to ensure that the solution is secure and properly configured. This includes implementing access controls and monitoring for any unauthorized access to the logs,” they added.