Solving for Account Takeover: Why MFA is Only a First Step
Multi-factor authentication (MFA) does not solve the threat of account takeover. It adds hurdles, yes, but determined attackers have discovered ingenious ways to bypass all the available authentication factors. Rather than solving for authentication, we should think of MFA as widening the attack surface: each factor introduces a new system of dependencies, new sources of bugs and vulnerabilities, and new opportunities for social engineering. Unfortunately, many security organizations view MFA as we once viewed the network perimeter, as a bulwark that solves for a wide range of attacks. The secure perimeter fallacy, exposed by the proponents of zero trust security, allowed attackers to exploit vulnerabilities inside networks to move laterally and escalate privileges. Likewise, the fallacy that MFA solves for account takeover prevents security organizations from recognizing the weaknesses of MFA and the many remaining system vulnerabilities that expose user accounts to criminal takeover. By looking at how attackers bypass MFA, this whitepaper demonstrates that MFA makes certain other security measures even more important, namely bot mitigation, JavaScript supply-chain protections, and the monitoring of contextual risk, techniques that reinforce the security advantages of MFA while reducing the friction it imposes on users.
The drivers of MFA
Despite its weaknesses, MFA is here to stay and for good reason; password-only authentication has clearly failed.
We humans simply cannot remember long random strings of characters. As a result, we take short cuts; we choose easy-to-remember, predictable passwords, reuse passwords across different applications, scribble passwords on post-it notes. While enterprises mitigate this risk by imposing requirements for password length and complexity, there are limits on human memory; even in the face of complexity requirements, we find ways to be predictable: capitalizing only the first letter, inserting special characters in place of similar looking alpha-numeric characters ($ for S), adding guessable digits such as 123 at the end of a password. (See research findings on password predictability.)
We humans also share flaws that make us vulnerable to social engineering. We give up our passwords when attackers play on our trust, desire to conform, respect for authority, and willingness to help. As it turns out, people will sometimes give up their passwords if you just ask them, which you can enjoy watching on this amusing video of Jimmy Kimmel Live.
Given these weaknesses of password-based authentication, government agencies and industry associations are driving the adoption of MFA. In May 2021, President Biden issued an executive order requiring federal agencies to adopt MFA within 180 days, and the Cybersecurity and Infrastructure Security Agency (CISA) is promoting MFA for private businesses. The Payment Card Industry Security Standards Council is mandating with its Data Security Standard v4.0 that organizations implement MFA for all access to credit card holder data by March 31, 2025.
With the clear advantages of MFA over password-only authentication driving its adoption, security professionals need to pay ever more attention to the disadvantages of MFA, to how it expands the attack surface and creates new vulnerabilities that enable attackers to bypass authentication controls.
The expanded attack surface of MFA
MFA is defined as the application of two or more factors in the authentication process. By factor, we mean a way of proving that you are who you say you are through:
- Knowledge: something you know such as a password or Personal Identification Number (PIN)
- Possession: something you have such as a mobile device, smartcard, hardware token, or USB drive
- Inherence: something you are, as determined by biometrics such as fingerprints, face scans, and iris patterns
There are myriad ways to implement MFA, and many of them either open new attack surfaces or leave applications exposed to the same vulnerabilities that characterize password-only authentication.
SMS-based MFA
There are myriad ways to implement MFA, and many of them either open new attack surfaces or leave applications exposed to the same vulnerabilities that characterize password-only authentication.
The most widespread implementation of MFA utilizes SMS to send users a one-time password (OTP), which in principle proves possession of a smartphone. Generally, a user will initiate the login with a username and password, triggering the app to send the text message. The user then views the OTP and enters it into the app, completing the authentication and generating a session token that will be valid for a set duration.
Remaining vulnerabilities of SMS-based authentication
Implementing the possession factor via SMS fails to close several key vulnerabilities. Because the user enters the OTP and the password into the application and because the application sends the OTP back to the server over the same communication channel used by the application, an attacker that has compromised either the application, the device, or the network will be able to access the password, the OTP, and the session token.
Attacking the endpoint
Using many well established and still prevalent techniques, attackers take over devices by infecting them with malware, resulting in a man-in-the-browser (MitB) attack. Running code in the browser enables attackers to obtain the password and the OTP that they can authenticate on behalf of the user. Alternatively, the attacker can allow the authentication to complete and then steal the session identifier, which could be used to bypass authentication and access a user’s account. (For recent trends in malware infecting endpoints, see the F5 Labs report on BlackGuard Infostealer.)
Compromising the app
By infecting an application, attackers can take over the accounts of users en masse. Other than compromising a company’s infrastructure through malware, criminals can gain access to application data by compromising any of the code libraries that comprises the application, a tactic known as a supply-side attack.
In a software supply chain attack, the attacker typically targets a trusted third-party vendor or open-source repository that provides software components (libraries, frameworks, services) to the targeted organization. The attacker injects malware into the component that is then integrated into the application. This attack can be effective because not every vendor and open-source team has the skills and resources necessary to enforce secure coding practices.
Web and mobile applications are particularly vulnerable to supply chain attacks because they typically include dozens of third-party scripts, many of them added to pages dynamically by tag managers. These scripts, which change frequently and without notice, do not pass through an organization’s code security checks. If an attacker can compromise any of these scripts, they gain total control of an application, meaning they can read user input, access data in browser memory, or hijack the user journey to direct them to a malicious app without warning.
These supply chain attacks, such as Magecart, have caused security breaches of hundreds of thousands of credentials. Very much like MitB attacks, these supply chain attacks work against any MFA solution in which the token proving possession is input into the application, which is typical of most implementations using OTPs. Since the malicious code is reading user input, it could steal both the static password and OTP, as well as any other personal or financial information gathered by the application.
Listening on the network
Because with SMS-based authentication, the password, OTP, and session token travel over the same network connection, this form of MFA remains vulnerable to man-in-the-middle (MitM) attacks using typical attack vectors such as DNS poisoning, ARP poisoning, and rogue wireless access points.
Social engineering
One of the most common and successful attacks against SMS-based MFA uses social engineering to establish a MitM attack via real-time phishing proxies (RTPP).
In this attack, the fraudster uses phishing emails to fool a user into visiting an attacker-controlled site, where the user duly enters their credentials. So far, this tactic is identical to a phishing attack for the theft of credentials, but to bypass MFA requires an extra step. When the user enters their username and password into the app, the attacker forwards those credentials to the target application, which then issues a second factor request to the user. The user is very likely to approve the request because they think they are authenticating to a trusted application; the user clicks the approve button or dutifully inputs the token in the app. In either case, the attacker gains access to the application. (For a demo of the attack, see this video by Kevin Mitnick.)
With automation and the propensity of users to fall for phishing scams, RTPP attacks can succeed on a large scale. (For more data on the growth of real-time phishing proxies, see the F5 Labs Phishing and Fraud Report.)
New vulnerabilities of SMS-based authentication
In addition to failing to close many of the existing vulnerabilities of password-only authentication, using SMS as a second factor exposes an application to additional attack vectors.
Theft of physical device
Perhaps the most obvious attack against possession-based authentication is theft of a physical device. A criminal that steals a phone might gain access to an OTP displayed in a notification, even with the phone locked. Many victims of phone theft have found themselves losing the funds in their bank accounts.
SIM (Subscriber Identity Module) Swapping
Criminals do not need actual physical possession of a phone to gain access to OTPs sent via text. SIM swapping, also known as SIM hijacking or SIM porting, enables attackers to bypass SMS-based authentication, which is the most popular form of MFA used in customer-facing apps. In a SIM swap attack, the fraudster exploits the ability of telecommunication service providers to transfer a phone number to another device, a feature which is beneficial whenever a phone is lost or stolen.
The fraudster begins by gathering personal information on the victim through online research, phishing, or social engineering. With this information, the attacker convinces the telephone company to transfer the victim's phone number to the fraudster's SIM. Or the attacker might break into the user’s account with the service provider using credential stuffing, brute force guessing, or a dictionary attack.
With control over the victim’s phone service, the fraudster will receive all the SMS and voice calls intended for the victim. This allows the fraudster to intercept any security tokens sent via text.
Hardware token devices
Hardware token devices are specialized devices, usually quite small, that display an OTP, which the user types into an application for authentication. These devices provide a means of proving possession without requiring communication from the application to the user, which removes one of the primary vulnerabilities of SMS-based authentication.
Rather than rely on sending the OTP to the user for each login, the device generates a stream of OTPs based on an initial seed value and an algorithm. The seed value itself is shared between the device and authentication service at set up. The seed value is augmented with a counter that is either incremented with an event, such as a login request, or a time duration such as 60 seconds. We refer to these respectively as event-based OTP (EOTP) and time-based OTP (TOTP). EOTP and TOTP are both types of hash-based OTP (HOTP) because the counter and seed together are passed to a hash function that generates an apparently random string of digits, which, when implemented correctly, does not reveal a predictable pattern.
By avoiding the need to send the OTP via text, hardware tokens make it impossible to capture the OTP before it reaches the user through means such as SIM swapping. However, because the user must enter the OTP into the app, which transports the OTP to the authentication service using the same communication channel as the password, most of the other vulnerabilities of SMS-based authentication remain. The attacker can gain access to the password and OTP by compromising the endpoint, the network, or the application in all the same ways as they would for OTPs delivered via text.
The most common attack against SMS-based authentication, real-time phishing proxies, works just as well for OTPs generated on hardware devices since the user is fooled into typing the OTP into the fake site regardless of whether the OTP appears on a phone or specialized device.
While hardware devices remove the possibility of attackers capturing the OTP in transit to the user, the devices rely on seed values that can be compromised. Attackers can access the seed value by gaining physical access to the devices (see mention of an electron microscope attack in 12+ Ways to Hack MFA), compromising the database used by the authentication service, or intercepting the set-up process in which the seed value is agreed upon between the device and authentication service.
Authenticator apps
Authenticator apps can function much like hardware tokens, generating a stream of OTPs based on an initial seed and algorithm, preventing the need to communicate the seed over a vulnerable channel, but they can also go a step further by utilizing an alternate channel to communicate the OTP. In this scenario, following the successful verification of a username and password, the authentication service sends a push notification to the authenticator app, which prompts the user to approve the request. Upon approval, the authenticator app sends the OTP directly to the authentication service without requiring the user to type it into the application. The communication between the authenticator app and the authentication service takes place over a distinct connection.
Using an alternate communication channel means that an attacker cannot access the OTP by compromising the application, since the OTP is never entered into the application. It is also more difficult to gather both the password and OTP by compromising the network connection because the password and OTP are delivered over distinct secured channels. Compromising the endpoint, however, could enable an attacker to access both the password and OTP if the application itself and the authenticator app are running on the same device. (See F5 Labs’ report on malware that compromises Google Authenticator.)
Unfortunately, authenticator apps do not prevent the use of real-time phishing proxies. The user is still fooled into entering their username and password into a fake site through a phishing text message. Upon entering their credentials, the application will trigger a request to the authenticator app. Since the user believes they are in the process of logging into a trusted application, the user is likely to approve the request, which completes the authentication. Although the attacker never sees the OTP, the attacker’s proxy will now have control over an authenticated session, giving the attacker access to the user’s account. (For more on RTPP and push notification authentication, see this article on phishing platforms in Hacker News.)
Moreover, the ease of use of authenticator apps has created another means by which attackers can defeat MFA through social engineering. In MFA bombing or MFA fatigue attacks, the attacker tricks the target into giving them their authentication code by sending multiple fraudulent requests for the code. The attacker typically uses automated tools to generate a large number of requests, overwhelming the victim with an excessive number of notifications or messages asking them to enter their authentication code.
While MFA bombing may trick a user into entering an OTP from an SMS message or hardware device, it is particularly effective against authenticator apps because the user can so easily make the flood of requests stop through the press of a button.
Biometric authentication
There are even more ways to implement biometric authentication than possession-based authentication. Not only are there numerous methods of triggering the authentication request and communicating that data back to the authentication service, but there are many forms of biometrics from fingerprints to iris scans. The hardware needed to perform the scan might be incorporated into the device running the application, such as a fingerprint reader camera on a laptop, or require separate hardware. The biometric reader might be controlled by the operating system or a specialized application. Given these variations in implementation, it is difficult to model every vulnerability. However, it is important to realize that despite the reputation of biometric authentication for greater security, there are still very clear vulnerabilities in biometric authentication.
Indeed, one of the popular methods of bypassing the possession factor, real-time phishing proxies, can be used just as well to bypass biometrics. Once the user logs onto an attacker-controlled application, thinking it is a trusted application, that application will use the credentials to log into the application on the user’s behalf, triggering the request for biometric authentication. As long as the user believes they are authenticating into the real application, they are likely to proceed with the biometric authentication, giving the attacker access to the account. (The FIDO2 standard WebAuthn, created by the W3C, includes protection against phishing, though it is not yet widely adopted by web applications.)
Whether biometric authentication can be defeated through compromising the endpoint, the application, or the network depends on the specific implementation. To the extent that the biometric authentication system runs on the same device as the application, compromising the endpoint might break the authentication. To the extent that the application manages the biometric authentication process, compromising the app might break the authentication. And to the extent that the biometric authentication is sent over the same communication channel used by the application, compromising the network may break the authentication. In short, biometric authentication requires detailed threat modeling specific to the implementation.
Biometric authentication opens the distinct vulnerability of copying and spoofing. Consider fingerprints. We leave them all over the place, on nearly every smooth surface we touch. We leave them on doorknobs, in restaurants, in the garbage. Collecting fingerprints from these surfaces is trivial; we’ve all seen it done innumerable times on police dramas. Replicating fingerprints is likewise trivial using anything from a 3d printer to gummy bears.
For other forms of biometrics, there is an ongoing contest between security researchers revealing how biometrics can be spoofed and vendors developing anti-spoofing technology. 3D masks have fooled facial readers at airports, though these masks can be detected through liveness checks and other methods. Likewise, attackers have used voice recordings with deepfake voice synthesis to bypass voice recognition systems, though it may be possible to detect these spoofs through the subtle distortions added by recording devices. Even iris images can be reproduced and spoofed using cosmetic contact lenses or an artificial eye, though various anti-spoofing techniques—including lighting distinctions between human tissue and synthetic materials—can detect the spoofing. In short, the security of biometric readers will depend on the current state of spoofing and anti-spoofing technology.
Even if we lived the lives of hermits and avoided physically touching surfaces, attackers could steal our biometric data. Through malware, social engineering, and exploiting unpatched vulnerabilities, attackers have stolen billions of usernames and passwords. If attackers can breach the databases storing our passwords, they will certainly break into the databases that store our biometrics. And once a single breach exposes our biometrics, we may not be safe using it for authentication depending on whether its spoofing can be detected.
Aggravating the security risk of copying and spoofing is the fact that we cannot easily change the characteristics that biometrics measure. When an attacker steals a password, we can change it. If an attacker steals an OPT dongle or cell phone, we can replace it and reset the seed. If, however, an attacker gains access to our fingerprint, palmprint, facial image, or any other biological characteristic and learns how to spoof them effectively, we cannot change these physical characteristics without suffering significant pain.
Improving the security of MFA
While MFA is an improvement over single-factor, password-based authentication, it is still vulnerable, at least in the currently popular forms of implementation. So rather than think of MFA as the end of the security journey, think of it as a new beginning. App security best practices remain as relevant as ever, including threat modeling, code reviews, vulnerability scanning, penetration testing, and red teaming. In threat modeling, look at each aspect of the authentication and session management process, considering the many points of attack, everything from the identity store to physical, network, and data security. Cyberattacks will likely target the weakest link. In particular, the vulnerabilities of MFA point to a few key areas of concern that require more attention: mitigation of automation, guarding against JavaScript supply chain attacks, and consideration of risk context.
Remove bots from your network
Criminals rely on bots to scale several key attacks on MFA including credential stuffing, real-time phishing proxies, and MFA bombing, meaning that mitigating bots is key to protecting all forms of MFA.
In credential stuffing attacks, as defined by OWASP, criminals obtain stolen credentials from prior breaches, typically through purchase on the dark web, and test those credentials against the logins of other applications. Because billions of credentials have been exposed through breaches, criminals maximize their returns by automating the testing with bots so that they can test massive numbers of credentials. The Federal Bureau of Investigation, Securities and Exchange Commission, and New York Attorney General have issued warnings on the financial risks of credential stuffing, and the Global Privacy Assembly, an association of over 130 regulatory agencies, declared credential stuffing a global threat to privacy.
Preventing credential stuffing is just as important for MFA as for password-only authentication. The entire point of MFA is the use of more than one factor, but if you fail to protect the first factor then you are left with only one factor. Once an attacker has discovered a user’s password, two-factor authentication becomes single-factor authentication, and defense in depth is lost.
Moreover, mitigating bots is critical because criminals use bots to attack more than just passwords. Indeed, bots are a key tool in launching successful real-time phishing proxy attacks, which are the most common mechanisms for defeating MFA. Whenever a user falls victim to a phishing email that lures them into entering their credentials into a fake site, the attacker will need to forward those credentials to the target application to generate the MFA request, whether that request involves SMS, an authenticator app, or sophisticated biometrics. To forward the request quickly and at scale, the criminal will need to automate the process, which means that the request will be forwarded to the application from a bot. (For an overview of services that use bots to bypass OTP, see the Krebs on Security post The Rise of One-Time Password Interception Bots.) This means that by preventing unwanted bots from submitting credentials, an organization can cripple the effectiveness of real-time phishing proxies and more effectively secure both possession and inherence authentication factors.
Another obvious way criminals use bots to attack MFA is through MFA bombing. Bombing in this context implies generating login requests at large volumes to trigger so many authentication requests that the user will comply either by mistake or just to stop the annoyance. To generate a large enough number of requests for many users so that the attack becomes profitable, the criminal will need to automate, which again means the login requests reaching your site will be created by bots.
As these examples illustrate, nearly any attack against MFA will depend on bots to succeed on a large scale, meaning that organizations implementing MFA need to take bot mitigation seriously.
Unfortunately, many organizations fail to appreciate the sophistication of bots and the determination of criminals to retool bots with great frequency to bypass detection. Rather, too many enterprises rely on bot mitigation techniques that no longer work, including CAPTCHA, IP address deny lists, and HTTP header fingerprints.
CAPTCHA accomplishes little for bot protection other than annoying real customers because bots can bypass these puzzles using low-cost CAPTCHA solving services that rely on machine learning and click farms. Just do a web search on CAPTCHA solving services and you will find at least a dozen competing on price and speed. For a good read on these services, look at a piece by Dan Woods, F5 Head of Intelligence, titled I Was a Human CAPTCHA Solver. Even more interesting, ChatGPT succeeded in bypassing CAPTCHA by social engineering a person into solving the CAPTCHA on its behalf.
For organizations that rely on WAF-based IP deny lists to mitigate bots, the task is equally daunting. There are services available that offer bot creators tens of millions of residential IP addresses intended to bypass bot detection. These services are advertised as rotating residential proxies; the bot sends HTTP requests to the proxy, much like many corporate browsers send requests through forward proxies, and the service continuously rotates the public IP address used to send the request to the website or API. In the past, bots typically used data center proxies, often from cloud services, which are well known and easy to identify. These new proxy services, however, use residential IP addresses from the same geographic area as your customers. Because each IP address could simultaneously represent either a bot or a valid customer due to NATing by Internet Service Providers (ISPs), it is not feasible to block all these IP addresses without turning away your real customers. (For research on how these services obtain these IP addresses, see the paper Your Phone is My Proxy.)
Trying to detect bots based on differences in header order likewise no longer works because bots have caught on to the trick. Indeed, several open source projects, including stealth-puppeteer and undetected-chromedriver, do the job of getting the header order correct, making it easy to bypass detections while using these popular automation frameworks.
Detecting advanced bots nowadays requires advanced signal collection, 24/7 monitoring, machine learning, and rapid reaction to bot retooling. Without a dedicated bot management solution in place, a defense that detects and reacts rapidly to retooling, bots will enable criminals to effectively scale attacks against MFA.
Guard against JavaScript supply chain attacks
Nearly any form of MFA imaginable will fail in the face of application compromise. If the attacker inserts code into an application, it’s game over. The attacker can capture credentials and other MFA inputs, take over sessions by stealing session identifiers, or exfiltrate data directly from the application. Because modern web applications are typically composed of over 20 JavaScript files, mostly from third parties and not reviewed by the organization’s application security team, the risk of application compromise through JavaScript supply chain attacks is higher than often realized.
Existing client-side security protocols are too static to defend today’s dynamic web apps. Content-Security Policy (CSP) restricts the actions of scripts in ways that could prevent JavaScript supply chain attacks, but CSP could too easily break a site’s functionality if a third-party vendor updates a script dynamically in ways contrary to the CSP restrictions. While you might want a script to fail if it breaks a security policy, that failure in production could dramatically impact customers. (See Why is CSP Failing?) Sub-resource Integrity (SRI), another web security protocol, is even less feasible for third-party dynamic content since it requires updating script tags with hash value every time a script changes, which is not possible if the changes occur without notice. Indeed, SRI is meant to prevent the type of script updates upon which most modern applications rely.
Without clear controls to eliminate JavaScript supply chain vulnerabilities, organizations need to be creative in finding means to at least monitor the risk. Organizations can better document the scripts on their site and rank them for risk based on source and frequency of change. Scripts added through tag managers should undergo regular reviews to evaluate risk. Monitoring tools can be obtained that track the behavior of scripts using either synthetic monitoring, CSP in reporting mode, or JavaScript-based agents running in the browser.
Because third-party scripts change with such frequency and without an opportunity for security review, it is important for organizations to continuously monitor their applications for suspicious behavior such as scripts reading sensitive data and exfiltrating it to untrusted domains. Without this monitoring for JavaScript supply chain attacks, no form of MFA will keep users safe.
Recognize known good users and challenge suspicious behavior
The purpose of MFA should be improving security rather than burdening customers with pointless security theater. By adapting login requirements to contextual risk, organizations can avoid continuously punishing valuable returning customers with MFA requirements and instead ease their journey with extended user sessions, welcoming them with a personalized, effort-free experience, like how TSA expedites trusted travelers with TSA PreCheck.
Contextual risk has many dimensions:
- Geography: Based on IP addresses, is the user logging in from their usual locale?
- ASN (Autonomous System Number): Based on IP address, is the user logging in from the same ISP as usual, one associated perhaps with their home, work, or favorite café?
- Device: Is the user logging in from the same device as usual?
- Time/day: Is the user logging in at the same time of day or day of week as usual, perhaps during the morning to do their banking and in the evening for gaming?
- Behavior: Is the user typing with the same speed as usual, moving the mouse in the same patterns, copying and pasting in similar ways?
- Functionality: Is the user utilizing the same functionality as usual?
If the user has a proven track record of good behavior and accesses a site from the same place, same device, same time of day, with similar behavior, using their usual functionality, it might not even be necessary to require the user to login; rather, conduct continuous silent authentication to extend the session for the user’s convenience. If the context deviates from normal, indicating higher risk, you have the ability to add adaptive policies to your application to increase the security demands in measured steps: requiring a password login, requiring 2FA, flagging an account for review, alerting the user via SMS or email about the login, or locking the account to force the user to contact support.
Too often, session length is a set period regardless of contextual risk, enabling anybody with a session token to continue accessing data for which the user is authorized, ignoring the risk of session hijacking. A more secure approach is to follow principles of zero trust: assume breach and monitor continuously. If context changes within a session, end the session early and require additional authentication, with the strictness depending on how much the context has changed and the sensitivity of the data.
Conclusion
In line with the cliché that security is a journey, MFA has created several forks in the path, providing additional options, which when implemented correctly enhance security in meaningful ways. Yet no form of MFA, no matter how many factors, how well implemented, how costly, lets us skip the journey to arrive at the destination. We are certain to see more proclamations of the death of passwords, more hype that new MFA techniques will make authentication secure once and for all, but there will remain ways for determined attackers to bypass new technology.
In your journey to better secure critical applications, you have a partner in F5. F5’s Distributed Cloud Services include Bot Defense for bot mitigation, Client-Side Defense to monitor JavaScript supply-chain attacks, and Authentication Intelligence to recognize returning users and quantify contextual risk. With F5’s support, you can ensure the security of MFA while optimizing the customer experience. Learn more about F5 Distributed Cloud Services and sign up to speak with our team.
Connect with F5
