MFA Implementation Attacks

Most Multi-Factor-Authentication (MFA) implementations do not protect your password from brute forcing or from account level DoS attacks. This article will demonstrate various attacks that exploit weaknesses found in nearly every industry Identity and Access Management (IAM) provider/solution as well as offer solutions on how to mitigate.

Note: This article builds on the previously released https://penconsultants.com/blog/tips-tricks/mfa-without-the-fud/

Remember the days when MFA protected authentication was a single step process? Your username, password, and MFA OTP were all provided on the same page, you would click Login, and either gain access or receive a generic “Login failed”.

You may still be using a system like this, but it is becoming less common. How times have changed.

Now, it is common for users to be prompted for their username and password only before clicking Login. The resultant message or page will either inform the user their credentials are incorrect, or, it will prompt them for their MFA OTP, send a push notification, or maybe require them to make physical contact with a hardware MFA token (ex. YubiKey). More user-friendly, right?

The Security Implications

Since 2014, PEN Consultants has flagged this 2-step authentication process as a finding in our pentest and red team reports (in most cases), and, since 2018, I have been publicly raising awareness of the attacks it enables.

By acknowledging a pass/fail when entering a basic username/password combo, two vulnerabilities are created that allow an attacker to “bypass” MFA protection:

• Account level DoS (Denial of Service)
• Password compromise

Red Team

In our experience, typical MFA implementations are worthless at defending against the attacks shown here. Your mileage may vary.

Example #1 – Account DoS

The account-level DoS attack should be straightforward to understand. The only prerequisites are:

• a reachable authentication service – ex. external VPN, email portal, etc.
• an account lockout policy – X failed logins == account lockout
• username(s) – can typically be obtained in multiple ways (ex. timing attacks, well-known format + LinkedIn, brute forcing, etc.)
• a script/tool – many script kiddie tools can perform this attack (ex. Hydra, Brutus, etc.) in addition to easy-to-develop scripts

The attacker simply beats against the login service using known bad passwords until the account lockout threshold is reached. Once the account locks out, the legitimate user can no longer access their account until the unlock process is run (manually, or timed). Using a multi-threaded process to beat against all of the users’ accounts in parallel, an attacker can very quickly lockout all user accounts.

Insane mode: Using the same multi-threaded tool/script, and using multiple sources/proxies (ex. leased botnet), an attacker can keep the user accounts locked out by operating faster than the victim can unlock them and avoid simple nACL based mitigations that may be tried.

Insane mode++: If the external web service uses the corporate Active Directory (AD) in the back-end for authentication, the attacker can do more than just lockout the web app accounts. In many cases, all internal AD user accounts can be locked out through the external web service from an external, unauthenticated attacker! If following the attack recommendations above, the victim will not be able to stop this attack without disabling the web service. If the web service is supporting remote work operations, the victim will suffer greatly until they implement proper mitigations (see Blue Team section).

Example #2 – Password Compromise and Reuse

The attacker can leverage the 2-step authentication process by exploiting the fact that the first step verifies the user credentials (username + password). Assuming the attacker remains below any account lockout thresholds, or other brute force mitigation measures, the credentials can theoretically be compromised without knowing or having access to the MFA.

For more information on predicting passwords with a great deal of accuracy, see this article: https://penconsultants.com/blog/tips-tricks/forced-password-rotation-incrementing/

Once the password is compromised, the attacker can exploit the fact that many users use the same password across many, or even all, of their other accounts – other work related accounts, email, bank, online marketplaces, entertainment services, etc. Although the victim’s system may mitigate an account-take-over (ATO) because of MFA, the user’s other accounts may not be protected and can be accessed using those same compromised credentials!

There is a good chance the web app developer has taken the stance of, “Users should not be using the same password across all of their accounts” as a defense for their poorly configured web app. Reality is many users do reuse passwords, and there will likely be no significant change in that regard anytime soon.

Example #3 – Brute Force the MFA

Another scenario we come across often is after compromising the user’s credentials (as in Example #2) and making it to the MFA verification step, the MFA check has no brute force protections, even when the first step does. When the attacker finds this weakness, simply brute force the MFA one-time-password (OTP) and gain access to the account!

In many cases, the OTP will be a moving target (ex. changes every 60 seconds). But, when you are brute forcing at wire speed, this only prolongs the inevitable ATO.

Example #4 – Social Engineer the MFA

Instead of brute forcing the MFA OTP (as in Example #3), the attacker can simply ask the user for the OTP through some form of social engineering – phone call, SMS, etc. It is not incredibly difficult to convince a non-technical user to give up this information in practice. And, let us not forget the “user friendly” push notification forms of MFA. There is a good chance the user will hit “authorize” without the attacker even having to ask because the user is conditioned to do so when it pops up.

Blue Team

Every one of the attacks described can be virtually eliminated with one simple change – check the MFA prior to the password, especially if multiple failed login attempts result in an account lockout.

If your users use some form of SMS OTP or push notification MFA, this could introduce another problem – users being bombarded with SMS or push notifications. In this scenario, you would want to verify the password in the back-end first with these important caveats:

• Ensure the response in the UI/API is the same regardless of whether the credentials were valid. You want to ensure the UI/API does not confirm a valid/invalid password directly or through timing differences. Example: prompt for the OTP or display the “sent notification/OTP” for both failed/valid.
• Do not actually send the OTP or push notification to the user unless the password is valid. If it is an attacker, they will assume it is being sent. If it is the legit user, they will receive what is needed.

Whichever direction you go with, you want to ensure you have sufficient monitoring in place to detect any brute force attacks so you can respond accordingly. In addition to an admin receiving these alerts, the app should also send your user a notification. Example:

We’ve detected an usually high number of authentication attempts against your account. If you did not initiate these attempts, please contact XYZ immediately to report this malicious activity.

Hopefully these real-world scenarios will help raise the industry’s concern level and change this common but insecure practice.

If you would like PEN Consultants to evaluate your authentication processes and perform these tests, we would love to speak with you! Contact us today!

Featured image is a derivative work from the following images: Alexander Klink / CC BY (https://creativecommons.org/licenses/by/3.0)