Researchers have discovered a new possible post-exploitation attack mechanism in Okta that allows attackers to access users’ passwords and credentials that are stored in the Okta audit logs. This approach was discovered in Okta. When a user attempts to log in to their Okta domain, it is extremely typical for them to put their password in the username box on the login screen. This causes the login attempt to fail and results in the user being unable to access their Okta domain. The unsuccessful login attempt will be noted in the Okta audit logs, along with the password written out in plain text in the area for the username. This is an undesirable result of the action that was taken. In the vast majority of instances, users will eventually carry out a successful login, therefore recording the real accurate username in the log file. Researchers discovered that the audit logs provided by Okta include a wealth of information regarding user behavior. This information includes login timestamps, usernames, and IP addresses. In addition, the logs provide information into whether or not attempts to log in were successful, as well as whether or not they were completed using a web browser or a mobile application.
Throughout their investigation, we found that unsuccessful login attempts often included passwords in the space reserved for the user’s name. Since passwords should never be stored in plain text in any form of record, the discovery of this fact raises serious concerns.
An attacker who knows the credentials of users may attempt to log in as those users on any of the organization’s numerous platforms that employ Okta single sign on if the attacker has access to the users’ credentials (SSO). Moreover, in the event that the passwords of administrators were leaked, one may exploit this knowledge to gain additional rights.
An attacker requires nothing more than the capability to access Okta audit logs in order to get this user information. The following are a few examples of how an adversary may examine such logs if they gained access to the system.
User were not authenticated
The audit logs are often stored in a SIEM system like Splunk that is used by a company. Users’ credentials may be harvested by an attacker if the SIEM product’s logs are readable and the attacker has authority to examine them. In addition, in such a situation, any user who has read-only access to the SIEM solution (which includes all staff in the SOC) has the possibility of having access to the passwords of other users, including Okta administrators.
Attacks on the Supply Chain
Services provided by a third party that have been granted authorization to read Okta configuration. Products and services that connect with Okta, such as CSPM products, may request a “Read-only” Administrator position. This job grants access to just read information about the environment, and it may be requested by Okta. Since the position grants the ability to read the audit logs, the associated goods and services are authorized to access the credentials of the users. So, an attacker may get the credentials of Okta users in the event that the services or products in question are compromised.
Okta’s user authentication process may be made much more secure with the implementation of multifactor authentication, often known as MFA. MFA may be configured by Okta administrators at either the organization or the application level. While entering into Okta using multi-factor authentication (MFA), users are needed to submit extra factors in addition to their password. These factors might be a one-time password, biometric authentication, or a security token. Even if an attacker manages to gain the credentials of a user, this may still assist prevent unwanted access.
Nevertheless, it is essential to keep in mind that multi-factor authentication is not failsafe and that attackers may still attempt to circumvent it using a variety of different ways. Take, for instance:
Phishing is a social engineering method that attackers might employ to deceive users into disclosing their MFA credentials. Phishing is also known as spear phishing. Phishing emails or phony login pages that require users to submit their multi-factor authentication (MFA) credentials or accept the push notification from the authenticator app are examples of this.
MFA fatigue occurs when users are inundated with repeated MFA requests and begin to accept them without adequately confirming the validity of the request. This may happen if a user has too many requests at once. This may be exploited by attackers by delivering a barrage of MFA push notifications in a short period of time, which causes the user to feel weary and accept requests without properly reviewing them. Because of this, the attacker is able to get into the user’s account without their permission. If a threat actor had access to the Okta logs, they could potentially wait for the perfect time to trigger multi-factor authentication (MFA) in order to circumvent it. This would involve monitoring the user’s login pattern and sending the MFA push within a few seconds after a genuine successful login in order to make the action look legitimate to the user.
Okta Response
“After reviewing the problem that was reported, Okta has determined that the behavior that was seen is consistent with what is to be anticipated when users accidentally put their password in the username box. Okta keeps a track of unsuccessful login attempts and includes the incorrect username among its entries when it does so. Okta administrators are the most privileged users in Okta and should be trusted not to participate in harmful actions. These logs are exclusively available to Okta administrators, thus only they can see them. The researchers had some degree of agreement with the Okta team. In most cases, users of the Okta platform who have at least the “Read-only Administrator” status are the only ones who are able to see the logs. However:
Even if you have been given the job of “Read-only Administrator,” you should not be able to see the passwords of other users. This is true even if you have this role.
Other users, who are not Okta administrators, are able to see the audit logs since they are often transmitted to a centralized security solution such as SIEM.
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.