I think this attack is slightly overrated by the other commenters (and those that say it defeats 2FA are wrong).

Here is the scenario he posted:

  > An Attacker enables 2FA in Victim’s account.
  > In another browser, Attacker waits indefinitely in the 2FA input page (Image 1).
  > Attacker disables 2FA.
  > The Victim regains access to the account (changing password & resetting sessions)
  > Then the Attacker could input a valid 2FA code and have access again to the account, without knowing the current password.

So to summarize:

- The attacker needs the password of an account that is not protected by 2FA.

- It allows the attacker to stay connected after a password change (usually, when a password change occurs, it logs out the user of all platforms).

In fact, 2FA protects you from this vulnerability : just activate it for your account and you are not vulnerable to this attack (the attacker cannot connect to your account in the first place, since he doesn't control 2FA tokens).

Moreover, if your account doesn't have 2FA and someone finds out your password, well I think you are already deep in trouble (the attacker could do many more things, since he's already connected).

So this attack is still a big deal (the user can't disconnect you) but it doesn't break 2FA security at all. It just adds a vulnerability to accounts that don't have 2FA enabled.

  > (usually, when a password change occurs, it logs out the user of all platforms).

That is what seems to be broken by this attack. You are not properly logged out when all sessions are closed, and you can manage to login without knowing the current password.

No, it does not break 2FA. No, it does not work if you have 2FA enabled.

I mean, it may well work if you have 2FA enabled (it depends on whether you can set up two different 2FA options and force the login provider to use the stale one) -- but you do have to hijack someone's account which is indeed considerably harder if they have 2FA enabled.

Security can roughly be described as "the inability to do something surprising, measured in dollars." The surprising thing here is that under some circumstances you might feel like you have "reclaimed your account" (by disabling their 2FA method and resetting your password) only to find out that you have not (because an authentication session dependent on the stale method and password is still "live in the system" and can be used to log in to your account). The distinctive thing is that this can be done for the low low price of just keeping a website open in a spare tab, but it requires a previous vulnerability to have paid the high price of hijacking the account in the first place.

What's interesting is that these sorts of it-makes-surprising-things-a-lot-more-surprising scenarios is that there are kind of two different equally-valid measurements of their security implications, one high and one low. In a total-cost-of-attack sense, yeah, you have to incur the cost to hijack the account in the first place and this means that if they're doing things right this is an "expensive" attack and therefore the service is still secure. But in a marginal-cost-of-adding-this-attack sense, this is a very cheap attack and points to the login flow having a deep security vulnerability. So it's contextual whether the system is secure or not.

That of course probably won't be news to anyone who works in security, I suppose -- they are used to security not being a monolithic thing that everything is easily classified as yes or no. (Like, if you have seen the different attacks on hash functions you already can appreciate "is this secure?" depends on what you're trying to do with it -- and that's bog-standard everyone-in-appsec-knows-that knowledge.)

Let’s consider a more realistic scenario: shared account and a soon to depart disgruntled employee.

The havoc someone in that situation could cause is substantial.

You change the password and they still have access to be angry and delete things or send malicious communications or steal secrets for their new employer.

We had this exact disgruntled employee issue with an instagram account in 2016.

I suppose it would be interesting to think of this attack in a scenario.

Say you worked for a company that didn't require 2FA yet. Then there is a hack, and your co-worker's account is stolen. IT investigates, clears it up, and pushes out a policy that enables 2FA. "Ok everyone, all clear! No need to worry anymore."

A while later, your account is hijacked.

Instagram: "[the attack] seems unlikely to happen commonly, making this more of a theoretical attack. The protection in this case is to not allow someone to steal your password"

LOL

Isn't the whole point of MFA to protect the theft of the one of the authentication tokens? and the password is the most likely to be stolen / compromised imho.

If you activate MFA, you are not vulnerable to this attack (see my top-level comment)

The point is that if Instagram thinks that people getting their passwords stolen is an important enough problem to offer MFA, then an abuse of MFA that only affects people who have their passwords stolen should be an equally important problem.

Not necessarily.

Instagram knows that people password spray its service regularly and that many popular accounts are often targeted for takeover by scammers. This is a common problem for them and happens regularly They also know what those threat actors do once they get an account.

I'm betting this scenario isn't one they see happening after an account is compromised or is easy to detect etc, and for those reasons the risk is different. How likely a vulnerability is to be exploited plays an important part in deciding the risk it carries.

Interesting but far from an account compromise on it's own. You still need to know the user's password in the first place and, I believe, you can't repeat the attack once they change their password. So if they change their password a second time or enable MFA themselves you're blocked permanently. So it allows for a existing attack to be prolonged one time and possibly makes it harder for a user to realize they're still compromised.

I can see some value in a targeted attack on an individual although only if they don't respond by turning on MFA themselves.

I've noticed that multiple sites that have two factor enabled give you the option to add a device, but not list or remove existing ones (without wiping them all).

At a glance, Google does not seem to enable you to do this, but might actually do it behind the scenes anyways.

I've seen some companies (Cloudflare springs to mind) which requires a support ticket to disable MFA on a user's account. It's a little tedious but does add an extra hoop for an attacker to jump through.

Google only allows one "device" at a time, as far as I know. Adding a new device invalidates all old devices.

When you set up a new device, it gives you a new seed.

If you want two devices for Google 2FA, you need to either: - scan the qr code on both devices at once - or write down the seed for later use

Google won't let you retrieve the seed later (to prevent people from adding a second device with 2FA without your knowledge)

I am wondering, why Instagram and MS did not react and fix this issue. And I am wondering, what one can do, if "forced" to use these two.

IG I am using privately, with my FB login. That works with a dedicated email address and password. So ok - one could hack that and do stuff. Well bad, but ok. But MS? I am forced to use it in the company setting I am in. What to do to secure this more?

Enable 2FA yourself. That way if the attacker manages to get your original password, they won't be able to login and enable 2FA themselves.

Thanks. Didn't read that right in my OP

> The protection in this case is to not allow someone to steal your password

Im sorry, but what?

"Oh you got stabbed? Well, next time, dont"

Well of course, if you don't have 2FA enabled, the only protection is to not allow someone to steal your password.

Or enable 2FA, which seems easier, and protects you from this attack.

I think the metaphor in this case is "The bullet proof vest didn't work? Well, stop standing in front of bullets!"

If they trust so blindly in the security of the password, why even have 2FA?

'All relevant cool sites are expected to have 2FA'

Twitter would be very criticised if they didn't have it.

So 2FA as PR rather than actual security.

You’ll realize how much this is true when you see how many people will lambast you for not implementing 2FA vs the handful of people who will actually use it once you implement it.

It’s like when McDonalds caved and started offering salads. The people saying McDonalds made you fat were happy, yet nobody actually orders salads from McDonalds.

An easier and more reliable, way to get persistence is to add an app code...

One of the most useless hacks I've ever seen

tldr: An attacker that compromised an account can maintain access even after user changes password. Exploit vector uses 2FA.

imo not a big deal as a prerequisite is a breached account which is game over already.