SQL Slammer

SQL Slammer is a computer worm that caused a denial of service on some Internet hosts and dramatically slowed down general Internet traffic, starting at 05:30 UTC on January 25, 2003. It spread rapidly, infecting most of its 75,000 victims within ten minutes. So named by Christopher J. Rouland, the CTO of ISS, Slammer was first brought to the attention of the public by Michael Bacarella (see notes below). Although titled "SQL slammer worm", the program did not use the SQL language; it exploited a buffer overflow bug in Microsoft's flagship SQL Server and Desktop Engine database products, for which a patch had been released six months earlier in MS02-039. Other names include W32.SQLExp.Worm, DDOS.SQLP1434.A, the Sapphire Worm, SQL_HEL, W32/SQLSlammer and Helkern.[1]

Technical details

The worm was based on proof of concept code demonstrated at the Black Hat Briefings by David Litchfield, who had initially discovered the buffer overflow vulnerability that the worm exploited.[2] It is a small piece of code that does little other than generate random IP addresses and send itself out to those addresses. If a selected address happens to belong to a host that is running an unpatched copy of Microsoft SQL Server Resolution Service listening on UDP port 1434, the host immediately becomes infected and begins spraying the Internet with more copies of the worm program.

Home PCs are generally not vulnerable to this worm unless they have MSDE installed. The worm is so small that it does not contain code to write itself to disk, so it only stays in memory, and it is easy to remove. For example, Symantec provides a free removal utility (see external link below), or it can even be removed by restarting SQL Server (although the machine would likely be reinfected immediately).

The worm was made possible by a software security vulnerability in SQL Server first reported by Microsoft on July 24, 2002. A patch had been available from Microsoft for six months prior to the worm's launch, but many installations had not been patched – including many at Microsoft.

The slowdown was caused by the collapse of numerous routers under the burden of extremely high bombardment traffic from infected servers. Normally, when traffic is too high for routers to handle, the routers are supposed to delay or temporarily stop network traffic. Instead, some routers crashed (became unusable), and the "neighbour" routers would notice that these routers had stopped and should not be contacted (aka "removed from the routing table"). Routers started sending notices to this effect to other routers they knew about. The flood of routing table update notices caused some additional routers to fail, compounding the problem. Eventually the crashed routers' maintainers restarted them, causing them to announce their status, leading to another wave of routing table updates. Soon a significant portion of Internet bandwidth was consumed by routers communicating with each other to update their routing tables, and ordinary data traffic slowed down or in some cases stopped altogether. Ironically, because the SQL Slammer worm was so small in size, sometimes it was able to get through when legitimate traffic was not.

Two key aspects contributed to SQL Slammer's rapid propagation. The worm infected new hosts over the sessionless UDP protocol, and the entire worm (only 376 bytes) fits inside a single packet.[3][4] As a result, each infected host could instead simply "fire and forget" packets as rapidly as possible (generally hundreds per second).

Notes

There is contention as to who found "Slammer" first. However, in terms of who first alerted the general public, this can be attributed to Michael Bacarella, who posted a message to the Bugtraq security mailing list entitled "MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!".[5] This was sent at 07:11:41 UTC on 25 January 2003. Ben Koshy is often credited as being the first; indeed the company he worked for put out a press statement to this effect.[6] However, his alert[7] to the public, sent to the NTBugtraq mailing list was not sent until 10:28 UTC. Robert Boyle sent an alert to NTBugtraq at 08:35 UTC[8] beating Koshy but lagging behind Bacarella. ISS, through Chris Rouland, sent out alerts at 11:54 UTC[9] and 11:56 UTC[10] to the ISSForum and Vulnwatch mailing lists respectively. An analysis released by Symantec is timestamped 07:45 GMT, which would precede these public announcements.[11]

References

  1. ↑ "Symantec W32.SQLExp.Worm".
  2. ↑ Leyden, John (6 February 2003). "Slammer: Why security benefits from proof of concept code". Register. Retrieved 2008-11-29.
  3. ↑ Moore, David et al. "The Spread of the Sapphire/Slammer Worm". CAIDA (Cooperative Association for Internet Data Analysis).
  4. ↑ Serazzi, Giuseppe & Zanero, Stefano (2004). "Computer Virus Propagation Models". In Calzarossa, Maria Carla & Gelenbe, Erol. Performance Tools and Applications to Networked Systems (PDF). Lecture Notes in Computer Science. Vol. 2965. pp. 26–50.
  5. ↑ Bacarella, Michael (25 January 2003). "MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!". Bugtraq. Retrieved 2012-11-29.
  6. ↑ "W3 Media's Ben Koshy first to identify Internet 'Slammer' Virus" (PDF). Press Release. W3 Media. January 24, 2003. Retrieved 2008-11-29.
  7. ↑ Koshy, Ben (January 25, 2003). "Peace of Mind Through Integrity and Insight". Neohapsis Archives. Retrieved 2008-11-29.
  8. ↑ Boyle, Robert (January 25, 2003). "Peace of Mind Through Integrity and Insight". Neohapsis Archives. Retrieved 2008-11-29.
  9. ↑ "ISS Security Brief: Microsoft SQL Slammer Worm Propagation". ISSForum. 25 January 2003. Retrieved 2008-11-29.
  10. ↑ X-Force (January 25, 2003). "Peace of Mind Through Integrity and Insight". Neohapsis Archives. Retrieved 2008-11-29.
  11. ↑ "SQLExp SQL Server Worm Analysis" (PDF). DeepSight™ Threat Management System Threat Analysis. Jan 28, 2003.

External links

News
Announcement
Analysis
Technical details
This article is issued from Wikipedia - version of the Thursday, March 24, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.