Defeating MFA “Number Challenges” through Phishing

Push verifications with an extra “number challenge” step have become a popular multi-factor authentication strategy. But, does this extra step actually offer any added protection against hackers?

Push verifications are a preferred multi-factor authentication choice for many organizations. They offer convenience and greater security when compared to other factor types such as TOTP or SMS-based codes. Notably, push verifications provide a way for an application to ask a user “hey, is this really you?” which can be useful for thwarting unauthorized sign-in attempts.

Comparison of different factor types, as rated by Okta.

However, the efficacy of push verifications as a second factor can diminish as people are prone to “push fatigue“. Push fatigue is a phenomenon where people become conditioned to accepting push verifications without scrutiny. For example, if a user becomes used to accepting several legitimate re-verifications per day, they may not think twice before approving a sign-in attempt by an attacker. Attacks in the wild have also involved threat actors spamming target users with many push notifications, with the hope that the user will accept at least one to make the notifications stop.

In response to this, some SSO providers such as Okta and Microsoft have started offering an additional layer of verification called a “number challenge”. When this feature is enabled, any user that accepts a push verification must also provide a challenge number displayed on their sign-in screen to prove that it’s really them trying to sign in. If an attacker tries to sign in, the target user will not have access to this number – effectively, preventing them from inadvertently allowing the attacker to proceed.

While number challenges can reduce the risk of unsolicited pushes being accepted, their usefulness becomes more debatable in interactive social engineering attacks such as phishing. If an attacker has a line of communication with the user during the authentication process, they can still coerce the user into allowing the sign-in. The ServiceNow Red Team demonstrated this in a recent campaign, where we developed a phishing site that used a technique to “man-in-the-middle” challenge numbers and manipulate users into approving our sign-in attempts.

How number challenges work, and where they fail

For an application with push verifications and number challenges enabled, a normal sign-in flow may proceed as follows:

  1. The user browses to the application sign-in page on their computer and submits their credentials.
  2. The application sends a push verification to the user’s verification app.
  3. The user accepts the push, and is prompted for the challenge number.
  4. The application shows the challenge number to the user on the sign-in page.
  5. The user provides the challenge number in the app, and the sign-in succeeds.

If an attacker signs in with a user’s credentials, they will be effectively blocked at step 3 because the user will not be able to provide the challenge number.

In an interactive attack such as phishing, the attacker can immediately use the credentials to initiate a push and obtain a challenge number. Then, the phishing site can be used to relay the challenge number to the user. More specifically, the entire attack may look like:

  1. The user browses to the phishing page on their computer and submits their credentials. The attacker then browses to the real application sign-in page and submits the stolen credentials.
  2. The application sends a push verification to the user’s verification app.
  3. The user accepts the push, and is prompted for the challenge number.
  4. The application shows the challenge number on the attacker’s sign-in screen. The attacker then shows the challenge number to the user on the phishing page.
  5. The user provides the challenge number in the app, and the attacker’s sign-in succeeds.

A key detail of this attack is that when the user initially submits their credentials, the phishing page will not immediately respond. The page will appear as if it is “loading” until the attacker provides the legitimate challenge number to the user.

In our attack, we developed a back-end to our phishing page that allowed us to serve the challenge number to waiting users, then redirect them to a legitimate location once they allowed our sign-in.

Attacker view: Sending the verification code to the user.

Victim view: The verification code is provided to the user, who can then approve the sign-in.

The state of things

The common flaw in many second factor types is that they are not phishing resistant: that is, users can still be manipulated into using their factor in a scenario where an attacker is controlling things. According to the Cybersecurity & Infrastructure Security Agency (CISA), “The only widely available phishing-resistant authentication is FIDO/WebAuthn authentication.” (“Implementing Phishing-Resistant MFA”, Oct. 2022).

WebAuthn achieves phishing resistance through a mix of physical hardware (such as a security token or even a Mac’s built-in fingerprint reader) and the concept of attestation. Attestation allows both the user and the application to guarantee the authenticity of each other. This prevents users from accidentally authenticating to a fraudulent application, while also preventing attackers from authenticating on the user’s behalf.

How WebAuthn works (Source: Trscavo at English Wikipedia, CC BY-SA 4.0 via Wikimedia Commons)

Any second factor is better than none at all, and push verifications with challenge numbers are still unquestionably better than merely one-time codes. However, the adage of “humans are the weakest link in cybersecurity” rings true. It is important to have controls that prevent or detect when people make mistakes, and modern factors like WebAuthn can help to prevent mistakes.