Network Outage Notification 1/25/2003

[support@n2net.net]

Valued N2Net Customers,

Many customers have seen seriously degraded service or outages over the last 24 hours due to an Internet-wide Denial of Service attack. A bug in Microsoft SQL Server was exploited by thousands of hosts just after midnight, Eastern Time on January 25th, 2002.

N2Net Engineers worked through the night restoring and stabilizing service to the majority of our customer base. As this has affected thousands of hosts on every network provider, you may still experience some difficulties reaching some sites. If you are continuing to experience widespread problems, please contact our Network Operations Center at 216-619-2000, Option 2 or e-mail support@n2net.net.

All customers running Microsoft SQL Server are strongly encouraged to ensure they have the latest security patches installed. Customers running other Microsoft products are further encouraged to regularly check that they are running the most current security updates to prevent future incidents of this magnitude. Should you require assistance with these patches and updates, please contact the N2Net Sales office at 216-619-2000, Option 3 to speak with a Solution Consultant.

Technical Details for Microsoft Administrators:
>From http://www.ngssoftware.com/advisories/mssql-udp.txt

When an SQL Server receives a single byte packet, 0x0A, on UDP port 1434 it will reply to the sender with 0X0A.  A problem arises as SQL Server will respond, sending a "ping" response to the source IP address and source port.  This "ping" is a single byte UDP packet - 0X0A. By spoofing a packet from one SQL Server, setting the UDP port to 1434, and sending it to a second SQL Server, the second will respond to the first's UDP port 1434.  The first will then reply to the second's UDP port 1434 and so on. This causes a storm of single byte pings between the two servers.

Only when one of the servers is disconnected form the network, or it's SQL service is stopped, will the storm stop. Exploitation of these security holes goes over UDP, a connection-less communications protocol. As such, it makes the task of bypassing the protection offered by a firewall considerably easier. The spoofing of an IP address in a UDP packet is also considerably easier. It is trivial for an attacker to send an attack through the firewall, setting the source IP address to that of the target's DNS Server and the source port to 53. Most firewalls will allow this packet through, as it will look like a response to a query to resolve a domain name.

It is strongly recommended that a rule be added to each organization's firewalls such that any packet destined for UDP port 1434 on the "clean" side of the firewall be dropped and logged. No host, even DNS Servers, should be allowed to send traffic to this port. It is also recommended that firewall administrators ensure that any packet received on the "dirty" interface with a source IP address set to an address on the clean side is also dropped and logged. Microsoft was alerted to this problem on May 17, 2002 and has since produced a patch that resolves these issues. All Microsoft Administrators are urged to test their SQL servers and apply these fixes as soon as possible. 

Details from Microsoft are available at:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-039.asp

The N2Net Security Team