The FBI multi-factor authentication notification that should have never been

While reviewing the recent Private Industry Notification from the FBI about using social engineering and technical attacks to circumvent multi-factor authentication, I was floored at how each of these account takeover scenarios seemed completely preventable. That’s because SIM swap and session hijacking were at the center of each account takeover scenario. Let’s take a closer look at each of these attack vectors and how to prevent them.

SIM swap attack

SIM swap attacks are when a cybercriminal tricks a mobile carrier into porting a phone number to their device. With a number ported from a legitimate user to a cybercriminal, when a different company – for example a bank – uses a voice call or SMS to authenticate, the attacker can respond as if they were the intended user.

This is due to a fundamental flaw in voice call and SMS authentication. They both rely on something the user does not possess; the mobile number. The mobile carrier possesses the number and is capable of porting it to any device. Although carriers are taking strides to prevent attackers from using methodologies like social engineering to port a victim’s mobile number to a device owned by an attacker, you will always be reliant on the carrier to safeguard the authentication factor.

I hope that one day we can all agree that any authentication factor that relies on possession of something that is not under control of the user is not a valid possession factor. The general excuse I hear for using SMS or voice call-based authentication is that it’s better than nothing. While that may be true at first glance, dig a little deeper and time and time again that has been proven to be false. Bad security is bad security and excuses won’t make it better.

Session hijacking

Session hijacking involves tricking a user to utilize a dummy website set up to mimic the real website of the company for which the user has an account. The dummy site proxies the interaction with the real website providing the user with the exact same user experience as the real website. In this scenario, capturing the user credentials is not the goal.

The attackers want to obtain the token used to authenticate the user so they can interact with the real website on behalf of the user. As such, session hijacking can be utilized regardless of the authentication process required by the real website.

It’s no longer safe to assume that if a user is logged in, they are originating any request in that user session. Phishing attempts, commonly used with session hijacking, have become much more sophisticated. In fact, I recently almost clicked on one of these new generations of phishing scams. As a security professional, I know better. Even so, I had to fight my initial urge to click on the link in the scam email.

What can be done?

There are two factors that can prevent account takeover, which results from the above types of attacks. Mixing true multi-factor authentication with rich context ensures that you are interacting with the intended user and that they understand what they are approving.

In a SIM swap scenario, using a secondary form of authentication that isn’t outside the person’s control would be enough to thwart the FBI documented attacks. For instance, a device that is registered to that person and not their phone number. However, such a solution on its own would not be enough to prevent account takeover resulting from a session hijacking.

What could help is providing more context around authorization requests and on a secondary device. I find it hard to imagine a hijacking attempt being successful if a user was prompted by their baking website to re-authenticate their session while receiving a request on their authentication device to authorize a credential change. The rich context provides the intended victim with enough information to reject the attempt by the attacker no matter how well they perform the phishing attack.

With the correct mix of authentication factors the current attempts at account takeover can be eliminated. And maybe, just maybe, an FBI multi-factor authentication notification like the one just issued will be a thing of the past.