Onderwerp: Fw: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!

Some News: http://news.zdnet.co.uk/story/0,,t269-s2099780,00.html
Advisory: http://www.nextgenss.com/advisories/mssql-udp.txt
Microsoft Fix:
http://www.microsoft.com/technet/tre...hnet/security/
bulletin/MS02-039.asp

MS SQL listens on port 1434/udp so that clients can figure out which method
of communication to use (named pipes, tcp/ip et al)
there are two problems that yield ability to execute code remotely while
unauthenticated.


-------------------------------------------------------
Jeremy Kister
www.jeremykister.com
PGP: http://www.jeremykister.com/jeremy/public_key.asc
-------------------------------------------------------


-----Original Message-----
From: Michael Bacarella [mailto:mbac@netgraft.com]
Sent: Saturday, January 25, 2003 2:12 AM
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
>
>

Hi,

This seems to have started for us about 4:30pm (GMT+11) today.

Lucky for us we block all MS-SQL 1434/udp traffic. We have logged over=20
130,000 firewall blocked connections across 15 odd sites, and it's commin=
g in=20
from all over the world.

I don't have any infected servers to study the habits of this worm, but t=
he=20
payload seems to always look pretty much like this.

8<---snip
20:56:02.115087 X.X.X.X.4178 > X.X.X.X.1434: [udp sum ok] udp 376 (ttl 1=
09,=20
id 46811)
0000: 4500 0194 b6db 0000 6d11 2e2d 89e5 0a9c E...=B6=DB..m..-.=E5..
0010: cb08 07c7 1052 059a 0180 bda8 0401 0101 =CB..=C7.R....=BD=A8....
0020: 0101 0101 0101 0101 0101 0101 0101 0101 ................
0030: 0101 0101 0101 0101 0101 0101 0101 0101 ................
0040: 0101 0101 0101 0101 0101 0101 0101 0101 ................
0050: 0101 0101 0101 0101 0101 0101 0101 0101 ................
0060: 0101 0101 0101 0101 0101 0101 0101 0101 ................
0070: 0101 0101 0101 0101 0101 0101 01dc c9b0 .............=DC=C9=B0
0080: 42eb 0e01 0101 0101 0101 70ae 4201 70ae B=EB........p=AEB.p=AE
0090: 4290 9090 9090 9090 9068 dcc9 b042 b801 B........h=DC=C9=B0B=B8.
00a0: 0101 0131 c9b1 1850 e2fd 3501 0101 0550 ...1=C9=B1.P=E2=FD5....P
00b0: 89e5 5168 2e64 6c6c 6865 6c33 3268 6b65 .=E5Qh.dllhel32hke
00c0: 726e 5168 6f75 6e74 6869 636b 4368 4765 rnQhounthickChGe
00d0: 7454 66b9 6c6c 5168 3332 2e64 6877 7332 tTf=B9llQh32.dhws2
00e0: 5f66 b965 7451 6873 6f63 6b66 b974 6f51 _f=B9etQhsockf=B9toQ
00f0: 6873 656e 64be 1810 ae42 8d45 d450 ff16 hsend=BE..=AEB.E=D4P=FF.
0100: 508d 45e0 508d 45f0 50ff 1650 be10 10ae P.E=E0P.E=F0P=FF.P=BE..=AE
0110: 428b 1e8b 033d 558b ec51 7405 be1c 10ae B....=3DU.=ECQt.=BE..=AE
0120: 42ff 16ff d031 c951 5150 81f1 0301 049b B=FF.=FF=D01=C9QQP.=F1..=
=2E.
0130: 81f1 0101 0101 518d 45cc 508b 45c0 50ff .=F1....Q.E=CCP.E=C0P=FF
0140: 166a 116a 026a 02ff d050 8d45 c450 8b45 .j.j.j.=FF=D0P.E=C4P.E
0150: c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45 =C0P=FF..=C6.=DB.=F3<a=D9=
=FF.E
0160: b48d 0c40 8d14 88c1 e204 01c2 c1e2 0829 =B4..@...=C1=E2..=C2=C1=E2=
=2E)
0170: c28d 0490 01d8 8945 b46a 108d 45b0 5031 =C2....=D8.E=B4j..E=B0P1
0180: c951 6681 f178 0151 8d45 0350 8b45 ac50 =C9Qf.=F1x.Q.E.P.E=ACP
0190: ffd6 ebca =FF=D6=EB=CA
8<---snip


