Intercepting and Capturing MFA LogonsAugust 01, 2017
Intercepting and Capturing MFA Logons
One of the interesting classes of vulnerabiltiies are those that are fairly well known to security professionals, and yes, generally equally well known to criminals. Yet bizarrely, usually considered non-issues, or impossible by decision makers and standards groups. We’re going to talk about one of those.
MFA with Office365
Office 365 runs its own app with push notifications to support MFA. Let’s be clear, the fact this exists at all puts them a long way ahead of businesses running domain registries.
But to the man who claimed he was “physically intimate” with Microsoft’s MFA solution, we’re going to show how an attacker can still phish themselves an account.
Open sourcing a toolkit
In order to prove this is a real thing, I’ve released a toolkit. You can grab it from Github.
Credit where it’s due, the main HTML/CSS template came out of the fantastic phishing frenzy project, which should be used a lot more by the world.
Running the attack
Not included: A decent phishing scam. Here’s one we made earlier. Do note, people in general care a lot less about fake speeding fines and requests to reset passwords, and a lot more about free iphones.
This email has been about 80% successful in at least getting a link clicked in testing.
With that done, grab the .js file and - after setting the URL appropriately - paste it into the console. Your attacker’s window will now poll the attacking server for a set of credentials. It should all end up looking a bit like this.
The user of course, will happily enter a password. And in more basic solutions, the password would be captured, and that’s the end of the story. But this isn’t a basic solution, because the user did the right thing and setup MFA.
Fortunately, our more advanced phishing page has a fake MFA page, which is in line with a user’s expectations based on their normal logon.
Microsoft ever so conveniently released an opt-in “New Sign On” page that started appearing right as I was proofing this blog. It’s been asserted that this totally negates this blog and project. We shall agree to disagree.
The templates aren’t perfect. The legitimate MFA page has this series of dots that move while you’re waiting. If your victim is likely to notice this (most users are not) spend $20 on Upwork or whatever and get the victim page improved.
Calling out attacks like this is only meaningful if you can call out a workaround. Let’s start by describing what’s not a workaround: Customised logon pages.
There’s a few places this falls down. First, if an attacker really wanted to, I’ll refer you back to the fact you could easily just modify your victim page suitably. But the other issue is that Microsoft has broken this feature several times, as you’ll see my scrolling to the comments section here. When users get used to Microsoft breaking a feature, it’s extraordinarily unlikely they’ll get used to panicking when it doesn’t occur.
Your real defence here is in the form of U2F based MFA. It does have an increased friction of push based - which is why I’m not here declaring the death of push based apps. I am however suggesting businesses protecting critical data should offer at least the same level of security I can get on Facebook, which has supported U2F as an early adopter.
Although you can Google “Amazon U2F” and get a whole lot of options for buying keys online, AWS appears to currently only offer TOTP or SMS based MFA. It’s ironic that you can sink money into hardware tokens for a feeling of “extra security”, but noone can explain why this attack couldn’t be adapted to a page that looks like this: