How to Reduce Your Chances of an API Data Breach
Securing APIs doesn't mean closing them off, rather it's about ensuring only trusted identities have access.
Join the DZone community and get the full member experience.Join For Free
With more companies embracing APIs, they are fast becoming the weak link in the organizational security chain. In our post-Equifax world, APIs still fly under the radar of security professionals, and the future will only bring more incidents unless leaders adopt strategies and tactics to mitigate the inherent “openness” of APIs.
The Equifax breach was the result of a known vulnerability in the Apache Struts web framework but not all exposures are so easily identified and patched. There are numerous potential attack vectors with APIs — on average, there are 22 vulnerabilities per web application and they are so commonplace that OWASP has an entire list dedicated to the API Security Top 10.
Why Are APIs Vulnerable?
While the growing spread of APIs makes them a popular target, there are other factors that motivate bad actors to intensify their efforts. Unlike the browser-based applications of ten years ago, where most of the data processing was performed on the server, today’s mobile and web apps take advantage of powerful client hardware to do the work. Giving users a faster experience, this architecture also greatly increases the amount of client-server traffic.
More than ever, APIs are leveraged to serve up data to countless browser and mobile endpoints. For the sake of user experience, a social networking site or a food delivery app must constantly send and process multiple HTTP payloads, each of which offers the opportunity for a potential exploit.
Moreover, many organizations believe that API transactions are covered by server-level monitoring, gateway, and logging functions. They assume that if a web server is running behind a firewall, then the APIs going through it are secured too. The reality, as we will see below, is that the boundaries of a server have little to do with the potential attack surfaces available through APIs.
The Peloton Breach
This month, security researcher Jan Masters revealed a vulnerability in Peloton’s user account API whereby requests for personal data could be made without the system checking for authentication. This allowed access to a Peloton user’s age, weight, location, gender, workout data, and more.
These types of exploits aren’t new, and are common enough that they fall under four categories of the OWASP API Security Top 10:
- API2:2019 Broken User Authentication — Incorrect implementation of authentication mechanisms that compromises a system’s ability to identify a user.
- API3:2019 Excessive Data Exposure — Exposure of more object properties than necessary due to the lack of consideration of their individual sensitivities.
- API4:2019 Lack of Resources and Rate Limiting — Lack of restrictions against the size or number of resources that can be requested by a user.
- API10:2019 Insufficient Logging and Monitoring — Lack of tracking mechanisms that allows attackers to further attack systems, maintain persistence, and threaten other systems without being detected.
It is impossible to know what went on inside Peloton before and after the breach was disclosed, but we do know that a Zero Trust for API security model would have helped. Models like Zero Trust protect the entire business by breaking everything into identities and ensuring that the user, system, device, applications, and data are separately authenticated and trust is verified before allowing access or granting privileges. This same model should be applied to API security, leveraging of trust attributes, access controls, authentication controls, least privilege, etc.
Authenticate and validate that only trusted identities have access to the API at every step of the transaction process, from client to server, and that every interaction is logged in detail for future analysis and action. In Peloton’s case, these trusted identities may have included user, device, and user behavior validated against the data stores being accessed.
Peloton has since resolved a majority of the API issues, but it is not clear if anyone gained access to the exposed customer data or whether the company had the logging mechanisms in place to determine extent and notify affected users.
Venmo Data Exposure
Dan Salmon, a masters graduate specializing in information security, used a public Venmo API to scrape user data from live transactions. Over six months, he was able to capture millions of Venmo transactions and identify usernames, who they were doing business with, their mobile platforms, their most frequent interactions, and more. Like the Peloton breach, this exposure falls under OWASP’s broken user authentication and excessive data exposure risks but there is a twist that many security organizations overlook.
The aggregation of sensitive data can be just as harmful as the exposure of single objects. As the Venmo example demonstrates, one exposed transaction is not enough for a threat actor to exploit. But collecting more information over time (the most frequent Venmo users that the target interacted with) has the potential to fuel a spearphishing attack. This is an attempt by an attacker to convince the target to perform actions by sending an email purporting to be a friend.
The lesson here is that if your organization is only watching the digital door for direct attacks, it is missing out on the API transaction patterns that could identify risky behavior in the aggregate.
Apple Sign-in Exploit
Bhavuk Jain, a self-proclaimed full-time bug bounty hunter, discovered a bug within the “Sign-in with Apple” authentication feature whereby an attacker could take advantage of a loophole in Apple’s JWT implementation to use a victim’s email ID to gain access to their account. The problem lay within the lack of email validation by Apple’s servers (classified by OWASP as API1:2019 Broken Object Level Authorization) that could allow operations to be performed with the victim’s credentials instead of the actual owner of the account. The exploit was fixed but this had the potential for widespread impact, as Sign-in with Apple is mandatory for all apps that use third-party or social login services.
This case exemplifies the philosophical debate between APIs and security. Should ease of access take precedence over protection? Most organizations focus on the former, rushing to deploy as many services as possible without considering API endpoint security or understanding how transactions flow through the system. This is where up-front security planning helps, during the design and deployment phases of system rollout, to adopt the tools and processes necessary to capture API data and feed it back into SIEM tools.
Microsoft Teams Account Takeover
Cyberark researchers uncovered a subtle vulnerability in the way that Microsoft Teams handles GIF images and links. When a victim viewed a malicious GIF or clicked a link, the Teams authentication process allowed attackers to create a token that could be used to take over the victim’s account. Unlike the exploits above, this vulnerability required no actions on the victim’s part — simply viewing the malicious GIF in the Teams chat window was enough to compromise the account:
“The fact that the victim only needs to see the crafted message to be impacted is a nightmare from a security perspective. Every account that could have been impacted by this vulnerability could also be a spreading point to all other company accounts. The GIF could also be sent to groups (a.k.a Teams), which makes it even easier for an attacker to get control over users faster and with fewer steps.” - Beware of the GIF: Account Takeover Vulnerability in Microsoft Teams, Cyberark
Although this vulnerability was patched by Microsoft, this example shows that the security of third-party applications cannot be taken for granted.
In 2019, a former Amazon employee was charged with stealing more than 100 million credit applications from Capital One, the result of a misconfigured firewall that the organization had deployed within AWS. The Server Side Request Forgery (SSRF) attack tricked the firewall into relaying requests to a back-end service that executed commands that it should not have been allowed to do. The stolen credit applications resulted in 140,000 Social Security Numbers, 80,000 bank account numbers, and over one million Canadian social insurance numbers to be stolen by the employee.
SSRF attacks are the result of a widespread problem in public cloud computing, where services assume that HTTP server requests are to be trusted rather than suspected:
“For example, when you’d tweet this blog post, an avatar would show up for this post on Twitter. The image, title, and description come from the HTML that this page returns. In order to download that information, a Twitter server makes an HTTP request to this page and extracts all the information it needs. Until recently, their link expansion used to be vulnerable to an SSRF vulnerability.” - How to: Server-side request forgery (SSRF), HackerOne
These types of attacks could be prevented by requiring additional identifying information in requests sent to the server or through two-factor authentication. Either way, this case and the Equifax breach show that even widespread awareness of a vulnerability doesn’t mean organizations have taken steps to protect themselves against it.
Assessing and Mitigating Your Risk
Protecting against API-level attacks requires elevating their importance within your security culture and infrastructure. The following recommendations will help:
- Educate your CISO and security organization on the vulnerabilities posed by APIs. Most focus on the “popular” threat types, such as ransomware, insider threat actors, and nation-state actors, but ignore the prevalence and relative ease of API exploits. They may also overlook that APIs are often a gateway for all these threat actors.
- Enforce a Zero Trust model from the very beginning of system rollout and maintain it throughout the API’s life cycle, including monitoring deprecated versions.
- Include legacy and on-premises systems in your security plan in addition to new, cloud-based solutions — whether on the frontlines or the back-end, any API interaction point is a potential opportunity for exposure.
- Implement robust API logging mechanisms that run parallel to server-level tracking, capturing the details of who, what, and how users interact with your systems. Many assume logging is enough, but the data has to be used to detect and respond to cyber threats and operational risk like outages and errors.
The business and reputational realities of the examples presented here demonstrate a necessary shift in the thinking of API transformation projects. Security leaders and practitioners must enable their organizations to embrace the fact that securing APIs does not mean closing them off, rather it is about ensuring only trusted identities have access to prevent serious consequences in the future.
Published at DZone with permission of James Carder. See the original article here.
Opinions expressed by DZone contributors are their own.