Hacking Two Factor Authentication: Four Methods for Bypassing 2FA and MFA

Hacking 2FA and MFA

When MFA is implemented correctly, it can be an extremely powerful and low-cost way to protect against the weakest link in the cybersecurity defense – which is generally the user’s password. It works by combing something you know, like a password – with something you have, like a hard or soft token. It can be expanded to include other factors, such as something you are – like biometrics, or somewhere you are – like a geolocation.

Attacks on MFA were once considered more of a proof of concept than an actual threat. The thinking was as long as MFA is enabled – it doesn’t really matter if an attacker gets a user’s password because they would still need access to the token. Over recent years, however, more and more attacks have proven to be not only quite successful but also quite common.

Here, we’ll take a deep dive into 4 of the most common MFA attacks seen increasingly being used in the real world, along with ways to mitigate these attacks so you can protect yourself and your organization.

Evilginx2

No matter how strong a security control may be, attackers will always target the weakest link. A great example of that is the attack framework evilginx2.

evilginx2 works by acting as a proxy between the user and the server. The attacker first needs to find a way to reroute the user traffic through the evilginix proxy. The traffic is then sent to the real web server and displayed back to the user. It’s important to note that the user is actually seeing the real site, not a replica like in a phishing attack. Evilginx is merely acting as a proxy, which means the user sees the content exactly as they would when they visit the actual site. This means it sees all communication between the user and the site – and in turn, grabs not only usernames and passwords but the authentication cookies as well. Captured authentication cookies are a goldmine because they allow the attacker to bypass any 2FA enabled on the user’s account. This concept is important because it is not just capturing tokens, which will change after each request and is no longer usable once the victim logs in successfully.

The framework actually captures the actual authentication cookie from the successful login. This allows the attacker to bypass any form of 2FA enabled on the user’s account from any machine. If you export cookies from your browser and import them into a different browser, on a different computer, in a different country, you will be authorized and get full access to the account without being asked for usernames, passwords, or 2FA tokens.

There are two ways to protect against this kind of sophisticated attack: one way is to monitor the URL and verify the domain you are visiting is the actual one in the browser. While this sounds obvious, even the most tech-savvy user can still have trouble identifying a real URL from an attacker’s redirect.

The other is to use a physical hardware key like Universal 2nd-factor authenticator. U2F was introduced to protect against this specific kind of phishing attack. In short, the user would need to press a physical button on the hardware, which interacts directly with the server to request the one-time code. The browser is only acting as a channel for communication and, therefore, not storing any session cookies which can be retrieved.

Evilginix is a kind of attack which can be considered part of a broader type called “Pass the cookie,” which leads us to our next item on the list.

The concept behind this kind of attack is that the user has already authenticated with their MFA token, and the website has stored the cookie in the user browser. While these cookies are encrypted by default, in this attack, we are attempting to retrieve and decrypt the cookies.

Unlike Evilginix, which acts as a proxy between the victim and the real server intercepting the authentication cookie – this attack involves access to the user browser via some other method. Once a system has been compromised via another method, the attacker retrieves the cookie database from a web browser. Once the cookie has been retrieved from the DB, Mimikats can be used to retrieve the decrypted cookie. Security research Jeff Warren shows us here how the Mimikats command you see on the screen was utilized to retrieve the keys. In his blog post, he illustrates how Azure was bypassed using the “Pass the Cookie” method.

Once the cookies have been retrieved and unlocked, the next step is to pass the cookie into the attacker’s web browser and attempt to visit the target application as the victim. With the authenticated cookie at hand, MFA is completely bypassed for the login duration.

Perhaps the most unsettling part of this attack is that the attacker does not need to know the victim’s username or password. However, they would need to compromise the victim’s machine and escalate privilege via some other method. Fortunately, there are a few things we can do to protect against this kind of attack:

