4 ms·

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 Attack

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.

dotjunior 8y ago
> (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.
- crdrost 8y ago
  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.)
cmurphycode 8y ago
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.
thatthatis 8y ago
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.

dotjunior 8y ago

> (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.

crdrost 8y ago
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.)

cmurphycode 8y ago

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.

thatthatis 8y ago

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.