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
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-1689
PUBLISHED: 2019-12-10
Mozilla Firefox 20.0a1 and earlier allows remote attackers to cause a denial of service (crash), related to event handling with frames.
CVE-2016-10001
PUBLISHED: 2019-12-10
inets in Erlang possibly 22.1 and earlier follows RFC 3875 section 4.1.18 and therefore does not protect applications from the presence of untrusted client data in the HTTP_PROXY environment variable, which might allow remote attackers to redirect an application's outbound HTTP traffic to an arbitra...
CVE-2019-6183
PUBLISHED: 2019-12-10
A denial of service vulnerability has been reported in Lenovo Energy Management Driver for Windows 10 versions prior to 15.11.29.7 that could cause systems to experience a blue screen error. Lenovo Energy Management is a client utility. Lenovo XClarity Energy Manager is not affected.
CVE-2019-6192
PUBLISHED: 2019-12-10
A potential vulnerability has been reported in Lenovo Power Management Driver versions prior to 1.67.17.48 leading to a buffer overflow which could cause a denial of service.
CVE-2019-4095
PUBLISHED: 2019-12-10
IBM Cloud Pak System 2.3 is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts. IBM X-Force ID: 158015.