Security Vulnerabity Alert

Hello,
Last night around 12:00 A.M. Eastern time, most hosts on the internet
began receiving a storm of udp traffic on port 1434, used primarily for
Microsoft sql servers. At one time this worm, caused outages to 5 of the 13
root nameservers, as well as severely degrading many backbone providers
networks.


To help remedy this situation, we have implemented filters for this
traffic and will be blocking it for the next several days. Any customers
who run MS/SQL servers are asked to please ensure that they have the latest
service pack as well as the current security rollup package. Service pack 3
for SQL server 2000 can be downloaded from:
http://www.Microsoft.com/sql/downloads/2000/sp3.asp.


As always, we encourage our customers to maintain sound security
policies, including ensuring that server patches are up to date. Both CERT
and Microsoft have mailing list that will keep you apprised of new security
issues and patches/workarounds for them.

All of Vortech Inc. servers have been patched for this worm and should not cause
any downtime for our network. As we are blocking port 1434 you will not be able
to login to the msSQL servers till we lift this block in the next several days.


Thank you for your time, and if you have any issues please do not hesitate
to contact us.


Information on the worm:
http://matrixwebhosting.net/forum/sh...&threadid=3011
http://www.cnn.com/2003/TECH/interne....ap/index.html
http://slashdot.org/article.pl?sid=0...thread&tid=109
http://bvlive01.iss.net/issEn/delive....jsp?oid=21824


Information on security and security alert programs
http://www.cert.org/
http://www.cert.org/contact_cert/certmaillist.html
http://www.microsoft.com/security/
http://www.microsoft.com/technet/tre...tin/notify.asp
http://www.iss.net/
http://www.iss.net/security_center/maillists/

Vortech Inc.
Brad
http://www.vortechhosting.com
http://www.matrixreseller.com
http://www.rapidcolo.com

If you have a SQL 2000 or MSDE 2000 server exposed to a public network, then
you should know about a worm that started circulating last night that
targets SQL Servers 2000 and MSDE 2000. The worm is non-destructive but
consumes large amounts of bandwidth. I don't like to cross post, but in
instances like this, NTBugtraq is the list of choice and in case you're not
on that list, here's a recent post from NTBugTraq regarding from Eric
Schulze at Shavlik if you are vulnerable:


-------------------
MS02-039 is applicable to SQL Server 2000 and MSDE 2000 SP2. Those running
SQL without an SP, or SQL 2000 SP1 will need to upgrade to SP2 in order to
apply this patch, or install SQL 2000 SP3.

The relevant file in MS02-039 is ssnetlib.dll. You need to have
2000.80.636.0 or later of this file to be considered patched.

MS02-039 was superseded by MS02-061 (Q316333). 02-061 includes ssnetlib.dll
version 2000.80.679.0. HFNetChk and MBSA will scan for 02-061 on SQL SP2
machines, however, the Microsoft hosted version of mssecure.xml does not
include a check for the ssnetlib.dll file. The Shavlik hosted file does
include a check for this file and can be referenced from mbsacli like so:

mbsacli.exe /hf -x https://xml.shavlik.com/mssecure.xml. HFNetChk 3.86 will
automatically use the Shavlik XML file.

Also note, the Microsoft hosted XML file does not include info about SQL
2000 SP3, the Shavlik file does. I've already contacted Microsoft and asked
them to include SQL 2000 SP3 in their XML file.


Marc from Eeye.com (which makes SecureIIS) states:


SQL Sapphire Worm Analysis


Release Date:
1/25/03


Severity:
High


Systems Affected:
Microsoft SQL Server 2000 pre SP 2


Description:
Late Friday, January 24, 2003 we became aware of a new SQL worm spreading
quickly across various networks around the world.


The worm is spreading using a buffer overflow to exploit a flaw in Microsoft
SQL Server 2000. The SQL 2000 server flaw was discovered in July, 2002 by
Next Generation Security Software Ltd. The buffer overflow exists because of
the way SQL improperly handles data sent to its Microsoft SQL Monitor port.
Attackers leveraging this vulnerability will be executing their code as
SYSTEM, since Microsoft SQL Server 2000 runs with SYSTEM privileges.


The worm works by generating pseudo-random IP addresses to try to infect
with its payload. The worm payload does not contain any additional
malicious content (in the form of backdoors etc.); however, because of the
nature of the worm and the speed at which it attempts to re-infect systems,
it can potentially create a denial-of-service attack against infected
networks.


We have been able to verify that multiple points of connectivity on the
Internet have been bogged down since 9pm Pacific Standard Time.


It should be noted that this worm is not the same as an earlier SQL worm
that used the SA/nopassword SQL vulnerability as its spread vector. This is
a new worm is more devastating as it is taking advantage of a
software-specific flaw rather than a configuration error. We have already
had many reports of smaller networks brought down due to the flood of data
from the Sapphire Worm trying to re-infect new systems.


Corrective Action
We recommend that people immediately firewall SQL service ports at all of
their gateways. The worm uses only UDP port 1434 (SQL Monitor Port) to
spread itself to a new system; however, it is safe practice to filter all
SQL traffic at all gateways. The following is a list of SQL server ports:
ms-sql-s 1433/tcp #Microsoft-SQL-Server ms-sql-s 1433/udp
#Microsoft-SQL-Server ms-sql-m 1434/tcp #Microsoft-SQL-Monitor ms-sql-m
1434/udp #Microsoft-SQL-Monitor


Once again this worm is taking advantage of a known vulnerability that has
had a patch available for many months. Microsoft has also released a recent
service pack for SQL (Service Pack 3) that includes a fix for this
vulnerability.


Standalone patch:
http://www.microsoft.com/technet/tre...hnet/security/
bulletin/MS02-039.asp


SQL 2000 Service Pack 3: http://www.microsoft.com/sql/downloads/2000/sp3.asp

[BCS]

As we are blocking port 1434 you will not be able
to login to the msSQL servers till we lift this block in the next several days.

Anyway for a firmer date/time? We have several customers inquiring ... they need to backup their DBs.

Thanks!

[Brangwyn]

btw I didnt actually think the remote tools needed 1434 open just the default instance port 1433. maybe I'll just get off my butt and test this later instead of asking heh.

[jon]

I have no problem connecting w/Enterprise Manager. It uses 1433.

Jon

[Brangwyn]

Yup as I thought .. QA and EM are both working fine for me.