I wasn’t sure at first whether/when there would be enough developments to justify a sequel to Thursday’s post. But then I looked a little deeper. And, uh, wow.
I just wanted to comment regarding theory 2A and the nuances of attacking 2FA. I am not familiar with the capabilities of the Twitter admin panel or how Twitter implemented 2FA, but it is possible that the attackers leveraged access that could have been used to bypass it without toggling it off. This would not have been that difficult depending on what they had access to.
The verification code is generated using a 2FA secret code that is combined with the current time and used by a publicly available algorithm. That 2FA secret code is all you really need to generate a valid verification code yourself since the algorithm is publicly available.
Generally, a company will go to great lengths to protect a user's password in a database so that you would not be able to derive the password from whatever is stored in their database (usually a hash representation of the password). I have no doubt Twitter adequately protects their passwords, but the 2FA secret is not generally given any sort of protection and is often stored in plain text in the database.
A support employee might have access to view what is contained in the database for a particular user through an internal tool of some kind. It is possible that Twitter adequately protected the password fields for a given user, but neglected to protect the 2FA secret codes. This may have allowed the attackers to use those codes to generate valid 2FA tokens at will. This, combined with the password reset abuse, may have allowed the attackers to circumvent 2FA without toggling it off or performing a SIM-swapping attack.
I am making a couple of assumptions here:
1) Twitter stored the 2FA secret codes for the SMS auth themselves and did not outsource this sms verification to a third party service
2) Twitter employees had access to database entries for users or at least could derive the 2FA secret code through the internal support tools
The reason this is important is because the 2FA secret code is often not protected like a password due to the perceived unlikelihood of its compromise being consequential in an attack. If this attack could have been prevented by protecting the secret code, it would be a great lesson for other software engineers. It would be great to learn more about how this happened.
Twitter, in the blog describing the attack, only says that the attackers managed to "get through" their two-factor protections:
The attackers successfully manipulated a small number of employees and used their credentials to access Twitter’s internal systems, including getting through our two-factor protections. As of now, we know that they accessed tools only available to our internal support teams to target 130 Twitter accounts. For 45 of those accounts, the attackers were able to initiate a password reset, login to the account, and send Tweets.
I know from other reporting that Twitter uses (or at least used) Okta. Ergo employee-level 2FA (as opposed to Twitter user 2FA) should have run through Okta's servers. So while their 2FA code could have been stored in plaintext there (though I kinda doubt it?), that would require a totally separate breach.
My sense is that they *probably* got around employee 2FA by SIM-swapping the phones in question. (But even there I'm not convinced. The official story has some weird elements that can't be easily harmonized.)
(As for user 2FA, apparently there was a toggle in the panel that let them just turn it off.)
I see - that clarifies things quite a bit, thanks. I was a little confused about the two distinct 2FA bypasses. It sounds like they managed to bypass the Twitter employee 2FA through some combination of SIM swapping and social engineering. That part makes sense and seems plausible. I doubt they could have acquired the 2FA secrets for Twitter employees to pull that part off.
The part I am unsure about is the user 2FA bypass. I didn't see any screenshot that showed a "disable 2FA" button. I saw some variation of these screenshots floating around a bit:
His logic makes sense, but it is still based in a few assumptions and I don't really see any hard evidence that the admin panel had a "reset 2FA" functionality or that the attackers actually did so.
I think his reasoning for his claim about the admin panel is begins here:
"
The tweet itself doesn’t explain how 2FA was circumvented, but we can assume that twitter admin tool’s can revoke 2FA because an hour after Twitter said “Internally, we’ve taken significant steps to limit access to internal systems and tools while our investigation is ongoing. More updates to come as our investigation continues.” I received the following:
<email from Twitter about the 2FA reset>
"
Lucky goes on to say:
"
It’s clear however that Twitter’s tool allow employees to revoke 2FA settings on an account with no action from the user, so we can assume that attackers did this same action after updating the email on file to their own to bypass 2FA. That said we know Twitter(as opposed to attackers) legitimately revoked 2FA and locked affected accounts out as the same experience above happened to several journalists. A Vice article by Janus Rose states:
"
It seems that he received an email notification about his 2FA being disabled an hour after the attack had occurred by Twitter (not the attackers). I don't understand why Twitter would lock his account and also take the additional step of disabling the 2FA unless they wanted to force everyone whose account was compromised to establish a new 2FA secret token. If that is the case, it might be that they presumed that the 2FA secret tokens were compromised and wanted users to reset them to be safe.
I think he is extrapolating the existence of a "reset 2FA" functionality in the admin panel from the fact that Twitter, in fact, reset multiple users' 2FA following the attack, but that seems like it is a bit of a leap. Twitter could have used a different tool or mechanism to disable the user 2FA here. it is technically possible that they had an engineer do this operation directly against the database and that they didn't use the admin tool in question.
There seems to be a lot of uncertainty surrounding what, specifically, this admin panel is/was capable of and what the attackers did to access the accounts in question.
Hi Jeremy,
I just wanted to comment regarding theory 2A and the nuances of attacking 2FA. I am not familiar with the capabilities of the Twitter admin panel or how Twitter implemented 2FA, but it is possible that the attackers leveraged access that could have been used to bypass it without toggling it off. This would not have been that difficult depending on what they had access to.
The verification code is generated using a 2FA secret code that is combined with the current time and used by a publicly available algorithm. That 2FA secret code is all you really need to generate a valid verification code yourself since the algorithm is publicly available.
Generally, a company will go to great lengths to protect a user's password in a database so that you would not be able to derive the password from whatever is stored in their database (usually a hash representation of the password). I have no doubt Twitter adequately protects their passwords, but the 2FA secret is not generally given any sort of protection and is often stored in plain text in the database.
A support employee might have access to view what is contained in the database for a particular user through an internal tool of some kind. It is possible that Twitter adequately protected the password fields for a given user, but neglected to protect the 2FA secret codes. This may have allowed the attackers to use those codes to generate valid 2FA tokens at will. This, combined with the password reset abuse, may have allowed the attackers to circumvent 2FA without toggling it off or performing a SIM-swapping attack.
I am making a couple of assumptions here:
1) Twitter stored the 2FA secret codes for the SMS auth themselves and did not outsource this sms verification to a third party service
2) Twitter employees had access to database entries for users or at least could derive the 2FA secret code through the internal support tools
The reason this is important is because the 2FA secret code is often not protected like a password due to the perceived unlikelihood of its compromise being consequential in an attack. If this attack could have been prevented by protecting the secret code, it would be a great lesson for other software engineers. It would be great to learn more about how this happened.
Twitter, in the blog describing the attack, only says that the attackers managed to "get through" their two-factor protections:
The attackers successfully manipulated a small number of employees and used their credentials to access Twitter’s internal systems, including getting through our two-factor protections. As of now, we know that they accessed tools only available to our internal support teams to target 130 Twitter accounts. For 45 of those accounts, the attackers were able to initiate a password reset, login to the account, and send Tweets.
I know from other reporting that Twitter uses (or at least used) Okta. Ergo employee-level 2FA (as opposed to Twitter user 2FA) should have run through Okta's servers. So while their 2FA code could have been stored in plaintext there (though I kinda doubt it?), that would require a totally separate breach.
My sense is that they *probably* got around employee 2FA by SIM-swapping the phones in question. (But even there I'm not convinced. The official story has some weird elements that can't be easily harmonized.)
(As for user 2FA, apparently there was a toggle in the panel that let them just turn it off.)
I see - that clarifies things quite a bit, thanks. I was a little confused about the two distinct 2FA bypasses. It sounds like they managed to bypass the Twitter employee 2FA through some combination of SIM swapping and social engineering. That part makes sense and seems plausible. I doubt they could have acquired the 2FA secrets for Twitter employees to pull that part off.
The part I am unsure about is the user 2FA bypass. I didn't see any screenshot that showed a "disable 2FA" button. I saw some variation of these screenshots floating around a bit:
https://www.bleepstatic.com/images/news/u/1109292/2020/Twitter%20admin%20panel.png
https://cnet4.cbsistatic.com/img/KPFYRpsQaxq_ls9uOtXEOgHaHIQ=/940x0/2020/07/16/858e5ce4-6287-4568-9f90-c72ac4c5b418/twitter-ban-3.jpg
Neither of them seem to show a "disable 2FA" button. The source of the claim that the attackers disabled user 2FA seems to be from Kreb's article (https://krebsonsecurity.com/2020/07/whos-behind-wednesdays-epic-twitter-hack/) which quotes Lucky. Lucky's medium post provides more details about his reasoning (https://medium.com/@lucky225/the-twitter-hack-what-exactly-happened-d8740d33c1c). Lucky controls Adrian Lamo's @6 Twitter account which was one of the victim accounts of this hack. It sounds like he is speculating about how the attackers were able to bypass the 2FA on the @6 account.
His logic makes sense, but it is still based in a few assumptions and I don't really see any hard evidence that the admin panel had a "reset 2FA" functionality or that the attackers actually did so.
I think his reasoning for his claim about the admin panel is begins here:
"
The tweet itself doesn’t explain how 2FA was circumvented, but we can assume that twitter admin tool’s can revoke 2FA because an hour after Twitter said “Internally, we’ve taken significant steps to limit access to internal systems and tools while our investigation is ongoing. More updates to come as our investigation continues.” I received the following:
<email from Twitter about the 2FA reset>
"
Lucky goes on to say:
"
It’s clear however that Twitter’s tool allow employees to revoke 2FA settings on an account with no action from the user, so we can assume that attackers did this same action after updating the email on file to their own to bypass 2FA. That said we know Twitter(as opposed to attackers) legitimately revoked 2FA and locked affected accounts out as the same experience above happened to several journalists. A Vice article by Janus Rose states:
"
It seems that he received an email notification about his 2FA being disabled an hour after the attack had occurred by Twitter (not the attackers). I don't understand why Twitter would lock his account and also take the additional step of disabling the 2FA unless they wanted to force everyone whose account was compromised to establish a new 2FA secret token. If that is the case, it might be that they presumed that the 2FA secret tokens were compromised and wanted users to reset them to be safe.
I think he is extrapolating the existence of a "reset 2FA" functionality in the admin panel from the fact that Twitter, in fact, reset multiple users' 2FA following the attack, but that seems like it is a bit of a leap. Twitter could have used a different tool or mechanism to disable the user 2FA here. it is technically possible that they had an engineer do this operation directly against the database and that they didn't use the admin tool in question.
There seems to be a lot of uncertainty surrounding what, specifically, this admin panel is/was capable of and what the attackers did to access the accounts in question.
Interesting! Gonna sit with that for a bit.