In this post we discuss how an account with two-factor authentication could be bypassed if the password were breached.
How two-factor authentication protects your account
The goal of authentication for any given service is to verify that the user accessing the service is who they claim to be and not an impersonation. This is done by prompting the user to answer questions.
- Something they know. This is usually the user’s password or a PIN.
- Something they are. This is a user’s biometric data such as fingerprints, face ID, iris scan, or handwriting.
- Something they have. This is where modern two-factor authentication (2FA) applications come into play. The app will generate a secure random token (usually a 6-digit numeric code) that expires after a set amount of time. It could also be a physical smart card, a USB-based key, or a SMS based one-time passcode (OTP).
- Any two answers supplied by the user are used to verify the authenticity of the user, which constitutes two-factor authentication. Two-factor authentication is designed to provide security if a user password is leaked or compromised. It also serves as an extra layer of protection—or in security terms, defense in depth.
Two-factor authentication at work
Before diving into how 2FA could be bypassed, let’s see a high-level flow of 2FA in action.
Let’s consider a scenario where James is the administrator of a web application called MyWorkApp. Alice is an employee who uses MyWorkApp.
- James configures the 2FA service and enables it for the users.
- Alice logs into the application for the first time after 2FA is enabled. For this, Alice uses her user name and password.
- The application displays a QR code and a text box directing Alice to scan the QR code using her phone and enter the generated number. Let’s call this step SETUP. The URL associated with this step is https://myworkapp.com/2fa/setup.
- Alice scans the QR code in her phone’s authenticator app and enters the generated number.
- MyWorkApp gives Alice some backup codes for emergency purposes.
- The next time Alice enters her user name and password she is prompted for the generated code without the QR code being displayed. Let’s call this step VERIFY. The URL associated with this step is https://myworkapp.com/2fa/verify.
- Alice enters the code from her authenticator app, and she is logged in.
Figure 1: Normal application flow
Now that we have walked through the flow, let’s meet our attacker, Bob, who acquired Alice’s password via social engineering or other means. Bob does not have the 2FA codes that are generated in Alice’s phone, and without them, Bob should not be able to take over Alice’s account.
MyWorkApp, however, has a misconfiguration that allows more than one device to be configured for 2FA purposes. This means Alice can have 2FA set up with the same code generator running on two or more phones/devices. Bob uses this information to exploit the application in the following manner:
- Bob navigates to the login page and enters Alice’s user name and stolen password.
- Bob receives the response to this request with a URL that indicates location redirect to the VERIFY step i.e. https://myworkapp.com/2fa/verify.
- Bob intercepts this response and modifies the URL to the SETUP step. https://myworkapp.com/2fa/setup.
- The application server receives this request and prompts Bob with the QR code for 2FA setup.
- Bob scans the QR code obtained in an application in his phone.
- Now he has the 2FA code generator and can successfully use it to take over Alice’s account.
Figure 2: Attacker gains access to user’s OTP
How the attack happened
Bob was able to gain control over the Alice’s OTP generator because
- The generator allows more than one device to be registered for confirming OTP.
- The application server depends on client-side code to generate the next destination URL post login.
- The application accepts request to /2fa/setup without validating whether the user has previously registered a 2FA device.
The 2FA is likely to present the same QR code because it is coupled with the same user.
Improve your two-factor authentication
A secure implementation of a 2FA setup should check for a user’s authenticity before initiating a critical response such as the QR code for generating the tokens. A user setting up 2FA for the first time should receive backup codes that can be used alternatively to the generated tokens. These codes will serve as a backup if the user loses access to the device used to generate the tokens. If the application detects a valid backup code, it could prompt the user to disable the previously set device and enroll a new one. The application should also send a notification to the user when an unrecognized login occurs. Any user actions that change the state of the system or the user profile must be controlled and validated on the server side.
Stay on top of the latest in application security
*** This is a Security Bloggers Network syndicated blog from Application Security Blog authored by Chaitanya Purandare. Read the original post at: https://www.synopsys.com/blogs/software-security/two-factor-authentication-misconfiguration-bypass/