Become a fan of Slashdot on Facebook


Forgot your password?

MS SQL Server Worm Wreaking Havoc 964

defile writes "Since about midnight EST almost every host on the internet has been receiving a 376 byte UDP payload on port ms-sql-m (1434) from a random infected server. Reports of some hosts receiving 10 per minute or more. is reporting UUNet and Internap are being hit very hard. This is the cause of major connectivity problems being experienced worldwide. It is believed this worm leverages a vulnerability published in June 2002. Several core routers have taken to blocking port 1434 outright. If you run Microsoft SQL Server, make sure the public internet can't access it. If you manage a gateway, consider dropping UDP packets sent to port 1434." bani adds "This has effectively disabled 5 of the 13 root nameservers."
This discussion has been archived. No new comments can be posted.

MS SQL Server Worm Wreaking Havoc

Comments Filter:
  • by amigaluvr ( 644269 ) on Saturday January 25, 2003 @08:46AM (#5156231) Journal
    Kevin Mitnick is allowed back on the net and the net goes fubar
    • by Anonymous Coward on Saturday January 25, 2003 @09:22AM (#5156367)
      It was not Mitnick.

      I investigated into this matter, and came up with the following theory.

      Port 1434 = 1+4+3+4 = 12

      12 is the number of the month when Steve Gibson got hired as a consultant []. Coincidence? I think not!

      SQL (alphabet numbered) = S(19) + Q(17) + L(12) = 48

      48 is the number of states which are connected together on US map. That means that attack came either from Hawaii or Alaska.

      Using the search on a popular site called Google, I was able to track down [] the perpetrator.

      So at the end we are left with one answer: Steve Gibson is just hax0ring back, in an elaborate revenge plan to outlaw port 1434 and raw sockets.
  • Terrorism, must be (Score:5, Interesting)

    by isorox ( 205688 ) on Saturday January 25, 2003 @08:47AM (#5156233) Homepage Journal
    In South Korea internet services were shut down nationwide for hours on Saturday, the country's Yonhap news agency reported.

    It said the shutdown was triggered by "apparent cyber terror committed by hackers". []
  • by caluml ( 551744 ) <slashdot@spamgoeshere.calu m . o rg> on Saturday January 25, 2003 @08:48AM (#5156237) Homepage
    I find it lucky that the worm writer didn't make the worm fire out random traffic on random udp ports with spoofed addresses.

    It's only the fact the traffic is all destined for a certain destination port that makes it easy to filter.
    You are filtering it out on your firewalls, aren't you?
    /sbin/iptables -I FORWARD -p udp --dport 1434 -j DROP

    This could have been a lot lot harder to filter out. I expect we'll see ThisWorm v2 soon.

    I dread the day someone finds a hole in Apache, Sendmail or something really popular and writes a worm like this...
    • by bwalling ( 195998 ) on Saturday January 25, 2003 @08:55AM (#5156261) Homepage
      It's only the fact the traffic is all destined for a certain destination port that makes it easy to filter.
      You are filtering it out on your firewalls, aren't you? /sbin/iptables -I FORWARD -p udp --dport 1434 -j DROP

      Exactly. From the MS Security bulletin:

      The risk posed by the vulnerability could be mitigated by, if feasible, blocking port 1434 at the firewall.

      What the heck was it doing open in the first place?
      • by caluml ( 551744 ) <slashdot@spamgoeshere.calu m . o rg> on Saturday January 25, 2003 @09:02AM (#5156289) Homepage
        Wouldn't it be nicer if the owners of these machines bother patching the fucking things though?

        As far as I'm concerned, boxes SHOULD be able to stand on their own without firewalls. A firewall just adds another layer.

        Sounds like you're advocating armadillo security to me - hard on the outside, soft on the inside.
        • by Tassach ( 137772 ) on Saturday January 25, 2003 @02:35PM (#5157625)
          There's no good reason whatsoever for a database server to connect directly to the internet - it should only accept connections from trusted hosts. You never let an untrusted application talk directly to the database - if they need to query the database it should be proxied by a piece of middleware. Any DBA who says otherwise is an incompetent idiot.

          You put your webserver on a DMZ, and let it (and only it) talk to the database server through the firewall. Any 2-tier client-server app should be going through a VPN or other secure tunnel.

          The only way to do security is to have multiple layers, and to ruthlessly apply the priciple of least privilidge (you get only those permissions you ABSOLOUTELY need and nothing more).

      • What the heck was it doing open in the first place?

        Because sometimes you need to connect to SQL from somewhere outside the local LAN? For example, we have SQL passed logging services running in Sydney that connect back to a SQL server in London. Of course, inbound connections are limited to the correct address range.

      • by Anonymous Coward on Saturday January 25, 2003 @09:08AM (#5156319)
        What the heck was it doing open in the first place?

        When the SQL Server 2000 client Net-Libraries connect to an instance of SQL Server
        2000, only the network name of the computer running the instance and the instance
        name are required. When an application requests a connection to a remote computer,
        Dbnetlib.dll opens a connection to UDP port 1434 on the computer network name
        specified in the connection. All computers running an instance of SQL Server 2000
        listen on this port. When a client Dbnetlib.dll connects to this port, the server
        returns a packet listing all the instances running on the server. For each instance,
        the packet reports the server Net-Libraries and network addresses the instance is
        listening on. After the Dbnetlib.dll on the application computer receives this
        packet, it chooses a Net-Library that is enabled on both the application computer and
        on the instance of SQL Server, and makes a connection to the address listed for that
        Net-Library in the packet.

        So the UDP 1434 port is open when the SQL Server is started to listen all the clients
        with any IP address on this port. SQL Server only receives the packet from the client
        on this port to determine which instance the client attempts to access and return the
        related information of the SQL Server to the clients. Then, the clients can create
        the connection to the SQL Server with the protocol enabled on the server side.
        • by bwalling ( 195998 ) on Saturday January 25, 2003 @10:58AM (#5156662) Homepage
          So the UDP 1434 port is open when the SQL Server is started to listen all the clients
          with any IP address on this port. SQL Server only receives the packet from the client
          on this port to determine which instance the client attempts to access and return the
          related information of the SQL Server to the clients. Then, the clients can create
          the connection to the SQL Server with the protocol enabled on the server side.

          There is a difference between a port being open on the machine the service is on and the port being open to the world. You should not leave this port open to the world. If people outside your firewall need access to your internal MSSQL server, you leave TCP 1433 open to selective hosts.
      • I agree, it ought to be closed. However, our beloved MySQL also leaves its port open, listening on all NICs in a box.

        Gr.... All the more reason to run a host firewall on every machine.

    • by sql*kitten ( 1359 ) on Saturday January 25, 2003 @08:57AM (#5156271)
      You are filtering it out on your firewalls, aren't you? /sbin/iptables -I FORWARD -p udp --dport 1434 -j DROP

      I bloody hope no-one is specifically blocking this port. That's not how firewalls are supposed to be used. First you block everything then only open the specific ports you need. In most cases, these are 80 and 22 and maybe 25. There's no reason a database server's protocol port should ever be exposed to the public Internet!
      • by Anonymous Coward on Saturday January 25, 2003 @09:05AM (#5156303)
        Depends. If you're protecting your network, you are right: "allow required traffic, block everything else". If you're providing network services to others, they probably don't want to beg you everytime they need to open a port. In that case it's "filter bad traffic, allow everything else".
      • by caluml ( 551744 ) <slashdot@spamgoeshere.calu m . o rg> on Saturday January 25, 2003 @09:05AM (#5156305) Homepage
        No, firewalls are for use as your needs require.
        I, for instance allow no incoming, but don't restrict outgoing. It's not a huge corporation, it's a R + D lab, where the overhead and hassle I'd cause by restricting outbound traffic would stiffle the lab users productivity. Still, I added the block to that specfic port in the slim chance that an internal box was infected (lord knows how) that it would be a localised problem, not contributing.

        I don't think you should tell people what firewall rules they should be running.
        • No, firewalls are for use as your needs require.
          I, for instance allow no incoming, but don't restrict outgoing.

          Firewalls are not just for your needs. They are also for the protection of others, too. It's the all-ports-open-on-outgoing stuff that allows worms like this to spread and wreak so much havoc. It's dial-up Internet providers leaving port 25 open on outgoing that allow spammers to use throwaway accounts for spamming.

          I don't think you should tell people what firewall rules they should be running.

          Hey, if it's my network being affected by your lack of rules, I've got a moral right to tell you what rules your firewall needs.
      • There's no reason a database server's protocol port should ever be exposed to the public Internet!

        No reason? Really? What about distributed servers taking to a central database? Desktop software that queries a remote database? Remote administration of a remote database? All legitimate reasons.

      • by Fembot ( 442827 ) on Saturday January 25, 2003 @09:30AM (#5156390)
        Actualy I suspect most ISP's probably operate a policy of blocking only problem ports. Imagine how annoying it would be if your ISP/coloc host blocked everything except http, telnet and smtp on the grounds that one day there might be a vunerability in some of the other services that run on other ports... I suspect they wouldnt be my coloc host for long at all
    • by Anonymous Coward
      I dread the day someone finds a hole in Apache, Sendmail or something really popular and writes a worm like this...

      The point isn't finding the hole, it's people not patching their servers. I mean FFS this was discovered and patched over six months ago. SQL Server is not consumer software - you can't blame Joe Public for not being up-to-speed on net security issues - this is professionals not doing their jobs properly.
    • by giel ( 554962 ) on Saturday January 25, 2003 @10:43AM (#5156599) Journal
      I find it lucky that the worm writer didn't make the worm fire out random traffic on random udp ports with spoofed addresses.

      As far as I can see that's nonsense. If he or she had the worm wouldn't work as well as it did.

      • Using random ports it doesn't work. You need a specific port because that's the one you know how to exploit. A different port might be closed, safe or exploitable in a different way.
      • I think spoofing the return address wouldn't work very well either because the traffic payload the worm generates is caused by packets travelling between two machines. A spoofed address would cause the effect to die.
    • by davew ( 820 ) on Saturday January 25, 2003 @10:49AM (#5156623) Journal
      I dread the day someone finds a hole in Apache, Sendmail or something really popular and writes a worm like this...

      Um, like the original Internet Worm [] which started all this trouble in the first place? :-)

      This was the incident that sparked the creation of CERT/CC []. Every time I see another worm, I wonder why we still haven't learned [].


  • by h2odragon ( 6908 ) on Saturday January 25, 2003 @08:49AM (#5156240) Homepage
    the fun's almost over now

    Collected a packet disasembly and some urls here [].

    Everyone seems to be assuming this is a new use of an old (July) hole; I'm not certain of that. Any facts welcomed, see above url.

    • by numatrix ( 242325 ) on Saturday January 25, 2003 @09:49AM (#5156446)
      I'm relatively sure it ~is~ the old vulnerability. Notice in your very own hex dump.

      It starts off with 04 (the same hex byte as in my IDS signature for the Server resolution service buffer overflow everyone thinks this is) and then a bunch of padding with 0101. I myself am skeptical based on volume alone how this could be an old vulnerability, but remember, Code Red and Nimda were old too, and they didn't have any problem finding lots of new hosts very quickly.
    • by Graspee_Leemoor ( 302316 ) on Saturday January 25, 2003 @12:00PM (#5156909) Homepage Journal
      " been watching this all night...
      the fun's almost over now"

      I sincerely thank you, Sir or Madam. I previously thought that I was the most sad, laughable figure in the entire world, but now, having read your post, which conjures up images of someone sitting in front of their monitor, snacks in hand, gasping in amazement at the output of tail -f on their firewall log all night, I know that there is yet hope for me.


  • Patch (Score:5, Informative)

    by sql*kitten ( 1359 ) on Saturday January 25, 2003 @08:50AM (#5156243)
    Microsoft released a patch [] for this 24th July, 2002.
    • Re:Patch (Score:5, Funny)

      by Anonymous Coward on Saturday January 25, 2003 @12:01PM (#5156914)
      I found it amusing that the two current headlines on the front page under the technology section at CNN are:

      Gates pledges better software security
      Electronic attack slows Net

      Now if they would only address security before they released their products we might not see these issues.
  • wow yeah! (Score:5, Interesting)

    by matth ( 22742 ) on Saturday January 25, 2003 @08:50AM (#5156245) Homepage
    Where I work we ended up with quiet the excitement. Around 1am I lost connectivity on my DSL modem at my house.. and I just figured something was up with the DSL so I fooled around with that for a while.... but then I realized the data light on the hub for the DSL modem was blinking a WHOLE lot and nothing else on the hub was (ie broadcasts were coming through)... I couldn't ping our core router, nothing... YIKES! So I hiked into work... only to find that 3 machines had been compromised. A co-lo we have, and some other ones. Nothing bad mind you.. easy to fix.. install Service Pack, and then firewall the ports out.. but still.... it was interesting.. I walked into the server room and was greated with a ton of orange lights (that are normally just blinking!) That thing can really cook out the damage!

    Someone really has carefully crafted this worm to try to bring down the net.. and what better time then on a Saturday morning when all admins are away and not planing to work the next day!
  • by vicviper ( 140480 ) on Saturday January 25, 2003 @08:51AM (#5156246)
    how many quries at the root level are unnecessary. :)
  • First hand report (Score:5, Interesting)

    by AirLace ( 86148 ) on Saturday January 25, 2003 @08:51AM (#5156247)
    Waking up at 2AM after falling asleep at work on a Friday evening, to be greeted by a wall full of router racks lit up like a wall-shaped christmas tree is a sobering experience indeed. Needless to say I've been working since then to apply appropriate firewall rules accross our network to block port 1434. Once this blows over, it's time to start some real PostgreSQL advocacy..
    • Re:First hand report (Score:3, Informative)

      by bwalling ( 195998 )
      Needless to say I've been working since then to apply appropriate firewall rules accross our network to block port 1434.

      What you really need to do is to assess which ports you need to leave open, and to which hosts they correspond. You need to block everything, and then set rules to enable only the ports/hosts that are necessary (open ports 80/443 to webserver, etc).

      Otherwise, you'll be doing the same thing for the next worm.
  • by tigress ( 48157 ) <> on Saturday January 25, 2003 @08:51AM (#5156250)
    ZDNet [] and Yahoo.
  • by cscx ( 541332 ) on Saturday January 25, 2003 @08:53AM (#5156253) Homepage
    Outside a firewall for no apparent reason is a tool. That being said, we live in a world of idiots. Why?

    NGSSoftware alerted Microsoft to this problem on the 17th of May 2002 and
    they have produced a patch that resolves these issues.

    This is January 25 2003 if I'm not mistaken. Are these the same people that leave their cars unlocked with the keys in the ignition?
  • how bad is it? (Score:3, Interesting)

    by chevelleSS ( 594683 ) on Saturday January 25, 2003 @08:54AM (#5156257) Homepage
    What does this worm rank compared to other DDOS in the past?
  • by Anonynmous Cow ( 637479 ) on Saturday January 25, 2003 @08:55AM (#5156260) Homepage Journal
    I was very surprised to discover both AP and CNN beat Slashdot to this story.

    Very disappointing.

    Timely is as important as accurate SlashEditors. Many of us look to you when big events occur...

    Especially considering this all began about 8 hours ago!
    • It was covered by the Slashdot masses on another security-related [] thread earlier this morning.

      If you want an non-editor-controlled story queue, with story selection subject to user moderation, try submitting/reading here []; the capability is now possible on Slashdot. It's not as simple as it could be, and it's only a week old, but it works without you having to leave Slashdot.

  • by Anonymous Coward on Saturday January 25, 2003 @08:56AM (#5156268)
    This site has a disassembly with an explanation: []
  • by valdezjuan ( 83925 ) on Saturday January 25, 2003 @09:01AM (#5156282)
    From digitaloffense: A new worm which exploits a vulnerability in MS SQL Server is bringing the core routers to a grinding halt. The speed of the propagation can be attributed to the attack method and simplicity of the code. The worm sends a 376-byte UDP packet to port 1434 of each random target, each vulnerable system will immediately start propagating itself. Since UDP is connection-less, the worm is able to spread much more quickly than those using your standard TCP-based attack vectors (no connect timeouts). Some random screen shots and information about the worm can be found HERE. []
  • Whoever... (Score:5, Insightful)

    by wulffi ( 176311 ) on Saturday January 25, 2003 @09:01AM (#5156284) Homepage
    Whoever puts a database outside a firewall? and then leave its external port open???

    Sysadmins like that should be dragged into the street and shot.
  • by tigress ( 48157 ) <> on Saturday January 25, 2003 @09:02AM (#5156285)
    ...the Slashdot article, that is. I've been watching this since I got up this morning (about five hours ago, local time). There's been plenty of discussions about this on various mailinglists, including NANOG [] and NordNOG [], as well as several IRC channels I frequent. I'm surprised it took this long for Slashdot to post anything about it.

    According to unconfirmed sources on NANOG, the worm seems to eat up bandwidth at line rate (even at GigE links), is rumored to amplify itself via Cisco routers, and is the creation of Saddam Hussein.

    My journal [] on the worm.
  • best writeup (Score:5, Informative)

    by numatrix ( 242325 ) on Saturday January 25, 2003 @09:02AM (#5156286)
    Best writeup I've seen is over at []. They were the first to update their internet status homepage alerting of the vulnerability as far as I can tell.
  • problem still around (Score:3, Interesting)

    by Dynamic Drive ( 636263 ) on Saturday January 25, 2003 @09:05AM (#5156302) Homepage
    I've been watching this havoc unfold all night as well. I wonder how long it's going to take for the entire problem to clear. Most sites that were previously unaccessible are for me are now, except some of our own. Makes me wonder if something else is going on in these datacenters.
  • Collected info: (Score:5, Informative)

    by Anonymous Coward on Saturday January 25, 2003 @09:06AM (#5156306)
    There's a stream of related info in the comments of Slashdot's Cross-Site TRACE [] story.

    Some snippets from there:

    Mabu's message says: Here's what we've been able to learn, at 4:30am Central time.

    We have reason to believe that something called the "SQL Worm" is in play. Some sort of DDOS attack which creates overwhelming traffic on port 1434. This is all preliminary stuff, so take it as such but I have one link up and 3 others down.

    I don't have confirmation or details on what systems are affected but we have information to indicate that the following networks are currently affected: Quest, Cable & Wireless, Broadwing, Sprint (partially). My Worldcom link seems to be unaffected (which is why I can post). Note that the connectivity interruptions may be regional but that's what we are dealing with in the South Central area of the US. This has been going on now for about 4-5 hours.

    What we are seeing is a major outage due to DDOS on port 1434, on portions of the Internet backbone. At this point, the exact pattern of the outage has not been clarified.

    Expect the problem to potentially be addressed when the backbone providers start filtering port 1434. However, it's taken them at least four hours to figure this out.

    We just got notice (a few moments ago) that Quest finally started filtering port 1434 and everything went back up. So now we need to figure out what vulnerability this was. My information indicates that port 1434 is MS SQL server resolution service (see related CERT advisory []. My initial impression is that while this vulnerability was discovered awhile back, someone just recently figured out a very effective exploit using the vulnerability. I am looking forward to hearing more about what people find out.

    The issue currently happening, from what anyone can tell at any rate is that a flaw in MSSQL has been found, due to everyone noticing a lot of traffic on 1434.. MSSQL port anyhow, I was running MSSQL earlier and my dns crapped out ctrl+alt+del'd and saw 85% cpu used by mssql server, killed it and boom everything was okay, possibly a worm traveling around, UUnet seems absolutely destroyed ;)

    I'm watching my firewall logs fill up even as I type, and all the 1434 hits are coming from different IPs... no dupes yet that I can see (maybe there are... but I'm not planning on sitting here all night reading logs). [] is an advisory about port 1434 [] shows a vivid picture of overall net health due to this

    SQLServer listens to 1434 to accept incomming connections. SQLServer 7 would then normally transfer these connections to 1433 by default. SQLServer 2000 would transfer the connection to a random port.

    It's best to 'hide' the SQLServer from the internet, and/or disable TCP/IP listening for SQLServer totally when it's connected to the Internet. MS also suggests SQLServer should never be exposed to the Internet directly. You can hide SQLServer (2000) directly, using the Server network utility, shipped with SQLServer. You can there first deselect TCP/IP as a protocol that's active, and if you need it, you can select 'hide' to hide the server on the internet, however it's better to disable TCP/IP totally, since you do not need it when you work with SQLServer from the same box (f.e. a website running on the same box accessing the SQLServer).

    Oh, of course it should be mentioned, there is a patch for this available at MS' technet site. [] may be the CERT article related to this vuln.

    From: Michael Bacarella Date: Fri Jan 24, 2003 11:11:41 PM America/Los_Angeles
    To: nylug-,,

    I'm getting massive packet loss to various points on the globe. I am seeing a lot of these in my tcpdump output on each host.
    02:06:31.017088 > udp 376
    02:06:31.017244 > icmp: udp port ms-sql-m unreachable [tos 0xc0

    It looks like there's a worm affecting MS SQL Server which is pingflooding addresses at some random sequence. All admins with access to routers should block port 1434 (ms-sql-m)!

    Everyone running MS SQL Server shut it the hell down or make sure it can't access the internet proper! I make no guarantees that this information is correct, test it out for yourself!

    -- Michael Bacarella 24/7
    phone: 646 641-8662
    Netgraft Corporation
    "unique technologies to empower your business"
    Finger email address for public key. Key fingerprint: C40C CB1E D2F6 7628 6308 F554 7A68 A5CF 0BD8 C055

  • by g4dget ( 579145 ) on Saturday January 25, 2003 @09:10AM (#5156326)
    While part of the problem is that Microsoft software sucks particularly badly when it comes to security, something like this can happen with other software as well. The real problem is that we have a software monoculture: we need many more, different, independently implemented software systems. They will all have bugs, but as long as they all have different bugs, we are mostly OK. And that's the real reason why Microsoft's market dominance, in particular on large numbers of small machines run by non-experts, is a problem.
  • Open the gates... (Score:4, Insightful)

    by Tyreth ( 523822 ) on Saturday January 25, 2003 @09:11AM (#5156327)
    ...let the mandatory "this wouldn't happen if sysadmins upgraded" comments begin!

    Seriously though, you should have upgraded!

  • by ediron2 ( 246908 ) on Saturday January 25, 2003 @09:22AM (#5156368) Journal [] has a great annotated geeks-eye-view of this worm.

    Kudos to cstone@boredom. Interesting & educational, with a nutty crunchy flavor.

  • by JasonUCF ( 601670 ) <> on Saturday January 25, 2003 @09:35AM (#5156405) Homepage
    I groggily stumble up to my computer, it being a normal enough sort of Saturday AM, and as I sit down I cast a lazy eye at my firewall counter.

    Woah! What's.. uh.. 150 inbound requests.. doing.. today.. worm?

    I start to fire up /. -- a lengthy process due to my dumbass ISP not having reverse DNS entries -- so I sniff around my logs.

    *clickity click*

    1434? The hell is 1434. Worm?

    *slashdot shows*

    Ah ha! Ve haf comprehension.

    *groggily shuffle off to get coffee, oooo black gold*

    For what it's worth, a majority of the packets so far have been mostly US servers -- .edu's with cute names like 'staging3', 'testing1', and, no joke, 'snoogans'.
  • Fox News (Score:5, Funny)

    by avalys ( 221114 ) on Saturday January 25, 2003 @09:39AM (#5156419)
    Heh...on the Fox News Channel's ticker, they had the following tidbit of information:

    "The virus spreads using a Microsoft vulnerability known as "SQL Server""

    • Re:Fox News (Score:5, Funny)

      by Kashif Shaikh ( 575991 ) on Saturday January 25, 2003 @12:37PM (#5157069)
      Heh...on the Fox News Channel's ticker, they had the following tidbit of information:

      Well, on CNN's headline newsticker they have:

      "[Microsoft][ODBC SQL Server Driver]Operation canceled

      [Microsoft][ODBC SQL Server Driver]Timeout expired

      ODBC: Msg 0, Level 16, State 1

      Communication link failure

      Connection Broken"

  • by Alien Being ( 18488 ) on Saturday January 25, 2003 @09:50AM (#5156448)
    Is this thing directly targetting root/tld servers? Is the worm doing dns lookups as opposed to just picking an ipaddr? Is it the PTR servers which are being hammered by loggers doing reverse lookups?

    Did someone jump to a bad conclusion based on ping stats?

  • by Raven-sama ( 527194 ) on Saturday January 25, 2003 @09:50AM (#5156449)
    I don't know if anyone else has had the same problem, but email addresses seem to not be working on Hotmail. I doubt they're related, but has anyone else had the same problem, and is this likely to be the cause? By the way, accounts work fine.
  • 50% from Colleges??? (Score:5, Interesting)

    by Gothmolly ( 148874 ) on Saturday January 25, 2003 @10:04AM (#5156484)
    About half of the sources I've seen have been either .edu sites or sites in other countries which belong to colleges (, etc.). Is there some sinister corellation here? Perhaps colleges get free MS-ware, and let the students run the networks?
  • by weave ( 48069 ) on Saturday January 25, 2003 @10:13AM (#5156499) Journal
    A post to bugtraq by George William Herbert, notes that the floods caused by this worm is causing many cisco routers to shut down, which helps contain the damage ironically enough. I've seen this happen at one of my work sites that is admined by someone else. The infected box, according to MRTG, was nailing its closest router at 100 megabits/sec for about an hour, then the router itself went down. Sweet...

    "...the volume from this triggers the Cisco netflow switching bug and is causing routers to lock up at places, etc."

  • This will continue (Score:5, Insightful)

    by NineNine ( 235196 ) on Saturday January 25, 2003 @10:43AM (#5156600)
    Worms that do this sort of thing will continue ad infinitum. The reason is that there's no financial detriment to having one of your own boxes act as a zombie and send out tons and tons of packets. None whatsoever. There's no central accountability. That's the way the Net is set up. I don't see any way around it.
  • by codepunk ( 167897 ) on Saturday January 25, 2003 @11:09AM (#5156704)
    Yes it can indeed get inside a firewall. Say you got bonehead web developer front page dude at home running the developer version. It is no doubt infected with the worm since said developer is using front page and MS SQL on his home xpeeee box. He thanks you by logging in via VPN into your network and spreads the joy. Priceless.....

  • Ironic timing... (Score:5, Informative)

    by weave ( 48069 ) on Saturday January 25, 2003 @11:19AM (#5156745) Journal
    Gates pledges better software security [] (btw, isn't this basically a repeat of what he spammed out last July?)

    Gates acknowledged that the technology industry must make significant improvements, adding that, "Microsoft has a responsibility to help its customers address these concerns, so they no longer have to choose between security and usability."

    How about easier ways to apply hotfixes remotely to desktop computers? (There are ways apparently, but requires installing IIS and SQL ironically, to run something called SUS.) I'd prefer the hotfix to simply have an option like '-m\\machine' to apply to domain machines in a domain admin context so I can script the installs to my tastes and needs. No need to get overly complex. Besides, I'd rather not have an IIS server at my site if I can help it. Apache runs everything. Just another damn thing to learn for something that should be simple.

    Also, the hotfixes themselves only have about 10 different ways of applying at the command line unattended. How about standardizing the hotfix installers too...

    Example, this is what is run after an XP desktop install with SP1 at our location...

    q329834 -u -n -z
    q323255 -u -n -z
    q329048 -u -n -z
    start /wait q328310 -u -n -z
    start /wait vm-sfix3 /q /r:n
    start /wait q324929 /q /r:n
    q329115 -u -n -z
    q329390 -u -n -z
    q810565 -u -n -z
    It doesn't include latest javavm fix, which for some reason won't install right during the guirunonce part of an install, so I have to script to reboot the machine TWICE before running...

    start /wait msjavwu.exe /q /r:n
    Think that's bad? Here's some pre sp1 hotfix command lines from an earlier script..

    Msjavx86.exe /c:"javatrig.exe /exe_install /l /qq" /q:a /r:n
    vbs56nen /q /r:n
    msxm /q /r:n
    start /wait q318202 /q /c:"dahotfix /q /n"
    And the syntax to install unattended is never easy to find on their site. I usually have to use google to search to find what I need, their search engine really sucks. Others must feel the same way since there is a dedicated google page for this at []
  • by Featureless ( 599963 ) on Saturday January 25, 2003 @02:48PM (#5157684) Journal
    OK, help me out here.
    1. The first and foremost way we should have stopped this worm was with firewall rules and the "Server Network Configuration." You don't want to be running anything like this open to the network. Fine.

      The bad assumption people are making here is that there's "no reason to break this rule." Well, unfortunately, this is just not so.

      In my case, a project involved upsizing a client's access database, and then transferring it from my dev machine to an ISP's SQL Server instance. The client has a dynamic IP address, and they would never even consider the cost of using a VPN. My SQL Server ports were open for only 3 weeks, during the transition period, and would have been shut down next week.

    2. Everyone is saying "it's your fault - you didn't install the patch."

      I kept up on service packs (I was up to SP2), and had installed every SQL Server security patch I could find. I had a non-guessable sa password. I got it anyway.

      So why is that? I'm not sure. But I have some observations about the manner in which you're supposed to keep SQL Server (and other MS applications for that matter) current which bear seriously on the issue:

      1. First, there's the "fine print" phenomenon on Microsoft patches. Aside from service packs, these are usually just utterly simplistic "unzip and spray files" installers, occasionally with a few scripts thrown in. Install them in the wrong order, or fail to obey some other 8pt type caveat (and there can be dozens) and you render yourself unprotected again, while maintaining the appearance of being protected. It's likely this is why I wasn't protected despite believing I was.

      2. Where is the complete list of all patches, with downloaded links? What part of Microsoft's site is it prominently displayed on? Where's the order they need to be installed in, with concise instructions?

        Anywhere? I can't find it today. Maybe it exists and I just didn't notice it. That would be atrocious site design. Or maybe a simple, centralized "MS SQL Server 2000 Security Page" with ordered patch list and instructions doesn't even exist. That's just atrocious.

        All I can find is top-level references to service packs and an unqualified link to an all-microsoft download search page. When you select SQL Server 2000 in it, you get everything, not in order, patches thrown together with samples, evaluation downloads, etc.

        And I'm supposed to check here... every week? Sounds sensible on the surface, but if they really wanted to prevent trouble:

      3. Two words: WINDOWS UPDATE! What the hell is wrong with these people that if they have a patch for SQL Server 2000, they can't just throw it into Windows Update? It does a little check - do you have SQLSvr installed? Yes? Do you have the patches installed?

        IT'S SO BLOODY SIMPLE. Yet they didn't bother.

        Compare this to redhat, where there's one tool, up2date, and it works for everything. And you are trivially notified by email when there's an update.

      4. I believe there's a tool that lets you examine your installation to see what service packs are installed and which aren't. I remember vividly running it last summer and discovering that I was up to date. Tellingly, I can't even find it in their site today.

      5. Yes, the service packs. I notice SQL Server 2000 SP3 protects you against this buffer overflow. I also notice this service pack came out last week.

        At any rate, we can at least tell people a convenient fix - go install SQL Server 2000 SP3.

    What's the bottom line? I had a reason to have the port open. And I had a not-for-nothing false sense of security that I was protected against this vulnerability. And most of all, if this was RedHat (for instance) I would never have had this problem - because I would have been notified the moment the patch was available, and would have installed it in a heartbeat, through their single, consistent, easy-to-use interface; and so would tens of thousands of others.
  • Whats interesting... (Score:4, Interesting)

    by Anonymous Coward on Saturday January 25, 2003 @04:17PM (#5158066)
    ... is that our Corporate IT has *outsourced* all control of our firewalls (to a company which recently filed chapter 11, if I recall), and so can't update them on the fly...

    And, on top of this, our "corporate IT security" just sent out an email that some of their *internal* machines were infected (so obviously *something* was accessable through the firewall) and now we who are connected to corporate via a T1 must apply the patches. So much for the firewall.

    This also happened with Code Red two years ago. Big panic, everyone patching their systems, because corporate had holes in the firewall.

    Yet, we have our own firewall to a customer site (which we've managed on our own for years, and which corporate now wants to take over) which we have *never* been infected via. Go figure.

    Not saying that we shouldn't have been up on it, but we have noone dedicated to IT Security (funny, since we do DOD work) in our building, and we are all so swamped with other stuff we rarely have the time to keep up with it.

    At my *last* job, however, we setup a new box and immediately port-scanned it... knew what every service was on the box, and if we didn't, closed it down. And that *wasn't* DOD... e-commerce. And we kept on top of patches.

    So... you credit card number was *really* safe at my old job... but our nation's secrets may not be at the new job.

    Go figure.
  • by strAtEdgE ( 151030 ) on Saturday January 25, 2003 @04:19PM (#5158093)
    My intial thought on this was that this isn't MS's fault and we shouldn't be bashing them for this worm; almost every os and daemon out there has had it's holes and exploits and MS has already put out the fix so it's in the admins hands now.

    But on second thought, when I look at the serious impact of the worms that have been created for MS products and their vulnerabilities the last few years, the obvious becomes apparent: admins of MS OS's and processes on them are a LOT slower to patch than any of their counterparts (read: stupider). And the thing is, MS knows this, they specifically market to the stupid/lazy admins. They're the "easy" OS, they sell their products by telling people that you just install them and never worry about them again. I've taken too many MS courses (I am an MSCE and MSCDBA if they haven't expired on me, but I couldn't care less) and not once was patching the operating systems or server processes ever mentioned during all those courses, which is amazing to me.

    And hey, to each their own I guess... apparently there aren't enough intelligent or well read admins around so there is a demand for these products and this approach. But if that's the case, then I think it has to be said that MS has a greater responsibility to create products free from exploits than anyone else, if they're marketing and teaching the idea that you don't need to patch.

    It's by creating that laissez faire attitude towards administration that MS is directly responsible for the proliferation of these worms.

I've noticed several design suggestions in your code.