A few days ago, our team helped someone who had been a target of account takeover (ATO). Despite protecting the account with mandatory two-step verification using SMS and the Authenticator app, attackers had broken into the account and changed the password.
MFA had failed.
In my last blog I explained how your pa$$word doesn’t matter - but multi-factor authentication (MFA) does! Several folks commented that “MFA isn’t a panacea.” That’s true in targeted attacks when attackers are willing to invest enough to break MFA, and there’s no easier way.
Let’s not get crazy - Multi-factor Authentication (MFA) is the least you can do if you are at all serious about protecting your accounts. Use of anything beyond the password significantly increases the costs for attackers, which is why the rate of compromise of accounts using any type of MFA is less than 0.1% of the general population.
Compared to password attacks, attacks which target non-password authenticators are extremely rare. When we evaluate all the tokens issued with MFA claims, we see that less than 10% of users use MFA per month in our enterprise accounts (and that includes on premises and third party MFA). Until MFA is more broadly adopted, there is little reason for attackers to evolve. But MFA attacks do exist, and in this blog we’ll confront them.
The target initially used their Authenticator app to recover their password. Then the attackers changed the password again and removed the app from the account.
This was a specific and targeted attack with direct human involvement.
All Authenticators Are Vulnerable
There is a broad range of mechanisms to break authenticators, from simple guessing to coercion. That doesn’t make all authenticators equally vulnerable. Costs vary massively by attack type, and attacks which preserve anonymity and don’t require proximity to the target are much easier to achieve.
Unfortunately, virtually all authenticators in common use today – phones, email, one-time passcode (OTP) tokens, and push notifications – are vulnerable to relatively low-cost attacks involving takeover of the communication channel used for the authenticator (Channel-Jacking) or intercept-and-replay of authentication messages using a machine-in-the-middle (Real-Time Phishing). Unfortunately, both have been in the news lately in some high-profile attacks (as well as in our caseloads). MFA bypass attacks are so rare that we don’t have good statistics on them – but when they do happen, they devolve to one of those two cases.
Here’s a list of common credential types with an assessment of vulnerabilities (excluding coercion, which is possible with all factors). If I learned anything from the last blog, several of you will share more ideas .
Credential |
RealTime Phishable |
Channel-jackable |
Other ways to break credential |
Passwords are user-selected secrets which are entered at a login screen and then compared with a representation of the password stored on the server. |
Y |
Y |
See my last blog. |
Personal Identification Numbers (PINs) are simpler user-selected secrets used like passwords, typically four to eight characters. Like biometrics, they are best reserved for local credential access. |
Y |
Y |
As passwords, but easier to guess, with more re-use and (usually) poorer storage hygiene. |
Simple approvals (only) verify the channel or device is in the user’s possession. An app may pop a simple “approve/deny” request, or a phone call may say “Press 1 to approve.” Useful in cases where legacy authenticator protocols prevent a more sophisticated interaction. |
Y |
Y |
“Grief” the user by sending multiple requests in hopes the user will approve one. |
Steal the device which indicates approval. |
|||
Server transmitted one-time passcodes (OTP) are codes transmitted to the user for entry in the login screen. They indicate control of the communications channel or target device. The login server sends a code to the user, and the user enters the code to prove they are in control of the channel or device. |
Y |
Y |
Steal the device which receives the OTP. |
Time based one-time-passcodes (TOTP) on OATH hardware tokens use a shared secret between the token and the login server and the current time to generate a code on the token. The secret is built into the hardware token. It must be registered with the server and stored in a recoverable (plaintext or encrypted) form. This can be done out of band by admins, or by the user converting the token ID to a secret via a brokering service. At login, the generated code is entered by the user in the login server UX, which validates it using the stored secret. The code is usually available to anyone in possession of the physical token. There are OATH-derivatives that modify the registration process, but they don’t significantly change the security model. |
Y |
N |
Stealing or accessing the device long enough to read the code to achieve login |
Intercepting the secret at the time of registration using a person-in-the-middle. |
|||
Stealing the database in which the secrets are stored. A high cost attack, but one which yields all OATH tokens for the login server. |
|||
OATH software TOTP tokens only differ from OATH hardware because the secret can be delivered by the software token to the server. The registration may be more vulnerable than for hardware tokens because the secret is transmitted directly. The actual secret is sometimes brokered in OATH derivative tokens like RSA or Symantec Tokens. Apps that host software OATH tokens such as Microsoft Authenticator and Google Authenticator may protect the codes with a device unlock gesture like a fingerprint, face scan, or PIN. |
Y |
N* |
*Unless OS state backup is enabled for secrets. |
Stealing the device (may not be as fruitful if an unlock gesture is required) |
|||
Attackers may be able to intercept secrets at registration with malware on the device |
|||
Authentication applications like the Microsoft Authenticator use an app which is registered on a device. Like Smartcards and Windows Hello, the registration procedure is secure and registers a public key (no secret stored).
|
Y |
N* |
*Unless OS state backup is enabled for keys. |
Grief the user, unless the app requires the user to know something present on the screen to log-in. |
|||
Takeover the OS account, and recover OS backed up app data if backup/restore is available and enabled for the app. |
|||
Smartcards use a secure registration procedure to exchange keys at registration. The server remembers a public key (no secret stored) which can be used to validate the fact that it is seeing the same token that was registered. In some cards, both registration and use are bound to the hardware that the login is being attempted from, making them unphishable. |
N |
N |
“Shoulder surf” the PIN and steal the card. |
Windows Hello uses a secure registration procedure to exchange keys at registration. The server remembers a public key (no secret stored) which can be used to validate the fact that it is seeing the same token that was registered. Importantly, both registration and use are bound to the hardware that the login is being attempted from. |
N |
N |
“Shoulder surf” the PIN and steal the PC (hard if bio enabled). |
FIDO tokens use a secure registration procedure to exchange keys at registration. The server remembers a public key (not a secret) which can be used to validate the fact that it is seeing the same token that was registered. Importantly, both registration and use are bound to the hardware that the login is being attempted from. See Pamela Dingle’s blogs to learn more. |
N |
N |
“Shoulder surf” the PIN and steal the token (hard if bio enabled). |
Note: I am not covering server registered biometrics here as I consider it an anti-pattern (once a database of your fingerprint is breached, it invalidates use of your fingerprint on any other server), and reserve them for device unlock gestures (such as Windows Hello and the IOS and Android equivalents). I will blog on this issue separately.
Given low cost to attack, Channel Jacking and Real-time Phishing are the dominant ways we see non-password authenticators compromised.
Channel-Jacking
Many authenticators rely on a communications channel to function. For example, when you get a code on your phone to type into the login screen, your phone – with all the associated mobile operators, infrastructure, customer support, and SIM infrastructure - is the channel. Often, an attacker can take over the channel as the simplest mechanism.
The most common channels in our consumer account system are emails (55%), text messages (44%), push notifications (4%) and voice calls (1%). Each of these mechanisms has the potential for Channel-Jacking. Each is backed by a provider account (email provider, phone company, or operating system vendor) which is vulnerable to password attacks, social engineering or bribery of support staff to greater or lesser degrees.
Mobile phones add a raft of additional radio communication and protocol vulnerabilities – an attacker can deploy a software-defined-radio to intercept messages, or a nearby FEMTO, or use an SS7 intercept service to eavesdrop on the phone traffic.
Removing the authenticator must have required another factor, so we asked the target to check their cell phone. Within a few minutes they confirmed that the SIM wasn’t working.
The mobile operator’s customer support team had been tricked into porting the target’s SIM to an attacker-controlled phone.
Again, such attacks are extremely rare when compared to password only attacks, and even SMS based authentication prevents the vast majority of even targeted attacks . But beware of a channel that can be eavesdropped, phished, socialed, bribed or password-guessed out from under you. If you use email or mobile phone number for your recovery mechanism on other accounts, harden them as much as you can – most mobile operators, for example, offer opt-in additional security like PIN codes or OATH authenticator support, and you can use non-password authenticators on your email-based recovery account.
The chain of trust breaks at its weakest link – this is often the communications channel. Compare your cell phone, with its support and protocol vulnerabilities allowing intercept of unencrypted traffic to something like FIDO, where OS level malware is required to even snoop on the encrypted traffic in the exchange. At this latter level of security, the authenticator is functionally channel independent – and that’s what it takes to beat Channel-Jacking.
Real-time Phishing
As smart admins are requiring their users to use MFA, some phishing has advanced to fully replay the requests from the site it is impersonating. Tools like Modlishka are making it easy. This is sometimes called “real-time phishing,” and relies on bringing the user to an attacker controlled “machine in the middle” (MitM). Our mail systems are detecting a huge increase in phishing mails, though we can’t say how many of these are leveraging Real-Time Phishing.
Visually, I think of the MitM as Janus, the Roman god of transitions. Janus is a two-faced god; in this analogy, one face emulates the client to the login server, and the other the login server to the client. Our MitM simply repeats whatever it hears from either party to the other.
With tools like Modlishka, the MitM can repeat everything it hears from one party to the other. Once lured to the site, the client’s only hope of defeating the attack lies in recognizing that the login server is a fake – something humans are notoriously bad at , even when the browser warns them they are dealing with a fake site.
The target’s password had already been compromised, probably via Phish, Spray, or Stuffing.
So when the attacker channel-jacked their phone, it was game-over.
Beating real-time phishing requires that the authentication process enforces what the National Institute of Standards and Technology (NIST) 800-63-3 calls “Verifier Impersonation Resistance” (the “Verifier” is the login server). This means the authenticator must cryptographically verify that the login server is who it claims to be. The client somehow needs to verify a signature from or encrypt a message for the login server using its validated public key. Client authenticated TLS is one way to do this, but ultimately, the authenticator itself needs to verify that the server is who it claims to be – because humans just aren’t good at it.
NIST goes so far as to say: “Authenticators that involve the manual entry of an authenticator output, such as out-of-band and OTP authenticators, SHALL NOT be considered verifier impersonation-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated. In an MitM attack, an impostor verifier could replay the OTP authenticator output to the verifier and successfully authenticate.”
Put simply, ANY authenticator which doesn’t cryptographically verify that the login server is who it says it is can be phished.
We immediately locked the target’s account, and because we had definite proof of identity, we were able to restore the account with new, valid authenticators.
Hope on the Horizon?
In recognition of the fundamental vulnerability of human users to trickery in social and phishing attacks, channel independent, verifier impersonation resistant authenticator types have emerged. Chief among these are Smartcards, Windows Hello, and FIDO. From a security perspective, these credentials are incredibly hard to crack, though they do offer issuance and recovery challenges I will explore later.
Ultimately, our target’s accounts were restored. The mobile operator account was hardened with a PIN, and the Microsoft account SMS number was replaced with a FIDO token.
Given an overall strong authentication rate of only about 10%, doing any form of MFA takes you out of reach of most attacks. MFA (using any mechanism) is just too costly to break - unless a highly motivated attacker is after that high value account or asset. That’s where verifier impersonation resistant authenticators come in. These “phish proof” authenticators are resistant to everything but coercion – and for all but the most determined and well-funded attackers, coercion – with all its associated risks and costs – is too high a price to pay, and pushes even motivated attackers (at long last) away from credential attacks.
You should definitely turn on MFA now – and anything is >99.9% better than nothing. If you are using a phone as second factor, harden that account. Better yet, use the Microsoft Authenticator as the mechanism is channel independent, has great usability, and is free to deploy (we are working on verifier impersonation resistance now). And start building a long-term authenticator strategy which hinges on channel independent, verifier impersonation resistant authenticators like Windows Hello and FIDO.
Stay safe out there,
Alex