As you may have seen in the news, a hacker stole 49 million customer records from Dell. The attack wasn’t novel or sophisticated. Instead, the attacker used a business logic flaw and an API to scrape 49 million records from Dell.

How did they do it?  Here is the attack flow.

The attacker registered for an account within the Dell ecosystem to be a reseller/partner. They weren’t going to be. But Dell didn’t perform any checks, and within 48 hours, the attacker had a valid account.

Next, the attacker found an API endpoint that allowed “partners” to input a Dell service tag. The API would then provide them with customer details, such as name, address, phone number, etc.

Since the Dell tag is only seven characters long and alphanumeric, the attacker created a script that would send 5,000 randomly created 7-character strings a minute to the API. With no rate limit or API monitoring, the attacker could harvest over 49 million customer records without anyone detecting this activity.

This attack illustrates why API protection is so complex and why you need a tool like Salt to help. Let's review the attack again, but this time, consider how a few changes and the addition of Salt would have detected and possibly stopped this attack.

Account registration. In API attacks, it is common for the adversary to create an account within the system and use that as the entry point for their reconnaissance and attack.  In Dell’s case, this was not an API problem but a business logic problem. The system that grants supplier/partner access needs to validate and, dare I say it, have a human check to see if the person/company signing up is legitimate.

If Dell had a tool like Salt monitoring their API, this attack would have been detected and thwarted. Here is why. When Salt monitors your API, it uses ML and AI (not just buzzwords; see patent) to create custom templates based on our algorithm that align with the API's functions. Thousands of attributes go into this template. But what makes Salt unique is a second algorithm called “User Intent.” This algorithm learns what normal user behavior is within your application and these APIs.

In this case, Salt would have learned that a typical supplier/partner queries the Service Tag customer lookup API maybe four times a day or maybe four an hour at most. The alarm bells would have been going off as soon as the first 5k request was received.

If you would like to learn more about Salt and how we could provide you with API discovery, governance, and protection, please contact us, schedule a demo, or check out our website.

The post The Dell API Breach: It could have been prevented appeared first on Security Boulevard.