One way would be to add additional context to the user authentication. Because this attack works by exfiltrating authenticated cookies out of a legitimate machine to another location, only authorized IPs and client machines should be allowed to access sensitive machines.
Another option is browser fingerprinting, where the remote application would require a new authentication when a new browser or device is detected. This is similar to what banks do whenever you try to log in from an unknown device or machine.

This attack illustrates the point that no matter how strong your password policy and MFA maybe, an attacker will always use the path of least resistance.

SMS-based man-in-the-middle attacks

Perhaps the biggest weakness in MFA is the use of SMS or Email as a delivery vehicle for the one-time token. When using SMS for 2FA or MFA, the one-time token is delivered to the user via SMS text message, which is then inputted by the user to log into the system. This is perhaps the most popular method of MFA because it’s very easy to implement and does not require any soft or hard token. In fact, many of us have used this method to log into banks and other personal websites.

However, the use of SMS over a physical or soft token device is a problem because the attacker can get access to the victim’s SMS rather easily. This attack works by first doing a SIM swap on the victim’s phone number. A SIM swap is when an attacker transfers the phone number of a victim to their own SIM card, which is then controlled by the attacker. All phone and SMS messages are then sent to the attacker’s phone instead of the victim. This means that One Time Tokens are also sent to the attacker’s phone without the victim’s awareness.

SIM swaps are surprisingly too easy to do. As a VICE article recently put it, all it takes is a prepaid account and phone number to transfer ownership. As the author put it:

“Once the hacker is able to reroute a target’s text messages, it can then be trivial to hack into other accounts associated with that phone number. In this case, the hacker sent login requests to Bumble, WhatsApp, and Postmates and easily accessed the accounts.”

In a recently covered T-Mobile data breach that happened earlier this year when an open test router was used to penetrate the corporate T-Mobile systems. Part of the impact of that breach was the exposure of over 50 million user records which included PII and phone numbers. As I mentioned, user phone numbers meant that attackers could easily target user accounts with their matching phone numbers.

The key takeaway for this attack is to never use SMS as a delivery mechanism for one-time tokens. Using hard tokens like RSA fobs or soft tokens like Google’s Authenticator app is a simple solution to this relatively easy bypass.

Attack on Soft and Hard Tokens

While speaking about hardware and software-based tokens, it’s worth mentioning that when they are utilized – they too can be the weakest link in the chain. Software tokens have come under the biggest scrutiny lately due to recent major zero-days that have been found on iOS and Android smartphones. While software tokens like Google Authenticator or RSA’s SecureID Authenticate are generally considered secure, their nature of BYOD means organizations still have to worry about malware to the phones themselves. In this attack, the victim’s phone is compromised and used to retrieve the One Time Code from the MFA system.

In one example used by a security researcher at NextWeb – a 0 day SMS exploit on Android made it possible to mirror the victim’s phone and even launch applications without their knowing. The attacker can log in to the victim’s phone, open the app in the background, and retrieve the One-time code. By having this level of access to the victim’s machine, no secure software token is safe from prying eyes.

Similarly, hardware tokens can fall victim to user errors as well. By doing some digging on Shodan for open webcams, Cybersecurity researcher Toddsy could clearly see an employee’s RSA key fob through a watching webcam. Both of these attacks illustrate the point that attackers can, and will, always find ways around the strongest security technologies to their least common denominator.

Application Bypass

The last item on our list is not a single item but more of a general category to always keep in mind, and that’s application exploits that bypass MFA altogether.

As an example – earlier this year, Microsoft exchange servers were the target of a zero-day exploit named Hafnium. In this attack, the server side is targeted to completely disable the MFA process altogether.

Another example was a DoS attack on the MFA library on the popular Liferay DXP platform. We can review several examples to get the point across – the easiest way to bypass MFA is to go around it.

These two examples hopefully serve as warning signs to the theme throughout – which is that attackers will always go the route of least resistance. In the big picture, that means fortifying all parts of the attack surface and never thinking you’re in the clear simply because of any one technology.