Researchers discover over 3,000 mobile apps exposing Twitter’s API keys
Cybersecurity researchers have discovered over 3,000 mobile apps exposing Twitter Inc.’s application programming interface keys that can be used to access or take control of Twitter accounts.
Detailed by security firm CloudSEK, 3,207 apps were found to leak valid Consumer Key and Consumer Secret keys. 230 apps, some of which are described as belonging to unicorn startups, were found to leak all four Twitter authentication credentials that could be used to fully take over Twitter accounts.
With full access, an attacker would have the ability to perform actions such as reading direct messages, retweeting, liking, deleting, and deleting and adding followers, as well as the ability to change account settings and the image of account display.
The researchers explain that API key exposure is typically caused by errors in which developers embed their authentication keys into the Twitter API, but then forget to remove them when releasing the mobile app.
By exposing API keys, the risk of exploitation is real. A malicious actor with access to the API keys can use them to create a “Twitter bot army” that could be used to spread misinformation or used in a phishing scam.
Researchers highlight a recent case where Twitter was exploited to promote a “fake suspension notice” phishing scam. In this case, verified Twitter accounts were used to give credit to the scam.
The researchers concluded that it is imperative that API keys are not directly embedded in code and that developers must follow secure coding and deployment processes. Processes include implementing a standardized review procedure to ensure accurate versioning, key masking to increase security, and API key rotation to reduce the threat of key leaks.
“There are only two ways to solve this problem,” David Stewart, chief executive of mobile app protection firm Approov, told SiliconANGLE. “Either adopt a mobile security solution that allows you to store your API keys off-device and only provide them when needed, or require an independent second factor to be present alongside the API key to access backend data and resources – ensuring that API keys can’t be abused even if they leak.