Slashdot Mirror

It's great that bugs are fixed, but how about investing more in user education, so that people at least realize that they could have every patch imaginable installed but still be owned by SQL injection, a problem with whoever wrote their webpage or app that interfaces with the SQL server and not the SQL server it self.

MySQL is a lot better about it then MSSQL due to the lack of comments, but disastrous things can still be done with this.

For those that are curious, more info on SQL injection can be found here and here.

Or you can follow the instructions at http://www.nextgenss.com/advisories/winampheap.txt to disable xm at a lower layer. (This is from a link from the techworld article.)

Yes, According to the notice:


Systems Affected: Nullsoft Winamp versions 2.91 to 5.02 (possibly older versions, although this is not confirmed)

Adobe Acrobat Reader... can be extended using the XML Forms Data Format or XFDF... XFDF files... are rendered automatically on downloaded [sic] when using applications such as Internet Explorer... When parsing an XFDF document the Adobe Reader suffers from a classic stack based buffer overflow vulnerability... On contacting Adobe, they confirmed that the current version is no longer vulnerable and NGSSoftware urgently advises users of Adobe Reader to upgrade.

Whatever you do, do *NOT* go to their login page. If you do go there, do *NOT* put in an apostrophe for both your username and your password. If you should somehow make the mistake of doing so, do NOT read the error message from SQL server, and do NOT proceed to read any research papers on how to exploit SQL injection bugs. You have been warned...:)

This Research Advisary reads real well ... lays it right out there. Any admin-type that ignores this should really find another line of work.

I meant that the original intent was to be idle for a while and then do lots of damage, not that the exploit as it happened will actually accomplish this.

From this page it's clear the author of the worm could have used it to execute absolutely any code he wished with the same level of privilege given to MSSQL on any given server (how much privilege that usually is, I don't know).

However, from this disassembly of the worm it's also clear that, as written, it's incapable of anything other than self-propagation. My speculations were unfounded.

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

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

It is believed this worm leverages a vulnerability published in June 2002.

It is strongly recommended that a rule be added to each organization's firewall such that any packet destined for UDP port 1434 on the 'clean' side of the firewall be dropped and logged. No host, even DNS Servers, should be allowed to send traffic to this port.

It details stack-based, heap-based and network-based DOS vulnerabilities. Wheee!