SQL Slammer 16 years later: Four modern-day scenarios that could be worse

It’s been 16 years since the SQL Slammer worm struck on January 25, 2003. It was the fastest spreading computer worm in history, and surprisingly nothing has beat it since. Will that record stand much longer?

What is SQL Slammer?

If you were in IT in 2003, you remember what you were doing when Slammer went off like all civilians do when a president is shot. It was a Saturday…early Saturday. The SQL Slammer worm had been launched outside the U.S. in what was the early morning hours of Eastern Standard Time (EST). America’s IT defenders, for the most part, were asleep. By the time many of us woke and heard about it, it had already brought down most of the world’s SQL servers and networks. Bank ATMs were down. Newspapers printed late. If your company used personal computers, it was likely impacted.

SQL Slammer was an amazing 376 bytes of malicious code. It attempted to connect to every computer it could find over MS-SQL UDP port 1434. It didn’t care if the computer it was connecting to was running SQL or not. It just blasted its buffer-overflow-abusing code against every computer it found.

Until then, many researchers thought the “just try it” approach would be very inefficient. Why waste your time trying an exploit that didn’t possibly exist unless you encountered a verified unpatched MS-SQL server? The experts were wrong. Turns out just blasting away at every possible target was incredibly fast at infecting every reachable, vulnerable computer. They included not only SQL servers, but any workstation running unpatched versions of Microsoft’s SQL client-side product, which Microsoft was attaching to more and more products. It only took one vulnerable SQL server in your company to crash the network.

SQL Slammer spread to tens of thousands of computers in the first hour. Within a few hours, its hammering code had infected most of the unpatched servers on the internet, and certainly that was the case by the end of the day. When Slammer overflowed a SQL server, it immediately began using that computer to search for and infect every other computer it could reach. It didn’t have a traditional payload and to this day we don’t know who wrote it or for what purpose.

Guesses include an experiment run wild and an uber-smart hacker who wanted to break into a specific SQL server unnoticed among all the noise. My best guess is that it was a mischievous hacker who knew what they were doing when they launched it, but even they had to be shocked. Until then, no other malware program had come close to spreading and causing as much damage as fast as Slammer did. It was an immediate paradigm shift.

The two biggest signs that you had a SQL Slammer infection in your organization was that all your SQL servers and any application that relied upon them were down, and your entire network was crawling to a halt because of all the bandwidth the hungry digital-carnivore was using.

The amazing thing about Slammer was that a patch that closed the vulnerability it exploited had been out for nearly six months. Security researcher David Litchfield and his company, NGSSoftware, had discovered the bug in May 2002. He responsibly reported it to Microsoft and other security researchers and Microsoft released a patch for it in July 2002.

What SQL Slammer taught us

Back then no one rushed to patch. When SQL Slammer went off six months later, no one was surprised that hardly any SQL servers connected to the internet were patched. SQL Slammer taught us that critical vulnerability patches had to be applied as quickly as possible. No longer could the world be lulled into a false sense of security just because hackers and malware writers didn’t take advantage of exploits quickly.

Today, once a vendor releases a patch, dozens of hacker groups reverse-engineer the patch and have exploit code ready to go within a few hours. There are probably tools that automate the process, meaning the time from patch release to exploit code creation can be measured in seconds. We just don’t know about it until things are tested and publicly released.

The saving grace of Slammer was that it didn’t do any intentional harm beyond crashing the SQL server and killing network bandwidth. It didn’t infect files, delete data, collect passwords, or do any of the devious things that nearly all malware does by default today. To recover from it, you applied the patch and rebooted the server. It was that easy.

Have we done something to prevent future slammers?

Since then we’ve all wondered if a more devious malware program might beat Slammer’s record. Malware writers are far more sophisticated today, but it’s been 16 years and nothing has beaten Slammer’s record. Is it possible that Slammer will go down in history as the fastest spreading malware program?

True. Nearly every computer defense and defender has improved. Firewalls are everywhere. Nearly everyone is patching faster. Patches are often automated. We are all monitoring our servers, networks and internet traffic like never before. Even if a fast spreading malware program struck in the dead of night, there would be tens of thousands of defenders working to mitigate its worst effects. ISPs and network chokepoints would put it down. Automation would kick in and we would all get to see how good our artificial intelligence engines really are.

The best proof we have that our better defenses are stopping future Slammers is that we haven’t had another Slammer. We just don’t get the fast-moving broad attacks that we used to regularly get. Malicious email attachments no longer take down the whole email system. Not only haven’t there been any Slammers, there haven’t been any Iloveyou worms, Melissa macro viruses or Code Red web server worms.

