You ain’t got no problem, Jules. I’m on the Multifactor.
Intro
I’m so sorry it’s been nearly SEVEN MONTHS since my last blog! A lot has changed in my personal life (burnout, job change, selling ABC books, new baby, coaching youth soccer, pumpkin patch?) and I just haven’t had the time to research or write anything fun in a while. I can’t commit to monthly posts like before but I do have some research planned soon!
To my delight, I’m starting to become known for phishing in the community and often get the question, “How can I bypass Multifactor Authentication (MFA)?”. On the flip side, while doing security architecture reviews or awareness trainings for customers, I often identify gaps and share ways that a client’s MFA implementation can be improved upon. Maybe they hire me to do a Spear phishing campaign because they use KnowBe4 or something and they’re feeling confident (ha!). On both sides of the fence there seems to be a common misconception that MFA is a silver bullet that can’t be bypassed practically. No, I’m not talking about SMS interception here.. that’s been discussed ad nauseam and in my opinion, not as practical as other methods I’d like to share. I’ll die on the hill saying any MFA is better than no MFA but if misunderstood and implemented poorly, can lead to a false sense of security. Let’s talk about ways to bypass (or strengthen!) BMF (please make this a thing).
Some BMF Implementations
Implemented, but not enforced
During Threat Modeling or Architecture Review meetings (Application or Enterprise), I always ask about MFA and the response is often, “We support MFA.” That’s great, really! Is it enforced though? Supporting and enforcing MFA are not the same. Supporting MFA essentially leaves security up to the user and we already know how this story ends. I’ve also seen hybrid approaches where administrators or certain departments are the only ones who have the requirement. This is better and is often done for the sake of convenience but as we all know, it only takes one successful credential harvest before phishing can turn lateral and harder to prevent. It’s also more of a pain to manage role-based requirements as employee turnover occurs and there’s more opportunity for human error. Don’t leave enrollment as a choice for the user for critical applications.
Less-secure methods accepted
This is something I preach about a lot and I covered some of these in extensive detail at the bottom of a lengthy phishing blog previously, so I won’t go into much here. PINs or tokens that you type in, either from a hardware device or software, are subject to interception in the same way your user credentials are! People are typically initially confused by this but think about it, if you’re typing your password and an attacker can just send that to themselves, they can do the same with your PIN and use it before you can. (Yes, even within 30 seconds) If you have a user, password, and token field and you submit all of them, I will have all three. You should instead use a method that can’t be as easily intercepted, such as a Push notification. That simple “Yes, it’s me!” button is not only more convenient for users than typing a PIN, but it’s way more secure since the attacker doesn’t have your device to do that with.
You might be thinking, “Well I only use PIN codes as a backup but Push is my primary default.” Sure, but I take advantage of this all of the time when I create phishing landing pages by simply forcing them to use their PIN in their app. Most solutions support this by allowing the user to launch the app manually and entering a token. They might wonder why this time it’s asking for a PIN when all of the other times it defaults to Push, but you’d be surprised how often this works. You’re only as secure as your weakest link and my advice is to disable all of the insecure MFA options available to you unless you only have one, as a user. As an administrator, consider only allowing Push notifications or hardware keys. If you want to read more with examples see my other blog.
Some login forms let you supply an alternative means to log in if you don’t have your MFA device. There’s really no industry standard that I’m aware of and I’ve seen a lot of varying implementations by developers in web applications. Some places will text you a One Time Password (OTP) to a registered phone, Bluetooth or NFC, and others will simply allow you to use a backup password or password hint, essentially offering to bypass MFA for your attackers.
Open Enrollment
This is a big one that I see in the real world during phishing assessments all the time. Say you do the right thing and you enforce MFA for EVERY account by default now. They are now required to enroll their mobile device before they log back in. Does your MFA provider send a text or share an invitation link that the user can use to enroll with? This is the more secure route. Instead, maybe users are forced to enroll themselves upon next login. I call this open enrollment. If I can use only your credentials and log in from anywhere then your authentication is weak initially and I can enroll on your behalf with my device. It always makes for a fun screenshot in a report when I show myself accepting a push request for another user I phished. Enrollment should be by invitation only.
Infinite Enrollment Period
Similarly, or combined with Open Enrollment, the issue can be exponentially more critical if there is no period set for enrollment. This is really bad. You’re basically saying that your users can enroll whenever they want, just before they can get on again. All they need are their current credentials to do this. Consider with me a scenario with someone goes on vacation or doesn’t have a business need to use this application for a few months. Or, they’re in another department and have no business need at all to use that system so they never follow through. I recently performed a campaign for a customer who wanted me to test their MFA through phishing and was confident because of enforced enrollment for all users, which was pushed out years prior. I was able to claim device ownership and enroll my own phone for about 25% of the accounts. Your MFA enrollment invitations should be set to expire after a reasonable amount of time.
Users Accepting Attackers’ Push Requests
Okay let’s say as an organization you’ve done everything right. You enforce enrollment for all users, allow Push notifications only, and it’s done via invitations only that expire after a few days. Can MFA still be bypassed?
YES.. all the time, yes. As a red teamer I still have a good success rate phishing MFA credentials even if the org does everything right. Although, in this case I would argue that sometimes MFA providers can do more to protect their users. I experience a surprisingly good success rate when phishing users with cloned landing pages where users actually accept the push notification on my behalf! Before you laugh and say, “Wait why would anyone do this?” it’s a pretty reasonable mistake. As an attacker, if I time it right (using my PhishAPI phishing framework) I receive their credentials as soon as they submit them and the victim is seamlessly forwarded on to the legitimate site. They’re actively trying to authenticate and are expecting a push notification, so when I’m logging into the legitimate site with my recently acquired credentials, they’re actually receiving the Push notification from MY attempt, not theirs. They probably wonder why accepting it didn’t log them in so they try again (this time on the legitimate site) and they get in without a second thought. Another tactic I use if they actually decline me is to simply make the request multiple times. I can only assume the user either gets annoyed or thinks there’s a glitch and they eventually accept it out of frustration.
What can MFA providers do to help protect against this? Well for one I shouldn’t be able to prompt an MFA request for an account that only ever authenticates from London and I’m in Indiana. This ties back into authentication as well, but MFA push notifications should at the very least show the location of the login attempt and perhaps IP address, even if it doesn’t detect anomalies itself (like multiple attempts from more than one geographic location within minutes). A user could glance at this and say, “That’s not where I’m currently trying to log in!” and deny the request. It probably goes without saying but users should never accept MFA Push notifications when they’re not actively trying to log in, but I’ve seen this be successful in a real-world situation before.
In Conclusion
I know there are many more ways to bypass or harden MFA than what I wanted to go into here, but these are the ones I’ve personally pulled off and were relatively easy to do from an attacker’s perspective. These are also mostly easy to resolve by hardening existing implementations for defenders. Now, sometimes I like to use a transparent proxy leveraging tools like Evilginx or Modlishka to perform Session Hijacking. I won’t get into this but for those unaware, the idea is to forward legitimate traffic through a intermediary server to capture a valid session token that can be used to authenticate, after the MFA and valid credentials have been used on the legitimate site. These attacks are harder to protect against and you’re going to have to rely on security awareness and security tools to try and prevent them, but the point is that MFA is not a silver bullet. However, it IS perhaps the lowest-cost, most effective, and easiest-to-implement solution out there to significantly reduce risk of unauthorized access from compromised credentials.
Please, if you’re an organization that doesn’t currently leverage MFA, simply do. It doesn’t have to be inconvenient. If you already use MFA please consider my advice as best practice until there are more formal requirements placed around them, based on my experience attacking these systems. If you’re an MFA vendor, consider including more information to help a user determine if a request should be approved or not. I recently was made aware of a great XMind project listing MFA bypass techniques, although at the time of this writing none of the methods above are included.
Stay safe out there and thanks for reading!! :) — Curtis
