I used to be a huge fan of Push-Based Multifactor Authentication (MFA), but real-world use has shown that most of today’s most popular implementations are not sufficiently protective against real attacks. In short, using social engineering, hackers have been able to bypass most Push-Based MFA like it was not even there.
It does not have to be that way. Push-Based MFA solutions can be improved to make it a lot harder for hackers to be successful, and some vendors are already offering more advanced forms that are more resistant to hacking. You should be using phishing resistant MFA when you can rather than more easily phishable forms.
What features make Push-Based MFA more resistant to hacking? Read on.
What Is Push-Based MFA?
Push-Based MFA is MFA that proactively sends an “out-of-band” approval message to the user to review when someone is trying to authenticate to a push-based MFA login portal/service. The message will indicate that the user’s related identity account is attempting to log in and asks for the user to approve or deny the request. Here is a very common example from me logging on using Microsoft Authenticator:
Some of the push-based approvals arrive via SMS phone message versus an installed app, like this early example from Amazon.
Sadly, it is not hard to see how this sort of message could easily be a phishing attempt from a fraudster.
Luckily, now Amazon does it through their app, like this:
Here is an example from Google Gmail:
Push-Based MFA Hacks
I wrote “the book” on hacking MFA. In it, I cover over 50 ways to hack various push-based MFA solutions, including push-based MFA, although I have come up with more ways since the publication.
Here are some of the common ways push-based MFA can be bypassed or compromised:
-
Social Engineering
Most MFA, including push-based MFA, is susceptible to simple phishing attacks. The most common ploy is the potential victim receiving a fraudulent email which claims to be from a service or website that requires the victim’s MFA solution to log in. The victim is tricked into clicking on a fraudulent URL, which unknowingly takes them to a malicious man-in-the-middle (MitM) website, which then captures and redirects all inputs from the victim to the real website, and vice-versa. Everything the user types in, including MFA codes and approvals, is captured by the malicious website and vice-versa. Kevin Mitnick does the best video demonstration of this attack (although not using push-based MFA).
When push-based MFA is involved, the malicious MitM website is the location that is really directly connecting to the victim’s intended website or service; and not the victim. If the victim is tricked into approving the push-based notification, then the MitM website is the entity that is able to access the victim’s intended website or service. The MitM website simply disconnects the victim’s connection after taking over the victim’s authenticated session.
The most common defense to MitM attacks is for the push-based MFA to include the location of the login in the notification message (such as the Google Gmail example shows above). The idea is that the user should pay attention to the reported login location and not approve the login if it is not their current location. Unfortunately, many users do not pay attention to the location. Some people never pay attention to it and many others start to unconsciously ignore it after seeing it over and over during each login. So even if the login location was different than their location, they simply would not “see” the clue and recognize that a MitM attack was happening.
Also, many VPNs, so popularly used today, end up redirecting the user’s reported login location to the location where the VPN hub is located. For example, many push-based notification messages have erroneously reported my current login location as Washington, DC, Colorado, and Austin, TX, even though it was me logging on from my Tampa, FL home. There is also the chance the MitM attacker could be located in the same login location as the victim or use a VPN-like login service to originate their redirected login location to be the same as the victim. Although these latter two scenarios are probably pretty rare and maybe sometimes used by nation-state attackers against high value targets. The much bigger, and far more likely issue, is simply end users ignoring or paying little attention the location hint as part of their daily life. -
Tied to a Phone Number
Many push-based authentication prompts are tied to a phone number and move with the phone number. This is bad. Phone numbers can be maliciously moved and stolen using a variety of attacks, including an attack known as a SIM Swap. Brian Krebs covers SIM swap attacks fairly frequently on his blog if you want more details. In short, there are many ways to take anyone’s phone number and move it, if only temporarily, to another cell phone. Attackers, when targeting victims with phone number-attached MFA, will switch the victim’s phone number to their phone and then the SMS-based or push-based login message gets incorrectly redirected to the attacker’s phone.
This sort of attack happens all the time and has been occurring for over a decade. SMS-based MFA fraud is so rampant that the U.S. government has been saying not to use SMS-based MFA since 2017. And the U.S. government’s call for vendors, websites and users, not to use SMS-based MFA has continued in 2021 and 2022 in the form of presidential executive orders.
The defense against these sorts of attacks is to try and use an MFA method that is not tied (only) to a phone number. Many more secure phone-based authentication apps require the end user to log in using separate login credentials, so that even if the app gets moved to an attacker’s cell phone, the app will not allow the attacker to use it without first logging on using the victim’s other login credentials. This can be done by the attacker, but that means more work for the attacker in order for them to be successful. And making attackers work harder is always a good thing. -
Workaround Issue
One of my favorite stories about how push-based MFA is abused came from an IT worker who was in charge of helping to better secure the logins of oil rig workers. He went with a push-based phone app. His first lesson was that not all “roughnecks” had smart phones, which were required to use the push-based login app. So, he had to purchase, provide and train oil rig workers on how to use smart phones…no easy task. And this was before he taught them how to use push-based authentication. But the IT worker pushed on through and did all the appropriate training and education.
A few weeks later, he learned that many of the oil rig workers could not use (or could not easily use) the push-based MFA app, so what they did was to re-register their involved push-based apps to push to their supervisor’s phone. The supervisor was getting nearly all of his employees’ push-based notifications every day and, of course, just approving everyone who was coming in, without really knowing for sure that all the logins were legitimate. When caught, the supervisor was warned that this was against company policy and very risky to do.
A few months later, the IT worker checked again, and again the supervisor was approving all his worker’s logins from his phone. When confronted, again, the supervisor said it very plainly, “Man, we are just trying to do our job and this new login method is just making the job harder!” Never underestimate humans to circumvent security controls if it makes their life harder. There is a big lesson for MFA design in there. -
Just Approve All Prompts
The straw that broke the proverbial camel’s back for me regarding my previous strong support for push-based MFA was this story. A large midwestern company was hit by ransomware. The resulting investigation revealed that the organization’s own CISO was responsible for approving dozens of push-based login messages for logins he was not involved in. And those logins showed on-the-screen, that they were coming from Russia, and not from the state the CISO was in. When asked why he approved all the illicit push-based authentications that he was not involved in, the CISO said defensively, “I just approved all the login messages like I was told to do!”
Either that CISO was not instructed on when to approve and not approve messages or they were not listening/reading. Sometimes we can pretend to be paying attention and learning when we are not. I can also easily see IT teaching the CISO (and the other employees) on how to use the new push-based MFA method to help them log in using the new method, and possibly not covering the fact that users should not approve logins that they are not involved in. The instructors likely thought that any reasonable person should understand not to approve a login that they are not involved in, but they were overestimating everyone’s ability to understand how the push-based MFA login worked.
Users approving push-based MFA logins they are not involved in is not a rare thing. In reading multiple CISA ransomware incident response reports, many involve notes indicating that attackers were able to trick end users into approving logins that they, the user, was not actually involved in. And I have talked to several penetration testers who say they always easily compromise sites that use push-based authentication. They especially love push-based MFA that is really single factor authentication (1FA), which is very popular these days. The penetration test teams simply type in the user’s login name to the login screen, the user gets the push-based approval prompt and approves it. One leader of a penetration testing team told me, “It is like walking up to a New York City apartment building with one of those buzzer panels to get past the front door. You just hit all the buzzers at once and there is always someone waiting on someone else who will buzz you on through without confirming who it is.” Penetration testing teams tell me that they smile when they hear that the intended target that they are being hired to break into has push-based authentication.
All of these attack types and stories changed my initial belief in the strong security of push-based MFA. I no longer believe that to be true. I now classify most push-based MFA as weak protection, unless they have additional features to prevent the types of attacks I discussed above.
What Features Make Push-Based MFA More Resistant To Hacking?
-
Security Awareness Training and Education
Security awareness training and education is KEY to helping push-based MFA be as secure as it can be. Make sure, best as you can, that all users understand the importance of only approving their logins that they themselves are personally, actively involved in. And not approving any illegitimate login and reporting it to IT/IT Security/Help Desk, so the risk can be investigated and addressed. -
Location, Location, Location
All MFA solutions should include physical login locations, even if it is often ignored by end users. Again, training is key. Also, administrators, buyers and users should try to avoid VPN solutions that impact the user’s physical login location. -
Device Registration
Any authentication solution that locks logins to particular, preregistered devices (such as the user’s laptop) are a good deterrent to MitM attacks. FIDO2 solutions require this. I do not know how many FIDO2-solutions are also push-based MFA, but if you find push-based MFA that is FIDO2-enabled, I like it. Many other MFA solutions, like Beyond Identity work with multiple MFA solutions, including push-based MFA, and involve device registration. -
Geo-Fencing
Geo-Fencing (or Geofencing) is the process of limiting logins (and other activity) to only pre-allow physical or logical locations, such as physical location, IP address, country, etc. Geo-fencing can be applied to push-based MFA, so that approved logins are only allowed from locations the user is known and allowed to log in from. For example, the user lives in Virginia Beach, VA and logs in from there every day. A rule can be created only allowing the user to log in when the originating physical location is detected as being from Virginia Beach, VA. This of course usually requires that the user proactively tell IT when they are traveling from their normal, everyday location so that any new locations are allowed. -
Geo-Kinetics
Geo-Kinects (or Geokinetics) is a relatively new term (you will not find it a lot of places), but the practice has been happening on various sites and services for years. Geo-Kinetics is the practice of sites and services recording the login location of each user login and then denying impossible logins from two different timely logins. Such as a user logging in from Tampa, FL at 8:30 AM EST and then from China two hours later. Microsoft and Google have been doing this sort of detection for over a decade. Early on, both services simply reported to the end user where their previous login occurred from, but morphed to a more sophisticated version where they notified users when they spotted an impossible login location combination. As far as I know, neither service does proactive blocking when they detect “impossible logins”, so I have always taken that as a sign that there are ton of false-positives/false-negative problems involved with correctly detecting user login locations (e.g., VPNs causing issues, etc.). -
Geo-Correlation
WatchGuard MFA is starting to use geo-kinetics. They do something known as geo-correlation, as well. With geo-correlation, both login factors, say the user’s laptop and the cell phone, have their physical locations identified. And if the two locations do not agree, then the login is not allowed. This should defeat most MitM attacks. -
OTP Code That Has To Be Inputted
One way to guarantee that the user is actually involved in an active login is for the login screen to display a code which the user must type into their push-based MFA app as part of the approval process. It does not stop MitM attacks, and users do not like the additional “friction” during login, but it does significantly improve the odds that the user is actually logging in. It might even frustrate well-meaning bosses.
I am sure there are other traits and methods that can help to improve the security of push-based authentication.
I would love to hear from anyone about any that I may have missed. If you have any other methods please email me at rogerg@knowbe4.com.
Conclusion
I will end with this note of caution: Push-Based MFA, as popularly implemented today, is not as secure as I once thought it to be. Mostly because some large percentage of end users will approve logins that they, themselves, are not involved in and the ease of MitM social engineering attacks. End user education is key to any authentication method, including MFA, including push-based MFA. Teach your push-based MFA users about the various types of attacks that could be successful against the solution they are using and how to detect and prevent those attacks.
And any push-based MFA using some of the newer methods I describe above, over and above, simply displaying location information to the end user during login, should be preferred over methods that do not use these additional methods.
