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

6 of 906 comments (clear)

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

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

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