Slashdot Mirror

← Back to Stories (view on slashdot.org)

MS SQL Server Worm Wreaking Havoc

Posted by ryuzaki0 on from the no-man-will-know-the-day-or-the-hour dept.

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. internetpulse.net 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."

22 of 906 comments (clear)

  1. As I said in a previous post... by caluml · · Score: 4, Informative

    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...

    --
    Get your own free personal location tracker
    1. Re:As I said in a previous post... by bwalling · · Score: 5, Informative

      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?

    2. Re:As I said in a previous post... by sql*kitten · · Score: 5, Informative

      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!

    3. Re:As I said in a previous post... by Anonymous Coward · · Score: 5, Informative
      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.
    4. Re:As I said in a previous post... by sporty · · Score: 4, Informative

      Actually, then the firewall rules are screwed up. If there is an ISP with billions and billions of servers, the firewall should block all traffic to the servers while routing all traffic to specific subnets. Block first, allow through later.

      --

      -
      ping -f 255.255.255.255 # if only

    5. Re:As I said in a previous post... by silas_moeckel · · Score: 4, Informative

      That depends on what sort of routers they are using. A lot of Cisco gear an others have overhead running ACL's (first Cisco that can do compiled is a 7200 I think) so you want to accept/deny your most common traffic first so your router dosent die when your throughput goes up.

      --
      No sir I dont like it.
    6. Re:As I said in a previous post... by bwalling · · Score: 4, Informative

      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.

  2. been watching this all night by h2odragon · · Score: 4, Informative
    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.

    1. Re:been watching this all night by numatrix · · Score: 3, Informative

      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.

  3. Patch by sql*kitten · · Score: 4, Informative

    Microsoft released a patch for this 24th July, 2002.

  4. ZDNet and Yahoo stories by tigress · · Score: 3, Informative

    ZDNet and Yahoo.

  5. Another look at the worm by valdezjuan · · Score: 3, Informative

    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.

  6. best writeup by numatrix · · Score: 4, Informative

    Best writeup I've seen is over at iss.net. They were the first to update their internet status homepage alerting of the vulnerability as far as I can tell.

  7. Some Links by Isomer · · Score: 5, Informative
    Reachability issues caused by the worm:
    http://average.matrixnetsystems.com/Daily/markR.ht ml
    http://mrtg.nac.net/switch9.oct.nac.net/3865/switc h9.oct.nac.net-3865.html

    The advisory announcing the flaws:
    http://www.nextgenss.com/advisories/mssql-udp.txt Various disassemblies and discussions: http://www.snafu.freedom.org/tmp/1434-probe.txt http://www.digitaloffense.net/worms/mssql_udp_worm / http://www.boredom.org/~cstone/worm-annotated.txt

    Writeups:
    http://www.cnn.com/2003/TECH/internet/01/25/intern et.attack.ap/index.html
    http://news.bbc.co.uk/2/hi/technology/2693925.stm
    http://story.news.yahoo.com/news?tmpl=story&u=/ap/ 20030125/ap_wo_en_po/na_gen_internet_attack_2
    http://bvlive01.iss.net/issEn/delivery/xforce/aler tdetail.jsp?oid=21824

  8. Collected info: by Anonymous Coward · · Score: 5, Informative
    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 [cert.org]. 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, http://internethealthreport.com/ 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).

    http://www.nextgenss.com/advisories/mssql-udp.txt is an advisory about port 1434

    http://average.matrix.net/Daily/markR.html 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.

    http://www.kb.cert.org/vuls/id/370308 may be the CERT article related to this vuln.

    Resent-From: mbac@romulus.netgraft.com
    From: Michael Bacarella Date: Fri Jan 24, 2003 11:11:41 PM America/Los_Angeles
    Resent-To: bugtraq@securityfocus.com
    To: nylug- talk@nylug.org, wwwac@lists.wwwac.org, linux-elitists@zgp.org
    Subject: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!

    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 150.140.142.17.3047 > 24.193.37.212.ms-sql-m: udp 376
    02:06:31.017244 24.193.37.212 > 150.140.142.17: icmp: 24.193.37.212 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 http://netgraft.com/
    "unique technologies to empower your business"
    Finger email address for public key. Key fingerprint: C40C CB1E D2F6 7628 6308 F554 7A68 A5CF 0BD8 C055

  9. Re:What's inside ? by AirLace · · Score: 4, Informative

    There are no SQL commands in the worm. It just initiates a bouncing ping between two MS SQL servers that continues until the network or one of the servers is brought down. An annotated dissection of the worm is provided here.

  10. This is inside... by dark-br · · Score: 3, Informative



    Disassembly of the 404 bytes being sent by affected systems

  11. A bug in CISCO routers is helping to control this! by weave · · Score: 4, Informative
    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."

  12. It can get inside a firewall by codepunk · · Score: 3, Informative

    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.....

    --


    Got Code?
  13. Ironic timing... by weave · · Score: 5, Informative
    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 microsoft.com 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 http://www.google.com/microsoft
  14. Attention! You must have SP3 or MS039!! by Anonymous Coward · · Score: 3, Informative

    I've been a call all morning and we are sure now that SP2 does NOT protect your server from this attack...YOU MUST APPLY MS-039 to protect your server

    1. Re:Attention! You must have SP3 or MS039!! by RedWolves2 · · Score: 3, Informative

      Full description on NAI web site http://vil.nai.com/vil/content/v_99992.htm#Removal Instructions

      Need both MS02-034 and MS02-039 MS02-034 must be included on SP3.