Re: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!

From: Charles Miller (cmiller@pastiche.org)
Date: 01/26/03

  • Next message: Brian McGrogan: "RE: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!" 
    From: Charles Miller <cmiller@pastiche.org>
Date: Sun, 26 Jan 2003 10:59:49 +1100
To: Bugtraq <bugtraq@securityfocus.com>

    Jason Coombs propagated the following meme:
    >
    > As of now we don't know who wrote the worm, but we do know that it looks
    > like a concept worm with no malicious payload. There is a good argument to
    > be made in favor of such worms.

    There are many arguments against them, too.

    1) They have the potential to seriously disrupt delivery of important
       services.

    2) It takes one bug in the worm to turn it from "mostly harmless" into
       "crippling", and nobody has a spare Internet to test a worm on
       before releasing it.

    3) They cause enormous problems even for those who are not directly
       to blame. Consider a co-location. You can keep your own systems
       up to date, but that's really no consolation if some idiot in the
       same facility hasn't patched their SQL Server boxen, and they melt
       the router.

    4) They feed a cycle of short, sensationalist incidents that target a
       single vulnerability, and then fade into the background.

    5) It feeds the myth that it is "good enough" to be reactive when it
       comes to security.

    6) It has no appreciable long-term benefit. Last year, it was Code Red
       and Nimda. Everyone patched their IIS servers. There was the Apache
       mod_ssl worm (to a lesser extent) that reminded everyone to patch
       their Apache servers. This year, there's Sapphire, and everyone patches
       their SQL Server boxes. Next vulnerability, next worm, even if it's in
       IIS, Apache or SQL Server again, will catch the _same_ people, _again_.

    The solution isn't defensive worms. The solution lies in the recognition
    (seldom expressed, lest we later regret it ourselves), that the failure
    to patch a seven-month bug is NEGLIGENCE, the failure to firewall non-
    essential open ports on network servers is NEGLIGENCE. In other matters,
    the failure to implement egress filtering is negligence. We could
    probably come up with a pretty good baseline of what is obvious systems
    administration negligence when it comes to security.

    Few worms exploit vulnerabilities that are new and unknown. Most exploit
    those that have been known for months. That it is cheaper for negligent
    administrators to wait until the worm hits, suffer a day of disruption
    and then fix the problem du jour is simply unacceptable. The only solution,
    however, is to somehow make it more expensive to be negligent than it is
    to be diligent.

    This is difficult. Tort law really isn't very good at handling cases where
    a lot of people each do small amounts of damage to a lot of other people.
    Even though the aggregate effect is significant, you can't really put your
    finger quite firmly enough on who did what to whom. And since the Internet
    is decentralised, you can't be slapped down by some authority in charge of
    keeping the 'net healthy.

    There's always the doomsday scenario. Maybe if this worm had caused major
    data-loss, there _would_ be some lasting effect? Or maybe the admins would
    have just restored from backup. Who knows?

    Charles Miller 

    -- 
"Bill Gates reports on security progress made and the challenges ahead."
  -- Microsoft's Homepage, on the day an SQL Server bug crippled large
     sections of the Internet.

    Relevant Pages

    • Re: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!
      ... And there's no SP3 for MSDE, ... Make sure SQL Server is not running while you copy over the files ... If anyone writes a worm for the Hello bug, I hereby pre-name it the "Yo ... > A worm which exploits a vulnerability in SQL Server is bringing ...
      (Bugtraq)
    • Re: URGENT: New SQL Worm?
      ... MS02-039 patches the vulnerability this new worm is attacking. ... Blocking inbound access to UDP1434, the SQL Server 2000 Resolution ... Service port. ... Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor ...
      (NT-Bugtraq)
    • Re: Massive SQL Server attack
      ... MS02-039 patches the vulnerability this new worm is attacking. ... Blocking inbound access to UDP1434, the SQL Server 2000 Resolution ... Service port. ...
      (microsoft.public.win2000.security)
    • URGENT: New SQL Worm?
      ... installations were compromised by some sort of SQL Server Worm. ... Installation of the SP3 after compromise seemed to resolve ... system outside of SQL Server, and whether trojans have been installed. ...
      (NT-Bugtraq)
    • RE: Does Slammer effect my VPN?
      ... the "Slammer" worm is an Internet worm ... and begin evaluation and deployment of SQL Server 2000 SP3 or MSDE ... Check to see if there is a real network problem or if you have any ...
      (microsoft.public.sqlserver.security)