In the previous blog post, I introduced the Denial of Wallet bug class and what's in it for attackers.

Whenever I discuss DoW in security meetups or with peers, I find a recurring misconception. "Denial of Wallet is a serverless function attack vector. If you don't use serverless functions, you don't need to worry about it."

It's not their mistake.

News and security blog posts mostly associated DoW attacks with serverless platforms. Typical examples are static websites hosted on serverless platforms that generate huge bills after a DDoS attack, web scraping, or many spam account signups.

Even academic papers on the Denial of Wallet focus on serverless platforms only. (Ex: One, Two, Three, Four)

How DDoS Leads to DoW in Serverless Functions

The most common (and easiest) way to generate a massive bill for serverless customers is through DDoS.

Let's analyze a sample DDoS attack.

1. The serverless function is accessible from the Internet. DDoS traffic reaches the function

2. The cloud platform auto-scales the function to respond to each request

3. The cloud platform charges (a massive) fee because of the usage. This charge includes both compute and bandwidth usage.

Let's examine step 2.

In step 2, the cloud provider lacks the context of traffic. From their point of view, requests from L7 DDoS can look the same as those from massive Black Friday/Christmas sales. So, they auto-scale the serverless functions to handle the traffic.

Once the DDoS attack is over, you will end up with a massive cloud bill- as the cloud provider assumes it was genuine traffic, and they helped to seamlessly "scale up" the backend to meet the needs.

Suppose you remove the "auto-scaling" part from this attack scenario and keep the concurrent execution of functions static; a DDoS attack doesn't lead to a massive cloud bill. The attack might take down your application. But it will not skyrocket your serverless compute charges.

Hence, rapid provisioning of resources (aka scaling up) leads to more cost.

DoW In Cloud Native Services

Cloud Native services often abstract the infrastructure underlying it. This abstraction also includes scale-up and scale-down operations.

Let's take the example of a cloud-native blob storage - Amazon S3.

Do you want to store 1 GB of data? You can. Do you want to store 10 TB of data? You absolutely can. In both cases, you'll not know the underlying infrastructure, such as the number of storage disks or servers used. All you know is that Amazon S3 is a reliable and durable cloud storage system for storing your files.

But with abstraction comes grey areas. Pricing is one among them.

Cloud providers have to come up with "creative" pricing that pays for the underlying infrastructure and other overhead costs (salaries to devs developing the cloud services, profits, etc). More importantly, this pricing must be based on parameters visible to cloud customers.

Often, this includes parameters like the geographical region, number of requests, and data transfer involved.

Let's take Amazon S3, for example, again.

You have a separate price for the storage (and the storage class) used.

You have a separate price for the number of requests sent to S3.

You have a separate price for the data transfer from the bucket to the Internet (aka anyone downloading the files).

Let's look closely at the cost of requests.

Cost of Misconfigured Amazon S3 Bucket

I created an empty S3 bucket and intentionally misconfigured it to list the objects.

Let's demo what happens if an attacker sends a million requests.

Amazon S3 service assumes that the traffic the bucket receives is intentional and auto-scales underlying infra (when necessary) to respond to a million requests.

The Cloud Provider lacks the context of traffic. The Cloud Customer lacks control over the underlying scaling configurations of cloud-native services.

At the end of attack Amazon S3 handling a million unauthenticated requests, my empty bucket (with object listing enabled) got me a bill of USD 5.

Key Takeaways

Any cloud or cloud-native service where attackers can trigger the scale-up of resources is susceptible to the DoW bug class.

Serverless functions and platforms are infamous for DoW attacks. Cloud-native services are kind of "serverless" because the underlying infrastructure is abstracted from customers and auto-scaled by cloud providers to handle traffic.

If you're threat modeling serverless applications or integrating cloud-native services with your systems, you should consider the DoW bug class.

In the next blog post, I'll talk about how weaponizing internet bandwidth can make cloud customers bleed money.

If you liked this post, please forward this email to your friends working in Cloud Security or share it on social media.

If you wish to get the next blog post to your inbox, subscribe to this newsletter.