Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/22/2020
How an Industry Consortium Can Reinvent Security Solution Testing
Henry Harrison, Co-founder & Chief Technology Officer, Garrison,  5/21/2020
Is Zero Trust the Best Answer to the COVID-19 Lockdown?
Dan Blum, Cybersecurity & Risk Management Strategist,  5/20/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-13458
PUBLISHED: 2020-05-25
An issue was discovered in the Image Resizer plugin before 2.0.9 for Craft CMS. There are CSRF issues with the log-clear controller action.
CVE-2020-13459
PUBLISHED: 2020-05-25
An issue was discovered in the Image Resizer plugin before 2.0.9 for Craft CMS. There is stored XSS in the Bulk Resize action.
CVE-2020-13442
PUBLISHED: 2020-05-25
A Remote code execution vulnerability exists in DEXT5Upload in DEXT5 through 2.7.1402870. An attacker can upload a PHP file via dext5handler.jsp handler because the uploaded file is stored under dext5uploadeddata/.
CVE-2020-5537
PUBLISHED: 2020-05-25
Cybozu Desktop for Windows 2.0.23 to 2.2.40 allows remote code execution via unspecified vectors.
CVE-2020-13438
PUBLISHED: 2020-05-24
ffjpeg through 2020-02-24 has an invalid read in jfif_encode in jfif.c.