[unisog] udp port 1434 worm?

John H. Sawyer jsawyer at mail.ifas.ufl.edu
Sat Jan 25 14:28:24 GMT 2003


The little gem causing all the problems would be the new SQLslammer worm.
Check out the Neohapsis archives to see what has been posted to Bugtraq and
other lists concerning it.  It hit last night and has been DOSing everyone.
Included are several e-mails with enlightening info.

http://archives.neohapsis.com/archives/today/

-----------------------------------------------------------------------
The following e-mail is from HD 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
-----------------------------------------------------------------------
-----------------------------------------------------------------------
----- Original Message -----
From: "Russ" <Russ.Cooper at RC.ON.CA>
To: <NTBUGTRAQ at LISTSERV.NTBUGTRAQ.COM>
Sent: Saturday, January 25, 2003 8:04 AM
Subject: W32/SQLSlammer

I would like to revise my previous statement.

W32/SQLSlammer, as its being called now, does not act like SQL-Spida,
and the mitigators to prevent SQL-Spida are not necessarily effective in
preventing SQLSlammer.

SQLSlammer is delivered entirely in the single connection, 367 bytes of
attack code. It appears to be entirely memory resident, iows, it won't
drop anything. It does not appear to take advantage of weak passwords or
any stored procedures, it simply overflows the buffer and executes.
Also, SQL-Spida attacked 1433, whereas this attacks UDP1434.

If this attack is also employing the SQL Ping bounce described by David
Litchfield last July, then this could account for the amount of
bandwidth being consumed by this. Look in the NTBugtraq archives for
David's email.

There is some discussion occurring that ISPs are blocking this traffic,
so we should see recovery relatively quickly.

So far there have been no reports of SQL 7 or lower being affected.

More as its available.

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

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

-jhs

========================
| John H. Sawyer                           |
| Environmental Horticulture Dept   |
| University of Florida                     |
========================



More information about the unisog mailing list