I would also recommend that all your IDS sensors get a new signature to r=
ecord=20
all outbound 1434/udp in case it sneaks into your networks via private li=
nks,=20
etc.

Regards,

Ed.



On Sat, 25 Jan 2003 6:11 pm, Michael Bacarella wrote:
> 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!

--=20
"It is always possible to agglutinate multiple separate problems
into a single complex interdependent solution. In most cases
this is a bad idea."

-- RFC-1925=20

This is also being widely reported on the NANOG
and inetproviders lists. Check traffic outbound
from your MS SQL hosts if any. Firewall 1434/UDP
inbound and outbound if you don't already.

Tier 1 backbones are reporting a bad night: routing
instabilities, one major dropped most of its peering
for a while, the volume from this triggers the Cisco
netflow switching bug and is causing routers to lock
up at places, etc.


-george william herbert
gherbert@retro.com

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

It seems you're right.
My firewall is taking alot of hits on port 1434 since about 4pm Australian
Eastern Daylight Saving Time:

Jan 25 16:30:31 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
eth870.sa.adsl.internode.on.net:1310 (376 data bytes)
Jan 25 16:32:35 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
dev1.cinemas.ch:1683 (376 data bytes)
Jan 25 16:34:21 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
216.179.192.248:4161 (376 data bytes)
Jan 25 16:34:41 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
sql.webcoretech.com:3113 (376 data bytes)
Jan 25 16:34:42 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
hds-connected.hds.com:3967 (376 data bytes)
Jan 25 16:35:34 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
216.95.164.23:1141 (376 data bytes)
Jan 25 16:35:56 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
134.210.1.226:3975 (376 data bytes)
Jan 25 16:36:54 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
211.104.36.123:2550 (376 data bytes)
Jan 25 16:38:30 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
cts21612069172.cts.com:1031 (376 data bytes)
Jan 25 16:38:31 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
216.109.150.210:3462 (376 data bytes)
Jan 25 16:39:02 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
207.102.74.40:4605 (376 data bytes)
Jan 25 16:39:05 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
66.189.0.11:4198 (376 data bytes)
Jan 25 16:39:20 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
dnsup1.biz.rr.com:3915 (376 data bytes)
Jan 25 16:39:50 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
211.139.140.18:3623 (376 data bytes)
Jan 25 16:40:24 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
210.91.85.200:1113 (376 data bytes)
Jan 25 16:40:26 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
criminal.justice.state.mn.us:1335 (376 data bytes)
Jan 25 16:40:37 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
server4.hostu.net:1038 (376 data bytes)
Jan 25 16:40:45 sarkmekawk iplog[234]: UDP: dgram to port 1434 from
61.135.134.154:3935 (376 data bytes)

That is only a very small portion of the log. There are hundreds more
entries.




************************************************** *******
** P&O - Celebrating 150 Years in Australia: 1852-2002 **
************************************************** *******

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25 Jan 2003, Umit Tiric wrote:

> We can confirm it here in Toronto, Canada. Even though the effect was
> minimal to us, we saw many major networks dissappear on the Internet.

We're seeing large network disruption here in Los Angeles. Right
now, packet loss is running at roughly 95%. (This is not a typo. I do
mean *ninety-five percent* packet loss.)

> You have to patch your MS-SQL Server to the highest service pack.

More details available here:

http://www.kb.cert.org/vuls/id/370308
http://www.kb.cert.org/vuls/id/399260
http://www.kb.cert.org/vuls/id/484891

And to think...up until tonight, I thought the vulnerabilities
that paved the way for Nimda were the worst that Microsoft could do to the
net.community. They've really topped themselves this time.

- -Jay

