As of this point (1.5 to 2 days after the incident), Twitter has stated it does not yet know exactly how attackers accessed it's internal customer support admin tool. That makes sense, as these things take time to verify. They are being remarkably candid about their ongoing investigation in the Twitter Support thread that Ben has linked to in this post. I hope this sets a standard of communication for other companies, although I am not hopeful.
Joseph Cox at Vice published an article during the incident with sources inside the hacking group claiming they paid an internal customer support admin for either their credentials to the admin interface or paid them directly to modify account settings via the interface.
There was another recent article from a different journalist revealing information about one of the hackers that seems to verify this reporting that I'm not going to link to. As an aside, Joseph Cox is an excellent reporter to follow for information security journalism.
So, we have an internal customer management tool that can change an account's settings, such as change the registered email address and disable 2FA. These seem like typical customer support actions, presumably not available to tier 1 support but can be escalated to someone with the authorization to perform these actions after verifying a user. Hackers paid off one of these authorized customer support admins for access to this tool and used it to change the primary email address of accounts to one under their control. They additionally either disabled 2FA or set the registered phone number to one under their control as well. They then triggered a password reset, received that email to their email address, and proceeded from there to take over the account. They appeared to script this whole process to quickly capture a number of accounts.
Questions I want to leave you with:
How do you protect against someone using an internal tool in the way it was designed? Someone who has access to the tool as part of their regular responsibilities?
You can require 2+ people to sign off on account activities like this. So instead of buying 1 person, you'd need to buy 2 who could then modify settings. I'm sure Twitter's security teams will be implementing interesting new monitoring checks around these internal tools as well, which brings me to my next point.
How well architected is your monitoring and logging in your application? Are you capable of detecting anomalous behavior patterns? Are you only checking for increased error rates? Monitoring and logging are such an important aspect of information security they've made it into the OWASP Top Ten in 2017. It is hard to be effective preventing a lot of insider threat scenarios and still be a functioning organization. A company needs to be able to detect and respond to incidents quickly, which is where logging and monitoring come into play. If you are throwing everything into Splunk but then don't have any automatic alerts actioning on the logs, you're not helping anyone.
Finally, let's cool it with the diatribes against Twitter's security teams. Even in situations like Equifax's breach, it is very rare for the security team to be behind any mistakes. I have yet to encounter a security group that is ambivalent toward protecting their users (Facebook, for example, has one of the best security teams in the world). It is usually the business who prevents the security team from implementing the controls they want due to real or perceived friction for business operations. If you want to be frustrated at Twitter, go ahead. But I will be highly surprised if future articles about this incident reveal that Twitter's security team had any part in this story.
Edit: and this is why I didn't link to the other article.
As of this point (1.5 to 2 days after the incident), Twitter has stated it does not yet know exactly how attackers accessed it's internal customer support admin tool. That makes sense, as these things take time to verify. They are being remarkably candid about their ongoing investigation in the Twitter Support thread that Ben has linked to in this post. I hope this sets a standard of communication for other companies, although I am not hopeful.
Joseph Cox at Vice published an article during the incident with sources inside the hacking group claiming they paid an internal customer support admin for either their credentials to the admin interface or paid them directly to modify account settings via the interface.
There was another recent article from a different journalist revealing information about one of the hackers that seems to verify this reporting that I'm not going to link to. As an aside, Joseph Cox is an excellent reporter to follow for information security journalism.
So, we have an internal customer management tool that can change an account's settings, such as change the registered email address and disable 2FA. These seem like typical customer support actions, presumably not available to tier 1 support but can be escalated to someone with the authorization to perform these actions after verifying a user. Hackers paid off one of these authorized customer support admins for access to this tool and used it to change the primary email address of accounts to one under their control. They additionally either disabled 2FA or set the registered phone number to one under their control as well. They then triggered a password reset, received that email to their email address, and proceeded from there to take over the account. They appeared to script this whole process to quickly capture a number of accounts.
Questions I want to leave you with:
How do you protect against someone using an internal tool in the way it was designed? Someone who has access to the tool as part of their regular responsibilities?
You can require 2+ people to sign off on account activities like this. So instead of buying 1 person, you'd need to buy 2 who could then modify settings. I'm sure Twitter's security teams will be implementing interesting new monitoring checks around these internal tools as well, which brings me to my next point.
How well architected is your monitoring and logging in your application? Are you capable of detecting anomalous behavior patterns? Are you only checking for increased error rates? Monitoring and logging are such an important aspect of information security they've made it into the OWASP Top Ten in 2017. It is hard to be effective preventing a lot of insider threat scenarios and still be a functioning organization. A company needs to be able to detect and respond to incidents quickly, which is where logging and monitoring come into play. If you are throwing everything into Splunk but then don't have any automatic alerts actioning on the logs, you're not helping anyone.
Finally, let's cool it with the diatribes against Twitter's security teams. Even in situations like Equifax's breach, it is very rare for the security team to be behind any mistakes. I have yet to encounter a security group that is ambivalent toward protecting their users (Facebook, for example, has one of the best security teams in the world). It is usually the business who prevents the security team from implementing the controls they want due to real or perceived friction for business operations. If you want to be frustrated at Twitter, go ahead. But I will be highly surprised if future articles about this incident reveal that Twitter's security team had any part in this story.
Edit: and this is why I didn't link to the other article.
I feel like Twitter should've always audited verified accounts incredibly thoroughly since it seems so easy to just pop in and do whatever you want.