OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Chip Andrews (chipandrews_at_USA.NET)
Date: Thu Jan 30 2003 - 13:16:46 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    A couple of things I forgot to mention in my last post and these are
    important points:

    1) My (nor Alan's) suggestion does NOT mitigate the risk of remote
    expoitation of the SQL Resolution Server as exploited by the SQLSlammer
    worm. Disabling all netlibs only serves the function of making the SQL
    Server inaccessable to network clients and stops information leakage about
    server versions, netlibs installed, clustered status etc. The SQL
    Resolution server is still listening (and exploitable) when no netlibs are
    enabled - it just does not respond.

    2) You can disable all netlibs using the Server Network Utility installed
    with SQL Server or by clearing the registry located at

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNet
    Lib\ProtocolList
    or
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
    Server\(Instance_Name)\MSSQLServer\SuperSocketNetLib\ProtocolList
    (for named instances)

    I hope that clears things up a bit. I just want it to be clear that
    disabling all netlibs does not protect you from the SQLSlammer worm. It's
    simply a good lock-down technique that enforces security in-depth.

    Clearly, the best defenses for SQLSlammer are keeping up with patches and
    server isolation (port filtering).

    Chip Andrews
    www.sqlsecurity.com

    ----- Original Message -----
    From: "Chip Andrews" <chipSQLSECURITY.COM>
    To: <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>
    Sent: Thursday, January 30, 2003 12:55 PM
    Subject: Re: Slammer Worm and SQL Server Network Protocols

    > Alan,
    >
    > The problem with that solution is that it does not produce the desired
    > effect.
    >
    > Removing the TCP/IP netlib alone does NOT stop the SQL Resolution Service
    on
    > UDP 1434 from listening or responding. As evidenced by the following
    > SQLPing output even after configuring the server to Named Pipes only:
    >
    > Response from 192.168.10.115
    > -----------------------------
    > ServerName : BASEREM2
    > InstanceName : MSSQLSERVER
    > IsClustered : No
    > Version : 8.00.194 (Keep in mind that this version is never current
    as
    > reported by MSSQL- It always returns the base version)
    > np : \\BASEREM2\pipe\sql\query
    >
    >
    > If you want the server to stop responding to UDP 1434 queries you should
    > disable ALL netlibs on the SQL Server instance. This will force all local
    > connection attempts to use the Shared Memory netlib (an oxymoron). This
    > netlib will only work for instances installed on the same machine but is
    > even more fast and efficient than your named pipes solution since no
    > network-layer calls are used at all.
    >
    > Chip Andrews
    > 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