顯示具有 Exploit_Shellcode 標籤的文章。 顯示所有文章
顯示具有 Exploit_Shellcode 標籤的文章。 顯示所有文章

2013年12月27日 星期五

Shellcode惡意代碼分析利器 – scdbg

原文:Link
What is scdbg?

scdbg是一款多平臺開源的Shellcode模擬運行、分析工具。其基於libemulibrary搭建的虛擬環境,通過模擬32位元處理器、記憶體和基本Windows API運行環境來虛擬執行Shellcode以分析其行為。有了虛擬執行媽媽再也不用擔心我的電腦中病毒了。
基本原理
眾所周知,shellcode為了實現特定的功能必須通過調用系統API來完成-不論先前怎麼變形怎麼加密最後都會調用系統APIscdbg就是通過模擬執行以及hook多達200多個API來探測shellcode的行為。當然比如創建檔和訪問網路這些危險的API並沒有真正的在本機執行,而是通過傳回虛假的返回值來欺騙shellcode讓其平穩運行。
示例
      直接命令列輸入scdbg.exe example.sc 來看看輸出:
      其中example.sc檔就是以二進位形式保存的Shellcode,我們可以看到這段shellcode調用了兩次較關鍵的函數-CreateProcessA,第一次調用tftp.exe程式下載winapi32.exe,第二次準備執行之。很典型的下載並執行行為。有了scdbg我們就不必花很多時間在搭建測試環境、解碼shellcode、調試理解各種分支跳轉、擔心機器是否中招。。。。。。簡單明瞭。

scdbg和通常的命令列工具一樣,有著眾多參數選項,這裡只做最基本的演示,就不一一列舉。想必大家都有在命令列下痛苦的經歷,命令列的歷史就是我等小菜的血淚史,還好scdbgGUI圖形介面版:

指定偏移,自定參數一目了然。

亮點
A.  跨平臺開源
      同時支援unixwindows系統。對有系統潔癖的同學來說可以放心在unix下搭建環境“調戲”shellcode了。
B.文檔類格式漏洞
      scdbg能很容易通過對話模式分析諸如pdf,excel,word等文檔類漏洞釋放出來的shellcode。這類漏洞的相同點就是首先肯定會通過調用GetFileSize找到宿主檔案控制碼然後進行下一步操作(是這樣的吧:)。感覺這項功能還是有很多應用場景的,命令列如下:
$ ./scdbg -f test.sc -fopen bad.pdf -i
fopen(bad.pdf) = 4d565c
Loaded 312 bytes from file test.sc
Initialization Complete..
Interactive Hooks enabled
             
401083  GetFileSize(4) = 2031b
401112  GlobalAlloc(sz=2031b) = 60000
401118  SetFilePointer(hFile=4, dist=0, FILE_BEGIN)
401132  ReadFile(hFile=4, buf=60000, numBytes=2031b)
401147  CreateFile(x.exe)
        Interactive mode local file: /tmp/WHhUmhtM
401158  WriteFile()
401176  WinExec(x.exe)
其他重要功能
 記憶體監視-簡單調試ShellROPshellcode分析-記憶體dump。。。。。。


資源下載
Windows Native Source/Binaries (201 hooks - current development branch)

*nix/Cygwin Source/Binaries (100 hooks - inactive)

The older gcc compatible and cross-compilable version is available here:
(tested with cygwin/gcc 3.4 & 4.3, RHEL 2.6/ gcc 4.1)

Help screen below: (see scdbg -h for current options)

 scdbg is an adaption of the libemu library and sctest project
 Libemu Copyright (C) 2007  Paul Baecher & Markus Koetter
 scdbg developer: David Zimmer
 Compile date: Apr 14 2011 21:02:02

 /foff hexnum          starts execution at file offset
 /mm                   enabled Memory Monitor (logs access to key addresses)
 /mdll                 Monitor Dll - log direct access to dll memory (hook detection/patches)
 /nc                   no color (if using sending output to other apps)
 /f fpath              load shellcode from file specified.
 /o hexnum             base offset to use (default: 0x401000)
 /redir ip:port        redirect connect to ip (port optional)
 /i                    enable interactive hooks
 /v                    verbosity, can be used up to 4 times, ex. /v /v /vv
 /e int                verbosity on error (3 = debug shell)
 /t int                time to delay (ms) between steps when v=1 or 2
 /h                    show this help
 /ba hexnum            break above - breaks if eip > hexnum
 /bp hexnum            set breakpoint on addr or api name (same as -laa  -vvv)
 /bs int               break on step (shortcut for -las  -vvv)
 /a                    adjust offsets to file offsets not virtual
 /d                    dump unpacked shellcode (requires /f)
 /las int              log at step ex. -las 100
 /laa hexnum           log at address or api ex. -laa 0x401020 or -laa ReadFile
 /s int                max number of steps to run (def=2000000, -1 unlimited)
 /hex                  show hex dumps for hook reads/writes
 /findsc               detect possible shellcode buffers (brute force)
 /dump                 view hexdump of the target file (can be used with /foff)
 /disasm int           Disasm int lines (can be used with /foff)
 /fopen file           Opens a handle to  for use with GetFileSize() scanners
 /- /+                 increments or decrements GetFileSize, can use multiple times
 /hooks                dumps a list all implemented api hooks
 /r                    show analysis report at end of run
 /pp                   peb patch - required for some shellcodes (rare)
 /b0                   break if 00 00 add [eax],al
 /patch fpath          load patch file  for libemu memory
 /dir  folder          process all .sc files in  echo results to .txt

   dbg> shell prompt commands:
        ? - help, this help screen, h also works
        v - change verbosity (0-4)
        g - go - continue with v=0
        s - step, continues execution, ENTER also works
        c - reset step counter
        r - execute till return (v=0 recommended)
        u - unassembled address
        b - break at address
        m - reset max step count (-1 = infinate)
        e - set eip
        w - dWord dump,(32bit ints) prompted for hex base addr and then size
        d - Dump Memory (hex dump) prompted for hex base addr and then size
        x - execute x steps (use with reset step count)
        t - set time delay (ms) for verbosity level 1/2
        k - show stack
        i - break at instruction (scans disasm for next string match)
        f - dereF registers (show any common api addresses in regs)
        o - step over
        .lp - lookup - get symbol for address
        .pl - reverse lookup - get address for symbol
        .seh - shows current value at fs[0]
        .reg - manually set register value
        .poke1 - write a single byte to memory
        .poke4 - write a 4 byte value to memory
        .savemem - saves a memdump of specified range to file
        q - quit



