If you want to stick it to a startup that relies on serverless infrastructure, you may be able to inflict $40,000 in financial damage every month with a modest 1,000-node botnet.
That estimate comes from computer-science boffins Daniel Kelly, Frank Glavin, and Enda Barrett at National University of Ireland, Galway, in their recent paper, "Denial of Wallet – Defining a Looming Threat to Serverless Computing."
Denial of Wallet, or DoW, attacks aren't actually a widely recognized threat – as the authors observe, "No DoW attacks have been publicly recorded." But they have been reported as a consequence of deploying subpar code and concern about the possibility has been bandied about for the past few years.
So our three NUIG academics have set about trying to model how such attacks might work.
The term "Denial of Wallet," a nod to "Denial of Service," dates back at least to 2013, a year before Amazon launched its serverless Lambda offering. It became more commonplace around 2017, when adopted by OWASP. But worry about unanticipated charges in the context of cloud computing, often referred to as bill shock, dates back more than a decade.
In 2008, DoW was referred to as an economic denial of sustainability (EDoS).
Similar method, different results
DoS attacks and DoW attacks have different goals: The former is focused on exhausting computing resources while the latter is focused on exhausting financial resources.
A DoS attack may have the same financial effect as a DoW attack if a targeted company tries to spend the DoS away by paying for the IT resources to handle the crushing load of network requests. But the same isn't true for a DoW attack, where the defense is to stop, or control, spending.
Google Cloud (over)Run: How a free trial experiment ended with a $72,000 bill overnightREAD MORE
The three academics acknowledge there's much that can be done to mitigate the risk of DoW attacks, such as writing efficient serverless functions, setting time and disk usage limits, applying throttling on API calls, enforcing access controls, and utilizing libraries that offer defenses against application layer assaults based on ReDoS or the Billion-Laughs-Attack.
"However, this does not mitigate against potential attacks spanning long timescales and high volumes of attacking nodes, that will inevitably drive the function run time up," they claim. "Setting limits such as timeouts, disk usage and API throttling, shifts the attack from DoW (exhausting finances), to DoS (exhausting resources).
"Access control is only as effective as its difficulty in acquiring credentials. While administrator-specific functions may be safe, API endpoints accessible to account holders of an application are susceptible to exploitation by fake users."
Kelly, Glavin, and Barrett argue that a slow, leeching attack, designed to continually hit API endpoints to invoke functions, is the most effective way to bypass defenses tailored to DoS-style flood attacks, like rate limiting rules. They further contend that an effective DoW assault should consider not just the way specific serverless services operate but also whether the cloud functions being attacked have been poorly implemented.
"To fully realize the potential harm a DoW attack may be capable of, it should not be simply seen as a slow burning DoS attack," they say. "Instead it should fully exploit any oversights the developer may have made. If there is no limit imposed upon functions that process files, the run time of a function will increase."
And in the real world
For example, they note that because Microsoft Azure Functions does not let developers configure the memory allocation of a function like other serverless platforms, an attacker might be able to force an Azure Function to scale to a higher memory allocation to handle larger inputs.
To demonstrate the potential of such attacks, the boffins built a Serverless Platform Pricing Emulator. It's a Python program tied to Prometheus monitoring code that sits atop an OpenFaaS serverless deployment for testing the cost of function invocations on AWS Lambda, Google Cloud Functions, IBM Cloud Functions and Microsoft Azure Functions.
A modest bot-net of 1,000 nodes ... will cost an application owner between $400,000 and $500,000 if left unchecked for a year
Using machines running a Python script that issues GET requests to functions and then cycles its IP address, alongside the DoS tool Low-Orbit Ion Cannon, the uni trio devised a proof-of-concept attack based on a common serverless functions scenario – image reprocessing, which is to say creating thumbnails from a user-uploaded image.
With an image of 4032×3024 pixels from an Apple iPhone X, the boffins calculate a serverless function with a memory allocation of 512MB would have a run time of 2950ms. When they looked at how much this would cost over time, they found Google Cloud Functions cost the most, followed by AWS Lambda, IBM Cloud Functions and lastly Azure Functions.
"With a modest bot-net of 1,000 nodes, a slow rate attack of 2,000 requests per hour will cost an application owner roughly $40,000 after one month and between $400,000 and $500,000 if left unchecked for a year," they report. "The number of attack nodes simply linearly affects the financial damage. A botnet of 10,000 nodes will do the same damage in one month that 1,000 nodes would do in a year."
Now we just have to wait for someone to try a DoW attack in the wild, if that hasn't happened already and gone undetected. ®