Last updated at Fri, 10 May 2019 16:57:57 GMT
A vulnerability has been discovered in Okta SSO running in Delegated Authentication (Del Auth) mode, a popular configuration for Okta SSO. By timing the responses from “authn” API call, a remote, unauthenticated attacker can determine whether a given username is valid for a particular Okta SSO instance in this configuration.
R7-2018-43 is categorized as CWE-204: Response Discrepancy Information Exposure and has a CVSSv3 base score of 5.3.
Okta SSO in Del Auth mode provides a cloud-based authentication service using a delegated authentication scheme, wherein a back-end Okta component queries a delegated authority for username and password verification. This enables secure authentication against a Windows Active Directory domain, without the need of a pre-existing VPN connection. More details about Del Auth can be found on Okta’s website.
This vulnerability was discovered by Rapid7 researchers Sean Kelly, David Greene, and Nathan Reaney. It is being disclosed accordance with Rapid7's disclosure policy.
By examining timing differences in responses from the ‘authn’ API component of an Okta SSO in Del Auth mode, an attacker can differentiate between a username that does not exist in organization and one that does exist. The screenshot below demonstrates the substantial timing differences between the two cases:
In the above test cases, usernames that do not exist return in between 75 and 82 milliseconds, while usernames that do exist return in approximately 730 milliseconds. Thus, nonexistent usernames trigger a much faster response from the ‘authn’ component than usernames that are valid, but the passwords supplied are invalid. This is because usernames are first validated for authenticity, then the supplied password is authenticated. If the first test fails, the function returns immediately, and the user is informed of the failure.
While usernames are generally not considered “secret,” most modern organizations do not publish lists of valid accounts for their enterprise. Attackers can leverage such lists to further other attacks, such as spam delivery and targeted phishing attacks. Attackers can also monitor valid accounts for status changes, indicating the account owner has left the organization. Other malicious uses of discovered or verified usernames certainly exist. Note, that in both cases, the text provided to the user is, “Sign in failed!” which offers no indication whether the username part or the password part is the offending failed component.
A vendor-supplied update to Okta SSO instances could insert a random wait time between determining whether a user’s login is unsuccessful and displaying that failure to the user. The wait time should be both random enough and long enough to obscure the timing differences between the two states of “username not found” and “password not valid.” Slightly longer wait times on unsuccessful logins will incidentally have a positive security side effect of increasing the cost of online password guessing for attackers.
One popular technique for mitigating this condition is to challenge users with a CAPTCHA test after a few failed login attempts. This would have a similar effect of preventing both username enumeration and online password guessing. This solution could also be integrated with a change to explicitly tell the user that either the username or password is invalid—with only a few attempts allowed before a CAPTCHA lockout, attackers would be able to enumerate only a tiny subset of the total username space.
Absent a fix from the vendor, administrators of Okta SSO instances could mitigate exploitation of the vulnerability by hosting Okta login pages in VPN-controlled networks, or otherwise disallow unknown users from attempting to log in to Okta SSO-controlled services. Another solution would be for implementors of Okta’s SSO solution to proxy authn API calls and inject their own random sub-second sleeps to mask the delay differences. Finally, an orchestrated security solution could identify problematic source IP addresses automatically and block all access from those sources for some time, thereby effectively rate-limiting persistent failed attempts with network-based controls rather than web application controls.
- Thursday, Sept. 20, 2018: Support ticket 00505303 opened with the vendor.
- Wednesday, Oct. 3, 2018: Vendor support engineer asserts the behavior is as expected.
- Wednesday, Oct. 19, 2018: Escalated with the vendor
- Thursday, Jan. 31, 2019: Escalated with the vendor
- Thursday, March 21, 2019: Disclosed to CERT/CC (VU#942253)
- Thursday, March 28, 2019: Public disclosure (planned)