HalDispatchTable Kernel 提權原理(x64也通用)

原文:Link
ms11-080ms11-046exploit利用程式放出來後,很多人都利用源碼進行編譯和測試,甚至是拿到實戰中進行提權。剛放出來那會,我也編譯並測試通過,但始終沒去分析漏洞的形成原理和利用的技巧,今天有時間先Google了一下,漏洞原理網上已經很多人分析了,至於利用的整個流程,我也簡單分析一下,也許對有些同學有幫助。

借用網上名言:如有雷同,純屬抄襲,請勿拍磚!


PsInitialSystemProcess是內核匯出的指向System進程的EPROCEESS結構體的指標。

因為PsReferencePrimaryToken包含了從EPROCESS中取Token的操作,而針對不同的系統進程Token相對EPROCESS的偏移是不一樣的,因此可以通過此函數來確定Token相對EPROCESS的偏移。本系統System進程Token相對EPROCESS的偏移為0xc8。前面的一點分析主要是如何完成通用內核提權shellcode的編寫。

至於在內核提權中為什麼經常覆蓋的地址為HalDispatchTable+4處的位址,而通過調用NtQueryIntervalProfile函數來執行我們的shellcode,我們可以仔細分析一下看看NtQueryIntervalProfile函數的執行流程:

可以明顯看出NtQueryIntervalProfile函數通過調用KeQueryIntervalProfile進入ring0,再跟進ring0去看一下都做了些什麼動作?

由此可見,在KeQueryIntervalProfile函數內部調用了HalDispatchTable+0x4,因此只要在內核利用shellcode去覆蓋掉這個位址,然後再調用NtQueryIntervalProfileshellcode將會在內核以系統許可權被執行,此時你就是系統許可權了,至於想在shellcode中做些什麼,就看你自己的發揮了。

MS11-080 exploit完整提權過程分析:
此處省略n多,漏洞的原理。
總之就是在內核寫固定位址到任意位址(此任意位址可由輸入控制)。由此觸發漏洞。
具體代碼為:*(DWORD *)theIrp.UserBuffer   =    theIrp.IoStatus.Status;
而此處Status總固定為0xC0000207,用戶不可控。
MS11-080 exploit利用中,傳入的位址為HalDispatchTable + 4 + 2,可以windbg中看一下此位址是多少:

exploit執行之前,該位址值為0x7436806eexploit執行後,將會被修改為0xC0000207,如下圖:


這樣我們再看一下HalDispatchTable + 4的位址被覆蓋成什麼樣了,畢竟這個位址才是最後漏洞觸發後代碼執行入口。



由此可以發現,此時HalDispatchTable + 4位址已經被覆蓋為0x02074bba了。覆蓋的最終結果均會將HalDispatchTable + 4的高四位位址覆蓋為0207,因此咱們只需要在0x02070000起始的位址分配記憶體,然後在0x02080000填充shellcode的代碼,雖然覆蓋目標低四位元位址不可確定,但極限情況下也不會超過FFFF,所以只要call進了HalDispatchTable+ 4shellcode的代碼肯定能得到執行。
exploit覆蓋的位址是從HalDispatchTable + 4 +2 開始覆蓋,起始從HalDispatchTable + 4 + 1開始覆蓋也是可以的,只是覆蓋成功後,shellcode的起始位址就變成了0x000207xx!!! 
總結一下:通過覆蓋HalDispatchTable+4來完成利用只能針對內核任意位址寫固定位址或任意地址的內核漏洞。如有錯誤,還請指教!這樣以後遇到同一類型的內核漏洞就知道該怎麼利用了。

PS:在x86上 HalDispatchTable + 4  偏移為+4
     在x64上 因為資料結構改變, HalDispatchTable+ 8 偏移變為+8

PS2:此技術目前work in x86/x64  Win7 ,但因為Win8多了(Supervisor Mode Execution Protection) SMEP,禁止KernelMode 直接存取 ---> UserMode,所以此技術不能直接運用於Win8。