SSO Exploits: Okta SSO + Duo + Yubikey
Exploit Type: AitM, Session Hijack
Login Factors: Password, Yubikey
What happened?
An adversary sets up a phishing proxy server that looks and behaves exactly like an SSO login page. This proxy will capture all information coming in and out of the server.
A victim is phished into visiting the malicious site and enters their username and password, and successfully completes the Duo + Yubikey prompt as a second factor of authentication.
Because the victim authenticated through the phishing proxy, the adversary steals the username, password, and also the session cookie for the application that was authenticated into. The adversary can use the stolen credentials to perform malicious actions such as an account takeover, data theft, or further lateral movement within the network.
Why is this an exploit?
In this authentication flow, three main components are involved: (1) the application, (2) the user, and (3) Duo Security. The application sends a login request to the user, the user completes a Yubikey authentication with Duo, and a login response is sent back from the user to the application. The process utilizes YubiKey for authentication between the user and Duo, leveraging U2F (Universal 2nd Factor) and WebAuthn protocols, which is generally phishing-resistant.
However, the exploit in this scenario is that an adversary positions themselves between the user and application as an Attacker-in-the-Middle (AitM). By intercepting the login response from the user to the application, the attacker is able to hijack the user's session.
The login response is accepted by the real authentication server from the adversary's phishing server, and the login experience is the exact same for the end user. The end user is still relying and trusting that their experience is legitimate. Neither the victim nor the system administrator is notified as stolen, but legitimate, credentials are used to access the system.
How do you prevent this from happening?
Use phish-resistant MFA with origin validation. The authentication server should accept requests coming only from allowed domains, and not malicious domains. Even if a user falls for phishing, your authentication service should prevent any and all unsafe access.
Check out how Beyond Identity's phish-resistant MFA prevents this exploit from happening.