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. There’s a school of thought that says you should never bury your lede; that when you have something even halfways remarkable to share, it should be
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.
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.