Some WAFs in the market offer rate limiting features designed to stop automated API attacks. They do this by implementing a centralized control plane with shared state and counters in the cloud to enable over time detections. However, these solutions still struggle with the unique challenges posed by API attacks, leaving customers frustrated enough to post about in on reddit:

The problem with many WAFs is that they are not architected to handle high volumetric attacks because they are over-reliant on a cloud control plane. Let's take an example of a typical legacy agent based WAF based on this type or architecture:

Cloud based detections are too slow

First, WAF agents rely on the cloud to detect attacks.  WAF agents are thin clients - they run some basic detections and then forward metadata to the cloud in order to optimize for performance and latency.  However, this approach means that any behavioral based detections (again, going back to the credential stuffing example) can only be detected in the cloud, and not locally at the agent because the agent does not have state or awareness of what is happening.  Attackers can take advantage of this type of system by sending attacks in at high rates in a distributed manner, getting in high volumes of attacks before the agents can check in with the cloud.

The Cloud is a single point of failure

Second, legacy agents have a single point of failure when it comes to detection - the cloud.  Because all the state is stored in the cloud, if the cloud goes down then all behavioral based detections stop working as well, as does any blocking and threat mitigation of these types of attacks.

Impart has decentralized the agent

We designed Impart from the ground up to solve these problems using a next generation decentralized architecture - an agent mesh.  Unlike traditional distributed systems which utilize a hub and spoke architecture (centralized control plane, distributed data plane), Impart is designed as a completely decentralized system that does not require a central control plane.

Instead of using centralized cloud communications to share and distribute state, our agents can share state directly with each other, as well as with the cloud.  The agents can also elect a leader to check in with the cloud so that not every agent has to update the cloud with the shared state, which is more efficient from a load perspective.

‍

What this means for security teams is two things:

Faster detection and response

First, Impart is able to detect and respond to attacks much more quickly than solutions based on legacy agents because we are not reliant on a round trip check in with the cloud to share state. In the example provided above, when a single inspector (our agent) detects an attack, it immediately shares this information with other agents in it's group. This allows all the agents to know when a single agent is experiencing an attack, and drastically reduces the time to detect an attack such as credential stuffing.

This matters in the real world.  Credential stuffing attacks are typically rapid, with attackers using off-the-shelf automation tools to generate and send numerous requests in a short time. Speed of detection is crucial in these scenarios.  In a recent deployment, Impart was deployed alongside a legacy agent based WAF and found that the it was not identifying or respond to prolonged attacks quickly enough. Thousands of credential stuffing attacks per hour slipped through before the  legacy agent based WAF could react, whereas Impart identified and acted on these attacks almost immediately.

Improved resilience and availability

Second, Impart is able to withstand an outage to the cloud without impacting behavioral detections, or reporting and analytics.  If the cloud has a problem, detections continue with all relevant metrics being captured and shared amongst all of the agents.  Whenever the cloud returns to normal, all of that shared state can be backfilled by the agents to the cloud, or sent locally by those agents to the customer's SIEM. This matters because most enterprises don't want to pin the reliability of their security tooling to the reliability of a single cloud provider. With this type of architecture, a customer's detection and response capabilities remain intact no matter what is going on in their WAF's control plane.

Reflecting on our journey at Impart, it's clear that the landscape of API security requires innovative solutions. Traditional WAFs, with their cloud-dependent architectures, simply can't keep up with the fast-paced, automated nature of modern API attacks. Our distributed control plane approach not only accelerates detection and response times but also ensures resilience even during cloud outages. It's been incredibly rewarding to see how our solution makes a real difference in protecting businesses from API threats.

If you want to learn more about our unique approach, sign up for a demo today!

‍

‍

‍

Want to learn more about API security? Subscribe to our newsletter for updates.

Recently, Dell faced a significant data breach, where a threat actor exploited API vulnerabilities to steal 49 million customer records. This incident not only underscores the growing threat of API abuse but also highlights the necessity for robust security measures to protect sensitive data.

