It’s no exaggeration to say that, when it comes to API security, there are a lot of challenges. Not only are attacks that exploit vulnerabilities in APIs
on the rise, but there is good reason to believe that API vulnerabilities will be among the most common sources of security breaches in the coming years.
In some ways, the nature of APIs makes these risks inevitable. APIs can be designed in a variety of ways, meaning there is little standardization. This results in a “wild west” of code behind API requests, making it difficult to enforce best practices or mitigate security risks at the code level – especially when using siloed tools.
At the same time, ever-increasing adoption of distributed systems and cloud-native architecture means that APIs are handling more and more data. By 2025,
according to Gartner, 95 percent of new workloads will be deployed in distributed, cloud native environments. APIs will be the glue that holds those environments together by allowing applications to share data both internally and externally. The result will be even greater levels of risk if your API gateway is not configured securely.
Those are the key challenges we face going forward when it comes to API security. To understand how to address them, however, it’s worth looking at how prior API attacks worked – Specifically major API-related security hacks that took place in 2021. By looking at how attackers have exploited APIs previously, we can gain a better sense of what’s needed to keep APIs secure in the future.
Let’s explore the top 5 API security breaches of 2021, and the lessons they teach us about modern API security.
Parler API hack
In January 2021, Parler, the social media platform, had its data exposed to the world at large due to what Wired called “
an absurdly basic bug.”
That bug (actually, you could argue that it was more of a fundamental API design flaw than a coding bug) came in the form of a lack of authentication for the Parler API. Because the API allowed third parties to request data without any type of authentication for those requests, malicious actors were able to guess the URLs where private information was hosted on Parler, then download it without having to log in.
The lesson here is dead-simple: If you’re going to create an API that lets people request data from across your app, make sure the requesters at least have to authenticate using tokens or passwords.
Clubhouse leak
Clubhouse suffered a
similar API breach in the spring of 2021 due to the same mistake: Exposing an API without authentication.
In Clubhouse’s case, an attacker used the API to download personal information; about 1.3 million users from a SQL database. Here again, the fact that the API was not secured with authentication tokens or passwords enabled unfettered third-party access to sensitive information.
LinkedIn breach
Data associated with 92 percent of LinkedIn users was
exposed in June 2021 in yet another example of API insecurity 101: The exposure of a public API that lacked authentication.
Using the authentication-free API, a malicious actor was able to scrape LinkedIn to download data of about 700 million users, then offer the data for sale on the Web. This data, which included email address and phone numbers, was a potential goldmine for hackers looking to target high-level executives/finance personnel in advanced phishing attacks
LinkedIn characterized the event as an “aggregation of data” rather than a breach, because all of the data was accessible on user profile pages. Still, the fact that an attacker was able to amass all of that data in a single breach speaks to the perils of building public APIs without sufficient authentication protections.
Referring to the Parler, Clubhouse and LinkedIn breaches, Portshift CEO Ran Ilany describes the risk of unauthenticated APIs this way: “As proper authentication wasn’t in place, essentially the entire database was exposed, meaning hackers were able to download it without any issues”
NoxPlayer attack
While requiring authentication for API requests is important, it’s not always sufficient to prevent API security breaches.
That’s the takeaway from an
API attack against NoxPlayer, an Android emulator. In this attack, hackers accessed the emulator’s update API in such a way that they could use it to install malware on users’ devices. Therefore, instead of downloading updates from the legitimate server NoxPlayer server, the API delivered malware-laden “updates” from the attackers’ server.
While authentication for API client requests would not have sufficed to stop this attack, building server identification into the requests could have. Thus, the NoxPlayer attack is a reminder of the importance of including endpoint visibility for both parties – the server and the client – during API transactions.
As Ran Ilany says, “This was a sophisticated attack. It piggybacked off a specific API vulnerability and installed malware onto the users' system when they downloaded what they believed to be a legit update.”
Log4Shell vulnerability
The infamous Log4Shell vulnerability, which researchers have
called the “worst cyberthreat in a decade,” was also facilitated by problems with API security.
To exploit Log4Shell, attackers issued an HTTP API request that exploited a bug in the Log4j logging framework. Using the request, they inserted arbitrary strings into logs, which in turn created connections between a compromised application and an attacker’s server. Once the connection was made, attackers deployed malicious code onto the target.
In Log4Shell’s case, the root of the vulnerability lies in a software framework, not the API itself. Still, stronger API authentication could at least have mitigated the attack risk by preventing unauthorized parties from connecting to applications that use Log4j. But because the API accepts unauthenticated requests, anyone can perform a “drive by” Log4Shell attack by simply issuing requests with malicious content to an application that runs a vulnerable version of the software.
Bolstering API gateway security
Protection against API security threats, like those that succeeded against businesses in 2021, hinges on
five key elements of API security:
- Vulnerability identification, so you know where vulnerabilities lie.
- Data encryption, to enhance data privacy.
- Authentication of all communications, to prevent unauthorized access via APIs.
- Security for internal as well as external APIs, both of which can lead of breaches.
- Continuous API security monitoring, to enable early detection of breaches.
Panoptica can help in delivering comprehensive Container, Serverless, API, Service Mesh and Kubernetes Security in a single platform. For API security specifically, Panoptica provides:
- Complete inventory of internal and external APIs.
- API policy creation to create rules which prevent attacks from succeeding
- Automated Fuzz Testing, results shared with Dev via their tools.
- Detailed API security posture information with actionable insights.
Sign up for the
free tier of Panoptica today!
And don’t forget to follow us on
Twitter and
LinkedIn to stay up to date with the latest developments!
