MITM Attack Risk on Okta

Disclaimer: The risk described in this article applies to ANY website or SaaS platform with a public authentication mechanism that allows using traditional 2FA, such as push approvals or OTP, not just Okta.

📜 Background Story

An enterprise client suffers a significant compromise, security teams and organizations with an IAM system begin to question how safe their systems are, and many theories surface, most of them incorrect. The purpose of this "yet another article about MFA fatigue" is to give a more straightforward understanding of how these attacks happen and what Okta customers CAN DO to prevent them.

First, cookies/session storage cannot be accessed by a remote website / reverse proxy unless the computer is heavily compromised; this is an essential security feature in all modern browsers, called the Same-origin policy. So a website "cloning" a session of another website without a significant browser vulnerability or device compromise is impossible.

The same level of device compromise or network compromise would also be required for DNS hijacking, but this goes beyond our scope for mitigation, so we will consider that the hostnames have not been altered. Hackers are relatively efficient creatures and won't go to extreme lengths when they can do something much simpler and more discrete.

From here, we can assume the following:

• The attacker uses a MITM technique involving a reverse web proxy similar to Modlishka, Muraena, or Evilginx2. Think of them as traffic brokers that are replicating user interactions to the actual website in real-time
• In theory, the victim can identify the malicious domain if they pay attention to the URL (although the site is identical, most users will not notice or look for it), and if the reverse proxy server is correctly set up, they will not see a certificate warning either.
• The victim will proceed to log in, the credentials are being stolen, but the session is established by the attacker with the actual website, allowing the user to move forward to the multi-factor step; the tool then intercepts the session tokens/cookies and optionally can create another session with the stolen credentials to trigger another factor prompt immediately, and the victim is likely to approve it out of confusion

⚠️ The Risk

1. The victim will not know their account has been compromised, and the attacker session will persist for longer.
2. All it takes is a phishing link; even state-of-the-art EDR systems will likely not catch it. Such a solution would have to "fingerprint" and identify cues specific to the reverse proxy without blocking legitimate traffic to a shabby web server that has bad peering and only then stops the user from initiating a session.

📣 Mitigation solutions

Until recently, WebAuthn was the only factor considered phishing-proof, but Okta has now added an Early Access feature that also makes FastPass phishing resistant. However, I could not find any technical details of Okta's implementation of phishing resistance for their FastPass product.

But what about the vendor?! Well, while there are things Okta can do to block such toolkits from reaching its services, it still won't guarantee 100% accuracy, and all it takes is one highly privileged account to be compromised. So what can you do? Here are a few methods and how I classified them based on utility/efficiency.

1. High efficiency:

• Switch to a phishing-resistant MFA (WebAuthn/FIDO2 with Touch ID / Windows Hello or Yubikey)
• Okta FastPass with EA feature for phishing resistance
• Block unknown domains via EDR (CrowdStrike, Cisco Umbrella), allowing users only to use a predefined set of legitimate websites
• Allow access only from managed devices
• If done right, email security added to your technology stack can prevent a lot of these attacks from gaining traction

2. Low efficiency:

• Set Okta ThreatInsight to Block and Log. Some of their insights from (Neustar?) may be able to fingerprint the proxy server, but you can't treat it as a reliable source
• Enable reCAPTCHA, which won't stop the attacker but will make it more annoying for newbie attackers
• Block unsecured sites via device management / EDR, but this will only block proxies that don't use a certificate

3. Useless:

• Enable phishing-resistant prompts (number challenge) for Okta Verify; this won't help at all
• Behavioral policies that directly block access for impossible travel anomalies, although this doesn't bring much benefit and is likely to have false positives for people using VPN or to switch to mobile data

Optional:

• Enable the Okta feature "Block passkeys for FIDO2" to make sure end users are not enrolling unmanaged or personal devices as additional FIDO credentials

✅ Benefits of WebAuthn over OTP and mobile authenticator apps:

• Native to the device and complements passwordless authentication very well
• Asymmetric credential key pairs, scoped for each WebAuthn the Okta user enrolls
• Better UX, most sane people will prefer biometric authentication
• The same biometric you use to log in or unlock the device can be used to access apps!
• Multiple devices and 3rd party solutions adopt the WebAuthn API, which gives more choice

Suggested Usage

1. A password or FastPass will be used to access the Global Session, and any application will require WebAuthn (FIDO2), which is phishing-resistant.
2. Use the Okta FastPass in combination with the phishing-resistant feature enabled

Which devices are compatible with WebAuthn?

This varies depending on hardware, OS, and browser and their support/version.

UX on macOS

UX on Windows

Thank you for your time, and I hope this is useful for someone out there.

As always, feedback and questions are welcome! 🙏