What happened?

An adversary starts the login process with Okta FastPass on their browser and obtains the App Scheme URL (see Launch Mechanisms) used to invoke FastPass natively. FastPass is not launched on the adversary's device, but their browser is still polling Okta Cloud through an updates channel for any updates on the authentication.

Meanwhile, the adversary sets up a phishing site that looks like an Okta login screen, with a button that invokes the App Scheme URL obtained above. A victim is lured into visiting the malicious site and completes the FastPass prompt.

Upon completing the FastPass prompt, the adversary's browser polls and receives the redirect URL from Okta Cloud in the updates channel. This completes the authentication on the adversary's browser, and they have hijacked the victim's session.

The adversary can use the hijacked session to perform malicious actions such as an account takeover, data theft, or further lateral movement within the network.

Why is this an exploit?

When invoking a login to the authenticating agent (such as FastPass) using App Scheme URL, an authentication can start on one system or device and be completed in another. Due to the lack of device binding, there is no assurance that the device that started the transaction is the same on that completed it.

This vulnerability arises from the absence of bidirectional communication between the browser and the cloud. While the browser can initiate authentication to the cloud, the cloud cannot directly inform the browser when the authentication has completed. Instead, the browser must poll an "updates channel" for updates on the authentication status.

Specifically, the updates channel that Okta Fastpass uses is vulnerable to snooping by a malicious actor as it is not secured from remote access and passes the redirect URL in plaintext. An adversary can exploit this by starting an authentication from their own browser, have an unknowing victim complete the Fastpass prompt, and assume the victim's identity on the original browser.

Neither the victim nor the system administrator is notified as hijacked, but legitimate, credentials are used to access the system.

How do you prevent this from happening?

In terms of using App Scheme URLS as a launch mechanism for authentication, we strongly recommend disabling this technique or enabling end user mitigation. An example of end user mitigation is a visual pop up notification asking if the user if they want to proceed, with some additional authentication context such as where the authentication request is coming from (OS, device, location, etc.).

Beyond Identity is phish-resistant by default using secure launch mechanisms.