Blogs

Writing a blog on distributed denial of service (DDoS) has its own challenges, one of which is delivering fresh and interesting content that’s not propaganda dressed up as news or, even worse, research. All too often what you read from other leading lights in the field of DDoS is nothing more than self-serving marketing, and where’s the value in that?

One way to avoid this trap is to highlight the work of other independent DDoS research and use the Juniper platform to showcase their research. With that in mind, for my next three blogs, I am going to utilize some recent work by Adrian Lane[i] of Securosis.

Adrian’s recent research has been focused on a very specific area of “App Denial of Service (DoS)” and that is Database DoS (DB-DoS). As I read through Adrian’s work, I am taken to back to late 2008 when we saw wave after wave of DB-DoS attacks that were simple and successful in locking up the DB servers. These attacks simply requested a read out of all the zip codes held on the server.

In the U.S., for example, a zip code is a five-digit sequence and there are circa 43,000 zip codes. So it’s a big request, and if you make enough requests, it’s more than possible to lock up the server holding the zip codes. If you think that’s bad, in the UK, there are a staggering 1,700,000 zip codes and typically they are three digits followed by a space and then three more digits. You don’t need to be a five-star hacker to know that’s a vulnerability that’s easy to exploit and that’s why Adrian’s recent work is timely and noteworthy.  

Introducing Database DoS

According to Adrian, there is an ongoing shift in DoS tactics by attackers, moving up the stack from networks to servers, and from servers into the application layer. As a result of concerted efforts to improve network defenses and harden servers, attackers are shifting their focus to easier targets: databases. Consistent with that trend we have both a new wave of reported database vulnerabilities and isolated attacks, all linked to denial of service. The vast majority of web applications are supported by databases, and while protections for SQL injection (SQLi) at the application and network layer are common, database hardening to fend off DoS attacks is not.

It may come as a surprise, but DB-DoS attacks have been common over the last decade. We don’t hear much about them because they are lost among the din of SQLi attacks, which cause more damage and offer attackers a wider range of destructive options. All things being equal, attackers generally prefer SQLi attacks because they can do just about anything to a database once they have taken control. But these attacks are much more difficult to exploit, and if the attacker just wants to disrupt operations, DB-DoS is a relative greenfield of opportunity. And with the growing trend of DoS attacks, databases are in the crosshairs of attackers.

DB-DoS attacks may not permanently damage the database or expose sensitive data, but they can certainly crash the database and usually the web application it serves as well. Service interruption is no longer a trivial matter. Ten years ago it was still common practice to take a database or application off the Internet for the duration of an attack. But now web services and their databases are critical business infrastructure, and expected to operate round the clock. Take down a database and a company loses money — probably a lot of money.

This blog series will examine trends in DB-DoS and take a look at:

• how attackers target databases and what types of exploits they leverage (part 1)
• why different classes of threats exist and how they’re exploited (part 2)
• what effective methods are available for addressing these attacks, so as to harden and protect your databases (part 3)

The Threat Landscape

You don’t need to be a database geek to know about DB-DoS—you just need to look at the news. We have seen recent Oracle issues with invalid object pointers, a serious vulnerability in the workload manager and the TNS listener barfing on malformed packets, and multiple vulnerabilities in MySQL, including a remote capability to crash the database.

The problem is not unique to Oracle’s products—we have seen a PostgreSQL issue with unrestricted networking access that was rumored to allow file corruption that crashed the database, and the IBM DB2 XML feature that allowed remote attackers to crash the database. Of course the presence of a vulnerability does not mean exploitation has occurred or will, but during our research we have heard many off-the-record accounts of database attacks. We cannot quantify the risk or likelihood of attack because there is too little public data to substantiate claims, but now is a good time to describe these attacks briefly and offer mitigation suggestions in response to this trend.

Now let’s talk about approaches attackers take. In a recent research report on DoS attacks, the most common approaches we found were based on “flooding the pipes” rather than “exhausting the servers.” Flooding is accomplished by sending so many network packets that they simply overwhelm the network equipment. This type of “volumetric” attack is the classic denial of service, most commonly performed as a DDoS because it typically takes hundreds or thousands of malicious clients to flood a large network. Legitimate network traffic is washed away in the tide of junk, and users cannot reach servers.

Exhausting servers is different. These attacks target software running on the server, such as the operating system or web application components, to waste all its CPU, memory, or other resources and effectively disable it. These attacks can target either vulnerabilities or features of application stacks to overwhelm servers and prevent legitimate traffic from accessing web pages or completing transactions. The insidious aspect of this attack is that, as you consume more hardware or software resources, platforms become less efficient. The closer to maximum utilization, the more servers slow down. Push them to the limit and they may simply lock up waiting for resources to become available. In some cases even removing the load does not bring servers back—you may need to reset or restart them.

The attacker motivation is very similar to other DoS attacks. Hacktivism is a major trend—taking down a major commercial website is an option for many people who dislike a company but lack legal or financial means to express their complaints. “Covering attacks” are very common, where criminals flood servers and networks—including security systems—to mask ongoing attacks. Common scenarios include shutting down competitors, criminal racketeers threatening DoS and demanding ransom, financial trading manipulation, and the list goes on.

The motivations behind DB-DoS are essentially the same. Recent tactics have evolved in response to a couple new factors. Network and server defenses are getting better with the current generation of firewall technologies, and it has become nearly impossible to flood the pipes of cloud services providers—to an attacker their network resources can be effectively limitless, redundant, and geographically dispersed. So attackers looked for new ways to keep old crimes profitable.

But attackers are not discriminatory—they are happy to exploit any hardware or software that enables them to accomplish their attacks, including web applications and databases. DB-DoS is conceptually no different than older DoS attacks at the server or application layers, but there are many more clever ways to conduct a DoS attack against a database. Unlike DDoS, you don’t need to throw everything including the kitchen sink at a site—often you just need a small logic flaw in a database function to push it over. Relational database platforms are some of the most complex application platforms in existence, so there is plenty room for mischief.

Attackers sometimes morph traditional protocol and server-based DoS attacks to move up the stack. But more often, they exploit specific database features in novel ways to take down their targets. Current DoS defenses are geared toward blocking network flooding and server attacks, so attackers have shifted targets to the application layer to better blend their incursions with legitimate customer transactions. Protection resources are generally focused on the lower layers, with relatively little attention paid to the application layer and virtually no time spent on defending against database attacks. Even worse, application layer attacks are much more difficult to detect because they tend to look like legitimate database requests.

Stay tuned for part two of this blog trilogy, where I’ll focus in on the database attack vectors.