Slammer Worm Slams Microsofts Own

MondoMor writes "Microsoft's forgot to patch some of its own servers to protect it from the months-old vulnerability exploited by the Slammer Worm, reports C|Net. Oops. Apparently Redmond's network was hit pretty hard. Just goes to show that no matter who you are, you'd better keep your apps patched." Update: 01/29 01:59 GMT by T : And if you're running systems which might be affected, take note: whitehorse writes "The Microsoft KB article for the Slammer patch found here has an incorrect URL for 'Download the patch' referring to KB Q316333 which is only a handle leak fix. The real patch may be found later in the article."

Comments

Microsoft didn't patch all their INTERNAL servers

[wbm6k]

The article I read (on yahoo) states the unpatched servers were all on the internal network, not the internet, and that they were in use by researchers within microsoft.

Let's not jump too quickly on the bash microsoft bandwagon for that. (Of course, if they just did enough testing and didn't release buggy, vulnerable software in the first place...)

Re:Zoiks!

[Anonymous Coward]

automatic update doesn't work with SQL server. you have to do patches the "old" way (unzipping files, renaming files, prayer), which is probably why so many novice admins never applied the patches.

Re:I wonder how long...

[jamesdood]

The thing to remember is this worm infected any machine running the MSDE (A scaled down MS-SQL server) So if you were running Access or Office 2000 or MS Visual Studio 6, or even Visio 2000 you could be affected by this. Most end users don't even know that they would be vulnerable and the statement "This particular worm largely ignored home and personal computers, due to the product it infects" is false. It also seems to have had an effect on certain Cisco routers. Not fun but you can't just blame "Poor Admins" as the culprits for the virualance of the worm.

Re:Zoiks!

[questionlp]

Please mod this parent up.

There isn't only no way to get SQL Server patches from Windows Update, but (as the parent mentioned), the steps required to update SQL Server and the Desktop Engine (MSDE) is a royal bitch and some.

For example, to apply any hotfixes or cumulative patches for SQL Server 2000, you must download the package, extract it, backup the SQL Server install directory and databases, manually copy over DLL files and other updated binaries, execute the SQL query files included in the patch (one at a time, in a certain order... MSDE users need to use the command line interface for it since there is no GUI provided), then pray that everything is okay and start SQL back up.

Worm's damage surprises experts -- takes out ATMs

[aengblom]

My rejected submission -- more details, but a bit long. The big news in my mind was not the microsoft bit--it was that ATM machines were unavilable because of the worm.

~~~

The worm that slowed the internet to a crawl over the weekend apparently did more damage than most originally believed. On Monday, many companies were still struggling to clean up. Financial companies and airlines seemed to be hit most acutely. Many web sites that manage payments and check loans were inaccessible. Inexplicably--and really inexcusably--some ATMS were also unavailable. Investigators are also struggling to pinpoint the worms starting point, but are having little success because it took off so fast.

Apparently similar code was released by David Litchfield of NGS Software Inc a few months ago. Virus "author," "Lion" credited Litchfield's code.

The Washington Post has an AP story up as well as this, which is older but has some additional details. The kicker to all this--the worm hit one year after Microsoft launched its "Trustworthy Computing." That and even some of Microsoft's own computers were hit (NYT Reg. Req.).

(Yep, still bitter ;-) )

Zero defects impossible; fix the fences instead

[satch89450]

Zero defects is not an attainable goal; it's too expensive and no one wants to pay for it.

This article shows just what happens when you expect zero defects in the infrastructure of a large organization like Microsoft Corporation. It's not going to happen. And before someone says I'm Microsoft-bashing, I will say that this is true for the vast majority of corporations, universities, foundations, and governments. That would include Sun, IBM, Red Hat, even the *BSD folks and LKML participants.

There is a damn good reason we won't see zero defects: employees are not measured by it. Their survival, pay raises, and promotions are based not on the number of defects they don't have, but on their contribution to the "bottom line." If you preach zero defects as Job One, then prove it by firing the people who generate defects, without exception -- including the CEO, COO, CFO, CIO, and other top brass, when they screw up.

So now that the myth of zero defects has been exposed for what it is, what do we do about it?

1. System administrators are going to have to re-think their perimeter access controls. This may require router upgrades to add processing power to support additional filtering.

