For Hackers, APIs are Low-Hanging Fruit
By 2022, API abuses will become the most frequent attack vector, predicts Gartner. We’re already witnessing new API exploits reach the headlines on a near-daily basis. Most infamous was the Equifax breach, an attack that exposed 147 million accounts in 2017. Since then, many more API breaches and major vulnerabilities have been detected at Experian, Geico, Facebook, Peleton and other organizations.
So, why are API attacks suddenly becoming so prevalent? Well, several factors are contributing to the rise in API exploits. As I’ve covered before, the use of RESTful web APIs is becoming more widespread through digital transformation initiatives and SaaS productization. And, the data these touchpoints transmit can carry a hefty price tag. Unfortunately, cybersecurity has not sufficiently progressed, making APIs ripe for the hacker’s picking.
I recently met with Roey Eliyahu, CEO of Salt Security, to better understand why more and more APIs hacks are making headlines. According to Eliyahu, a general lack of security awareness means these integration points are a low-effort, high-reward attack target. Establishing protection against zero-day threats means increasing the visibility of API holdings, testing for broken authorization and instigating ongoing monitoring of runtime environments.
Below, I’ll review the top factors contributing to the rise in API exploits. We’ll explore some of the top reasons why API attacks are increasing and consider how a zero-day protection mindset can mitigate common API vulnerabilities.
Six Reasons API Attacks Are Increasing
APIs are now pervasive. At the time of writing, ProgrammableWeb charts over 24,000 public APIs. Digital transformation initiatives have added to the number of APIs in use—as have current trends in microservices development. API-centric SaaS software, also known as API-as-a-product, is contributing to this API obsession, too. An organization may now have hundreds or thousands of separate APIs tied to their internal- and external-facing microservices, meaning that the attack surface is quite expansive.
The value of APIs (and data) has risen. The value of data has increased. Thus, the value of APIs as a transmission mechanism has increased, too. This value is amplified for financial or health care services, which may carry very sensitive data. The prize becomes much bigger when sensitive data is funneled through an API, Eliyahu explains. “Hackers have figured out, ‘This is my meal ticket,’” he says.
There is a general lack of API security awareness. There are many attack vectors when it comes to APIs, and these are growing exponentially. Yet, the market is still 10 to 15 years behind in their API security maturity, Eliyahu estimates. Plus, more exploits may be hidden from the public discourse. “Incidents we’re seeing in the news are probably only a fraction of what’s going on,” he says.
Traditional IT security measures aren’t enough. Traditional security measures, such as web application firewalls (WAF), API gateways and API keys, aren’t a sufficient response, as they don’t account for data exposure by malicious users who are authenticated, says Eliyahu. Malicious patterns can be challenging to detect with these strategies alone—API security is a much bigger issue. As an analogy, API security involves much more than just locking the front door—it requires multiple locks for every entry point and an alarm system.
Many API catalogs are unknown. To complicate matters, many API catalogs are not fully documented. This could be due to shadow IT, pressure to deliver rapidly or the result of a large enterprise lacking a unified dashboard into all their holdings. Without a clear picture of the potential attack surface, how can you successfully arm your APIs?
Most APIs are vulnerable. Vulnerabilities are just as pervasive as the growth of APIs. In his work auditing client security ecosystems, Eliyahu states that 90% of the time, a significant API vulnerability is found within three days of investigation. Most APIs suffer from some form of broken authorization, data exfiltration, data overexposure or privilege escalation. Some extreme API vulnerabilities could result in a full account takeover.
Broken Object-Level Authorization
As you can see, all these factors combined mean APIs are low-hanging fruit for nefarious minds. But, what is the most common type of API attack? Eliyahu reports that number one on the OWASP top 10 API vulnerabilities list, broken object-level authorization, is perhaps the most routinely exploited hack. It’s simple and hard to trace.
This kind of attack involves manipulating API calls by changing a parameter so that callers can access information they otherwise shouldn’t. Exploiting broken object-level authorization could be as simple as altering a user ID to return data on a different user (as was the case in a recent Facebook Graph API exploit). In the case of bank account information, the repercussions of such data exposure could be severe.
Eliyahu repeatedly encounters different styles of this vulnerability in action. But, this hack is challenging to detect, as a fully authenticated user changing a single ID may not appear, at first, to be malicious behavior. In turn, discovering this vulnerability requires highly granular authentication checks to verify all potential avenues. “It’s very hard for developers to get it right,” says Eliyahu.
API Security Starter Steps
API security is challenging to implement, especially since security teams may not be used to protecting APIs. So, where do we start? Eliyahu recommends API owners first begin by taking stock of their total API inventory. Compile a complete discovery list of all APIs, methods and their payloads. Map out the connections and gain granular visibility into how the APIs function.
Next, test production APIs for broken authorization issues. Each API call may contain hundreds of parameters, each one responsible for fetching different data models. You must understand how IDs are being changed, verify scenarios one by one and test again with every code change. Since it’s nearly impossible to test all potential use cases, Eliyahu recommends starting with the most sensitive endpoints.
Of course, manual static analysis can only go so far. API practitioners will require some sort of automated runtime component to continually monitor how APIs are used, with traps to find hackers manipulating calls. “You can’t do all this in static code testing,” says Michelle McLean, vice president of marketing at Salt Security. “You have to see it in operation; you have to see it in runtime.”
Much like how a user account is disabled after multiple failed login attempts, APIs should similarly analyze the sequence of calls and be reactive to prevent suspicious behavior early on. To help enable this, “big data and AI could help reveal the bigger picture,” says Eliyahu.
Finally, shift security left. After you secure at-risk production endpoints and are guarding and monitoring sensitive production environments, then it’s time to consider how you can improve design standards to release more secure APIs.
API Security Awareness
The frequency of API exploits is increasing and likely won’t slow down anytime soon. Vulnerabilities are prevalent, yet most organizations have not yet advanced their API security awareness. Companies also lack visibility into their APIs. For example, it took Facebook a year to realize their API was leaking tokens; that oversight resulted in 50 million compromised accounts.
All these conditions are making APIs a primary attack target. As banks, cars, retail and more scenarios embrace APIs as connective tissue, taking a zero-day protection mindset will be critical to guarding the integrity of our digital (and physical) spaces. Thinking like a hacker to anticipate potential threats is part and parcel of a defensive posture.
One silver lining is that compared to other cloud-native technology, like Kubernetes, APIs allow security teams to better take the reins. “Security can be a lot more self-sufficient when it comes to getting good at API security,” says McLean. “IT security can gain control of their own destiny.”
