Alert: MS SQL worm

From: Russ (Russ.Cooper@RC.ON.CA)
Date: 11/23/01 

Message-ID:  <E9A01F52DC939448BBDE44ED2E1C468F23CE2A@muskie.rc.on.ca>
Date:         Fri, 23 Nov 2001 13:49:35 -0500
From: Russ <Russ.Cooper@RC.ON.CA>
Subject:      Alert: MS SQL worm
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

Folks,

A worm was discovered which attacked TCP1433 directly, exploiting stored and
extended procedures within most Microsoft SQL servers. Ultimately it used
XP_CMDSHELL to get a DOS environment and then run FTP to download a program
to the SQL server. The script used fixed IP addresses to download its
payload, and those sites were quickly shut down. To my assessment, this made
the issue far less urgent and I thought I would inform you of it on Monday,
after the U.S. holiday.

Since its been reported through several media outlets (and I'm calling the
NIPC a media outlet these days), I figured it prudent to let you know what
we know now.

First detected attacking on Tuesday 11/20 by Douglas P. Brown <doug@unc.edu>
and reported to SecurityFocus' Incidents mailing list
<incidents@securityfocus.com>, it attempts to establish a connection via
TCP1433 and then uses XP_CMDSHELL to download win32mon.exe and
dnsservice.exe. If it successfully executes dnsservice it establishes a
connection to an IRC server and reports in as being available. Again, both
the FTP site and IRC server identified in the original incarnation have been
shut down, but of course it would be trivial to change these addresses.

The fact that this thing is dependent on foreign fixed servers for
propagation means it will be very short-lived, but it is, never-the-less,
proof of concept subject to modification.

It is dependent on the availability of an MS SQL server with mixed-mode
authentication enabled, an SA account with no password, and at least the
XP_CMDSHELL extended procedure present and not secured. This would be a
standard configuration for MS SQL 6.5, but not MS SQL 7.0 (MS SQL 7.0
installs using NT authentication by default, not mixed mode).

If you are at all concerned by these events, I highly recommend you remove
the XP_CMDSHELL stored procedure. If you don't need to shell to a DOS
command during a Query, you don't need the procedure. You can always add it
back later if you find you need it. MS SQL 7.0 will show you whether
anything is dependent on it (in case you didn't write your own procedures).
Drop this procedure and you've taken a step in the right direction.

I would like to point out SQLSecurity.com. They have an excellent checklist
for MS SQL servers available at;

http://www.sqlsecurity.com/checklist.asp

that covers XP_CMDSHELL and others. Did you realize that a stored procedure
can interact completely with the registry?

Meanwhile, I'll keep you informed if this thing rears its ugly head in a
form which can propagate. I still do not expect this one to be of much
consequence in the near term, so in my opinion you don't need to rush into
the office and alter your SQL configs, but if you can, drop that stored
procedure ASAP and then look over the SQLSecurity.com checklist for further
actions you should take.

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor
"My thoughts are facts in my world, opinion to you. YMMV"

============================================================================
Delivery co-sponsored by Trend Micro, Inc.
============================================================================
BEST-OF-BREED ANTIVIRUS SOLUTION FOR MICROSOFT EXCHANGE 2000
Earn 5% rebate on licenses purchased for Trend Micro ScanMail for
Microsoft Exchange 2000 between October 1 and November 16. ScanMail
ensures 100% scanning of inbound and outbound traffic and provides
remote software management. For program details or to download your
30-day FREE evaluation copy:
http://www.antivirus.com/banners/tracking.asp?si=53&bi=245&ul=http://www.a
ntivirus.com/smex2000_rebate

Relevant Pages