2. Sysadmins who have been running "mostly-open" filter configurations may want to consider moving to a "mostly-closed" configuration: deny everything except services that have been cleared for use. Don't allow arbitrary connections. Many unknowing MS SQL servers were protected from participating in this little exercise because the firewall upstream of the desktop system wasn't allowing connections to get through, even if the desktop system had a globally-routed Internet address.

3. Computer mail order houses and computer stores should consider carefully whether they should bundle appropriate software firewall products with the computers they sell. Software configured to require the user to say "Yes, I want to make SQL server available for public access!" before 1433 and 1434 would be open.

4. We need to ask the reporters and editors of mainstream publications to be more responsible when reporting problems like Sapphire/SQL. The facts were pretty well known, and available to those who tried hard enough to get them even at the height of the packet storm, so that reporters could make their deadlines and get the facts straight. [Names of the guilty withheld, at least for now -- they know who they are.]

5. Tier 1 and Tier 2 bandwidth providers need to consider modifications to their Acceptable Use Policies to require some basic filtering of packets in both directions. These AUP changes have been discussed before; perhaps now is the time for them to go into effect:

   • Upstream packet source addresses must be verified at the perimeter such that the packet's return address points to a host in the network, and not to a random IP address or to broadcast addresses
   • Downstream packet destination addresses must be verified at the perimeter such that the packet is directed to a single host in the network, and not to a random IP address or broadcast address (other than multicast addresses, if such are allowed in the network)
   • As one drills down the levels of networks, packet source/destination verification must be done at all levels -- no exceptions (the excuse "It costs too much" doesn't wash when you consider that suitable packet filter technologies are available in both *BSD and Linux flavors, running on hardware that costs less than your standard business power lunch for four)
   • "Small services" (TCP 0:19 and UDP 0:19) must be blocked at the perimeter, both as source and destination ports.
   • A small number of other, specific ports must be blocked at the perimeter, those ports being identified as services that are intranet in nature instead of "global" services. The specific ports to be blocked should be determined co-operatively to avoid denying essential services to customers.
   • Encourate the use of VPN for interaction between two separated locations needing the above-mentioned intranet services over the Internet.
   • Encourage the use of abuse-prevention methods such as Network Address Translation on all circuits [cable operators take note] to block access to those systems that are NOT intended to be servers.

6. Update the Best Practices RFCs to incorporate some or all of these suggestions, so that Internet operators around the world can participate in solving the problem.

(N.B.: I want to point out that many USA-based cable operators are contributing to the problem by disallowing the use of NAT and VPN technologies in their apparent [alledged] quest to limit the broadband "Internet service product" to browsing and downloading files. I believe that such an attitude contributed to the problem, not the solution. I understand well the technical and business motivations for this, but I also believe that there are (U.S.) national security implications against such a policy. THINK!)

Are any of these ideas new? NO. The only new idea is to have the Lords Of The Internet use their influence over their customers to implement them more widely.

Good fences make good neighbors. The Internet is a neighborhood.

Actually No

[ravenmoon]

Microsoft incorrectly states in bulletin MS02-061 that SQL Server 7.0 and MSDE 1.0 are also affected by the worm.

While troubleshooting an issue related to the patch w/ MS phone support, the technician told me that 7.0 is not affected and the bulletin was incorrect.

It is entirely possible he was misinformed though.

Re:SQL 7 is *not* succeptable to Slapper

[the-matt-mobile]

SQL 7 is *not* succeptable to this vulnerability. SQL 7 doesn't use port 1434 for anything. That's new in SQL 2000. However, 7.0 is vulnerable to plenty of other things.

That's the SP, not the patch!

[burgburgburg]

The service pack was released January 17, 2003, a week before Slammer hit. The patch, which does require all of that manual effort is what has been out there for the past six months.

Alot of sysadmins were waiting for the SP to be released before even approaching this one, just because the patching process is so complex. They just waited a week too long

Re:Problem is IPv4

[trybywrench]

actually what made this especially bad was UDP. Not many programs run on UDP ports almost always they are TCP. TCP has a VERY important feature and that is upon a non-ack'd window it throttles back the send rate. This is a way to get congestion feedback to a host and tell it to "settle down". The problem with UDP is there is no way to tell it to slow down. Also, the fact that the Internet is a "best effort" network means that no matter what the UDP incoming rate the routers will do their best to deliver the packets. This comes at the expense of all other traffic flows in the router, no way to get congestion feedback to the host means no way to limit the incoming rate. Even if the routers just dropped the packets that still increases CPU and RAM utilization and with the volume that was happening would still probably bring traffic throughput to a trickle.