This is a follow-up blog to a great API World event a couple weeks ago in San Jose. To that end, I’ll continue on the topics of Mobile API Security, and the nearly incredulous lack of even the most basic of security in major mobile apps and their APIs. This blog will explore several recently discovered major Twitter API vulnerabilities, and take you through concrete steps on how to easily prevent exploit and keep your mobile apps, APIs and SDKs secure.
October certainly wasn’t a good month for Twitter security. It was revealed that Jack Dorsey’s own Twitter account was hacked. He would later blame the breach on an unnamed mobile carrier for allowing a SIM swap attack, while NIST has been warning about Twitter’s low-grade form of 2FA-based account verification practically since Al Gore invented the Internet.
Twitter API Vulnerability
Then just a few days later a major Twitter API vulnerability was discovered in Twitter’s mobile APIs. The net result of the vulnerability is a compromise of Twitter’s OAuth sequence for their ‘social login’ functionality. After compromising the auth sequence, whitehat hackers were able to successfully take over Twitter accounts, all with a pretty simple man-in-the-middle technique.
Like the Uber API vulnerabilities I wrote about previously, this was all possible with legitimate certificates and credentials, which once compromised gave the attackers free rein over the account.
The root cause of the issue was traced back to an outdated 3rd party library which was packaged inside an earlier version of the Twitter Kit iOS SDK. This is a very popular mobile SDK, which is currently embedded in thousands of 3rd party apps around the world, so there may still be quite a large number of apps that still exposed the Twitter API vulnerability. If you embed the Twitter SDK in your app, I highly recommend you check the app to make sure that the version of the SDK you implemented had already updated the library.
Another problem that exacerbated the situation is that the incomplete/incorrect implementation of Certificate Pinning. That enabled the attacker to insert themselves in the auth sequence, using a legitimate cert. They then routed traffic to their own domain which the app permitted because domains were not validated (only digital signatures). So the attacker was able to use a valid cert and his own (malicious domain), which was accepted by the app (thus bypassing the certificate pinning which should have detected the domain switch). As with previous blogs, here are some mobile dev best practices to keep your APIs and apps safe and healthy.
- Implement Certificate Pinning with strict chain inspection settings, especially for sensitive connections such as authentication
- Always implement multiple detection techniques where possible. Hackers are constantly tweaking their techniques to evade detection
- Implement MFA on all sensitive flows and actions, or at minimum leverage In-app pin codes or biometrics to provide a first layer of defense. Device pincodes are unreliable because you can’t control or enforce them in a BYOD world. .
- Encrypt and obfuscate your code to make it harder for attackers to collect data or reverse engineer or tamper with your apps.
Whether you’re a mobile developer, SecOps, DevOps, or just a non-coding product dude like myself, you can implement all the above and much more on Appdome – all without writing a single line of code. Like I say in every blog I write, don’t take my word for it. Create your account and see for yourself.
As promised above, here’s a video showing how to prevent each of the attack methods described above, using a combination of data at rest encryption, proxy detection, certificate pinning (server and client-side), MFA, and code obfuscation – all in less than 3 minutes end-to-end.
Happy Fusing!
