Phishing with FIDO
“Change is the law of life. And those who look only to the past or present are certain to miss the future.”
The Rise of MFA
The use of multi-factor authentication (MFA) has been slowly but steadily increasing over the last few years. The main driver for this is the widening recognition that password based authentication is now simply too weak and vulnerable to provide a reasonable level of security. More specifically:
There are now billions of account and password combinations that can be harvested from previous data breaches. This vast trove of account details means that even simple attacks such as credential stuffing (trying many known username/password combinations) or password spraying (trying all known account names along with a commonly used password) will often enable an attacker to compromise multiple accounts.
The relentless rise in the frequency and sophistication of phishing attacks places password protected accounts at significant risk. A simple mistake by a single employee is all it takes to enable a network breach. For organisations with thousands of employees this means the risks of password protected accounts are simply too high to tolerate.
While most forms of MFA do provide a robust level of protection against credential stuffing and password spraying attacks, they can still be susceptible to sophisticated phishing attacks. The fundamental weak-link in these attacks is often the human factor. Our tendency to be trusting and helpful, along with the inherent difficulty in differentiating valid emails and web sites from well engineered phishing attacks, means that a determined and creative attack will often succeed in getting hold of any authentication data needed to access an account.
The attackers also have numbers on their side: if the target is a large organisation then they can cherry-pick from a large set of employees and keep trying until they manage to get access to an account. Security awareness training and well defined processes do go some way towards making the attacker's job more difficult, but it seems clear that this is never going to be enough to really make this problem go away.
FIDO to the Rescue
FIDO (Fast ID Online) is a set of standards that are designed to enable public key based authentication. One of FIDO's headline claims is that it is "phishing-resistant". So how does FIDO overcome the human factors that often make phishing attacks possible?
It all comes down to one specific aspect of the way FIDO works. The FIDO standard used for web based authentication, WebAuthn, includes the constraint that:
"A public key credential can only be used for authentication with the same entity (as identified by RP ID) it was registered with."
During a WebAuthn authentication, the web browser provides the HTTPS authenticated server domain name (WebAuthn calls this the RP ID) to the authentication device. If this doesn't match the domain name used to register the account then the authentication request will be denied.
This is a neat solution. Even if an attacker convinces a user to attempt an authentication using a phishing site, the device will notice that the phishing domain name doesn't match the registered name and the attack will fail.
This simple validation step goes a long way towards mitigating a wide range of phishing attacks. It is one of those seemingly rare, but very welcome, instances where the technology actually helps to the user to avoid making a mistake.
Attacks Always Get Better
It is a common mistake to deploy a mitigation to a specific attack and then just expect those attacks to stop. In practice, the attackers just refine their approach and will devise more creative and sophisticated attacks that work around the deployed mitigations. Rather than waiting to see what the attackers come up with it is often instructive to preempt this step and try to predict how the attacks will evolve.
To conduct a phishing attack against FIDO/WebAuthn, the attacker would need to have control over a HTTPS authenticated site that uses the same domain as the registered device. While this does raise the bar significantly it doesn't completely eliminate phishing attacks, there are still some common cases where such an attack might be possible.
Subdomain Hijack
Subdomain Hijack vulnerabilities are the result of common DNS configuration errors, these result in a valid subdomain pointing at an unused resource. In some cases an attacker can register that resource and can then effectively take control over that part of the domain. For example:
The DNS entry for subdomain.example.com contains a CNAME Redirect to unregistereddomain.com
An attacker registers unregistereddomain.com and deploys a phishing site to it.
As the attacker now has control over subdomain.example.com, they can also request a valid TLS cert from a service such as Let’s Encrypt.
A user now visits https://subdomain.example.com and is presented with a legitimate looking phishing site.
While this type of vulnerability is well known, they are often considered to be low priority issues. They are also very common: it is actually very rare that we see any reasonably complex corporate domain that doesn't have some of these vulnerabilities. For example MGM Resorts, who were recently the victim of a social engineering attack, have a number of these configuration issues in their main domain:
Unresolved domain dependencies from mgmresorts.com. Screenshot from Secmatics EdgeScope.
There are also around 1,500 additional top level domains we have recorded that have unresolved redirects to a name in the okta.com domain. The intent here isn't to criticise MGM or Okta, but to make the point that these issues are very common, they are everywhere.
The problem here is that the use of a hijacked subdomain could potentially bypass the domain validation used by FIDO/WebAuthn. The standard does allow the origin site to present a domain name that is a parent of the site's origin. If, in the above example, the user had a FIDO device that was registered using the domain name example.com then WebAuthn would allow the attacker's page at subdomain.example.com to present example.com as the RP ID to the authentication device. In this case it is very likely that the DNS misconfiguration would effectively negate FIDO's phishing protection and the attack would succeed.
Web App Vulnerabilities
The underlying security risk associated with Cross Site Scripting (XSS) vulnerabilities is that they enable an attacker to execute code in the context of a trusted web application. If such a vulnerability exists in a domain used with FIDO then that injected code might be able to request a FIDO authentication. From the perspective of the browser the injected code has the apparent origin of the legitimate page so it could make a WebAuthn request using that origin or any parent domain name.
XSS vulnerabilities are still very common and the technical bar for discovering and exploiting these issues is relatively low. This means that XSS vulnerabilities, or any other browser or application level same orign bypass vulnerabilities, could end up being a common component of phishing attacks against FIDO deployments.
Mitigation Options
While the phishing protection provided by FIDO/WebAuthn is a very welcome feature, it is important to recognise that this could easily be undermined by other vulnerabilities. If you deploy a FIDO solution without taking steps to address these other issues then an expensive MFA deployment might turn out to provide relatively little incremental protection against sophisticated phishing attacks.
One potential defensive measure is to use a dedicated subdomain as the registration name for any FIDO/WebAuthn deployments. So rather then use a top level domain name such as example.com, register all devices using a specific subdomain such as login.example.com.
If you then ensure that this subdomain is never used by other web apps or DNS entries then you can significantly constrain the attack surface that could be used in a phishing exploit. The WebAuthn standard only permits the caller to use a "registrable domain suffix" of the origin, so an attacking page from other subdomains would not be permitted to present login.example.com as the RP ID. Unfortunately many FIDO/WebAuthn examples do seem to suggest the use of a top level domain as the RP ID, once deployed in this way making a change could be quite disruptive.
How to Protect Your Organisation
Secmatics EdgeScope can monitor your complete Internet attack surface for Subdomain Hijack and other common DNS configuration issues. With fully automated vulnerability analysis that utilises NIST's Vulnerability Database and the CISA's Known Exploited Vulnerabilities Catalog, full attack surface indexing and searching, and an interactive DNS dependency view, EdgeScope provides an unparalleled set of features that enable you to monitor and secure your Internet facing attack surface.
If you are looking for some help identifying or mitigating the types of vulnerability mentioned above then don’t hesitate to get in touch.
One More Thing
The fact that FIDO and other MFA solutions do not offer perfect protection should not deter anybody from moving away from password based authentication.
Nearly all MFA solutions, and FIDO solutions in particular, still represent a very significant improvement in security when compared to legacy password based authentication.
