Application Security // Database Security
6/4/2013
11:01 AM
Adrian Lane
Adrian Lane
Commentary
50%
50%

DoS-in Your Database

The re-emergence of database denial-of-service attacks

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.

Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Latest Comment: nice one
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-0845
Published: 2015-04-17
Format string vulnerability in Movable Type Pro, Open Source, and Advanced before 5.2.13 and Pro and Advanced 6.0.x before 6.0.8 allows remote attackers to execute arbitrary code via vectors related to localization of templates.

CVE-2015-0967
Published: 2015-04-17
Multiple cross-site scripting (XSS) vulnerabilities in SearchBlox before 8.2 allow remote attackers to inject arbitrary web script or HTML via (1) the search field in plugin/index.html or (2) the title field in the Create Featured Result form in admin/main.jsp.

CVE-2015-0968
Published: 2015-04-17
Unrestricted file upload vulnerability in admin/uploadImage.html in SearchBlox before 8.2 allows remote attackers to execute arbitrary code by uploading a file with an executable extension and the image/jpeg content type, a different vulnerability than CVE-2013-3590.

CVE-2015-0969
Published: 2015-04-17
SearchBlox before 8.2 allows remote attackers to obtain sensitive information via a pretty=true action to the _cluster/health URI.

CVE-2015-0970
Published: 2015-04-17
Cross-site request forgery (CSRF) vulnerability in SearchBlox before 8.2 allows remote attackers to hijack the authentication of arbitrary users.

Dark Reading Radio
Archived Dark Reading Radio
Join security and risk expert John Pironti and Dark Reading Editor-in-Chief Tim Wilson for a live online discussion of the sea-changing shift in security strategy and the many ways it is affecting IT and business.