In-Depth

Killing Slammer Is Not Enough

A tiny piece of code caused big problems. We examine what lessons IT has learned.

• By Mathew Schwartz
• 02/05/2003

A 376-byte computer worm, variously known as Slammer, MS-SQL Server worm, Sapphire, SQL Slammer, or SQL Hell, struck early on Saturday, January 25, using network connections—and randomly chosen IP addresses—to spread itself to other machines via a flaw in Microsoft’s Windows SQL Server 2000 database software. As the worm spread, the number of queries it made soon overwhelmed the entire Internet, slowing it on average by 50% for U.S. sites and 30% for Asia-Pacific Web sites, according to Keynote Systems Inc. Various reports said that ATM machines at the Bank of America, and in parts of Canada, were offline.

“The other significant outage that we saw in corporate networks was the voice over IP phone networks,” said Oliver Friedrichs, Senior Manager of Security Response at Symantec Corp.

Experts warn that the virus will continue spreading, especially since some machines still don’t have a patch.

The vulnerability was first diagnosed in July 2002, and Microsoft issued a patch that October. The software can also be part of Visual Studio .NET, Office XP, Access 2002 and Visual FoxPro. Despite an early warning as the worm first started to spread, the voraciousness of this attack caught many by surprise. “The response team for the lab at which I work really threw us and others a curve in that it issued a severity rating of less than critical when this vulnerability was first reported. And I notice that nothing has been done to upgrade the severity rating, even after all that has occurred,” said Dr. Eugene Schultz, research director and trusted security advisor for Global Integrity Corp., in a newsgroup posting.

“We saw this story a little while ago, it was called CodeRed, so clearly people haven't learned their lesson,” says Tim Howes CTO and EVP of Development for Opsware Inc., a data center automation software company, referring to the CodeRed worm discovered in July 2001, which also overwhelmed large numbers of computers.

Slammer moved faster, however, aided by the fact that SQL databases tend to run on high-speed machines with excellent network access. “Because it used the EDP protocol rather than TCP, which is what Code Red used, it was able to really reach a peak and saturation point within two hours, whereas a Code Red took almost a day to reach that point,” said Sachs.

As the worm spread, many companies tried to rapidly test the patch and install it without taking any other measures. Most failed. Even some of Microsoft’s own machines, unpatched, were affected, the New York Times reported. Several days after the attack, Johannes Ullrich, CTO of the Internet Storm Center at The SANS Institute, said the worm had affected 211,853 systems, at least several hundred of which belonged to the U.S. government.

Still, Alan Paller, director of research for The SANS Institute, said that things could have been much worse. “Damage from this worm was reduced much more quickly than for other worms because systems infected by SQL Slammer immediately flooded their own networks and created local outages. People fixed their systems quickly because there was no other way to stop the pain.” In addition, the worm created a denial-of-service attack, because of the volume of its requests, but didn’t install Trojan programs, back doors, or otherwise wreak havoc on servers.

The Patch

The worm resides in computer memory. To detect and fix an infected system, IT has to first block all UDP traffic at port 1434, manually deactivate SQL, then run a tool to scan and eliminate the worm. Free tools that can quickly scan entire networks are available from such companies as ISS (www.iss.net) and Symantec (www.Symantec.com). Finally, the fix requires installing the Microsoft patch and rebooting the system.

One problem is that the original patch wasn’t an executable file. “This was labor intensive even when compared to other patches. It wasn't like you could just use it in an enterprise and it would run automatically,” said Jason Fossen of The SANS Institute. Microsoft since released an easier-to-install version.

Birth of Slammer

The origins of the worm are not a mystery. Writing to the BugTraq newsgroup, David Litchfield of UK-based e-business security company NGSSoftware Ltd. (www.ngssoftware.com/) said, “On analysis of the code of the Slammer worm it is apparent that my code was used as its template.” Litchfield first presented the code at the Blackhat Security Briefings (www.blackhat.com) in Las Vegas in August 2002. “As part of my talk I published my shellcode [sic] that demonstrated that this was a critical issue and should be patched at all costs,” he said. On the other hand, the creator demonstrated knowledge of buffer-overflow exploits, would have been able to write Slammer on his own, and probably only saved about 20 minutes of coding by using the published code, says Litchfield.

Given the results, however, “I am questioning the benefits of publishing proof ofconcept code,” he says, or whether he should discuss the problem publicly at all.

No one has yet to take credit for unleashing the worm.

Learning an IT Lesson

Slammer provides pundits with endless ammunition for critiquing the way many IT organizations handle patching. Then again, when a patch has been available for three months, there’s blame aplenty.

Of course the fact that so many systems were not patched points to multiple failures. “The vendors seem to think that their responsibility is over once they've posted the patch,” says Opsware’s Howes. The hard part, he says, is actually testing patches, disseminating them through the organization, getting people to do it, and even knowing which machines to patch in the first place.

Opsware sells eponymous, so-called data center automation (DCA) software that maintains a centralized record of what’s running on every machine, and whether or not new patches will interfere. IT can also upload patches to Opsware for easy, centralized access for the rest of the company—great for those times when the Internet at large is largely compromised. Finally, IT can use Opsware to enforce security policies, so no one installs a program such as Microsoft’s SQL Server on a machine when they’re not allowed without warning bells ringing at IT headquarters.

Organizations must create a baseline of what’s on all of their machines simply to know what’s vulnerable, and what to patch, when the inevitable “software updates” arrive.

IT Tools

Three tools “help deal with the load, time and effort of patching,” and beat future Slammer-like attacks, says The SANS Institute’s Fossen.

One is a hotfix network-checking tool that will “scan a range of IP addresses in your LAN and report which patches you don’t have installed,” he says. One such product is from Shavlik Technologies LLC (www.shavlik.com).

Another preventive measure is the free Microsoft Baseline Security Analyzer (http://www.microsoft.com/TechNet/Security/tools/tools/MBSAHome.ASP). “You can apply this to SQL servers and it will give you a list of recommendations of a dozen things you can do to lock down that machine,” says Fossen.

The final free tool we'll mention is the Microsoft Software Update, which is essentially a Systems Management Server (SMS) that sits on the corporate network. The server downloads all security updates from Microsoft so IT will then be able to install patches—when they install them, that is—from a server already on the network, saving time.