Over recent years, the popularity of serverless computing has exploded, as organizations continue to realize the benefits of this easily scalable, cloud-based infrastructure model.
In fact, one study estimates that the number of serverless customers will exceed seven billion by 2021.
With this trend, however, comes the added risk of cyber-attacks specifically targeting cloud-based infrastructure.
Counted among this growing list of exploits is the Denial-of-Wallet attack – a lesser-known but easy-to-execute technique that that can leave victims severely financially damaged.
What is a Denial-of-Wallet attack?
Denial-of-Wallet (DoW) exploits are similar to traditional denial-of-service (DoS) attacks in the sense that both are carried with the intent to cause disruption.
However, while DoS assaults aim to force a targeted service offline, DoW seeks to cause the victim financial loss.
In addition, while traditional web-based distributed denial-of-service (DDoS) attacks flood the server with traffic until it crashes, DoW attacks specifically target serverless users.
Contrary its name ‘serverless’ does not mean the user isn’t connected to a server, but rather that they pay for access to a server maintained by a third party.
Denial-of-Wallet attacks exploit the fact that serverless vendors charge users according to amount of resources that are consumed by an application, meaning that if an attacker floods a website with traffic, the site owner could be landed with a huge bill.
Read more of the latest cloud security news
An attacker doesn’t personally gain from DoW attacks in the same way they might through other exploits – except, of course, from causing their target financial distress.
“When you have servers in a data center and an attacker just wants to bring you hurt, they can DDoS you and your site goes down,” explains Scott Piper, AWS security consultant at Summit Route.
“When you run in the cloud, an attacker can do things such that your site might stay up, but you’ll be bankrupt.”
Make it rain: Denial-of-Wallet attacks can cause huge financial losses for serverless users
What is serverless computing?
Serverless computing is when backend services are supplied on a ‘used-by’ basis. The company pays a serverless vendor to provide the infrastructure and maintain the server.
Popular serverless brands include Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP), which together count many millions of users.
Serverless pros
There are obvious upsides to using a serverless mode, one being that it allows smaller organizations to get their services live without the need to invest in hardware.
Another positive is that because the service is provided on a pay-as-you-go basis, the user isn’t charged for any bandwidth or resources they don’t use.
YOU MIGHT ALSO LIKE A guide to spear-phishing – how to protect against targeted attacks
“Serverless computing is stateless architecture for stateless applications, Erica Windish, founder of serverless vendor IOpipe, told The Daily Swig. ”I think there’s security benefits to such an architecture, as it enforces immutability.”
Because serverless environments are constantly being updated, this makes it difficult for malware or nefarious applications to stay dormant inside the infrastructure for too long.
Serverless cons
Employing serverless computing does, however, come with risks. For example, Windish notes, it can sometimes hinder the opportunity to perform an in-depth infrastructure analysis.
“Serverless also creates some challenges around security observability, such as if a compromised container is destroyed every five minutes to eight hours, how do you do a post-mortem? There are no tools to freeze or save those environments for analysis,” she said.
The serverless model also causes the user to rely on the vendor’s security practices. If the server is insecure, Denial of Wallet isn’t the only cyber-attack that administrators should be worrying about.
How can you spot a Denial-of-Wallet attack?
A victim will likely notice something is up when their bill is higher than expected. However, there are ways you can stop a Denial-of-Wallet attack before it becomes too costly.
In the first instance, Piper of Summit Route suggests setting up a billing alert. This will notify the user if they are exceeding a predefined spending limit.
Users should also employ limits to mitigate any runaway code, especially lines that can trigger an infinite loop scenario.
“Many people have stories about infinite loops happening in AWS that caused resources to be created over and over again, or a Lambda to trigger that caused itself to trigger again,” Piper said.
“This is a common enough problem that the Cloudwatch Event Rule documentation even has a warning about it.”
He added: “Without these limits an attacker could try to spin up a million EC2s, but due to these limits, the attacker might only spin up a few dozen EC2s.”
Serverless users should put limits in place to trigger billing alerts
Where does the term come from?
The origin of the DoW attack can be traced back to 2008, Piper told The Daily Swig, when it was termed ‘Economic Denial of Sustainability’ in a blog post by Rational Security.
Piper suggests that the term ‘Denial of Wallet’ was first used in 2013, pointing to a Twitter user named @gepeto42.
How can you protect against Denial-of-Wallet attacks?
There is no actual bulletproof protection against Denial-of-Wallet attacks. Instead, serverless users should put in place the above limits to trigger alerts should they become a target.
The OWASP Top 10 Serverless Threats (PDF) describes the risk of DoW:
To ‘protect’ against such attacks, AWS allows configuring limits for invocations or budget. However, if the attacker can achieve that limit, he can cause DoS to the account availability.
There is no actual protection that is not resulting in DoS. The attack is not as straightforward in traditional architecture as in serverless. Therefore, the risk should be high.
Measures should also be put in place to secure credentials associated with a serverless account.
Piper said that if an attacker is able to make costly API calls to a victim’s AWS account, “they likely also have the ability to delete all your files in S3, terminate all your instances, and cause other mayhem that has the potential to cause worse business impact”.
He suggested mitigating against this scenario by implementing least privilege services, enforcing multi-factor authentication on all users, and implementing service control policies.
