On Saturday 25th January 2003, the internet was hit by a rapacious computer worm now known as SQL Slammer. Spreading like wildfire over the internet via a bug in a version of Microsoft SQL, it is believed to have infected over 75,000 machines within a matter of minutes. Globally, over 250,000 computers were thought to have been affected.
The spread of SQL Slammer
At its height, SQL Slammer, which was the most widespread worm since 2001’s Code Red worm, doubled in size every 8.5 seconds. South Korea, one of the most connected countries in the world at the time, had an outage of internet and cell phone coverage for 27 million people, while in the US, almost all of Bank of America’s 13,000 ATMs were temporarily knocked offline.
Although the worm’s impact was short-lived, the immediacy of this damage was critical. It demonstrated cybersecurity knowledge shortfalls, the viciousness and speed of cyberattacks and just how technologically connected the world was becoming.
Origins of SQL Slammer
The potential for what would become the SQL Slammer worm was originally discovered by the security expert David Litchfield. In 2002, the ‘”bug hunter” ethically developed two methods to bypass the prevention mechanisms built into a version of Microsoft SQL Server. He uncovered a flaw and reported it to Microsoft, whom he assisted with in finding a fix.
Not long after, a patch was developed, meaning that when he later spoke at a Black Hat conference, he was not only able to warn people of the defect, but also highlight that a patch was now available. He said that those who did not fix the buffer overflow vulnerability – in Microsoft’s SQL Server 2000 – would be at risk of being infected.
As was subsequently revealed, SQL Slammer, which was only 376 bytes worth of code (akin to a short paragraph of text) – would eventually spread courtesy of this buffer overflow.
Once a server was infected, the worm would replicate itself and identify new targets to attack. The process would then repeat itself in milliseconds, allowing multiple systems to be infected almost instantaneously. It was as virulent as worms come.
Restoring order
The fix for Slammer was relatively simple; systems could be rebooted, and, if the patch had been installed, the problem was immediately fixed.
Also, as Lysa Myers, a security researcher at ESET, remembers, because SQL Slammer was file-less and existed only in memory – “a fairly novel technique at the time” – it did not write itself directly onto a disk. It could therefore be removed easily.
Once technicians and security experts had cottoned onto what had happened, they responded with fixes. Things started to calm down, as Aryeh Goretsky, a distinguished researcher at ESET, recalls.
“I spent most of that weekend driving around to my client’s customer sites, shutting down servers and networking gear and then bringing them back up,” he notes. “I think by Monday or Tuesday everything was back to normal.”
The impact of SQL Slammer
Sure, the internet was up and running, but the environment had changed (for the better). SQL Slammer, while fairly easily to resolve, revealed gaps.
“In retrospect, some of the biggest changes that it forced us to make were in responsible disclosure and patching,” explains Myers. “It made people realize the very real potential for damage in releasing proof of concept code even for patched threats (and many people learned the hard way how important it is to apply patches promptly).”
The attack was also an information security wake-up call – security solutions matter, as Goretsky highlights: “While most customers ran anti-virus software at the time, there were some that didn’t to spend money on firewalls.
“That changed in 2003 and folks started paying attention to the idea of layers of security using a defense in depth approach.”
While SQL Slammer was not the first worm to exist, and certainly not the last, its unique exploits have helped it achieve information security infamy.
