A Closer Look at MFA in the Browser

Multi-factor authentication is — thankfully — a normal part of our digital experience. Whether at work, connecting with your bank, or logging in to social media, we’re used to the extra step of entering a short code or acknowledging a push notification during login.

Attackers are on the hunt

In recent years, attackers have grown an arsenal of capabilities — varying from sophisticated to straight-forward — to bypass the security MFA provides. Examples from recent incidents that included MFA bypasses are the SolarWinds breach, which was carried out by Russian state-actors the NOBELIUM APT; the Nvidia and Microsoft breaches, who are believed to be carried out by LAPSUS$ cybercrime gang, and most recently the Uber incident, by a currently unknown attacker. All of these incidents have a common thread: these organizations used MFA but their attackers found a way to bypass it.

What are we going to cover in this article?

The Island Enterprise Browser enables administrators to embed MFA authentication into every web application and on every user flow at will, and enforces strong MFA methods. We will cover the different types of MFA methods, the challenges of using them within enterprise applications, and how the Island Browser brings it all together. 

A one time challenge, or no challenge at all

MFA adoption is dependent on application developers, and security teams often have to find creative ways to enforce MFA consistently. This gap becomes even more apparent in legacy applications that are no longer maintained, or that were developed with technologies that make incorporating MFA difficult or impossible. Thus, many critical applications that we use do not, or cannot, adhere to the security standards we all wish to see. 

Implementing MFA eventually sums up to better security at the stage of authentication to the application. Once an attacker has already obtained an authenticated session (through session hijacking, for example), they can do anything they wish in the application. In fact, relying on authenticated sessions is one of the most common ways attackers bypass MFA altogether.  

With the ability to embed MFA everywhere, Island allows administrators to build a secured workflow for their users within any application, and protect the most sensitive actions they perform within the browser. For example, with Island, an administrator can choose to prompt for MFA when the user decides to edit a sensitive financial file, or add an MFA prompt to a legacy application that doesn’t support MFA natively. 

The MFA method you choose does matter

Rolling out MFA in the organization is not a silver bullet — security teams must be conscious of which MFA methods they use and weigh the risks of each. In the following sections, we will review some of the most common MFA methods and the risks associated with them.  

SMS-based MFA

One of the most common MFA methods is SMS-based MFA. Once a user enters their password, a temporary code is sent to the user by SMS, which they input in order to complete the authentication. But according to research from CISA, Microsoft, Okta, and others, it’s also one of the weakest. 

SMS-based MFA hinges on the ownership of the phone number tied to the account, and not on ownership of the mobile device itself. Except for phishing and malware, SIM swapping is one of the most common attack vectors on SMS-based MFA — an attack in which the attackers take over the victim’s phone number. 

One common method of executing such an attack is using social engineering to impersonate their victim, claim to have lost their device, and convince the mobile carrier to move the number to a new device. In a recent example, an attacker pleaded guilty to stealing some $50 million USD in Bitcoin from a wallet after a successful SIM swapping attack, which allowed him to gain access to the victim’s email and then their cryptocoin wallet. 

Time-based One-Time-Password (TOTP)

Another common MFA method is time-based one-time password, or TOTP. In TOTP, a shared-secret is set up between an application (usually on a mobile phone) and a web application, usually by scanning a seed provided in a QR-code. After the shared secret is created, the application generates short-lived codes derived from the secret and the creation time of the secret, making the generation of new codes by a malicious actor extremely difficult. 

TOTP is a strong MFA method, but it is not bulletproof. A phishing website that simulates the authentication process with the destination website can intercept the password TOTP code. This allows an attacker to create an authenticated session with the real website on behalf of their victim. Alternatively, malware on the device can steal the TOTP shared secret, and generate a valid code on demand.

Recently, a sophisticated campaign targeted organizations by creating phishing websites mimicking their SSO authentication pages, and intercepting the victims TOTP codes to create valid sessions.

App based push notification

Push-notification based MFA gives a great user experience: a user simply has to click a notification from an MFA app to approve an MFA challenge. Since the challenge is given and completed in a trusted application on one of the user's devices, app-based push notification is considered one of the strongest MFA methods.

However, most applications do not require the user to prove they are physically present near the device used to access the account (by asking the user to input a code shown on the screen, for example). Attackers can flood users with push notifications until a user approves it out of habit. Also, a malware can steal the push notification client key or read the notifications directly. Such attacks allowed both sophisticated state-sponsored APTs as well as cybercrime gangs to bypass MFA of users from very large enterprises. 

FIDO2 and WebAuthn

In recent years, using biometric authentication (such as fingerprint and facial recognition) for web applications has been on the rise, with steady adoptions on physical devices and operating systems from vendors such as Apple and Microsoft. Biometric authentication is just one type of authentication that has been made possible by the FIDO2 (Fast Identity Online) project, and the WebAuthn standard. WebAuthn allows the use of a private key stored in a device — a laptop, a mobile phone, or a security key, that upholds certain hardware and software security standards — to authenticate to a web application while verifying its identity. 

WebAuthn-based MFA is considered the safest MFA method these days, as it relies on a private-public authentication mechanism and has a verification of the destination website during the authentication process. This can prevent most phishing scenarios, like those described above. If possible, always use a WebAuthn based authentication. 

Browser attacks

Besides directly attempting to bypass MFA, an attacker can aim for getting the end result of such bypass directly: a valid session token or cookies of the victim. There are some possible ways to achieve that and they all revolve around attacking the browser. Some examples: 

Stealing cookies from the endpoint 

An attacker who has access to the endpoint, or the browser, can (assuming they have user privileges) retrieve the cookies stored in all common browsers — both Chromium based (such as Chrome and Edge) and others (such as Firefox). The cookies are stored encrypted on the endpoint. However, since the encryption mechanisms are known and the keys are accessible to the user, malware can also access the cookies and decrypt them.  

In a recent example, the LAPSUS$ cybercrime gang has claimed to have breached EA by buying an active session token of an employee to the company’s Slack. This token was most likely obtained from malware installed on an employee’s devices from which they used to login to the corporate Slack.

Stealing cookie via MITM

SSL is almost ubiquitous in the modern world and keeps our online activities both secure and private. However, Man-in-the-Middle (MITM) attacks are still a possibility. For example, malware installed on the endpoint can add the attacker’s trusted certificate, allowing them to decrypt SSL traffic. By achieving visibility to the unencrypted traffic between the victim and the service, attackers can steal all of the tokens and cookies sent in it.

Island makes MFA ubiquitous

The Island Enterprise Browser empowers organizations by allowing them to use MFA everywhere. Some of the most common scenarios include:

1. Application access: Attach MFA to access any application, modern or legacy, and enforce the highest standard of security. 
2. User interaction: Attach MFA to any type of user interaction that is deemed sensitive, such as clicking on production-sensitive flow in a web application, downloading a file, or sending a form. 
3. Physical access: Island can protect against physical access of an idle machine by obscuring the window and requiring MFA to resume work — even on an unmanaged device. 

In addition to making MFA another tool in the administrators tool shed, Island also protects against endpoint and network attacks, like the ones mentioned above. This is done through various methods of local and cloud-based encryption of sensitive browsing data and network integrity checks and verifications. By combining the power of MFA everywhere with strong MFA methods, last-mile controls and enterprise-grade protections, Island protects the enterprise, while empowering the end user.

‍