SQL Server security threat: An expert's advice

Security specialist David Litchfield answers questions for SearchDatabase.com about what he calls the most severe security threat to the SQL Server in its history. Litchfield, Next Generation Security Software co-founder and a frequent guest speaker at Black Hat conferences, stresses the importance of moving fast on this week's security threat.

How difficult is this vulnerability to exploit?
Anyone who can code a buffer overflow exploit will have no difficulties here. And, of course, when these programs reach the script kiddie community, then anyone who hasn't patched or firewalled themselves will be at considerable risk. This could be a target for the next big Internet worm. Should people drop what they are doing and patch this right away?
In an ideal world everyone would drop everything and apply this patch, but the reality of the situation is that this is just not feasible. Many organizations require a testing period before applying a patch to production systems - for fear it will break their applications. This is understandable, but I would urge security and database administrators not to linger with this one. In the interim I'd suggest that administrators set a rule on their firewall such that all packets bound for UDP port 1434 on the SQL Server be dropped - regardless of where the packet seemed to originate from and whatever its source port. How does this compare with past vulnerabilities in SQL Server?
This, to my knowledge, is the first unauthenticated vulnerability that allows an attacker to take complete control. Others SQL Server vulnerabilities require the attacker to be able to log on, in some fashion. This may either be done directly, or through SQL Injection via a Web-based application. Why is it so important to move quickly?
Here's why this is important. Let's say someone has a SQL Server on their DMZ, and it has a non-RFC 1918 address. And the organization has an external DNS Server, so the firewall is set up to allow responses to DNS queries into the 'clean' side of the firewall. All an attacker would need to do is spoof the IP address of the DNS Server (a very easy task as far as UDP is concerned) and set the exploit packet's source port to 53. To the firewall, this will look like a DNS response. It will allow the packet to pass through and, in turn, the SQL Server is hit. Since this is a buffer overflow vulnerability, an attacker can choose a code to execute. They can do anything they want to the database and its data. If you can't patch this quickly, then use your firewall to protect yourself. How severe is this vulnerability?
This is a very high risk problem. It's the most severe issue SQL Server has seen. An attacker with no user ID or password can send a single UDP packet to the server and gain complete control. How would a user know if they have this vulnerability?
If they're running SQL Server 2000 and they haven't applied the patch, then they will be vulnerable. Although the Microsoft bulletin neglected to say so, MSDE2000 is also vulnerable to this issue. As MSDE2000 is installed with Visual Studio .NET, anyone who has this on their system may be vulnerable and not know it.

Dig deeper on SQL Server Security

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchBusinessAnalytics

SearchDataCenter

SearchDataManagement

SearchAWS

SearchOracle

SearchContentManagement

SearchWindowsServer

Close