With Multi-Factored Authentication, Does Login Sequence Matter?
Yes, yes it does.
Let’s suppose an internet-facing system has multi-factor authentication (MFA) setup to prompt for the user’s password first. Let’s also assume this is an enterprise system and the passwords are from a centralized single-sign-on repository (e.g. Active Directory). Is this a problem?
Short answer: yes.
“But how can the attackers learn the password?”
All systems are a little different, but there are usually several different ways to enumerate this. If the UI (user interface) presents a new login form to collect the secondary credentials, then there is a signal being sent to the UI to indicate the first step was completed successfully (usually). That signal can come in the form of an HTTP status code from a RESTful service, or perhaps a redirect to the second login form, but it will be there.
“But what if my system always asks for both at the same time?”
Well, most don’t for UX (user experience) reasons. Even if they did, it’s typically helpful to the human to indicate which credential failed to help them troubleshoot. Even if the system does NOT do that and has a generic “access denied” message, it’s often possible to tell from timing attacks — which are very difficult to prevent. For example, the code path to check the AD password may be longer if the user account does not exist than if it does, OR, the code path for verifying the AD password may be faster than the stronger MFA prompt.
If you’re interested in timing attacks, you can learn this concept in more depth from an older article series I wrote attacking credit card tokenization services. The concepts are the same. (https://medium.com/@malcomvetter/breaking-credit-card-tokenization-d8fa770625c6). Or watch the video of my ShowMeCon (https://www.youtube.com/watch?v=3ZnIa6GNWaQ) or DerbyCon talks on the same subject (https://www.youtube.com/watch?v=17UcQohAjXw).
I can hear your thoughts:
“But, but … this portal is MFA and requires the [insert really cool and hard to defeat secondary authentication mechanism here] as the second step!”
That’s fine. That just means that portal won’t be abused for complete access, but there are more reasons this configuration with password first is advantageous to the attacker. Here are three reasons (maybe you can come up with more):
Credential Harvesting for a MFA Phish
It’s possible the attacker is planning on a multi-stage attack, where the first stage is to spray for as many passwords as possible, and then follow-up with spear-phishes or call the victims using the knowledge of the password credentials to elicit the stronger authentication credential, e.g. one time passwords (OTP). Of all the possible explanations, this is actually is the best one you can hope for, because it means your attacker is playing checkers, not chess, and not really thinking but one move ahead (at most).
Lateral movement via External Password Spray
Maybe the attacker doesn’t even care about the access the portal provides. Maybe the attacker only wants a way to verify credentials. They may very well already have internal access via some other means (e.g. phishing), but they need additional access from certain users in order to move towards their objective. A password spray against the MFA portal exposing AD passwords first can provide that angle. As the attacker verifies the first step (the AD password), the attacker gains credentials that can be used for an internal resource via their primary internal access method. This is a form of lateral movement, but to the defender who only has the perspective of the half-failed login attempts on the portal, this looks like an external attack that isn’t successful. It can be challenging to coordinate those half-failed login attempts with additional internal access movements.
Confusion as a Diversion
This is a worst case compared to the first two. Perhaps your attacker is playing chess with you, thinking several moves ahead, while you are only playing checkers. Your attacker may have internal access and may be planning on conducting a sneaky, but bold move. Your attacker may need cover fire, just like a military element moving in on a target. Maybe your attacker needs a noisy and distracting diversion. What better way than an externally facing MFA application with the password authentication first in the sequence? Spray the credentials, get some hits, some misses, and an alert defender must answer these questions:
· Was this a mistake or intentional?
· If this is intentional, then what is the attacker’s motivation for this attack? Clearly, they don’t have the stronger second factor. Or do they? (Now go double check all valid logins for each affected user.)
· Are they spraying here and logging in quietly someplace else with only a single factor? What other location could this single factor authentication be used for internal access? Is your asset inventory wrong? Did you miss something?
· How much time should we devote to rotating any successfully harvested passwords versus hunting for other anomalous behavior that might be related?
All of these questions take time and energy away from the defender. They present a tangible COST to the defender, which presents an advantage to the attacker.
Solution
The easiest solution is to always default to the strongest form of authentication first, where “strongest” means the form of authentication that is least likely to be acquired by the attacker.
The harder solution is to always present the exact same interface, experience, and timing, right down to each individual cookie, HTTP header, HTTP status code, CSS class, etc. You probably won’t get that right. So take the easy button.
