Chapter 14. Incident Detection: Finding the Other 68%

Grant Geyer

Brian Dunphy

Midnight on Saturday, January 25, 2003—and something devastating was about to happen across the Internet. Hundreds of thousands of computer systems across the globe in data centers, corporations, and even homes were exposed to the massive attack that would soon be launched. The worm would exploit a known vulnerability in Microsoft SQL Server first reported a full six months earlier on July 24, 2002.

From our point of view at Symantec on that quiet night, analysts at our Security Operations Centers went through their normal routines, analyzing security incidents from hundreds of customers worldwide and looking for signs of cyber attacks. But the quiet shift erupted into a sudden storm, with our analysts’ queues filling with tens of thousands of alerts within minutes. From the analysts’ view, the monitored intrusion detection systems were all concurrently alerting us of an “SQL buffer overflow” as the monitored firewalls were detecting a flood of traffic on port1434/udp.

For organizations allowing port 1434/udp through their firewalls, the worm wreaked havoc within their internal infrastructure within hours, causing denials of service as the worm attempted to propagate. For companies who were blocking port 1434/udp, when Monday morning arrived, many users with MS SQL on their laptops unknowingly carried the worm past the perimeter as they plugged in their computers, allowing the exploit to occur from within. ...

Get Beautiful Security now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.