10 Years After SQL Slammer 58
Trailrunner7 writes "Ten years ago today, on Jan. 25, 2003, a new worm took the Internet by storm, infecting thousands of servers running Microsoft's SQL Server software every minute. The worm, which became known as SQL Slammer, eventually became the fastest-spreading worm ever and helped change the way Microsoft approached security and reshaped the way many researchers handled advisories and exploit code. This is the inside story of SQL Slammer, told by David Litchfield, the researcher who found the bug and wrote the exploit code that was later taken by Slammer's authors and used as part of the worm."
Also decided in favor of restrictive firewalls (Score:5, Funny)
Kind of hard to believe that ten years ago it was quite common for people to still have their SQL Servers hooked up the Internet with no firewall or firewall rules that permitted direct connections to the control port. Good luck finding that configuration today...
Re:Also decided in favor of restrictive firewalls (Score:4, Interesting)
There are still tons of them.
I have heard such a setup suggesting in the past 12 months by a customer to make life easier for them. We did not do that.
Re:Also decided in favor of restrictive firewalls (Score:4, Insightful)
My guess is it's far more common than you'd think. A lot of software is really awful when it comes to security, and a lot of places don't do much better.
I ran into a piece of software about 3-4 years back which lived in the DMZ to provide access to internal servers. The software in question stored passwords in plain text in the registry -- we're talking the admin password for the production database. I screamed bloody murder at how big of a risk that was, but eventually got told to STFU. Thankfully, it was a short contract and I wasn't around much longer.
You might be shocked to find out how often security is secondary to cost and convenience. I'm betting loads of people here on Slashdot have encountered things like this.
Look at all the stories we've seen about SCADA [slashdot.org] devices being on the internet -- people are regularly putting mission critical stuff directly onto the internet with no good security.
Re: (Score:2)
I'd love to implement great security for every customer we have but it's always up to them and how much "trouble" they want to get through using their network (even if it isn't really).
The only thing I don't like is IT companies setting up a customer with a shoddy network in the first place.
Re:Also decided in favor of restrictive firewalls (Score:5, Insightful)
That's the real problem. It will always be easier to NOT do something than it will be to do something.
And NOT doing something will, 99%+ of the time, will be less expensive than doing something.
It is only when that less-than-1%-of-the-time event hits that "something" gets done. And even then the 'something" is usually a panic reaction and NOT real security.
Re: (Score:2)
My guess is it's far more common than you'd think. A lot of software is really awful when it comes to security, and a lot of places don't do much better.
I ran into a piece of software about 3-4 years back which lived in the DMZ to provide access to internal servers. The software in question stored passwords in plain text in the registry -- we're talking the admin password for the production database. I screamed bloody murder at how big of a risk that was, but eventually got told to STFU. Thankfully, it was a short contract and I wasn't around much longer.
You might be shocked to find out how often security is secondary to cost and convenience. I'm betting loads of people here on Slashdot have encountered things like this.
Look at all the stories we've seen about SCADA [slashdot.org] devices being on the internet -- people are regularly putting mission critical stuff directly onto the internet with no good security.
With the exception of the password storage using clear text, what you're describing has nothing to do with software insecurity but everything to do with architecture insecurity. SCADA devices, database servers, or any "back office" infrastructure that is exposed broadly to the Internet without a genuine business case for anyone and their dog to have direct access to it is a bad idea. It's not about the software, in that case, it's about how the infrastructure is designed to contain it (or not). And the r
Re: (Score:2)
> And the really odd thing is that it's usually WAY easier to address this kind of insecurity than it is to fix problems in software, especially COTS products. You just have to try. Yes, it costs a bit, but it's not exactly exotic and it's not all that expensive. Firewalls are cheap, faster than ever and not terribly difficult to manage anymore.
No, it's usually WAY difficult to address this "architecture" insecurity as you put it. I really don't understand why you're even mentioning firewall costs at al
Re: (Score:2)
Oh yeah, you have a critical non encrypted database with some proprietary applications running in the same internet web server box, and you fix everything by adding a Linux PC with iptables and one IP tunnel. You're a total genius.
Check your firewall logs. (Score:3)
You'll see all kinds of ancient exploits still being tried by machines around the world.
At one place I worked, the contractors who came in to install the VoIP system also connected one of the Win2K3 servers directly to the Internet so that they could manage the VoIP system "easier". And that was back around 2010.
Never underestimate the power of laziness and stupidity.
Re: (Score:2)
It was almost his last install and last day breathing. He took a can of drink into the server room and had it sitting on a large UPS of quite a few kW
Re: (Score:2)
HTTP Slammer (Score:5, Funny)
Slashdot does it again.
Every minute (Score:2)
Can't get my head around this... why would you want to run MSSQL every minute? It's not that unstable.
Google Cache Version (Score:5, Informative)
http://goo.gl/PCkGM [goo.gl]
Re: (Score:3)
Security priorities have changed (Score:5, Insightful)
So this guy "wrote the exploit code that was later taken by Slammer's authors and used as part of the worm", and he's not dead or serving an eleventy hojillion year federal prison sentence?
Times change indeed...
Re:Security priorities have changed (Score:5, Informative)
So this guy "wrote the exploit code that was later taken by Slammer's authors and used as part of the worm", and he's not dead or serving an eleventy hojillion year federal prison sentence?
Times change indeed...
The article mentions he was paid by a company in Germany to penetrate their heavily-fortified SQL Server installations. This is when he developed the exploit code. Presumably it's not illegal for a company to pay you to security test its systems.
He also took the steps of communicating the exploit to Microsoft before releasing the code. He even asked their permission before divulging the code, and didn't do so until MS had released a fully corrective patch.
You're right, however, he'd be in jail if it happened today.
Re: (Score:2)
One has to ask, why would he release the code?
What was the point?
What was the benefit?
Re: (Score:2)
That's like saying having a spate of burglaries on your block convinced everyone to install alarm systems so now the neighborhood is a little bit more secure.
Re: (Score:2)
So that's a great big "Nuh Uhhh" from the AC eh?
Re: (Score:2, Flamebait)
Nice.
An A.C. all lathered up about Full Disclosure.
Re: (Score:2)
It's more a case of do as I say, not as I do.
Re: (Score:2)
Do as I say, not as I do is pathetic.
Don't lecture people about something you are not prepared to do yourself.
Re: (Score:2)
Okay, so we'll all post our real names, addresses, and telephone numbers.
Starting with you, of course.
And once we've all done this... Guess what? Nothing will have changed: the AC will still be just as right, and you will be just as wrong.
Re: (Score:2)
Our article on the subject: (Score:5, Informative)
We (David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford, and myself) did the analysis of how it spread, including showing how it infected all the vulnerable systems in 10 minutes, and detailing flaws in the random number generator.
Our article eventually appeared in IEEE Security & Privacy [ieee.org].
Re: (Score:2)
Re: (Score:2)
Why would removal and reinstallation of MSDE be required?
Re: (Score:2)
Re: (Score:1)
It'll cost me 31 dollars to read that article. I think I'll pass.
Re: (Score:2)
"The kind of thing people die over"? Isn't that a bit, shall we say, dramatic?
Apologies for the paywall... (Score:2)
I didn't know. So here's a Non paywalled copy [berkeley.edu].
Re: (Score:2)
Thank you.
This also saves me the effort of working out what it means when it asks me for "US£31.00".
You can't beat clueless (Score:4, Insightful)
Letting a DB server out on the internet is moronic by itself, but not having installed a patch [microsoft.com] that was available 6 months before the worm started spreading, well, that's even worse.
The worst thing of all, however, is that Microsoft *itself* had unpatched instances of SQL Server out on the net and they themselves got pwned.
Re: (Score:2)
Yea, at that time Windows Update and SUS did not cover anything other than Windows itself. In fact, at that time SQL Server hotfixes and updates did not even have an installer. You had to use manual file copy to install them, and this included manual version checking if you installed more than one of them. Needless to say, when WSUS and Microsoft Update was created in mid-2005, SQL Server was included.
Re: (Score:2)
And of course not only does post SQL Server 2000 SP3 hotfixes have an installer, but the original patch was repackaged with it too.
Re: (Score:1)
Okay, so... (Score:1)
Ten years down the line, does it run on Linux yet?
Slammer Worm and the Blackout (Score:2)
Slammer Worm Hit FirstEnergy [crn.com]
Slammer worm crashed Ohio nuke plant network [securityfocus.com]
US blackout was computer related [theinquirer.net]
The good old days (Score:2)
I can remember back then when the campus network was put to a halt when a single laptop overloaded the poor Cisco router connected to the internet with too much requests. It took us quite some time to isolate the problem when we were using hubs and unmanaged switches. It was quite dramatic when I stormed the room in a middle of a presentation and pulled the UTP plug out of the computer! :)
I can also remember the Nimda worm back then when it infected a part of the network. Good thing we were using higher e