They say, “Experience is the best teacher.” Well, they never said it had to be your experience. If we look closely, there are lessons to be learned from these five fateful API attacks that can help any organisation secure its APIs better.
Here they are.
- Zendesk 2017
The scenario: The helpdesk ticketing platform Zendesk was exposed to attackers thanks to a SQL injection vulnerability in a GraphQL endpoint. A second flaw would allow attackers to, “steal data from any table in the target Zendesk account’s RDS, no SQLi required.” Security platform Varonis reported the bugs to Zendesk, and the company was able to repair the damage within a week. No sensitive data was exposed, but had the vulnerability been discovered and exploited by malicious actors, customer comments, conversations, email addresses and tickets could have been compromised.
The solution: GraphQL is susceptible to injection attacks for a number of reasons. It introduces new processing steps – the parser, the gateway and the sub-graph resolvers – which can each be exploited as an attack vector. It also turns multiple API calls into a single call, so more SQL injection damage can be done with a single stroke. Protections against this are basic; sanitize your database inputs, use stored arguments or prepared statements which cannot be interpreted as code and apply the principle of least privilege to all database clients.
- Dropbox 2022
The scenario: This notable API attack started out as a phishing scam. In October of 2022, Dropbox was hit by a malicious actor who illicitly gained access to their GitHub source code repositories and accessed “a few thousand names and email addresses belonging to Dropbox employees, current and past customers, sales leads and vendors.” Of note to this article is that the loot also contained several API keys, used by Dropbox developers, which were stored inside.
The solution: A couple of things could have prevented this, starting with basic MFA precautions. Secondly, anti-phishing awareness training would have been in good order, as the hacker gained access by getting the developer to click a malicious link in a fake “CircleCI” email, and then authenticate on a spoofed CircleCI site. But most important of all was the way the API keys were ultimately stored. It is best practice to not hardcode API keys and other credentials directly into the source code, for this very reason. To detect instances of this in your source code, use code analysis tools to ferret them out.
- Twitter 2022
The scenario: This API hack led to the breach – and sale – of millions of Twitter users’ personal information online. In one of the biggest API heists of the past several years, threat actors exploited an API vulnerability on Twitter which allowed them to manipulate the “discoverability” function to access a user’s Twitter ID with just an email and a phone number. Ultimately resulting in 5.4 million breached records, this zero-day attack was followed by another (leveraging the same vulnerability on a different API), bringing the total count to nearly 7 million records. Twitter patched the initial vulnerability six months after it was discovered.
The solution: To solve systemic API problems, systematic solutions are needed. Organisations need an API security program that regularly scans for vulnerable APIs, including those that are open source and public facing, in real-time. Rather than simply build a firewall around them, the next step would be to continuously test, verify, and triage these APIs at runtime so that the company is confident of the safety of their release.
The Future of API Security
As APIs continue to grow, evolve, and spread, so do API attacks. The simple “one-and-done” methods of the 2017 Zendesk SQL attack are giving way to more long-term, “low-and-slow” exploits. Traditional rule-based and signature-based technologies fall short of catching attacks that work via subtle malicious behaviours, poking around at weak spots undetected for months. Attackers have time on their hands, and they’re willing to wait for Big Game.
The solution? In addition to maintaining best practices such as the ones listed above, next-level API security needs to have runtime protections in place such as:
- Fuzzing to identify vulnerable code.
- Logging and monitoring to establish baselines and identify anomalies.
- Mediating APIs with API gateways to increase visibility.
- Encrypting the data sent by APIs for multi-layer defence.
- Externalize access controls and identity stores – never use API keys to authenticate.
Businesses have been quick to cash in on the API goldrush, but the speed of adoption has left API security behind. From simple exploits to more advanced reconnaissance tactics, attackers have not hesitated to fill those gaps. By learning from the API mistakes of the past – and anticipating the attacks of the future – we can scale API security to fit the demands of its growth.