What happens when an Okta user inadvertently enters passwords in the username field? Attackers use them to fetch Okta user details by reading the audit logs from the security information and event management (SIEM) product the organization uses, found researchers.
A potential post-exploitation attack method in Okta allows threat actors to read users’ passwords and credentials that are in the audit logs.
According to Okta, the logs of failed login attempts are only accessible to privileged Okta administrators, who are highly trusted.
Researchers at cybersecurity firm Mitiga pointed out that other users who are not Okta administrators can read the logs and, thereby Okta user details.
“Post-exploitation refers to any actions taken after a session is opened. A session is an open shell from a successful exploit or bruteforce attack. A shell can be a standard shell or Meterpreter,” says a Rapid7 explainer.
Passwords, errors, and Okta user details
Users accidentally entering passwords in the wrong access columns is an age-old error. However, logging this error facilitates fetching Okta user details, as researchers found that attackers can glean the information from the SIEM product logs.
“We at Mitiga collect our customers’ security logs. While looking at the logs for threat hunt purposes, we discovered in failed login attempts, log records passwords in the username field,” Or Aspir, Principal Security Researcher and Developer at Mitiga, told The Cyber Express.
“Then we understood that this scenario happens in the login step when the username enters its password in the username field by mistake. This scenario happens quite often. We found tens and even hundreds of user passwords in our customers’ logs like that.”
This information enables them to bypass the MFA through various methods.
The Mitiga team built a SQL query to match failed login attempts with a password pattern to subsequent successful login attempts, that can be used to detect if there are Okta user credentials in the audit logs.
Okta user logs and possible threats
Threat actors could use this data to compromise Okta user accounts, as well as access any resources or applications that they may have access to, effectively expanding the blast radius of the attack, Mitiga researchers found.
This could include sensitive data, intellectual property, financial information, or customer data.
Anyone with access to the audit logs, either directly through the admin console or via third-party systems where logs are shipped, can read the passwords of Okta users placed incorrectly in the section of ‘username’ during attempts to login.
“The biggest risk is that an attacker with the ability to read victim Okta audit logs can harvest users passwords and then login as those users. Think about how an SOC analyst worker can read the CEO login password,” Or told The Cyber Express.
Okta user risks and possible mitigation steps
“To detect if Okta user passwords have been mistakenly entered in the username field and are exposed in company logs, organizations can use their log analytics platform or SIEM where the Okta logs are stored,” read the Mitiga threat assessment report.
“We have created a SQL query that can help companies identify these potential password exposures. However, this query can be adapted to other log analytics platforms as well, depending on the specific syntax and functionalities they support,” it added.
Mitiga informed Okta on 21 February, Or told The Cyber Express. The company acknowledged the possible risks, but maintained that only privileged Okta administrators are able to access the logs of failed login attempts.
“Okta logs failed login attempts and includes the erroneous username in the 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,” said the company’s response.
Mitiga researchers pointed out that even users with “Read-only Administrator” role reading the logs in the Okta platform is undesirable. Moreover, Okta audit logs are often forwarded to a SIEM product, giving access to users who are not Okta administrators.
Or pointed out that the Okta team will not change the way they record failed logins. In order to protect Okta user data from unauthorised access, Or recommended customers to follow the following recommendations:
Validate fields: To ensure the input in each field conforms to the expected format, employ client-side validation. For the username field, custom character restrictions can be created using Okta’s functionality.
Integrate FastPass: With Okta’s FastPass feature, users can sign in with a single click or tap without the need for a username or password. The feature leverages biometric factors or device authentication to authenticate the user’s identity, streamlining the process and maintaining high security standards.
Use clear labels: To assist users, provide clear labels for the username and password fields. You can include placeholder text within each field, which acts as a visual cue for the user.