( ( _______
)) )) .-"There's always time for a good cup of coffee."-. >====<--.
C|~~|C|~~| (>------ Jay D. Dyson - jdyson@treachery.net ------<) | = |-'
`--' `--' `How about a 10-day waiting period on YOUR rights?' `------'

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (TreacherOS)
Comment: See http://www.treachery.net/~jdyson/ for current keys.

iD8DBQE+MnagTqL/+mXtpucRAjD0AJ9QEhwxeEdzn/s7d7M2Fs+Q6a7jjACdEAAN
krgyU75949WTlrDdKrsrQLc=
=mmPu
-----END PGP SIGNATURE-----

A worm which exploits a (new?) vulnerability in 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, a copy of the worm as a perl script, and a
disassembly (sorry, no comments) can be found online at:

http://www.digitaloffense.net/worms/mssql_udp_worm/

-HD

On Saturday 25 January 2003 01:11, Michael Bacarella wrote:
> 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!

-------------------------------------------------------

In-Reply-To: <20030125021141.A23211@romulus.netgraft.com>

This is indeed happening widely tonight. Some of the
client machines here have been hit as their boxes were
not patched up properly. We have firewalled access and
have brought our core switches online again after a
brief interruption where the traffic here got up to a
little over 110Mbits/s. The switches simply went into
failover. The good news is that it is not autonomous,
so you can control access through port filtering until
the patches are applied.

The UDP D.O.S. attack: (Random snippets from logs)
PROTO=UDP SPT=1518 DPT=1434
PROTO=UDP SPT=1032 DPT=1434
PROTO=UDP SPT=1077 DPT=1434
PROTO=UDP SPT=4319 DPT=1434

/b

>Received: (qmail 1867 invoked from network); 25 Jan
2003 08:39:23 -0000
>Received: from outgoing3.securityfocus.com
(205.206.231.27)
> by mail.securityfocus.com with SMTP; 25 Jan 2003
08:39:23 -0000
>Received: from lists.securityfocus.com
(lists.securityfocus.com [205.206.231.19])
> by outgoing3.securityfocus.com (Postfix) with QMQP
> id A5DACA30A5; Sat, 25 Jan 2003 00:59:36 -0700 (MST)
>Mailing-List: contact bugtraq-help@securityfocus.com;
run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@securityfocus.com>
>List-Help: <mailto:bugtraq-help@securityfocus.com>
>List-Unsubscribe:
<mailto:bugtraq-unsubscribe@securityfocus.com>
>List-Subscribe:
<mailto:bugtraq-subscribe@securityfocus.com>
>Delivered-To: mailing list bugtraq@securityfocus.com
>Delivered-To: moderator for bugtraq@securityfocus.com
>Received: (qmail 28308 invoked from network); 25 Jan
2003 07:06:20 -0000
>Date: Sat, 25 Jan 2003 02:11:41 -0500
>From: Michael Bacarella <mbac@netgraft.com>
>To: nylug-talk@nylug.org, wwwac@lists.wwwac.org,
> linux-elitists@zgp.org
>Subject: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT
1434!
>Message-ID: <20030125021141.A23211@romulus.netgraft.com>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>User-Agent: Mutt/1.2.5i
>Resent-From: mbac@romulus.netgraft.com
>Resent-Date: Sat, 25 Jan 2003 02:12:54 -0500
>Resent-To: bugtraq@securityfocus.com
>Resent-Message-Id:
<20030125071254.1B3F7681AD@romulus.netgraft.com>
>
>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
>

On Sat, Jan 25, 2003 at 02:11:41AM -0500, Michael Bacarella wrote:
> 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.
>
> It looks like there's a worm affecting MS SQL Server which is
> pingflooding addresses at some random sequence.

yeah. i guess it's an old vulnerability, but i don't keep up on
this stuff.

however, i have disassembled the code inside; all it does is send
itself to pseudorandomly generated hosts.

there is an annotated disassembly at
http://www.boredom.org/~cstone/worm-annotated.txt

--cstone@pobox.com

In-Reply-To: <20030125021141.A23211@romulus.netgraft.com>

Michael,

I feel your pain. I've seen the same thing starting at 12:46 AM EST 01-25-
2003 at one of our colocation facilities.

I haven't had time to analyze things as of yet - I discovered three
machines, all with activity that started at this same time, all running
windows 2000 and SQL Server 2000.

It crippled internal connectivity - basically, any machine that actively
had this going on, if we would plug it into a port on an HP4000 switch it
would freeze the switch instantly and then anything on the local network
would suffer.

I'm working on isolating these machines to a local segment and then
putting them back online so that I may see what type of traffic is
generated or received at brief intervals.

I don't know what it is, but it's certainly detrimental to network
performance!

Mike Tindor
FIRST Internet

>Received: (qmail 1867 invoked from network); 25 Jan 2003 08:39:23 -0000
>Received: from outgoing3.securityfocus.com (205.206.231.27)
> by mail.securityfocus.com with SMTP; 25 Jan 2003 08:39:23 -0000
>Received: from lists.securityfocus.com (lists.securityfocus.com
[205.206.231.19])
> by outgoing3.securityfocus.com (Postfix) with QMQP
> id A5DACA30A5; Sat, 25 Jan 2003 00:59:36 -0700 (MST)
>Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@securityfocus.com>
>List-Help: <mailto:bugtraq-help@securityfocus.com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
>List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
>Delivered-To: mailing list bugtraq@securityfocus.com
>Delivered-To: moderator for bugtraq@securityfocus.com
>Received: (qmail 28308 invoked from network); 25 Jan 2003 07:06:20 -0000
>Date: Sat, 25 Jan 2003 02:11:41 -0500
>From: Michael Bacarella <mbac@netgraft.com>
>To: nylug-talk@nylug.org, wwwac@lists.wwwac.org,
> linux-elitists@zgp.org
>Subject: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!
>Message-ID: <20030125021141.A23211@romulus.netgraft.com>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>User-Agent: Mutt/1.2.5i
>Resent-From: mbac@romulus.netgraft.com
>Resent-Date: Sat, 25 Jan 2003 02:12:54 -0500
>Resent-To: bugtraq@securityfocus.com
>Resent-Message-Id: <20030125071254.1B3F7681AD@romulus.netgraft.com>
>
>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
>

Jay Dyson wrote:
> And to think...up until tonight, I thought the vulnerabilities
> that paved the way for Nimda were the worst that Microsoft could do
> to the net.community. They've really topped themselves this time.

As of now we don't know who wrote the worm, but we do know that it looks
like a concept worm with no malicious payload. There is a good argument to
be made in favor of such worms. Whomever did write this worm could have done
severe damage beyond unfocused DDoS and chose not to do so. One would expect
intelligence agencies in developed countries to write and release precisely
this type of concept worm as a form of mass inoculation against malicious
attacks.

Before you get upset at your vendor, or anyone else's, consider the bigger
picture and recognize the increased security hardening the Internet just
received. Belief in this silver lining shouldn't be taken too far, of
course, but flaming anyone over an event like this is misplaced considering
the number of infosec experts who would probably have agreed to write this
worm if approached by their nations' government with proof that an adversary
was planning to cause severe harm by exploiting the W32/SQLSlammer
vulnerability.

Sincerely,

Jason Coombs
jasonc@science.org

However, this worm might not be so harmless as it appears because of
collateral damage:

Bank of America ATMs Disrupted by Virus

http://story.news.yahoo.com/news?tmp...id=569&u=/nm/2
0030125/tc_nm/tech_virus_dc

"SEATTLE (Reuters) - Bank of America Corp. said on
Saturday that customers at a majority of its 13,000
automatic teller machines were unable to process
customer transactions after a malicious computer worm
nearly froze Internet traffic worldwide."

Richard M. Smith
http://www.ComputerBytesMan.com

-----Original Message-----
From: Jason Coombs [mailto:jasonc@science.org]
Sent: Saturday, January 25, 2003 4:41 PM
To: Jay D. Dyson; Bugtraq
Subject: RE: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!


Jay Dyson wrote:
> And to think...up until tonight, I thought the vulnerabilities
> that paved the way for Nimda were the worst that Microsoft could do
> to the net.community. They've really topped themselves this time.

As of now we don't know who wrote the worm, but we do know that it looks
like a concept worm with no malicious payload. There is a good argument
to
be made in favor of such worms. Whomever did write this worm could have
done
severe damage beyond unfocused DDoS and chose not to do so. One would
expect
intelligence agencies in developed countries to write and release
precisely
this type of concept worm as a form of mass inoculation against
malicious
attacks.

Before you get upset at your vendor, or anyone else's, consider the
bigger
picture and recognize the increased security hardening the Internet just
received. Belief in this silver lining shouldn't be taken too far, of
course, but flaming anyone over an event like this is misplaced
considering
the number of infosec experts who would probably have agreed to write
this
worm if approached by their nations' government with proof that an
adversary
was planning to cause severe harm by exploiting the W32/SQLSlammer
vulnerability.

Sincerely,

Jason Coombs
jasonc@science.org

Can anybody confirm that this worm is spreading on the Desktop Engine too?
(MSDE)

Thanks,
Trent.

-----Original Message-----
From: H D Moore [mailto:sflist@digitaloffense.net]
Sent: Saturday, January 25, 2003 6:49 AM
To: bugtraq@securityfocus.com
Subject: Re: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!


A worm which exploits a (new?) vulnerability in 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, a copy of the worm as a perl script, and a
disassembly (sorry, no comments) can be found online at:

http://www.digitaloffense.net/worms/mssql_udp_worm/

-HD

On Saturday 25 January 2003 01:11, Michael Bacarella wrote:
> 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!

-------------------------------------------------------

Jason,

I can't believe you wrote this - seriously, I can't.

>=20
> As of now we don't know who wrote the worm, but we do know that it
looks
> like a concept worm with no malicious payload. There is a good
argument to
> be made in favor of such worms.=20
>

What good can come of a widespread DoS of the Internet? What about the
problems that come hacker getting a hold of the payload and making it
more malicious before everyone can respond? Remember, most people won't
know about this until Monday and won't be able to fix the problem until
later that day, or perhaps later in the week.

>=20
> Before you get upset at your vendor, or anyone else's, consider the
bigger
> picture and recognize the increased security hardening the Internet
just
> received.
>

It shouldn't have needed it. Microsoft released a patch for the
vulnerability some time ago (granted it wasn't easy to install,
especially for MSDE installations) but the real problem is those system
administrators who don't apply patches when there is no good reason not
to, and the network and firewall administrators who, for some
incomprehensible reason, leave open ports like this in their firewalls
and routers.

Maybe the time has come to draft legislation to prosecute not only the
writers of such malware, but those who recklessly leave their systems
vulnerable and defenseless and, through their negligence, help propagate
malware. Lastly, Microsoft and all other vendors need to make their
patches available for all configurations and easier to install (a quick
check shows that SQL Server SP3 is still not available for MSDE).

John Howie CISSP MCSE
President, Security Toolkit LLC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 25 Jan 2003, Jason Coombs wrote:

> > And to think...up until tonight, I thought the vulnerabilities
> > that paved the way for Nimda were the worst that Microsoft could do
> > to the net.community. They've really topped themselves this time.
>
> As of now we don't know who wrote the worm, but we do know that it looks
> like a concept worm with no malicious payload. There is a good argument
> to be made in favor of such worms.

Oh, that doesn't bother me. Net.downtime actually gives me an
excuse to take some time off and do other things.

What bothers me is that the very vendor that claims that their
closed source approach is "more secure" (and insists that Open Source is a
"threat to national security") and makes all manner of noises about how
they're raising the bar on security standards is THE VERY SAME vendor that
has done more to destabilize the 'net than any other vendor...BAR NONE.

That's what really sticks in my craw.

> Before you get upset at your vendor, or anyone else's, consider the bigger
> picture and recognize the increased security hardening the Internet just
> received.

Sure. And spontaneously-combusting consumer products are just a
community service announcement on the value of fire insurance.

Sorry, I don't buy the claim that this fault of Microsoft's and
the MS-SQL worm are going to result in any sort of "hardening" of the
'net. Hell, Nimda came out on September 18, 2001 and I have YET to see
an end to its presence on the 'net.

- -Jay

( ( _______
)) )) .-"There's always time for a good cup of coffee."-. >====<--.
C|~~|C|~~| (>------ Jay D. Dyson - jdyson@treachery.net ------<) | = |-'
`--' `--' `How about a 10-day waiting period on YOUR rights?' `------'

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (TreacherOS)
Comment: See http://www.treachery.net/~jdyson/ for current keys.

iD8DBQE+MxnmTqL/+mXtpucRAgASAKCs9OwErZYOvEIxv6ZfSstWMYQstwCbBGtS
C/LdyRjed9PYs9cIWhvBr8E=
=GCri
-----END PGP SIGNATURE-----

Colm MacCarthaigh wrote:
> If the worm had a malicious (in your terms) payload, it would have
> caused networks just as many problems (so no gain there), and more harm
> to MS-SQL users. Using your logic, surely this much more damaging
> experience would have cause MS-SQL admins to be more responsible in
> keeping up to date ? Or rather, more fearful of future exploits.

Precisely my point. Sapphire was not designed to inspire fear. If this had
been a terrorist act it would have done so, and it could have done so. It
did not. In my mind Sapphire inspires confidence that somebody, somewhere
might actually be thinking for a change. Unfortunate inconveniences aside,
anything actually *damaged* by Sapphire (in a physical/non-trivial sense of
the word) was too vulnerable for use in the first place.

Sincerely,

Jason Coombs
jasonc@science.org