A recent question that I’ve seen in light of this DarkReading article is, “Has Microsoft’s MFA been hacked?” The answer is “no,” but the overall story requires a bit more explanation. Let’s dive in.
First things first, what is AzureMFA? For organizations using Microsoft 365 services, one option available
is the use of Multi-Factor Authentication (MFA) to better secure the applications and data stored within those systems. AzureMFA, as it is named, is also available to people and companies using other Microsoft services – and even non-Microsoft services – so it is a popular security tool. When a user logs into an application or website using AzureMFA, they will provide their username and password, but also have to provide another identity token before the login is successful. This token can be obtained in several different forms, but the two most common are the Microsoft Authenticator app on a mobile device, or a six-digit One-Time Passcode (OTP) sent via text message. The Authenticator app can provide OTP’s as well, but opens up more options such as “tap-to-authorize” or requiring a user to match a number on the computer screen to one of several numbers displayed in the app.
The issue that the researchers from the DarkReading article uncovered applies to OTP’s sent via text message, but could also apply to OTP’s received via the Authenticator App as well. OTP’s are created through a complex mathematical formula that sends multiple variables – like the exact time of the login request and the unique identifier of the user device – through the equation. That generates a six-digit code which will (at least to any human being watching) be different for every login by every user. The problem is that the formula itself doesn’t change, just the variables that are fed into the front end of the equation. There are also a finite number of six-digit combinations, one million to be exact. This lead to the vulnerability the researchers discovered.
So, what happened? By flooding a login request with hundreds of thousands of attempts very quickly, the researchers were able to work out a pattern in the OTP’s that were being created for that user. Eventually, they were able to take things one step beyond that, and anticipate what the next OTP would be. After successfully “guessing” the OTP that would have to be entered on the next login, they realized that this flaw could allow a determined threat actor to bypass the MFA check and gain access to an application with just the username and password of the user – something considered to be extremely insecure these days.
While this is concerning, keep in mind that this only works if other security controls are not in place for that login process. Most organizations will limit login attempts to a specific number – usually somewhere in the dozens to hundreds – before temporarily locking the user account. These aren’t unsuccessful logins which would lock the user out within five or ten tries, but rather just repeated attempts that never finish, so a higher number is permitted. Others will forcefully slow down the ability of the person logging in to make another attempt after several tries, which could still allow this attack to happen but would make it cumbersome for the attacker. Of course, training users to avoid having their passwords stolen is also effective here, as the fewer valid credentials an attacker has, the fewer accounts they can try this with.
MFA solutions – including AzureMFA – also have multiple methods to avoid using OTP’s entirely. The most popular current technique is to match a number or character on the screen with a number or character displayed in the authenticator app alongside other, wrong, numbers/characters. You may see a number like “81” on the screen, and have between three and nine numbers to choose from – only one of which is “81” – in the app. Tap the matching number, and you pass the MFA challenge. Additional options are tap-to-auth which just requires the user to tap a confirmation message on their phone (not recommended), and physical tokens such as the very popular Yubikey devices (solid and secure, but more cumbersome for users).
This vulnerability is something organizations will need to guard against until Microsoft closes the ability to overwhelm the system with authentication requests, which they will probably do within a couple of days. If the organization is already using a matching system or physical token, and is not allowing the use of OTP’s, then there is less of a concern here. Restricting login attempts (not just failed logins)can also solve the problem if OTP’s are necessary for whatever reason. While it won’t eliminate the issue, enforcing longer and longer delays after each login attempt (successful or not) can also help to avoid the issue since the amount of time required to perform the attack will be longer than the attacker wants to wait. A real user will log in within a few attempts, and the initial delays are only a few seconds – but after a hundred attempts the attacker would have to wait minutes, and after a thousand they’d have to wait hours. An extremely determined threat actor might deal with that, but any others would give up quickly.
In short, there are options here that are not only available with AzureMFA, but can even make things easier on end users. Matching systems only require a tap, and are therefore easier for most users than copying six digits from one device to another. Though this is a concerning development in MFA security, its impact will be temporary (Microsoft will create a fix), will not require the organization to do anything on their end of things, and can be avoided entirely by restricting OTP use in favor of other – usually better – options.