Application Security // Database Security
6/4/2013
11:01 AM
Adrian Lane
Adrian Lane
Commentary
Connect Directly
RSS
E-Mail
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
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-2413
Published: 2014-10-20
Cross-site scripting (XSS) vulnerability in the ja_purity template for Joomla! 1.5.26 and earlier allows remote attackers to inject arbitrary web script or HTML via the Mod* cookie parameter to html/modules.php.

CVE-2012-5244
Published: 2014-10-20
Multiple SQL injection vulnerabilities in Banana Dance B.2.6 and earlier allow remote attackers to execute arbitrary SQL commands via the (1) return, (2) display, (3) table, or (4) search parameter to functions/suggest.php; (5) the id parameter to functions/widgets.php, (6) the category parameter to...

CVE-2012-5701
Published: 2014-10-20
Multiple SQL injection vulnerabilities in dotProject before 2.1.7 allow remote authenticated administrators to execute arbitrary SQL commands via the (1) search_string or (2) where parameter in a contacts action, (3) dept_id parameter in a departments action, (4) project_id[] parameter in a project ...

CVE-2012-5865
Published: 2014-10-20
SQL injection vulnerability in dispatch.php in Achievo 1.4.5 allows remote authenticated users to execute arbitrary SQL commands via the activityid parameter in a stats action.

CVE-2012-5866
Published: 2014-10-20
Cross-site scripting (XSS) vulnerability in include.php in Achievo 1.4.5 allows remote attackers to inject arbitrary web script or HTML via the field parameter.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.