Recently there’s been couple of reports in the news where an attacker managed to bypass a 2-Factor Authentication system.
That’s not the reason.
Researchers at TrimarcSecurity presented at a talk at TROOPERScon in 2019 some common ways to not only bypass MFA (multi-factor authentication) in general but also new exploits introduced by the MFA-system itself (DUO / „Bypass DUO auth when offline (fail open)“ – switch) where an attacker only has to take a machine offline (e.g. by arp-spoofing or maybe even dos) to bypass MFA.
That’s not the reason.
When I first integrated 2FA into Plesk and couple of WordPress Websites I felt proud and very secure. I started „selling“ 2FA to every customer, convinced there’s no sane way, other than in a lab environment, to bypass this. I mean an attacker would have to get hold of my second-factor device, like my smartphone, which I found not impossible but very very unlikely. I was wrong.
In another recent article I wrote about how my instant-theme website AMP-Tracks.com was hacked. This site also used 2FA at this point. As a webdeveloper and Linux-guy I’ve been always very security conscious but I didn’t have the same skills I have today. I knew the ways of numerous attacks in theory but had never used them myself practically. When the mentioned website got hacked, it was at that point in time, me being a theorist, not a practicioner. But I didn’t have to be a practitioner to realize an important thing: 2FA did not protect me from this attack. But why?
Why MFA doesn’t protect you from most attacks
MFA is an awesome tool if you want to secure, say, a banking transaction. Cause it’s a single event.
Authentication correct -> Allow transaction.
Authentication incorrect -> Don’t allow transaction, request new token.
The MFA isn’t used for anything else after this single transaction, at least it shouldn’t be.
It boils down to a very simple concept: MFA secures your log-in-event . And speaking in high-level concepts for non-tech savy: Two-Factor-Auth improves the security of your, potentially weak, password. It doesn’t do anything else. It’s not a magic new firewall surrounding all of your services.
It would be great, if it worked that way. If every service, every procedure call inside WordPress, every service worker on a server, would go out and ask the 2FA system „hey, is the current user multi-factor authenticated and allowed to executed this function?“. That’s not, how it’s working in reality. I guess it would be a nightmare to the devs to integrate it like that, it would slow down any code by the factor 10 and even worse it would integrate the 2FA system so deeply into the code, that we won’t be able to pull it out ever again if we find a better solution some day. You may realize at this point: 2FA offers absolutely no protection against most common CVEs, like a LFI over GET-Params in a WordPress Theme. It just secures your log-in process. If the security issue doesn’t rely on the attacker being logged in (we call these authenticated attacks, often with a low-priviledge user account), 2FA won’t help you to evade it.
Or in a more simple manner: MFA doesn’t protect you against any unauthenticated attack. Just from gut-feeling I would say, unauthenticed exploits make up for the majority of CVEs, 80% would be a proper educated guess.
That’s the reason.
MFA is fine to use if you have the time and can’t enforce strong passwords. It’s great for the masses on publics endpoints, e.g. a webhoster login panel – when that webhoster has the manpower to secure all of his services in other ways, too, meaning the provider takes care of scanning for and patching unauthenticated attacks. It absolutely helps a ton agains brute-force of credentials.
But to me as a freelancer, the cost of MFA no longer provides enough value:
- It’s anoying & costs time on every login
- Very hard to deploy remotely to customers („please scan that barcode I sent to you“ – but they never scanned it)
- I do know all of my customers personally
- Loss or technical malfunction of your MFA-smartphone containing 20 Google-Authenticator Logins is a nightmare I yet have to go through, luckily
- Often times only secures a single, primary admin account and no other accounts (e.g. Plesk)
- Doesn’t help against authenticated attacks, if you can generate a low-priv user account on the system, like a customer login or WordPress subscriber account, that doesn’t need MFA
- If I instruct or enforce a strong-enough password it is almost as secure as MFA
There’s nowadays more modern approaches that actually do provide what we’d need MFA to do: JWT, OAUTH and similar authorisation mechanisms that will hold the hand of your code on each procedure call, not only the login. Well, that’s not entirely true, I know – and yes, you could combine both MFA and JWT to build a strong system – but most IRL implementations, especially in the Windows Server world, don’t do it that way, neither do most WordPress solutions or even Server configuration panel software. I haven’t seen a MFA irl that goes to the full extend.