In this blog post, we will delve into the details of the Dell data breach, identify the specific API vulnerabilities exploited, and discuss how tools like Impart can address these types of security flaws.

Summary of the Dell Data Breach Incident

Dell recently experienced a significant data breach, with 49 million customer records stolen via a partner portal API. The threat actor, known as Menelik, exploited the API by registering fake companies, gaining access within 48 hours without verification. Once inside, Menelik used a program to generate service tags, sending up to 5,000 requests per minute over three weeks to scrape customer data, including names, order numbers, and warranty information.

The stolen data, comprising details of various Dell products like Inspiron Notebooks and Latitude Laptops, was put up for sale on the Breached hacking forum. Despite notifying Dell about the vulnerability on April 12th and 14th, Menelik continued harvesting data until the company addressed the issue two weeks later.

Dell confirmed receiving the threat actor’s emails and stated that they were already investigating the incident before being notified. The company has since engaged law enforcement and a third-party forensics firm to investigate the breach.

This breach highlights a growing trend of API abuse in data breaches. Similar incidents have occurred with Facebook, Twitter, and Trello, where APIs were exploited to scrape sensitive data due to inadequate rate limiting and security measures. This underscores the critical need for companies to implement robust API security practices to protect against such vulnerabilities.

API Vulnerabilities Exploited in the Dell Data Breach

The Dell data breach exploited several key API vulnerabilities, specifically from the OWASP API Security Top 10 2023 edition:

1. API1:2023 - Broken Object Level Authorization:
   • The partner portal API allowed access to sensitive order information without proper authorization checks, enabling unauthorized access to extensive customer data.
2. API2:2023 - Broken Authentication:
   • The API allowed new accounts to be registered with minimal verification, permitting the creation of fake companies to access the portal.
3. API4:2023 - Unrestricted Resource Consumption:
   • The absence of rate limiting allowed the threat actor to send up to 5,000 requests per minute, facilitating large-scale data extraction over three weeks.
4. API9:2023 - Improper Inventory Management:
   • Inadequate monitoring and detection systems allowed the threat actor to exploit the API and scrape data without detection for an extended period.

How Impart Addresses These types API Security Flaws

Impart takes a proactive approach to securing APIs, effectively addressing the vulnerabilities highlighted in the Dell data breach:

1. API1:2023 - Broken Object Level Authorization:
   • Impart Solution: Impart can protect against BOLA attacks by detecting enumeration attempts by attackers who created valid company accounts and API tokens,  then used those API tokens to enumerate through different service tags.  Impart can limit enumeration attempts using any combination of user attributes, such as API token, IP address, headers, ASN, and many others.  These hash patterns can be defined easily in code using built in hash pattern functions.
2. API2:2023 - Broken Authentication:
   • Impart Solution: Impart can protect against abuse from newly created accounts (in this case, accounts less than 48 hours) by adding new accountids (typically an API parameter or query string going to an account creation endpoint) to a dynamic runtime list which has more aggressive security monitoring and rate limiting in place.  Unusual activity from accounts from using these parameters or query strings can be monitored and prevented.
3. API4:2023 - Unrestricted Resource Consumption:
   • Impart Solution: Impart can rate limit the number of requests using any combination of user attributes, such as API token, IP address, headers, ASN, and more.  Rate limiting thresholds can be dynamically adjusted based on request history using dynamic runtime lists.
4. API9:2023 - Improper Inventory Management:
   • Impart Solution: Impart’s API Discovery feature maintains continuous inventory of all API endpoints.  This helps security teams better understand what APIs they have, what their purpose is, and how they work.

Conclusion

The Dell data breach serves as a stark reminder of the vulnerabilities inherent in APIs and the devastating impact they can have if left unaddressed. By understanding and mitigating these vulnerabilities, companies can better protect their sensitive data and avoid similar incidents. Impart's comprehensive approach to API security provides robust solutions to the vulnerabilities highlighted in this breach, ensuring that organizations can safeguard their APIs against abuse and maintain the trust of their customers.

Sources:

‍