DoW: Moving to serverless... think again !
You might be considering to taking all your infrastructure to serverless. Why? because it costs less no need to worry about managing servers, Right?
Well now it's time for you to think once again before making this decision especially if you are a startup or an individual.
Ever herd of DoS or DDoS, you heard it right? well, this is quite similar to that thing but with a catch. In Dos/DDoS the main target of the attacker is to make the service offline. But in case of DoW(Denial-of-Wallet) it causes financial loss to the victim.
Understanding the attack:
DDoS and DoW are based on same theme i.e. to cause disruption. While in case of DDoS the attacker tries to flood the server with traffic until it crashes.
On the other hand DoW targets serverless users. It does the same, tries to flood the server with traffic but since it is serverless and can scale infinitely, it results in a huge bill to the owner. Causing a financial loss.
DoW tries to exploit the fact that serverless vendors charges the users according to the amount of resource that are consumed by an web service. If they any how flood the service they can make a huge financial loss to the owner.
But what'sthe profit of the attacker?
The attacker may not personally gain anything from these types of attacks, unlike others but may cause financial stress to the owner of the service by making you bankrupt.
Preventing an DoW to happen:
Unfortunately, these types of attacks can only be spotted when you see the bill. But to prevent you from becoming bankrupt with this attack, there are few measures that can be taken but still you will not be fully safe.
The first thing you can do is to applying a billing alert to your service. So, that you can get a notification when the service is exceeding a certain limit.
And if you have a line of code that triggers an infinite loop scenario then just find a way to stop it after a certain time or limit. Ok, wait let me try to explain...
Let's say you have a code that creates a new VM everytime when triggered this might not be exposed publicly, may be some of your internal code does it. Or may be an attacker crafts a request in such a way that your function trigger, triggers itself repeatedly.
Now, if you have no limits applied then it may result in a million VMs, or a millions of requests and consuming huge time to execute your function. Imagine what your bill will be.
This above concept may seem like a joke but it happens in real life.
Another way to prevent from causing DoW attacks is to make most of the requests authenticated.
There is no actual bulletproof protection against Denial-of-Wallet attacks. Instead, you should put in place the above limits to trigger alerts.
Finally, I would like to quote some lines from the OWASP Top 10 Serverless Threats
The automated scalability and availability is one of the reasons to use serverless. This allows applicationdevelopers to pay only for what you use and to transfer the responsibility for scaling up the application to theinfrastructure provider.
Nevertheless, it comes with a cost that has no bullet-proof protection. Attackers can trigger resources (e.g.external APIs, public storage) upon their will and cause financial damage to the organization. To “protect”against such attacks, AWS allows configuring limits for invocations or budget. However, if the attacker canachieve 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 traditionalarchitecture as in serverless. Therefore, the risk should be high.