DoS-in Your Database

When I started writing SQL, I was never worried about security; I was worried that I would write a bad query that would crash the database. And it was really easy to write SQL that would consume 100 percent of the CPU power or cause disk drives to bottleneck. Queries with outer-joins, cartesian products, and complex comparison operations coupled with full tables scans could pretty much kill any database.

When I started to lead teams of DBAs and developers, newbies were not allowed to check queries into source code control until they were tested outside of production and vetted by a more senior engineer. At the time, that was considered an extraordinary precaution for developers, but it was enacted after a new engineer crashed the e-commerce server in the middle of the day. She had pushed a new query directly into production without testing first, thinking nobody would notice. The responsibility for a lost afternoon of revenue, during a holiday season, fell squarely in my lap. You can bet the programmer heard about it!

During the past decade, servers have become much faster, and more and more relational database functions are concealed with abstraction layers. This means fewer programmers actually see what type of SQL statements are being executed, and few care about query performance. But that may start to change.

We've seen a dramatic uptick in denial-of-service (DoS) attacks, such as those at banks and credit unions, social media, and even video game companies. But the interesting change is, with networks becoming more resilient to attacks, attackers are moving "up-the-stack" to the application layer. These attacks tend to look very similar to normal Web application requests.

In some cases, attacks are constructed in such a way that they consume tons of resources on the server -- for example, running "search" from hundreds of different sessions simultaneously, or loading up shopping carts with thousands of items and perpetually refreshing those carts. In some, the attacks exploit flaws in the database so the system locks up or crashes, as was a recent issue with Postgres. In other cases, they look to exhaust resource limits -- say the total number of application worker threads, which we saw a few years ago with 32-bit versions of SQL Server -- and in rare cases, a SQL Injection style attack that may not allow an attacker to take over a database, but causes unexpectedly high resource consumption in the database engine. Again, in most cases the application requests are to consume abnormal amounts of server resources, and in many cases make the user session look entirely normal.

Technically the Slammer worm was a DoS attack, specifically targeted at a flaw in SQL Server. But this trend is different, and how you deal with it will be different as well. That s because the mission of the attacker may not be to take control of your database; it may be to slow it down, crash it, or simply hide othermalicious activity while you chase down a DoS attack. Like most security issues, you want to change your code or bolt security on.

To fix the code you're likely going to need to look both at efficient query design, alterations to application logic, and resource-limiting options provided by your database platform to help fend off these attacks. Then again, most developers are still trying to figure out how to scrub input variables to cope with SQL Injection; looking at both input validation and learning query optimization may be a bit too much for short-term validation. Other external options include database monitoring, database firewalls, or query whitelisting, which can be effective options as well. In these latter cases, you'll have to tune the solutions to pass legitimate traffic and block the stuff you don't want; easier said than done.

All things being equal, a crappy programmer is still more likely to grind your database to a halt than an attacker, but we expect to see many more database and application-layer DoS attacks in the coming months.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security analyst firm. Special to Dark Reading.