Seems like the easy solution to this sort of attack would be to implement an exponential backoff for 2FA tokens, or give them a “lock until I turn it back on” option. That said, I’ve never considered needing such options before, so…
Exponential backoff might reduce the noise sent to specific individuals, but in practice the attacker will just source more targets. Rate limiting on specific IPs is also somewhat ineffective too. Given that this stage happens after a password is entered and found to be correct, I would recommend that a password reset be issued after some number of attempts. Somewhere between 5 to 10 MFA failures seems reasonable to me.
I suppose. I’m certainly not an expert but it seems like sourcing more targets would get expensive quickly, since you need a known password. But yeah, forcing a password reset after X failed attempts is probably the way to go. I was thinking that locking the account for 24 hours or something might be a decent alternative, since my brain hates things that fail in a disabled state forever, but after thinking about it more that’s exactly what you want here.
This theoretical case may imply the IT team broadly has their credentials compromised if they have to reach for break the glass credentials instead of resolving it for one another. I would not trust their hardware to safely interact with it at that stage, it smells like a keylogger.
Yubikey failures happen quite frequently for me actually — the first time I authenticate with a yubikey usually fails via NFC or on windows, and it’s always only the second or third time that works.
Purrly because the connection fails or Windows’ auth stuff breaks.
On Linux it’s more reliable, but it’s still an issue.
For reference, I’ve usually got several yubikeys enrolled and/or connected, which some systems apparently don’t like all that much?
Or just an off button in the client (MS Authenticator has one already). You should only ever get a notification in response to something that you’ve done, so if you get them at other times then you’re either under attack or there’s a bug. Either way, you can turn them off until you try to do a thing that should trigger one (and notify your support folks in the interim).
I don‘t quite get how you can harass someone with MFA push notifications. The user can always simply silence their phone or turn off notification for that app to get rid of the harassment. Also in what scenario would getting this amount of MFA notification be normal and not a tell tell sign of a hack?
Is there something I am missing?
(Don‘t get me wrong, in the right circumstances I probably would‘ve fallen for it, too)
They usually strike at night while the target is sleeping. When you are asleep you are more likely to just make the damn noise box shut up by hitting allow so it stops alerting you.
This is even more effective if you have a physically separate work device and just finished your oncall rotation.
It can be even more effective if you can trick them into attempting (or believing they are attempting) to log into an MFA system just before you spam the notifications. One approach to do this might be a watering hole attack where you redirect them to a system for which they expect MFA. You know it’s time to start the spam when you send the redirect.
The MFA apps are really bad at telling you what triggered it. I don’t think I could tell a valid notification from an attacker-triggered one in many cases, if it came at a time when I was expecting the notification.
Most of the things I get from MS Authenticator have a number appear on the login prompt and either require me to enter that number or select it from a list to log in. If two requests cross in flight then I’ll enter the wrong number and it will fail.
Thinking about it more, it probably works against a targeted attack, but not so much for phishing. It gives me a two-digit number. I’ve never seen 0, but let’s assume it’s there, so you have a 1 in 100 chance of guessing. If you pick 42 and do the attack on 50 people then there’s a 50% chance that you’ll correctly guess the number that they’re presented with. If you do it with more then you’re pretty much certain to get someone. If this is just the first step to getting onto the network then doing an attack on an entire company’s authorised staff is probably going to get someone.
When I’m asleep, my phone is in do-not-disturb mode and no notifications get through except Signal calls from family (ho are allowed to wake me up if there’s an emergency and know not to wake me up if there isn’t. I’d love it if Signal had a ‘this is an emergency’ button for this so that they could send me non-notifying messages when I’m travelling in a different time zone). The Authenticator app is definitely not on the allow list for this because it should never notify me except when I’m actively using a computer.
A good variant of the attack is to trick the target into attempting to log into something with MFA just before bombarding them with MFA notification spam.
You win the race if they tap “yes” on yours instead of the one they requested. And notification glitches are common enough that no one reports them.
Do I see this right that this sort of attack would not be possible with TOTP? I have TOTP as 2FA mechanism with my AWS account and there is no push notification involved. Don’t see how somebody could spam me into accepting them as a login device for AWS.
Is a push-based 2FA more secure in normal operation or why would I want to use it?
TOTP can be brute forced without the account owner knowing.
Push notifications from a vendor like duo is part of the incident Uber experienced.
For those wishing to keep push notifications, look into “Number matching”, Active Directory + Microsoft Authenticator and Duo have “number matching” where the account owner enters digits on screen into their device. While this solution makes it harder, I think it is still capable of being phished.
I collaborated with cadey on the post they linked next to this comment, consider reading push 2FA considered harmful.
I don’t think the brute-force argument against TOTP is that convincing. If you aren’t counting failed logins and locking accounts after X failures, then it’s a problem with your implementation not the concept as a whole.
I still agree with your conclusions though. TOTP fails because it sucks to use, and webauthn looks to be a better alternative.
If you aren’t counting failed logins and locking accounts after X failures, then it’s a problem with your implementation
I completely agree with this.
But either through ignorance or misconfiguration or no such feature at all, this check may not be performed on some SSO deployments or independent services and that is where it is vulnerable to brute force.
Seems like the easy solution to this sort of attack would be to implement an exponential backoff for 2FA tokens, or give them a “lock until I turn it back on” option. That said, I’ve never considered needing such options before, so…
Exponential backoff might reduce the noise sent to specific individuals, but in practice the attacker will just source more targets. Rate limiting on specific IPs is also somewhat ineffective too. Given that this stage happens after a password is entered and found to be correct, I would recommend that a password reset be issued after some number of attempts. Somewhere between 5 to 10 MFA failures seems reasonable to me.
I suppose. I’m certainly not an expert but it seems like sourcing more targets would get expensive quickly, since you need a known password. But yeah, forcing a password reset after X failed attempts is probably the way to go. I was thinking that locking the account for 24 hours or something might be a decent alternative, since my brain hates things that fail in a disabled state forever, but after thinking about it more that’s exactly what you want here.
Lock enough accounts forever, you’ll need the break glass credentials
This theoretical case may imply the IT team broadly has their credentials compromised if they have to reach for break the glass credentials instead of resolving it for one another. I would not trust their hardware to safely interact with it at that stage, it smells like a keylogger.
An MFA failure is surely a highly unusual event. Why would you ever reject one unless you requested one?
I’d give it 2 attempts max! Especially if it isn’t TOTP, so there are no typos.
Yubikey failures happen quite frequently for me actually — the first time I authenticate with a yubikey usually fails via NFC or on windows, and it’s always only the second or third time that works.
Purrly because the connection fails or Windows’ auth stuff breaks.
On Linux it’s more reliable, but it’s still an issue.
For reference, I’ve usually got several yubikeys enrolled and/or connected, which some systems apparently don’t like all that much?
You clearly haven’t met my users.
Or just an off button in the client (MS Authenticator has one already). You should only ever get a notification in response to something that you’ve done, so if you get them at other times then you’re either under attack or there’s a bug. Either way, you can turn them off until you try to do a thing that should trigger one (and notify your support folks in the interim).
Very well written article, thank you.
I don‘t quite get how you can harass someone with MFA push notifications. The user can always simply silence their phone or turn off notification for that app to get rid of the harassment. Also in what scenario would getting this amount of MFA notification be normal and not a tell tell sign of a hack?
Is there something I am missing?
(Don‘t get me wrong, in the right circumstances I probably would‘ve fallen for it, too)
They usually strike at night while the target is sleeping. When you are asleep you are more likely to just make the damn noise box shut up by hitting allow so it stops alerting you.
This is even more effective if you have a physically separate work device and just finished your oncall rotation.
It can be even more effective if you can trick them into attempting (or believing they are attempting) to log into an MFA system just before you spam the notifications. One approach to do this might be a watering hole attack where you redirect them to a system for which they expect MFA. You know it’s time to start the spam when you send the redirect.
The MFA apps are really bad at telling you what triggered it. I don’t think I could tell a valid notification from an attacker-triggered one in many cases, if it came at a time when I was expecting the notification.
Most of the things I get from MS Authenticator have a number appear on the login prompt and either require me to enter that number or select it from a list to log in. If two requests cross in flight then I’ll enter the wrong number and it will fail.
Yes. That raises the bar meaningfully over some others that essentially say “Login from (browser/OS) in (city). Is that you?”.
Thinking about it more, it probably works against a targeted attack, but not so much for phishing. It gives me a two-digit number. I’ve never seen 0, but let’s assume it’s there, so you have a 1 in 100 chance of guessing. If you pick 42 and do the attack on 50 people then there’s a 50% chance that you’ll correctly guess the number that they’re presented with. If you do it with more then you’re pretty much certain to get someone. If this is just the first step to getting onto the network then doing an attack on an entire company’s authorised staff is probably going to get someone.
When I’m asleep, my phone is in do-not-disturb mode and no notifications get through except Signal calls from family (ho are allowed to wake me up if there’s an emergency and know not to wake me up if there isn’t. I’d love it if Signal had a ‘this is an emergency’ button for this so that they could send me non-notifying messages when I’m travelling in a different time zone). The Authenticator app is definitely not on the allow list for this because it should never notify me except when I’m actively using a computer.
A good variant of the attack is to trick the target into attempting to log into something with MFA just before bombarding them with MFA notification spam.
You win the race if they tap “yes” on yours instead of the one they requested. And notification glitches are common enough that no one reports them.
During the day when you expect notifications that mean something, lots of notifications that don’t mean anything will harass you.
Do I see this right that this sort of attack would not be possible with TOTP? I have TOTP as 2FA mechanism with my AWS account and there is no push notification involved. Don’t see how somebody could spam me into accepting them as a login device for AWS.
Is a push-based 2FA more secure in normal operation or why would I want to use it?
I have a lot of thoughts about this, but see here for them because I don’t want to type them all out again.
TOTP can be brute forced without the account owner knowing.
Push notifications from a vendor like duo is part of the incident Uber experienced.
For those wishing to keep push notifications, look into “Number matching”, Active Directory + Microsoft Authenticator and Duo have “number matching” where the account owner enters digits on screen into their device. While this solution makes it harder, I think it is still capable of being phished.
I collaborated with cadey on the post they linked next to this comment, consider reading push 2FA considered harmful.
I don’t think the brute-force argument against TOTP is that convincing. If you aren’t counting failed logins and locking accounts after X failures, then it’s a problem with your implementation not the concept as a whole.
I still agree with your conclusions though. TOTP fails because it sucks to use, and webauthn looks to be a better alternative.
I completely agree with this. But either through ignorance or misconfiguration or no such feature at all, this check may not be performed on some SSO deployments or independent services and that is where it is vulnerable to brute force.