These super bugs seemed to pop up every few months. Then one day, they just stopped being the problem that they were. We all still get hit by bad malware programs. Heck, ransomware is pretty bad today, but in a global sense we don’t see things that go off and infect the entire world in a single day.

But have we seen the fastest malware program ever? Probably not.

For one, forever is a long time. Second, we have technologies that could result in massive infections that make somewhat innocuous Slammer seem like a quaint, fond memory.

What can beat Slammer’s speed record?

Slammer was somewhat limited in that it could only take down unpatched versions of MS-SQL. Imagine if you had a malware program with a zero-day exploit that worked against an operating system and spread as fast as Slammer. That would be scary. Instead of at least being limited by the malware attacking a single service, the program could attack every computer successfully. If a patch wasn’t already available, the recovery would be much harder. So, it isn’t out of the range of possibility that a traditional malware program with a zero-day might be able to beat Slammer’s record, but it’s these four scenarios that I worry about more.

1. Cloud-based malware

I worry about entirely new classes of malware that prey on our ever-evolving infrastructures, like a cloud-based infector. Today, most organizations run on cloud-based software. The joke is that cloud stands for other people’s computers. But it’s worse than that. It’s other people’s computers where you are just one of the customers. Your data and programs share and cohabitate with dozens to hundreds of thousands of other, unrelated organizations.

Imagine a new class of malware that once it gets loose in a cloud system can immediately exploit all the other sharing tenants. The malware wouldn’t have to run across networks and scan for new computers. It could just infiltrate the underlying cloud infrastructure and run the room. Slammer was supposedly doubling in size every eight seconds early on; what’s to stop a cloud-based program from just infecting “everything” in a few seconds?

This sort of thing routinely happens on web server programs that host hundreds to thousands of websites. One website infection ends up compromising all the websites on the same server. Same thing here, except it’s all servers and products within the same cloud. A cloud-based infection could move at the speed of electrons.

2. IoT attack

Possibly a more likely scenarios is the incredible risk we all face because of the vastly insecure universe of IoT devices. Thousands of new IoT devices connect to the internet every day and every single one of them is exploitable. Most are extremely easy to exploit.

We’ve already seen what one worm can do to quickly infect tens of thousands of vulnerable devices. The Mirai worm infected hundreds of thousands of networked IoT devices. Created by college students initially looking to cheat a game, it infected hundreds of thousands of IoT devices and created the largest sustained distributed denial of service attack the internet has ever seen. Maybe your home router or internet-connected camera was involved.

Imagine a Slammer-like worm that attacked every internet-connected IoT device. We’re talking tens of millions of network-connected IoT devices just today. That number will soon be in the billions. IoT devices are becoming more and more mission critical and their security is not improving. It’s a recipe for disaster, fast disaster.

3. Phone bot

We already have more cell phones than people on the planet. A hacker group is selling a zero-day, zero-click critical exploit that can infect any phone using iMessage. Many of these sorts of phone-impacting zero-days are likely being held by all sorts of people and organizations. Take just one of those and turn it into a Slammer-style bullet-fast worm. It hits your phone, sends it self to your contacts, and then takes your phone out of service. What would happen to our world if suddenly all our phones stopped working at once? Do you think that wouldn’t set off a panic?

4. Nation-state-owned zero-days

Nation-states are the very types of organizations that develop zero-day exploits — or buy them at a premium price. Then they just sit on them until they are needed. I would venture to say that you can’t call yourself a true nation-state attacker unless you have a cadre of fast spreading zero-days waiting to take out another nation’s critical infrastructure.

Our defensive capabilities are definitely not up to defending against these types of attacks. We are really just sitting ducks waiting for a war that we hope never has to happen. To be clear, we haven’t had a major world war in a long time, so we must just get lucky and not have to test what the first major cyber-offensive World War looks like.

It’s not all about speed

In reality, we shouldn’t be overly worried about speed. The speed at which Slammer attacked was ultimately its downfall. By not throttling its infection routines, it crashed so many servers and networks that it ultimately slowed itself down. If it had been more judicious in its searching algorithms, then it’s likely that it could have infected many more computers.

Ultimately, what damage something can cause is more important than its speed. Most computer security experts now worry about “low and slow” attacks, which can end up invisibly exploiting more computers and networks than Slammer could have dreamed about. A worst-case scenario might be something like a cross-platform worm that sneaks into networks and transparently manipulates data, corrupting it until no clean backups are left to restore from.

Slammer was bad, but it didn’t cause intentional damage. Imagine a slower malware program, like ransomware, that silently infects the whole planet and then goes off. That’s what we are worrying about these days.

SQL Slammer is still the fastest spreading malware program of all time. It changed the nature of how we defend computers. Let’s hope we don’t have to learn how to defend against something that causes even more damage.