Stay secure with FastPass and Trusted App Filters
Phishing resistance first
Phishing-resistant authentication is the current baseline for secure authentication, which means FIDO/WebAuthn, FastPass, PIV/CAC, etc. This post will focus on how those already meeting this baseline can take security to the next level.
Passwords, SMS, push notifications, and one-time codes are vulnerable to much less sophisticated attacks than those described in this article, so we don’t advocate for them.
Where phishing resistance falls short
As noted above, FastPass, Passkeys, and other FIDO authenticators are an excellent way to protect your organization from phishing attacks, essentially requiring the attacker to gain some sort of presence on your device (or even physically steal a key).
Phishing-resistant authenticators rely on two NIST-defined requirements, Verifier Name Binding and Channel Binding [this is a draft spec, comments are ‘closed’], which together successfully prevent most phishing attacks. Both FIDO and FastPass rely on Verifier Name Binding, for example.
In addition to these requirements, phishing-resistant authenticators must create a protected channel between the browser and the authenticator to prevent eavesdropping or relay attacks to a remote device. But the requirements don’t account for a malicious presence on the user’s device. As a result, a class of more sophisticated attacks can occur — and when successful, allow attackers to satisfy phishing resistance requirements.
Example attack: Cross-device auth via SOCKS
Imagine a victim who clicked on a link that installed malware on their system. As a baseline for this attack, the attacker must already be able to run code as the user on their machine.
|
1 |
The attacker creates a SOCKS reverse proxy between the compromised device and their own device (Step 1 in the diagram). With the right setup, the attacker can then relay either FastPass or FIDO2 challenges from their own device to the compromised device via the SOCKS proxy. |
|
2-3 |
The attacker attempts to access the user’s resources from their own device and relays the authentication challenge to the user’s device via the proxy. |
|
4 |
The browser polls directly from the attacker device to the Okta server, waiting for the auth challenge to be satisfied. |
|
5 |
The attacker must cause the compromised device to sign the challenge response with its TPM.
A well-configured policy will require user presence, triggering a user-facing prompt for biometrics or device passcode, which may raise the user’s suspicions. Given a scenario where malware is on the device, however, the attacker may be able to provide a passcode or cleverly time the attack such that the user isn’t surprised by the prompt (e.g. when the user is away from their machine or expecting an auth prompt anyway). |
|
6-8 |
Finally, the challenge response is sent from the compromised device to the Okta server, passing the TPM key checks, phishing resistance, and device trust guarantees.
As a result, the attacker’s device now has a valid session because they were able to transparently proxy the authentication between their web browser and the authenticator on the compromised device. |
Enter Trusted App Filters
In August 2024, Okta released a feature to mitigate this type of attack for FastPass: Trusted App Filters. This high-security setup allows admins to automatically block any authentication attempts by apps not specifically allow-listed or are either not signed at all or signed by an untrusted code signing certificate.
How it works
When an application like Chrome attempts to authenticate using FastPass, Okta’s sign-in widget will attempt to connect to Okta Verify running on the device and then deliver the authentication challenge from Okta’s backend.
While this connection is active, Okta Verify traces back the port and process that created the connection on the device. If the port and process can’t be found, it may indicate the origin was remote, and the connection is dropped.
If the process can be identified, Okta Verify then collects detailed signature data about the executable, verifying the signature matches the code signing certificate and the code signing certificate is trusted by the local trust chain.
For example, we use SecCodeCopySigningInformation (macOS) WinVerifyTrust (Windows) to obtain detailed information about the process. Once all this data is captured, it’s sent in a challenge-response along with management attestation and device signals, all wrapped up and signed with a hardware-bound key.
Monitoring
If you use FastPass on macOS or Windows, this data is currently available in your SysLogs.
This is an example of a login to the Okta Dashboard using Chrome for macOS.
As you look through your logs, you can see which apps your users are authenticating with and create workflows to alert you to new apps being used. You’ll want to have a good understanding of which binaries are associated with the apps being accessed in your organization. For example, users should authenticate with Slack only via a browser or the Slack native application.
Enforcement
After you’ve compiled a complete list of applications that apply to a given auth policy, you can enforce Trusted App Filters to block these attacks before they start. This can be a bit complex, so it’s simplest to create separate auth policy rules for each desktop platform (e.g. set the platform or device assurance rule to macOS or Windows for a given rule).
Once your Expression Language is in place, any application failing to pass the signature check (e.g. unsigned malware) will be blocked, along with the relevant SysLog Entry. Signed applications that aren’t in the list (such as the SSH daemon) will also be blocked.
Example 1: Chrome, Firefox and Safari on macOS
In this example, we allow all the main browsers supported on macOS, using either SSO extension or Loopback bindings. This means that only the two phishing-resistant bindings will trigger the rule for FastPass. Note that native applications with their own webviews like O365 would not satisfy this rule. If you want to allow them, you’ll need to include their identifier(s) as well.
Example 2: Edge and Chrome on Windows
Windows is a bit simpler, as LOOPBACK is the only valid binding for this check. Note that this will also prevent non-phishing-resistant flows triggered by CUSTOM_URL Binding.
Combining Trusted App Filters with FIDO or other authenticators
If you’d like to use a different authenticator from FastPass, for example a FIDO security key, you can also enforce Trusted App FIlters on that authentication rule, provided that an Okta Verify account is enrolled on that device as well.
To do that, create a rule with all of the following:
- A registered or managed condition
- The trusted app filters expression language
- Allowlist the authenticators you’d like to support, or use “Allow any method”
If you’re using FastPass on macOS or Windows in your organization, you can begin monitoring which native applications are triggering FastPass authentication today! Once you have a clear picture of which trusted applications are being used, you should allowlist those applications and block all others from using FastPass.
If you’d like to see more on this subject, including a great demo by Zach Newton, check out our talk from Oktane 2024 (free registration required).
Have a question about FastPass or Device Security? Join the Okta FastPass community board and start a conversation.
Have questions about this blog post? Reach out to us at [email protected].
Explore more insightful Engineering Blogs from Okta to expand your knowledge.
Ready to join our passionate team of exceptional engineers? Visit our career page.
Unlock the potential of modern and sophisticated identity management for your organization. Contact Sales for more information.