SQL Server solutions going forward
From: Chip Andrews (chip@SQLSECURITY.COM)
Date: 01/26/03
- Previous message: Russ: "Products which use MSDE?"
- Next in thread: Schmehl, Paul L: "Re: SQL Server solutions going forward"
- Maybe reply: Schmehl, Paul L: "Re: SQL Server solutions going forward"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 26 Jan 2003 09:23:27 -0500 From: Chip Andrews <chip@SQLSECURITY.COM> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
It appears the main contributors to this tragedy were:
(A) Microsoft SQL Server patches are a pain to install (since they require
manual operations) so people aren't installing them out of laziness or time
constraints.
(B) People are connecting SQL Servers to the Internet, opening UDP 1434, and
not patching the boxes (god knows why)
(C) Lots of people are installing third-party apps that use MSDE in the DMZ
unaware of the risk and their responisibility to patch.
Here are a couple of tips to help minimize exposure going forward:
(1) If you are a hosting provider or have some application that must give
direct SQL Server access to clients over the Internet without using a VPN or
secure tunnel then you should be on top of EVERY SQL Server patch (for
protection from the myriad privilege escalation attacks as well as external
attacks) AND blocking UDP 1434 at the firewall. UDP 1434 is not required for
clients that are aware of the SQL Server TCP port. Enterprise Manager will
work fine as well as all other apps (despite what you read in Books Online)
with UDP 1434 blocked. The ONLY effect of blocking UDP 1434 is that named
instances usually do not use the default TCP port of 1433 will be
inaccessable unless you create an alias in the SQL Client Network Utility
specifying the TCP port (or pipe name if you use Named Pipes) or you specify
the TCP port needed in the connection string (by simply placing a comma and
the port name after the server name - i.e. Network=dbmssocn;Data
Source=sql2.myhostingprovider.net,1478)
(2) If you have an application that uses a local MSDE database (or SQL
Server) then load the Server Network Utility and disable ALL netlibs
(followed by a SQL Server instance re-start). If you only have MSDE
installed and thus do not have the Server Network Utility then you can clear
the registry key below and then restart the SQL Server instance to get the
same results:
HKEY_LOCAL_MACHINE',N'SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocket
NetLib\ProtocolList (for a default instance)
or
HKEY_LOCAL_MACHINE',N'SOFTWARE\Microsoft\Microsoft SQL
Server\(Instance_Name)\MSSQLServer\SuperSocketNetLib\ProtocolList (for a
named instance)
In your application's connection strings or settings, make sure to use
"(local)" or "." (a period) as the server name since using the name of the
server will no longer work. This will force the application to use the
Shared Memory netlib since all other netlibs are now disabled and the SQL
Server is no longer network-enabled. You can always restore the settings to
the registry key at a later date if you need external connectivity (assuming
you recorded the registry key data before you cleared it - if you didn't
just set it to 'tcp' to re-enable the TCP/IP netlib or 'np' for named
pipes). Vendors - take note: You can ship your product this way and then
show the 1% of customers that must connect to MSDE remotely how to re-enable
the netlibs.
(NOTE: I have tested that this solution prevents the SQL Resolution service
from broadcasting information about SQL Server instances installed and
blocks all external SQL Server access but have not tested whether it
prevents exposure to the W32/SQLSlammer/Sapphire worm since just because the
service is not responding does not mean it is not exploitable. Assume it
does not and fully patch/block UDP1434 anyway)
Hopefully these two solutions can mitigate or at least minimize future
exposure and please take the time to write sqlwish@microsoft.com and demand
easier SQL Server patch installers and inclusion of SQL Server patches in
Windows Update.
Chip Andrews
http://www.sqlsecurity.com
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Delivery co-sponsored by TruSecure Corporation
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
TICSA - Anniversary Special - Limited Time
Become TICSA certified for just $221.25 US when you register before 3/31/03
with PROMO "TS0103" at www.2test.com. NO membership fees, certification
good for 2 years. Price for international delivery just $296.25 US, with
this offer. Offer cannot be combined with any other special and expires
3/31/03. Visit www.trusecure.com/ticsa for full details.
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
- Next message: Russ: "Update from Microsoft"
- Previous message: Russ: "Products which use MSDE?"
- Next in thread: Schmehl, Paul L: "Re: SQL Server solutions going forward"
- Maybe reply: Schmehl, Paul L: "Re: SQL Server solutions going forward"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
