MS SQL Server Worm Wreaking Havoc

Who did this I wonder????? by amigaluvr · 2003-01-25 00:46 · Score: 4, Funny

Kevin Mitnick is allowed back on the net and the net goes fubar

Re:Who did this I wonder????? by Anonymous Coward · 2003-01-25 01:22 · Score: 5, Funny

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.
Re:Who did this I wonder????? by zogger · 2003-01-25 06:38 · Score: 5, Insightful

--I thought this too, but I mean semi seriously. I stayed up real late watching it to make sure it wasn't a 'war' prelude. All the second world potential badguys have a cyber attack part of their assymetrical warfare plans, that's just freely available data you can read about.

My "oh crap,no internet" communications plans are a heap-o shortwaves and scanners. Better than nuthin. I know all the commercial am and fm and tv stations will all get taken over by the fema boxes, and start spewing dotgov propaganda (moreso than normal), so I'd be more monitoring some more "unregulated" sources.

Terrorism, must be by isorox · 2003-01-25 00:47 · Score: 4, Interesting

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

http://news.bbc.co.uk/1/hi/technology/2693925.stm

Re:Terrorism, must be by weave · 2003-01-25 00:54 · Score: 5, Funny

Terrorism? Bill Gates better be detained indefinitely as an enemy combatent then. Finally, some good may come out of this terrorism paranoia!
Re:Terrorism, must be by hardcode · 2003-01-25 04:37 · Score: 4, Funny

In South Korea internet services were shut down nationwide for hours on Saturday, the country's Yonhap news agency reported.

And every email admin in the western world heaved a sigh of relief
Re:Terrorism, must be by Nogami_Saeko · 2003-01-25 07:07 · Score: 5, Insightful

Not to mention every starcraft and diablo player :P

N.

--
"Nothing strengthens authority so much as silence." - Charles de Gaulle

As I said in a previous post... by caluml · 2003-01-25 00:48 · 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

Re:As I said in a previous post... by bwalling · 2003-01-25 00:55 · 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?
Re:As I said in a previous post... by sql*kitten · 2003-01-25 00:57 · 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!
Re:As I said in a previous post... by caluml · 2003-01-25 01:02 · Score: 5, Insightful

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.

--
Get your own free personal location tracker
Re:As I said in a previous post... by Anonymous Coward · 2003-01-25 01:05 · Score: 5, Insightful

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".
Re:As I said in a previous post... by caluml · 2003-01-25 01:05 · Score: 4, Interesting

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.

--
Get your own free personal location tracker
Re:As I said in a previous post... by Anonymous Coward · 2003-01-25 01:08 · 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.
Re:As I said in a previous post... by tom.allender · 2003-01-25 01:08 · Score: 5, Insightful

Consider a VPN dude.
Re:As I said in a previous post... by caluml · 2003-01-25 01:24 · Score: 5, Insightful

Firewalls promote softer security.

"Oh, it's OK because it's behind the firewall..."

I think firewalls make people lazy. Imagine if we didn't have firewalls. We'd have to keep our passwords good, our services minimal, and make sure we were running the latest, most secure daemons.

--
Get your own free personal location tracker
Re:As I said in a previous post... by Fembot · 2003-01-25 01:30 · Score: 4, Insightful

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
Re:As I said in a previous post... by sql*kitten · 2003-01-25 01:33 · Score: 4, Insightful

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?

That's what VPNs are for, my friend.
Re:As I said in a previous post... by sporty · 2003-01-25 01:47 · 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
Re:As I said in a previous post... by silas_moeckel · 2003-01-25 02:58 · 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.
Re:As I said in a previous post... by bwalling · 2003-01-25 02:58 · 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.
Re:As I said in a previous post... by Zeinfeld · 2003-01-25 04:08 · Score: 5, Interesting

