Phishing resistance in unmanaged iOS devices

Contributing to approximately 60% of all social engineering attacks and 36% of all data breaches, phishing claims the number one spot among cybercrimes. With 80–90% of all compromises originating from an unmanaged device, unmanaged iOS devices deserve a place at the top of your security concerns.

Okta FastPass

Okta FastPass protects users from phishing attacks by comparing the request's origin with an allow list configured for the organisation.  If a user receives an authentication challenge from any other origin, the user is immediately notified of the suspicious activity. FastPass protects users of Android, macOS, Windows, and managed iOS devices. Unmanaged iOS devices pose a unique challenge.

Challenge

Since iOS applications like Okta Verify can’t run as background services, a Universal Link (UL) is required to open FastPass from the browser-based Okta sign-in widget (SIW). The UL can contain the authentication request, but the UL does not provide a verifiable origin for the request. Therefore, an attacker can relay the link from one site to another, creating phishing opportunities. FastPass now solves this challenge. 

How it works  

Phishing-resistant authentication on unmanaged iOS devices works seamlessly with the existing Universal Link (UL) flow and is transparent to end users.

The familiar SIW and "Sign in with FastPass" options are presented to the user. Tapping the “Sign in with Okta FastPass” button launches Okta Verify with a UL containing the initial challenge.  After launching FastPass, the SIW begins polling the Okta server for the UL challenge verification response. Before sending the UL challenge to the OktaVerify server for verification, FastPass performs user verification with a biometric request or simple user presence verification, depending on the authentication sign-on policy. 

Previously, after the user verified their intent to authenticate, FastPass would verify the UL challenge with the Okta server, the SIW would complete polling as it received the UL challenge verification response from the Okta server, and the user would be authenticated. However, the UL challenge alone does not provide a verifiable origin, which is required to determine if the request is a possible phishing attempt.

To secure the UL authentication flow with phishing resistance, an ephemeral web server has been introduced. Adding a web server to an iOS application like FastPass includes its own security considerations, including the need to secure communication between the SIW and FastPass with TLS. These considerations include a registered domain and TLS certificate. Securing the private key to the TLS certificate also requires some care, as bundling it with or downloading it to FastPass also has potential security risks. To mitigate these risks, keyless TLS is utilised.

After the user verifies their intent to authenticate, FastPass calls the Okta server to obtain the public certificate and other web server configuration details. After the public key certificate is retrieved [9], the web server is started. Now, the original UL challenge is submitted to the Okta server for verification. Retrieving the public certificate and starting the web server before submitting the initial UL challenge for verification prevents race conditions from occurring with the SIW polling of the Okta server and future probing of FastPass. After the Okta server verifies the original UL challenge, the SIW completes polling the Okta server for the verification response. FastPass then notifies the user of the result and prompts the user to return to the browser. When the user backgrounds FastPass to return to the browser, FastPass receives a background event and requests additional background processing time from the OS.  

These steps complete the initial UL handling with the notable introduction of the ephemeral web server configuration and startup. Next is the phishing-resistant communication between the SIW and the FastPass web server.

Now that the SIW has successfully polled the Okta server for the UL verification response, the SIW begins establishing a connection to the FastPass web server.  A TLS handshake starts with the SIW sending FastPass a client hello, a client random, and a list of supported cipher suites. FastPass responds with the public certificate received from the previous request to the Okta server, a server random, and the selected cipher suite from the list of supported cipher suites. Since FastPass does not possess the private key nor have access to it, FastPass requests the signature for the Diffie-Hellman (DH) parameter from the Okta server. The Okta server responds to FastPass with the signature, and FastPass, in turn, sends the DH parameter and signature to the SIW. The SIW responds with the client DH parameter. Finally, the SIW and FastPass can derive a premaster secret with the client and server randoms as well as a session key with the client and server randoms and premaster secret. The TLS handshake is complete, and a secure channel is available for communication. FastPass now responds to the initial communication request with a 200 OK.

The final sequence begins with the SIW sending a second challenge over the now secure and verifiable communication channel established with the FastPass web server. FastPass now receives a challenge with a verifiable origin in the HTTP headers that it sends to the Okta server for verification. The Okta server verifies the challenge, and the origin of the challenge is in an allowlist for the user’s organisation.  FastPass responds to the SIW with a 200 OK, and the SIW begins polling the Okta server for the verification response. Upon successfully polling the Okta server, the SIW redirects to the user’s destination. If the origin is not contained in the allowlist, the user is immediately alerted to the suspicious activity, and the redirect is not performed.

Remaining challenges

Two networking features can challenge communication between the SIW and FastPass’ ephemeral web server. The first is iCloud Private Relay, an internet privacy feature available to iCloud+ subscribers that anonymises network requests by sending them through two separate relays. The request's origin is visible to the user's ISP and the first relay, Apple, only. DNS records are encrypted at this stage, so they’re not visible to the requestor’s ISP or the first relay. The second relay, operated by a third party, generates a temporary IP address, decrypts the DNS request, and makes the connection. These two relays prevent any party from identifying the requestor or building a profile based on requests. However, this currently prevents communication between the SIW and FastPass’ ephemeral web server. We’re investigating potential solutions to this challenge.

The second challenge is DNS rebind protection, enabled by default on some routers. A DNS rebinding attack commonly starts with a phishing attempt during which a user is tricked into navigating to a malicious website. The attacker controls the malicious website and the DNS server of the malicious website’s domain. On the first load of the malicious website, a DNS request for a resource results in an unsuspicious same-origin destination. However, since the attacker controls the DNS server, they can leverage a short time-to-live (TTL) for the DNS result, which will cause the user’s browser to re-request DNS information repeatedly as needed. During the initial website load, the attacker also attempts to identify potential targets on the user's local network.  They can accomplish this by scanning for open services or issuing cross-origin requests and waiting for an error to occur, indicating there is a potential target. After identifying potential targets, the malicious website repeatedly triggers additional requests. Due to the short TTL of the initial DNS request, this will also cause additional DNS requests. However, this time, the DNS server will respond with one of the potential local addresses, bypassing cross-origin restrictions. The malicious website will try each potential target, re-triggering DNS queries each time until a connection is made. HTTP consoles for network equipment, such as the user’s router left with default credentials, are likely easy targets.

Routers can be configured to block DNS resolution that results in the local address space to prevent this type of attack. This DNS resolution block is where the challenge exists. The domain name FastPass uses to provide secure communication with TLS resolves to the local address space, as the SIW and FastPass reside on the same network. 

The current solution to this challenge is to utilise a different network, such as cellular, or to disable DNS rebind protection on the router. Disabling DNS rebind protection can typically be accomplished with varying degrees of specificity. Options usually include disabling protection altogether, allowing localhost only, or allowing specific domains. The more specific the exception is, the better. Certain browsers also prevent this type of attack by enforcing a DNS cache period, thus invalidating the potential to leverage a short TTL.

Conclusion

We continue to work diligently to provide the most secure and seamless login experience via FastPass, now with phishing resistance for unmanaged iOS devices. As this was the last major uncovered device category, we recommend enabling phishing resistance for all sign-on policies to eliminate this attack from relevance in your organisation.

To learn more about how FastPass works, check out this blog post: A Deep Dive Into Okta FastPass.

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 organisation. Contact Sales for more information.