How State-sponsored Actors May Have Exploited Twitter’s Public Endpoint
In our continued push to help companies with APIs realize that 95% of API vulnerabilities are due to human error and not “hacks,” this week, we dive into an issue that Twitter found last December, but is only now reporting. The Twitter API vulnerability is particularly interesting because it didn’t involve a breach. It was a coordinated effort on a public endpoint that had a flawed design and shared too much information.
Let’s get into the details. When you create a new Twitter account, there is an option to connect with people you may know. This leverages an endpoint that matches phone numbers in your contacts to Twitter accounts for those people who have enabled the “Let people who have your phone number find you on Twitter” option. According to Android Community, that totals about 17 million accounts.
On the surface, we understand the reasoning for Twitter’s endpoint, but we can also see the privacy pitfalls of being able to find someone’s Twitter handle by just a phone number. Many people use Twitter as a personal outlet and don’t want that side of their lives linked to their professional lives. This “dual persona” issue points to people’s dual private and professional lives that are both connected to their mobile phones. Mobile phone numbers are used for authentication with countless platforms today. They have become a singular source of accountability.
While using a mobile phone number may not be the best way to maintain privacy, it means a bad actor would still need to know your phone number to attempt a targeted cyberattack. Well, Twitter’s endpoint did not help by allowing anyone to use their phone number endpoint as often as they wished.
In Twitter’s public response to the exploit, they state:
While we identified accounts located in a wide range of countries engaging in these behaviors, we observed a particularly high volume of requests coming from individual IP addresses located within Iran, Israel, and Malaysia. It is possible that some of these IP addresses may have ties to state-sponsored actors.
So a “wide range” (yikes) of countries ran attacks where they made countless calls checking to see if there was a Twitter handle for 917-555-6590, then 917-555-6591, then 917-555-6592, and so on. This brute-force approach made it possible for potential “state-sponsored actors” to identify Twitter users personally. That’s it. This wasn’t espionage – it was using an API with a flawed design as expected.
While building an API off a flawed design is a rough start, there are still a few types of tests that could have helped reveal the foundational issues.
Preventive Measures for Twitter
- Load Testing – APIs should have intelligent, but strict, throttling rules. Test against those rules.
- SecOps Review – Security is especially important today for large, influential platforms such as Twitter. While you can’t reasonably have a security review of every new feature, or product change, we do think it’s reasonable for at least a cursory privacy and security review of a new public endpoint.
Some people may disagree with our second point, but Twitter seemed to agree in their remediation, “After our investigation, we immediately made a number of changes to the endpoint so that it could no longer return specific account names in response to queries.”
Yes – you can connect people without returning their account names.
A product innovation didn’t need to be stopped at Twitter. The popular social media platform simply needed to rethink the API’s response. In the maxim, “Everything should always be tested,” it really means that testing must go beyond uptime and performance. Twitter could have tested how their API should function in real-world scenarios, and that includes bad actors.
Explore Unlimited Internal API Monitoring from API Fortress to see how enterprises leverage Unified Functional, Integration, and Load Tests to create API monitors that detect and diagnose API defects and vulnerabilities before APIs go into production.