Firewalls promote softer security.
I have argued for many years that people tend to get the idea that a firewall is some kind of +8 amulet of protection they just strap on which will protect them from pretty much anything.
However there are real benefits to using firewalls and NAT boxes. Unfortunately there are some members of the IESG who are confused on this point but thats because they are blinkered by the end-to-end dogma. I'll note here that Steve Bellovin, the new security AD knows a thing or two about firewalls.
There are actually two end-to-end principles. Applied to networking it meant put the intelligence at the ends, not in the middle of a communication. This was applied to security to mean the same thing.
End-to-end is appropriate to the design of network protocols, it is inappropriate as a guide to operational security. Many protocols are not designed securely, most protocol implementations have flaws.
Another dogma that is inappropriate to operational security is the 'security through obscurity' trope. A design that relies on security through obscurity is broken. This does not mean that operators should divulge all the details of their operations to attackers in the hope this will improve security, it will not. Argument of this type was used to block the introduction of shadow passwords on UNIX for years after the vulnerability to dictionary attacks was widely known and being exploited by attackers.
A firewall and NAT box provides a significant degree of security at low cost. NAT provides a means of concealing the internal structure of the network. This does not eliminate the possibility of attack but raises the bar significantly. If you are running a site that is considered attractive to hackers a technology that weeds out the knob turners and dimmer script kiddies has value.
What we need to move to is security in depth, recognizing that design security and operational security are different and that both are important.

--
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Re:As I said in a previous post... by Dudio · 2003-01-25 04:33 · Score: 5, Interesting

I wouldn't say firewalls make people lazy; it's more a problem of people not understanding security.

These people are just as likely to say things like "I'm 3DES encrypting my data, so there's no way anybody can read it", because they fail to understand the meaning of statements like "cracking 3DES is computationally infeasible". When you try to explain to them that their webserver and applications are much more likely to be their weakness than their encryption algorithm, they give you blank looks and mutter about the Computerworld article that said 3DES is "unbreakable encryption". It's not a problem with 3DES (or any strong algorithm); it's a problem with people not understanding that any security measure can be negated by poor design in other parts of their architecture.

It's the same thing with firewalls. Only the unknowledgable would drop in a firewall and then go off to the bar to celebrate their newly "secure" network. That doesn't mean that the firewall is useless; it is still a crucial tool for securing one's network. The problem is the people who have no idea how to use the tool properly, and no concept of what a real-world attack actually looks like.
Re:As I said in a previous post... by DarkZero · 2003-01-25 04:37 · Score: 5, Funny

Imagine if we didn't have firewalls. We'd have to keep our passwords good, our services minimal, and make sure we were running the latest, most secure daemons.

Locks promote softer security.

"Oh, I'm OK because I have locked doors and windows..."

I think door locks make people lazy. Imagine if we didn't have deadbolts, or doors for that matter. We'd have to sit in front of the front door, with a shotgun, never sleeping for more than a few moments.
Re:As I said in a previous post... by DavidTC · 2003-01-25 04:55 · Score: 5, Insightful

One of the best thing you can do with a firewall is something it's hard to do with a desktop machine...LOG.
This adds a third layer of security, in addition to the 'secure firewall' and the 'secure desktop'. If, god forbid, someone gets through your firewall, you'll at least know it.
And I'm talking about logging outgoing traffic, also. After all, if your firewall is set up correctly you can't have any random incoming traffic...but you'll have lots of outgoing. They have NIDS to detect suspicious traffic, or you can just get a huge dump and start filtering out things you know are okay.
And it's about the only way you'll ever catch that some idiot is running an ICQ from three years ago with a known buffer overflow or something stupid. Neither firewalls nor updated desktop machines can protect you from your own users, only log files of network traffic can do that.

--
If corporations are people, aren't stockholders guilty of slavery?
Re:As I said in a previous post... by Tassach · 2003-01-25 06:35 · Score: 5, Insightful

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

--
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?

been watching this all night by h2odragon · 2003-01-25 00:49 · 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.

Re:been watching this all night by Graspee_Leemoor · 2003-01-25 04:00 · Score: 4, Funny

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

graspee

Patch by sql*kitten · 2003-01-25 00:50 · Score: 4, Informative

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

Re:Patch by Anonymous Coward · 2003-01-25 04:01 · Score: 5, Funny

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! by matth · 2003-01-25 00:50 · Score: 5, Interesting

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!

Re:wow yeah! by sporty · 2003-01-25 01:36 · Score: 4, Insightful

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!

AND verisign will be down for certain hours while .org transitions to PIR/Affilias.

--
-
ping -f 255.255.255.255 # if only
Re:wow yeah! by dangermouse · 2003-01-25 02:33 · Score: 5, Funny

