| QUESTION & ANSWER |
SQL Server security threat: An expert's advice |
 |
By Ellen O'Brien
30 Jul 2002 | SearchDatabase.com |
|
|
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 severe is this vulnerability?
Litchfield: 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.
Should people drop what they are doing
and patch this right away?
Litchfield: 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.
Why is it so important to move quickly?
Litchfield: 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 difficult is this vulnerability to exploit?
Litchfield: 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.
| | | | This is a very high-risk problem and the most severe issue SQL Server has seen. | | | |
How does this compare with past vulnerabilities in SQL Server?
Litchfield: 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.
How would a user know if they have this vulnerability?
Litchfield: 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.
|
|
|
|
