How Attackers Bypass Modern Two-factor Authentication and How to Protect Your Users
In this article we'll have a look at an example of tools and techniques attackers can use to bypass two-factor authentication (2FA) methods, from SMS OTP to encrypted push notifications to a mobile app. The attack method can be very effective against most types of 2FA deployed today, including out of band authentication. We'll also discuss what kind of countermeasures can be implemented by banks to mitigate the risk of such attacks and protect their customers.
Understanding Two-Factor Authentication
2FA refers to an authentication process that includes two factors. By contrast, multifactor authentication involves two or more authentication factors. Authentication factors include either something you have, something you know, or something you are. In the typical 2-step verification process, a user submits their typical login credentials. Afterwards, the web application, mobile app, or tool will send a verification code or security key via text message to the user's phone number. The user will then plug that 2FA code into the login page, and they will then be given access to the user account or complete the account recovery or password reset. Alternatively, these security codes and recovery codes can be delivered through an authenticator app, authentication token, or other authentication system.
Setting Up the Attack
To execute this attack, we'll use a combination of two tools, Muraena and Necrobrowser. Muraena is a reverse proxy that will run our social engineering phishing page. The phishing page will proxy the original page which the victim will interact with. Once the victim has authenticated the session Muraena will hand over the session to Necrobrowser, which allows the attacker to take control of the session or automate the next steps of the attack. Because Muraena acts as a reverse proxy there will be no difference between our malicious site and the original website apart from the URL. Muraena can be configured to use SSL with certificates obtained through for example LetsEncrypt. From the victim point of view the whole experience will seem legitimate as it looks like they're interacting with the genuine page. They will go through the regular authentication process including the 2FA. If the 2FA consists of a regular one-time password delivered through SMS, hardware or software token then the victim will enter it as usual. However even modern methods such as a push notification to a mobile device or scanning of a QR code on the screen will be bypassed by this attack.
- User visits the phishing page, which has SSL enabled.
- The Reverse Proxy(Muraena) fetches the legitimate bank page and serves a copy to the victim.
- The victim attempts to log in to the page and is prompted for two-factor authentication
- After the victim has completed the authentication process, the Reverse Proxy (Muraena) hands off the session to the attacker (Necrobrowser) to take control, cutting off the victim.
In the image below you can see Muraena hosting Google on the domain phish.anti. For the purposes of demonstration, I've set up a local DNS to resolve this to my test machine and also issued certificates using my own CA which is trusted by the browser. However, this is exactly what it would look like from the victim perspective if this was deployed on your own domain using valid certificates.
Protecting Against the Attack
Now that we understand how the attack works, we can identify which steps would be successful in identifying or protecting against this type of attacks.
Dynamic linking provides a good first layer of defense against a variety of attacks. Dynamic linking consists of a two-factor authentication done at the time of transaction, which incorporates the details of the transaction into the signing process. Often called What You See Is What You Sign, because the end-user should be presented with the transaction details before completing the signing process. Once signed, the signature should only be valid for this specific transaction therefore making it harder to bypass for the attacker. Typically dynamic linking is implemented via hardware tokens, software tokens or integrated as part of a banking app. Below we have 2 examples of dynamic linking, first for a legitimate payment and the second where an attacker attempts to modify the payment.
- User creates a transaction in the online banking.
- User submits the transaction.
- Bank sends the transaction details to the mobile phone of the user.
- User verifies the details of the transfer and authorizes the payment with a biometric (Or another second factor).
- The mobile app generates a One Time Password using the transaction details and the token key inside the mobile app.
- User tries to create a payment in the online banking.
- Attacker modifies the payment to have a new beneficiary account and/or amount.
- Bank sends the transaction details to the mobile phone of the user.
- User is presented with the modified payment information and rejects the payment.
The examples above also illustrate the importance of using end-to-end encryption when implementing dynamic linking. Additionally, it shows that the mobile app itself should be protected as the attacker may try to attack the app to hide the modified payment details from the user.
Another effective way to recognize and defend against a large variety of attacks is to implement continuous monitoring onto your digital platforms. By monitoring the session from the moment of initiation until the end of the session, we can bring in more context through the actions of the users and the devices or accounts they associate with. Continuous monitoring combines perfectly with other layers such as 2FA or dynamic linking as it allows the bank to bring in context from these authentication devices as well.
The bank can then monitor for typical indicators of known attacks such as new devices, locations, presence of proxy, or others. This information can be correlated across its user-base to further understand the risk of these elements. We can then also factor in the operations the user is doing throughout the session itself and profile this against their usual behavior. This approach establishes a continuous risk profile for the session which can change with each action done by the end-user. Not only does this allow the bank to then take automated real-time actions when anomalies are detected, it also allows the bank to reduce friction for legitimate sessions by reducing the amount of authentications required for genuine sessions.
While the attack in this article uses technology and concepts that have been around for ages, we see that correctly applying them can still lead to great success and defeat various methods of authentication deployed today. It's important for banks to use a layered approach as most individual layers can still be attacked or exploited. When implementing dynamic linking banks need to make sure they establish a secure line of communication with the end-user. Relying on SMS for example has already proven to be unreliable as the messages can be stolen, spoofed, or intercepted by the attacker. However, when implementing mobile applications, banks should also be aware that these apps become a target and they should protect their mobile applications from external attacks. The goal of this article is mainly to demonstrate that phishing attacks can be modernized to defeat two-factor authentication at login and implementing 2FA alone does not offer complete protection from phishing. Finally we've mentioned some layers banks can implement to provide further protection to their end-users, as well as what pitfalls to avoid when doing so. To summarize:
- Implement dynamic linking with end-to-end encryption.
- Deploy server-side analytics to monitor end-user sessions, devices and behavior for potential attacks.
- Protect your mobile apps from malware and other external threats.