and what better time then on a Saturday morning when all admins are away and not planing to work the next day
What's it matter? It's not like you people have gone to work since last July anyway.

Ok now tell me by vicviper · 2003-01-25 00:51 · Score: 4, Funny

how many quries at the root level are unnecessary. :)

Re:Ok now tell me by DarkZero · 2003-01-25 02:31 · Score: 4, Funny

More today than yesterday.

First hand report by AirLace · 2003-01-25 00:51 · Score: 4, Interesting

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 by Dynedain · 2003-01-25 07:04 · Score: 4, Insightful

No, once this blows over it's time to apply the fucking patch. It's been available for six months mind you.

The patch does not affect routers stupid. Just because his routers are all lit up with massive amounts of traffic, does not mean that his servers are unpatched!

My link was down for 4 hours from the flooding with everything all lit up, and I'm not even running an SQL server.

--
I'm out of my mind right now, but feel free to leave a message.....

Whoever puts their database server by cscx · 2003-01-25 00:53 · Score: 5, Insightful

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?

Re:Whoever puts their database server by cyb97 · 2003-01-25 01:17 · Score: 5, Funny

Are these the same people that leave their cars unlocked with the keys in the ignition?
A real idiot would leave the car locked witht the keys in the ignition...
I guess they learn something at MSCE courses ;-)

Whoever... by wulffi · 2003-01-25 01:01 · Score: 5, Insightful

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.

Re:Whoever... by radish · 2003-01-25 02:10 · Score: 4, Insightful

I have three letters for you:

V P N

There is NO excuse for leaving BACKEND services like DBs, appservers, or whatever else visible on the public net. NONE WHATSOEVER. I work on a major website with multiple different data servers and backend applications, all distributed (and load balanced) over 4 physical sites on 2 continents. We use private circuits to handle the inter-site traffic, you could use VPN just as well. But everything vulnerable is buried from the internet behind several layers of firewall. Anything else is sheer lunacy.

Crappy admins bring this kind of attack on themselves, and alas, on the rest of us too.

--
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

best writeup by numatrix · 2003-01-25 01:02 · 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.

Some Links by Isomer · 2003-01-25 01:03 · 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

Collected info: by Anonymous Coward · 2003-01-25 01:06 · 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

Re:What's inside ? by AirLace · 2003-01-25 01:27 · 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.

Re:Turn your SQL server off? by Zocalo · 2003-01-25 01:32 · Score: 4, Insightful

What a pathetic overkill response.

No, it's a very reasonable one. Yes, you still need to patch, use non-blank SA passwords and the other things you suggest, but if you have an SQL server (any SQL server) directly visible to the Internet then you are either a fscking moron or have a very abnormal circumstance. A database server is a backend server, and should be completely hidden from the Internet by not one but two layers of firewalls.

Basically, in this day and age, your setup from the Internet in to your internal LAN, should be (as a minimum):

Internet router(s) => Firewall(s) => Web servers (HTTP, mail relays, proxies, VPN termination, etc.) => Firewall(s) => backend servers (SQL, internal mail etc..) => Internal network.

Some of these networks can quite easily be different ports on the same physical firewall, but I'm limited by ASCII. Alternatively, if you have no backend servers, that segment can obviously be omitted altogether.

Firewall rulesets can, and should, apply to outbound as well as inbound traffic and allowing traffic to flow cleanly accross multiple firewalls should be limited as much as possible. At a pinch, you could put your backend servers (if any) directly on the internal LAN, and get by with a single, three port firewall, but this should be the absolute minimum setup if you are hosting connections from the Internet. Sticking a two port firewall between your network and the Internet is simply not good enough anymore.

With resonable DMZ capable firewalls available for less than $500, either as a dedicated box, or old PC running the open source apps of your choice, there is no fiscal reason for even the smallest of companies not to be secure. As ever, the real reason is lack of a clue when it comes to matters of security.

--
UNIX? They're not even circumcised! Savages!

Yow! Good call /. by JasonUCF · 2003-01-25 01:35 · Score: 5, Funny

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 by avalys · 2003-01-25 01:39 · Score: 5, Funny

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

--
This space intentionally left blank.

Re:Fox News by Kashif+Shaikh · 2003-01-25 04:37 · Score: 4, Funny

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"

