2FA Bypass - IDN Mischief

Summary

Internationalized Domain Name (IDN) Homograph Attacks involve exploiting similarities between visually identical characters from different writing systems (e.g., Latin ‘a’ and Cyrillic ‘á’). In the context of Two-Factor Authentication (2FA), this vulnerability can occur when an application incorrectly normalizes or fails to distinguish between similar-looking characters in email addresses or usernames.

Description

I found a vulnerability where the website was using 2FA which can be bypassed using IDN homograph attack. I created two accounts on the website using normal and look-a-like emails (for e.g. [email protected] and emailOne@gmáil.com) and setup second factor authentication on both the accounts. Then I logged into 1st account ([email protected]) and used the 2FA code of a look-a-like email account (emailOne@gmáil.com) and I was logged in successfully. Then I also checked the reverse way where I logged in as look-a-like email (emailOne@gmáil.com) and used the 2FA code of the 1st email ([email protected]) and I was logged into the account. So the attack was possible both the ways but as an attacker’s perspective I used look-a-like email to bypass the 2FA of the 1st email.

Anatomy of 2FA bypass with IDN

1. Account Creation

   • Two accounts are created with email addresses [email protected] and user1@gmáil.com
   • The system stores both accounts as separate entities without normalization

2. 2FA Setup

   • Each account sets up 2FA and receives a unique secret key
   • The secret keys are stored against the respective normalized email addresses

3. Normalization Issue

   • During 2FA validation, the email addresses are normalized (e.g., converting user1@gmáil.com to [email protected])

4. 2FA Validation

   • The system retrieves the secret key for the normalized email, leading to the same secret key being used for both accounts
   • This allows the 2FA code generated for user1@gmáil.com to validate against the account of [email protected] and vice versa

What is Normalization ?

Normalization in this context refers to the process of converting different forms of a string (such as email addresses) into a standardized or canonical format before processing. This is often done to ensure consistency in handling user inputs, especially when dealing with characters that will look similar but are technically different, such as those found in Internationalized Domain Names (IDN) or Unicode characters.

How Normalization Occurs in the Scenario

1. Input Email Address

   • The user registers or logs in using an email address such as user1@gmáil.com or [email protected]

2. Normalization Process

   • During the 2FA setup or validation process, the system automatically normalize the email address
   • This could involve converting Unicode characters to their closest ASCII equivalents, such as converting á to a. For example, user1@gmáil.com can be normalized to [email protected]

3. Result of Normalization

   • After normalization, user1@gmáil.com and [email protected] can be treated as the same string: [email protected]
   • This means that any process relying on this normalized string (such as generating or validating 2FA codes) would incorrectly treat these distinct email addresses as the same account

Prerequisites

• An attacker should know the password of the victim for initial access.

How I found this vulnerability ?

1. I registered two accounts on the website with 2 emails, normal ([email protected]) and look-a-like (emailOne@gmáil.com)

2. I setup and enabled 2FA on both the accounts

3. Then from another browser I logged into to the normal account ([email protected])

4. Now from the authenticator app I used the 2FA code of the look-a-like email (emailOne@gmáil.com) and website allowed me to logged into the application

Why this happened ?

In my opinion,

It happened primarily due to the improper handling of email addresses during the 2FA process, specifically the normalization of email addresses that involve characters from different writing systems, such as IDN homographs. The system incorrectly normalized the email addresses, treating distinct emails with similar characters (such as á and a) as identical which led to the same 2FA seed being used for both accounts, causing the 2FA codes to be interchangeable.

Impact

1. Shared 2FA Seed - If the system uses the normalized email to generate or retrieve the 2FA seed, both [email protected] and user1@gmáil.com will share the same 2FA seed, leading to the same 2FA codes being generated.

2. Cross-Account Validation - When validating the 2FA code, the system will incorrectly validate a code meant for one account (e.g., user1@gmáil.com) as valid for another account (e.g., [email protected]) due to the normalization process.

Calculated CVSS

Vector String - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L

Score - 4.8 Medium

Mitigation

It is recommended to implement the below fixes to mitigate this kind of issues

1. Avoid Email Normalization During Validation

Do not normalize the email address when validating the 2FA code. Use the email address as it is.

2. Use Unique Identifiers

Utilize unique user identifiers, such as a user ID, to retrieve the 2FA secret key, ensuring that the correct key is used for each user.