Has Sapphire ‘Slammed’ Itself Out of Existence?

Word on the Street: The Worm Is Dead

So the word on the street is that the worm is dead.  Not any old worm mind you, but the worm, the Sapphire Worm.  You may know this worm by its street name, SQL Slammer. “Ah, right, yeah SQL Slammer,” you say to yourself, “Is that thing still active in the wild?”  The answer is yes, but just barely.  What’s surprising about that statement is not that it is still actively prowling the Internet looking for a vulnerable Microsoft Server or Desktop to exploit and compromise but that it has, for reasons inexplicable, diminished at a rate which can only be described as expeditious.  

A Little History about the Sapphire Worm

This was a special piece of malicious code.   It spread faster than any other computer worm (before or since) in history.  It was credited with infecting more than 90% percent of vulnerable hosts (numbers vary but some say the initial swath involved approximately 75,000 hosts) within 10 minutes!  Think about that, ten minutes!  Nothing moves that quickly today and there is good reason for that but were we to see a comparable threat in 2011 or beyond it would likely need to be much more intelligent than the Sapphire Worm and possess the ability to evade, bypass and recreate itself in a polymorphic manner.  The worm was based on a piece of proof of concept code first demonstrated by renowned bug hunter David Litchfield at Black Las Vegas 2002.    Litchfield would later (February 2003) go on to express concerns that his proof of concept code was being used as a template by unknown vandals in creating the worm.  The worm took on a variety of names:

• W32.SQLExp.Worm
• DDOS.SQLP1434.A
• The Sapphire Worm
• SQL_HEL
• W32/SQLSlammer
• Helkern

Ironically the program didn’t use the SQL language but rather exploited a buffer overflow vulnerability in Microsoft’s SQL Server and Desktop Engine database products for which a patch existed for approximately six months prior (July 2002) to the outbreak (MS02-039). The worm infected at least 75,000 hosts though it is believed that it impacted considerably greater numbers.  The byproducts of this outbreak included network outages, canceled airline flights, interference with elections, and automated teller machine (ATM) failures.  It was, to say the very least, one of the most epic instances of malware in the history of malicious code and content.  So what happened?  Before delve into exploring what happened we first need to understand a little more about the malware itself.  

Sapphire / Slammer’s most undeniable attribute was its speed. It owed this speed to the use of the User Datagram Protocol (UDP).  Lightweight, and much quicker than the Transmission Control Protocol (TCP) as it does not depend upon nor require a sender and receiver acknowledge each other in a handshake, UDP can carry a message in a single, one-way packet.  Microsoft's SQL Server 2000 software had a UDP-powered directory service that let applications automatically find the right database. Moreover, SQL code comes built into other programs that Microsoft sold and as a result many Slammer victims didn't even realize they were running SQL.

Recent Events with the Worm

So at this point we need to look at the historic record and ask ourselves what is affecting the worm’s decline and what is leading (ultimately) toward what looks like its end?  Let’s take a look at our data for the last 365 days related to this worm.  Below in figure 1 you’ll see the graph for the last year that depicts the activity associated with the Sapphire Worm (SQL Slammer) in the wild as it relates to hit rates associated with filters firing in the field.

                      Figure 1: Last 365 Days of MS-SQL Slammer-Sapphire Worm Activity

Now let’s take a look at the last 30 days of activity associated with the worm as seen in figure 2 below.  Note the dramatic decline in activity especially between March 11, 2011 and March 12, 2011.   From that point forward the activity of the worm has reached near stagnation.  HP DVLabs research corroborates that posited by the ISC and team at Kaspersky Labs regarding this occurrence though the real question of why this is occurring has yet to be addressed.

                      Figure 2: Last 30 Days of MS-SQL Slammer-Sapphire Worm Activity

Possible Causes Contributing to the Decline of the Worm

It’s difficult to say why this decline is occurring.  Some have posited that due to the high seismic activity noted in Japan recently while others speculate that it is directly related to the release of Microsoft patches on the day of the most noticeable decline (in our case March 11, 2011 thru March 12, 2011).  This seems unlikely as well due to the fact that none of the patches released by Microsoft that week were related to MS SQL never mind the fact that were these systems still actively spewing Sapphire / Slammer for the last 9 years it would imply that had not previously been patched and weren’t likely candidates for future patches.   So what’s left?

• Migration / upgrade to a new, more secure operating system (Microsoft or otherwise)?
• The Introduction of comprehensive end point security which has detected the presence of the worm and cleaned it while providing protecting via HIPS?
• The introduction of more robust consumer grade SOHO infrastructure equipment replete with anti-malware, ids / ips, firewalling etc.?
• Aliens?

At the moment no one seems to know though it is something we’ll continue to monitor and take note of.  For more information on the MS-SQL-Sapphire Worm please visit http://threatlinq.tippingpoint.com