Okta post-exploit method exposes user passwords. Learn about the security implications and mitigation strategies. A post exploit method discovered by researchers at Mitiga allows threat actors to read cleartext passwords stored by the IAM provider Okta. This could give criminals access to business services and applications, they said.
Okta responded to the findings, arguing that these risks are not vulnerabilities but functions that work as intended. Security-mature organizations forward these logs to their SIEM platform, they noted.
Audit Logs
A recent post-exploitation attack method allows adversaries to read cleartext passwords for Okta, the identity access management (IAM) provider, and acquire extensive access to a corporate environment. The attack works by exploiting the way that Okta synchronizes passwords with SCIM servers. According to research by Mitiga, when a user unintentionally enters their password in the username field on the login page, the IAM system saves the passwords to audit logs, making them easily accessible to threat actors.
The security risks of this issue stem from the fact that Okta stores these logs in plain text over an HTTP channel. This violates best practices for IAM, which requires the use of encrypted channels to protect the confidentiality and integrity of sensitive data.
In addition to their inherent vulnerability to Man in the Middle attacks, these plain text logs also make it difficult for an organization’s security team to identify suspicious activity or patterns. This can lead to a lack of confidence in the accuracy of the information gathered by security teams, which can ultimately result in a lag in responding to suspected threats.
Luckily, there are solutions that help improve the usability of these audit logs. By storing audit records in a more structured format, like JSON or Protobufs, it’s much easier for tools to parse and analyze them. These structured formats are also more compact than their plain text counterparts and can help to ensure that the data in an event log tells a complete story, even if it is being analyzed by multiple different systems.
Of course, while having a structured format for audit records is important, it’s just as important to have an easy-to-use interface that provides users with the details they need when reviewing these logs. In many cases, this involves a front end that offers users search, filtering, sorting and export capabilities for their audit logs. This can range from a simple table of events to full-featured admin panels that offer searching, viewing and filtering, as well as the ability to view a specific event by type, action or time stamp.
MFA Fatigue
The multi-factor authentication (MFA) system of many enterprises involves requiring more than just a password to log in. This extra layer of security helps prevent attackers from hijacking user accounts and accessing sensitive data. However, some users can be tricked into granting unauthorized access to their accounts by an attack known as MFA fatigue.
MFA fatigue attacks are becoming increasingly popular among hacking groups because of their effectiveness and simplicity. In order to carry out a MFA fatigue attack, threat actors must first gain access to a victim’s basic login info: their e-mail address, username, and password. This can be done through a variety of methods, including launching phishing campaigns and stealing information from previous breaches.
Once a threat actor has this information, they can begin bombarding their target with MFA push notifications. The goal is to make the notifications so frequent that the victim becomes fatigued and starts approving them without thoroughly checking each one. This can give the attacker access to the account because, as a recent article in Wired magazine explained, “people are less likely to recognize a valid notification than a fake one.”
The problem is that Okta’s audit logs include a user’s password in the space reserved for their username, which makes it easy for any attacker who has access to an organization’s logs to read the victim’s MFA password. This can be done by either directly accessing the Okta admin console or by using a SIEM that stores logs of failed login attempts.
In order to prevent these attacks, it’s important for businesses to educate their staff on the warning signs of MFA fatigue and what to do if they notice them in their own systems. It’s also important to teach them about good cybersecurity habits, such as denying push requests unless they’re positive they’re legitimate.
Additionally, it’s recommended that companies use a tool like Mitiga’s to identify potential password exposures. The tool uses a SQL query to find usernames that were mistakenly placed in the password field during an unsuccessful login attempt, and it can be used on any log analytics platform or SIEM that supports this type of search.
Multi-Factor Authentication (MFA) Credentials
Multi-Factor Authentication (MFA) uses multiple methods to verify the identity of a user. It’s a way to increase security beyond just a username and password, which attackers can easily crack using brute force attacks or pass through using stolen login credentials. MFA usually involves the use of a second verification factor, such as a code sent via email or Short Message Service (SMS), through an authenticator app on a smartphone, hardware that scans a fingerprint, retina, or voice, or prearranged security questions and answers.
When a user goes to log in to a website, they are prompted for a username and password, as well as the MFA information. When they enter the correct credentials, they can then access the system. If an attacker has access to a company’s MFA credentials they can then use them to gain access to all the systems that the user has logged into.
It is quite common for users to type their password incorrectly into the username field of a login page. Typically, this results in a login failure, which means that the password is recorded as a failed attempt to log in in the Okta audit logs. In some cases, these failed attempts are also recorded as a plaintext password, which makes it easy for threat actors to read.
Additionally, a number of products and services that integrate with Okta such as CSPM products have permission to read the Okta configuration. This allows them to read all the Okta audit logs and exposes users’ passwords when those products or services are breached.
The vulnerability has been reported by security researchers at Mitiga and it affects all organizations that use Okta for single sign-on (SSO). Mitiga suggested that potentially affected companies review the use of their log analytics platform or SIEM where their Okta audit logs are stored to see if any potential password exposures have been overlooked.
Attackers can also take advantage of this weakness by sending a flood of MFA push notifications to a victim in the hopes that they will get overwhelmed and approve them without properly checking them. They can then wait for a moment when the victim will be unfocused and access their account without their knowledge.
Recommendations
If a threat actor has access to an organization’s Okta audit logs, they can easily read passwords that have been mistakenly placed in the ‘username’ section of login attempts. This is because the IAM platform saves every login attempt – including failed ones, as well as associated IP addresses and login timestamps – to audit logs where they are presented in plain text.
While the functionality serves a real legitimate purpose, exposing passwords in clear text over unencrypted channels goes against industry best practices and leaves organizations exposed to attackers looking for ways to intercept, sniff or steal passwords as they are being transferred. An attack like this would allow hackers to use the stolen credentials on a company’s many platforms that utilize Okta single sign-on or as part of the login process for other apps and environments.
The Mitiga assessment report suggested that organizations relying on Okta for identity and access management should consider adjusting their configuration settings to prevent this type of exposure. Additionally, they should ensure that their network and any products or services that connect to Okta are configured with a “Read-only” administrator role. This limits the ability of these third parties to access Okta configuration data, thereby decreasing their risk of unauthorized access to sensitive login information.
Ultimately, the alleged breach of Okta by hacker group Lapsus$ is a reminder that your security defenses are only as strong as the cybersecurity defenses of your third-party partners and business associates. While the hackers may have been able to exploit an engineer working with Okta, it’s no secret that these types of breaches are often the result of a compromised supply chain. That’s why it’s critical to consider the security of all your partners, especially those that are a part of your IT and CISO’s security team. By implementing bifurcation of account privileges, Britive’s JIT Privilege Management solution helps to ensure that only the right people have the privileges they need, when they need them. And this approach, when combined with a comprehensive SIEM tool, helps to reduce the threat of cyber-attacks that could compromise your cloud environments and apps.
