Dealing with Database Denial of ServiceBy Adrian Lane
You have heard of denial of service attacks, but database denial of service? It may come as a surprise, but database denial of service attacks have become common over the past decade. Lately they are very popular among attackers, as network-based attacks become more difficult. We have begun to see a shift in Denial of Service (DoS) tactics by attackers, moving up the stack from networks to servers and from servers to the application layer. Over the last 18 months we have also witnessed a new wave of vulnerabilities and isolated attacks against databases, all related to denial of service. We don’t hear much about them because they are lost among the din of network DoS and even SQL injection (SQLi) attacks.
Database DoS doesn’t make headlines compared to SQLi, because injection attacks often take control of the database and can be more damaging. But interruption of service is no longer ignorable. Ten years ago it was still common practice to take a database or application off the Internet while an attack was underway. But now web services and their databases are critical business infrastructure. Take down a database and a company loses money – possibly quite a lot.
Here is an except from the paper:
The abuse of database functions is, by our count of reported vulnerabilities related to DoS, the single most common type of DB-DoS attack. There have been hundreds, and it seems like no externally accessible function is safe.
This class of attack is a bit like competitive judo: you shift your weight in one direction your opponent pushes you in the same direction to make you lose your balance and fall over. An attacker may use database features against you just like a judo expert uses your weight against you. For example, if you restrict failed logins, attackers may try bad passwords until they lock legitimate users out. If you implement services to automatically scale up to handle bursts of requests, attackers can generate bogus requests to scale the database up until it collapses under its own weight, or in metered cloud environments you hit a billing threshold and service is shut down. There is no single attack vector, but a whole range of ways to abuse database functions.
We would like to thank DBNetworks for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you folks for this most excellent price, without clients licensing our content. If you have comments of questions about this research, please feel free to email us with questions!