5.24.23 > Brian Kenyon
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.
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.
The key insight here is that MFA is not a universal protection against exploit or attack. Be smart about which factors you choose, how you protect against authentication session hijacking, and how you implement continuous monitoring to detect and quickly respond to suspicious activity.
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 generated TOTP code. This allows an attacker to create an authenticated session with the real website on behalf of their victim. Alternatively, malware on a 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, Main-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.
Multiple Protections for MFA
Like all security practices, securing web applications requires a layered approach. Modern MFA, using strong cryptographic methods like the WebAuthn example, is a good practice and should be adopted whenever possible. Going further, security leaders need to consider where those authentication challenges are taking place and interrogate the security of the browser, device, and network. Malicious attackers are constantly evolving their tradecraft, and so must security experts. Continuous logging, analysis, and incident response paired with good security practices offers a good defensive posture. But we must always be learning and adapting to the evolving security landscape.
Brian Kenyon, Chief Strategy Officer, Island
Brian Kenyon drives corporate strategy at Island as its Chief Strategy Officer and one of the company’s founding members. Brian has also held the role of CSO at Symantec and Blue Coat Systems. He built his early career in technical roles for more than a decade at McAfee where he was Chief Technical Strategist, as well as CTO, and served as chief architect at start-up Foundstone.
Brian is the author of Security Battleground: An Executive Field Manual; Security Sage: Guide to Hardening the Network Infrastructure; and Special Ops: Host and Network Security. He holds a B.A. degree in Finance from Loyola Marymount University.
You can Connect with Brian here at the Cyber Security Summit at >
And on LinkedIn at >