Cybersecurity researchers have discovered more than 3,000 mobile apps exposing Twitter Inc. application programming interface keys that can be used to gain access to or take over Twitter accounts.
Detailed today by security firm CloudSEK, 3,207 apps were found to be leaking valid Consumer Key and Consumer Secret keys. Some 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 take over Twitter accounts fully.
With full access, an attacker would gain the ability to perform actions such as reading direct messages, retweeting, liking, deleting and removing and adding followers, along with the ability to change account settings and the display picture on the account.
The researchers explain that the exposure of the API keys is typically the result of mistakes in which developers embed their authentication keys in the Twitter API but then forget to remove them when the mobile application is released.
By exposing the API keys, the risk of exploitation is genuine. A malicious actor who has access to the API keys can use them to create a “Twitter bot army” that could be used to spread false information or used in a phishing scam.
The researchers highlight a recent case where Twitter was exploited to promote a “fake suspension notices” phishing scam. In this case, verified Twitter accounts were used to lend credence to the scam.
The researchers concluded that it is imperative that API keys are not directly embedded in code and that developers should follow secure coding and deployment processes. Processes include implementing a standardized review procedure to ensure accurate versioning, hiding keys to increase security and rotating API keys to reduce the threat of leaked keys.
“There are only two ways to solve this problem,” David Stewart, chief executive officer of mobile app protection company Approov, told SiliconANGLE. “Either adopt a mobile security solution that enables you to store your API keys off the device and deliver them only when needed or require a second independent factor to be present alongside the API key to access backend data and resources – effectively ensuring that API keys can ‘t be abused even if they leak out.”