Re:Yow! Good call /. by caluml · 2003-01-25 01:45 · Score: 5, Funny

This one has surprised me most so far:
tybclbsqla02.listbuilder.com

Hmm. Lists equal large databases.
Large databases usually mean a DBA.
DBAs should know better.

whois listbuilder.com

Technical Contact:
Microsoft (EJSEHEQUAO)
msnhst@MICROSOFT.COM
Microsoft
One Microsoft Way
Redmond, WA 98052
US
425-882-8080

--
Get your own free personal location tracker

50% from Colleges??? by Gothmolly · 2003-01-25 02:04 · Score: 4, Interesting

About half of the sources I've seen have been either .edu sites or sites in other countries which belong to colleges (ualberta.ca, etc.). Is there some sinister corellation here? Perhaps colleges get free MS-ware, and let the students run the networks?

--
I want to delete my account but Slashdot doesn't allow it.

A bug in CISCO routers is helping to control this! by weave · 2003-01-25 02:13 · 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."

This will continue by NineNine · 2003-01-25 02:43 · Score: 4, Insightful

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.

billg has no uniform; therefore illegal combatant by Swordfish · 2003-01-25 03:03 · Score: 5, Funny

billg cannot be an enemy combatant because he
does not wear a military uniform.
So he must be an _illegal_ combatant.
Therefore, if guilty, he will have to go to
Guantanamo Bay for a few years to "help with
investigations".
Of course, proof cannot be given for his guilt
because that might jeopardize national security.
Therefore no trial until terrorism is defeated.
Can't afford to take chances with them terrorists!

Ironic timing... by weave · 2003-01-25 03:19 · 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

Re:UUNET woes? by RazzleDazzle · 2003-01-25 04:38 · Score: 4, Interesting

I work for an ISP and I just got home from work where we had to deal with this madness. It was absoultely horrible people. We got word from UUNET that it is port 1434/udp traffic and they are adding that to their egress filters. We just blocked 1434/udp altogether, at least initially.

We have many many colocated customers, many of whom run msql. This issue is horrible in that it is causing massive packet loss and when packets do get through the latency is around 500ms and up and that is for an all ethernet network segment. Our core router was getting slammed and cpu utilization would hang out at around 100%.

When we started unplugging switches from the routers, traffic would return to normal. We then pinpointed it down to all of our colo customers and disconnected just the sql servers from the network. Effing pain in the ass though.

Goddamned MS and their crappy no-password-requirement for the sql admin user and the moron admins who don't patch their system. Are people this trusting of MS that their servers are safe and/or this stupid they just don't apply patches until they get screwed?

Whatever, I am soooo tired... g'night

--
ZERO ZERO ONE ZERO ONE ZERO ONE ONE! Just brushing up for my next big invention: Ethernet over Voice (EoV)

Don't think MS is to blame? Read this: by Featureless · 2003-01-25 06:48 · Score: 4, Insightful

OK, help me out here.

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

--

Want to Know How to Cheat the GPL? Read On!

Whats interesting... by Anonymous Coward · 2003-01-25 08:17 · Score: 4, Interesting

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

We shouldn't blame MS... no wait, yes we should. by strAtEdgE · 2003-01-25 08:19 · Score: 5, Insightful

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.

--
----- sXe

Re:waiting for patches is hardly good security pol by sjames · 2003-01-25 10:25 · Score: 4, Insightful

Sounds like a damn good advice to me. Why the hell should either of those be exclusive?

It's very BAD advice! What happens when you blindly apply the patch and find out your mission critical app won't run anymore? A little QA testing would show you that on a test system instead of your live servers. If a firewall rule can protect you, use that, then QA the patch and apply if it is safe.

Consider that sometimes, the 'security patch' just disables a feature that 'nobody uses anyway' (except for your mission critical app, that is). Other times, it doesn't fix the hole, it just changes it's shape a little. In that case, you go from a hole you know about and can guard against at the firewall to one you don't know exists that has less information about it available.

It's not purely a dig at MS (though their track record for quality patches is spotty), any sudden change to widely deployed software runs the risk of causing a problem for sombody's configuration.

Slashdot Mirror

MS SQL Server Worm Wreaking Havoc

60 of 906 comments (clear)