An unbridled Twitter API
CloudSEK has discovered that more than 10K apps were leaking API twitter data and a subset of 3207 apps were “leaking valid Consumer Key and Consumer Secret.” That means that the adversary may try to gain access trying App-based Authentication (API KEY + Secret) or even going to User-based Auth (you will need to add Access Token + Access Secret to the mix), to at least perform the following actions, as if they were account owners:
· Create and Read someone’s direct messages
· Create and delete tweets, retweets and likes.
· Access and Change account settings: manage followers, privacy settings, display picture,…
With the complete secret dataset, Mallory may go Webhook, which gives the adversary a finger over the pulse of the account workings. Read & Write wise, no less, of course. And having OAuth 1.0 settled, Mallory may go for OAuth 2.0.
However, it could get worse as far as out of 3207, 230 apps were leaking all the 4 Authentication credentials and in 39 of them access was granted. That means the adversary has find a new fresh twitter bot farm from where Zombie Twitter accounts might be recruited. Those zombies will be used to spread misinformation, spearhead malware attacks through verified accounts shared by legit followers, spamming and influence campaigns (let’s pump this crypto!) and last but not least, phishing a treasure trove of PII for social engineering campaigns. Is very effective, as the victims perceive the source as a trusted and known account to which they have safely interacted in the past.
Why, Oh Heavens, Why?
Well it seems that the root cause points to the usual suspects:
· Weak configurations and hard-coded remnants of keys in the code. It seems there was no source code review worthy of that name.
· Improper storage of keys: plain-text storage, in obvious and readable configuration files.
· Remnants of Testing: while in test mode, developers store the credentials in several XML files available to them to ease the process. If they are not thoroughly removed before deployment for production, you have sent your API secrets to world. Mallory will reverse engineer by decompiling the APK package to get them and harvest bulk API Tokens to set the Bot Army.
MItigation
Well the good news it is that is not rocket science, just have a SLDC program in place, inside a real DevSecOps framework that instills cybersecurity in the process from back to back. That will give you assurance that basic cybersecurity measures are being implemented in the Development Pipeline.
· CloudSEK recommends that developers use API key rotation, which at least which would invalidate the exposed keys after a few months.
· Source Code Review to avoid hard-coding of keys and strict Change Management procedure checks to ensure you are not leaking your secrets from inside your very own app.
· Use mobile device secure storage for API keys versus storing them in configuration files or inside your application tree. The best practice imho is using a secured server, which will act as a middleman between the user’s device and the end service server, validating the session for every request prior to forwarding the request. Any requests by the client device to the end service will be routed via this server. In this way, we avoid storing the secrets in the client device, therefore reducing our surface attack.
The Aftermath: Who is impacted?
CloudSEK shared a list of impacted applications with BleepingComputer, with apps between 50,000 and 5,000,000 downloads, including city transportation companions, radio tuners, book readers, event loggers, newspapers, e-banking apps, cycling GPS apps, and more.
Most applications publicly exposing their API keys haven’t even acknowledged receiving CloudSEK’s notices after a month since the cybersecurity firm alerted them, and most haven’t addressed the issues.
And remember that your AWS or GitHub may be connected to one of the secret leaking apps too…
