針對CSRSS漏洞溢出工具包

漏洞原理

漏洞原理是通過往程序的緩沖區(qū)寫超出其長度的內(nèi)容，造成緩沖區(qū)的溢出，從而破壞程序的堆棧，造成程序崩潰或使程序轉(zhuǎn)而執(zhí)行其它指令，以達(dá)到攻擊的目的。造成緩沖區(qū)溢出的原因是程序中沒有仔細(xì)檢查用戶輸入的參數(shù)，對參數(shù)的類型、長度等未做限制。

舉個通俗易懂的例子，程序的緩沖區(qū)就像一個個格子，每個格子中存放不同的東西，有的是命令，有的是數(shù)據(jù)，當(dāng)程序需要接收用戶數(shù)據(jù)，程序預(yù)先為之分配了4個格子。按照程序設(shè)計，就是要求用戶輸入的數(shù)據(jù)不超過4個。而用戶在輸入數(shù)據(jù)時，假設(shè)輸入了16個數(shù)據(jù)，而且程序也沒有對用戶輸入數(shù)據(jù)的多少進(jìn)行檢查，就往預(yù)先分配的格子中存放，這樣不僅4個分配的格子被使用了，其后相鄰的12個格子中的內(nèi)容都被新數(shù)據(jù)覆蓋了。這樣原來12個格子中的內(nèi)容就丟失了，這時就出現(xiàn)了緩沖區(qū)（0~3號格子）溢出了。

案例分析

Freefloat FTPServer v1.0版本曾經(jīng)爆出過一個cve-2012-5106的漏洞，我們就以這個版本完成一次緩沖區(qū)溢出漏洞的復(fù)現(xiàn)及分析。

首先通過metasploit中的fuzzer模塊對其進(jìn)行模糊測試，估算ftp server進(jìn)程中可被覆蓋的緩沖區(qū)大小。

觀察發(fā)現(xiàn)當(dāng)客戶端向服務(wù)器發(fā)送大于250字節(jié)的緩沖區(qū)后，ftp server崩潰。崩潰的原因很顯然是eip被改寫成了一個不可讀的內(nèi)存地址。

Infigo FTPStress Fuzzer工具也可以對ftp server測試。發(fā)現(xiàn)發(fā)送520到700個字節(jié)之間大小的數(shù)據(jù)，服務(wù)器就會溢出崩潰。

雖然metasploit和Infigo FTPStress Fuzzer得到的緩沖區(qū)溢出大小不同，不過通常的思路是先使用范圍大的，然后逐步縮小。

將ftp server進(jìn)程附加到ImmunityDebugger中，使用插件mona發(fā)現(xiàn)該系統(tǒng)沒有開啟ASLR保護(hù)機(jī)制。另外，確保dep保護(hù)也是關(guān)閉的。

開始調(diào)試：找到輸出ftp服務(wù)器返回歡迎信息的函數(shù)，在該函數(shù)處設(shè)置斷點(diǎn)00402ffa，然后發(fā)送ftp請求及payload，ftp進(jìn)程直接跳轉(zhuǎn)到00402ffa。

f8單步調(diào)試，發(fā)現(xiàn)00403065處調(diào)用函數(shù)后就溢出。

重新調(diào)試，跟進(jìn)00403065處的函數(shù)，發(fā)現(xiàn)一個循環(huán)，為跳出循環(huán)，在0040210a和0040212a下斷點(diǎn)，跳出后到0040213a調(diào)用函數(shù)后又溢出了。

重新調(diào)試，在0040213a處下斷點(diǎn)，跟進(jìn)該函數(shù)，發(fā)現(xiàn)程序已經(jīng)運(yùn)行到了服務(wù)器用內(nèi)置命令和發(fā)送的命令在做比較。

繼續(xù)單步跟，發(fā)現(xiàn)還是不斷比較，那么這個調(diào)用比較字符串的函數(shù)其實(shí)是call ftpserve.00403d70，打開IDA發(fā)現(xiàn)，這個地址的確是調(diào)用一個strncmp函數(shù)，并且將三個參數(shù)壓入棧中，和ida中的函數(shù)形式參數(shù)一樣。

繼續(xù)單步，發(fā)現(xiàn)在004028ed處調(diào)用函數(shù)后又一次溢出。

查看esp，發(fā)現(xiàn)payload已經(jīng)壓入棧中。

重新調(diào)試，在004028ed處設(shè)置斷點(diǎn)并跟進(jìn)該函數(shù)，跟到00402e5f處，此處實(shí)現(xiàn)了REP MOVS循環(huán)拷貝。最后在retn 8處溢出，retn指令就相當(dāng)于pop eip。retn 8指令執(zhí)行后，esp會加8。

ida中查看REP MOVS循環(huán)，其實(shí)是使用函數(shù)strcpy完成循環(huán)復(fù)制。

問題就出現(xiàn)在strcpy函數(shù)，v8變量的最大長度是bp-fc，由于沒有使用ebp索引，因此變量最后分配到棧中的最大長度是0xfc即252個字節(jié)，而之前的payload長度是500。

使用mona插件縮小payload到300個字節(jié)。重新發(fā)送payload2。

溢出成功，eip定位為346943133。而346943133超出ftp程序的地址范圍，內(nèi)存不可讀。

計算34694133相對于ebp的偏移量，得知是251個字節(jié)。也就是說變量v8保存在棧中是從ebp到ebp-fc之間。因此eip被修改的位置是ebp-251。

繼續(xù)縮小payload，這次偏移251+4個字節(jié)，發(fā)送payload3，執(zhí)行到最后一條指令retn 8。當(dāng)執(zhí)行該指令后，esp指向的棧頂是00bdfc20，其值是BBBB，該值直接pop eip中。

f8單步果然如此。內(nèi)存地址BBBB很顯然是不可讀的，那么如果將esp改為一個能執(zhí)行的函數(shù)的地址，然后pop到eip中，那么該程序就會造成任意代碼執(zhí)行。

輸入命令!mona find -s "xffxe4" -m，查找jmp esp，選擇其中一個kernel32模塊，該地址是7c86467b。

構(gòu)造payload4,然后retn執(zhí)行后指令跳轉(zhuǎn)到7c86467b，然后esp則增加了8個字節(jié)。發(fā)現(xiàn)cpu下一條指令就要執(zhí)行7c86467b中的值，而該值正是ffe4即jmp esp，而jmp esp的意思正是將eip修改為esp的值，因此下一步就要構(gòu)造shellcode，而shellcode會由于緩沖區(qū)溢出而壓入到棧中，而此時的esp則會指向shellcode。

再次構(gòu)造pyload5，而shellcode就是我們要注入的惡意代碼，這里暫時用字符串test代替。由于retn 8，因此esp會加8，因此要用至少8個空字符x90代替這段8個字節(jié)。

f8單步執(zhí)行，eip執(zhí)行+1，最終會執(zhí)行到esp為00BDFC34，而00dbfc34的內(nèi)存值則是7465即我們的shellcode字符串test，那么現(xiàn)在構(gòu)造真正可執(zhí)行的shellcode即可。

使用MessageBox彈窗api生成exp.exe。

加載exp到調(diào)試器中，提取匯編代碼對應(yīng)的機(jī)器碼。

shellcode=“x66x81xECx40x04x33xDBx53x68x2cx63x63x72x68x20x66x6fx72x68x20x79x6fx75x68x67x6fx6fx64x8BxC4x53x50x50x53xB8xEAx07xD5x77xFFxD0x53xB8xFAxCAx81x7CxFFxD0”

發(fā)送payload6，成功溢出并執(zhí)行任意代碼。

通過調(diào)試器，也可以看到執(zhí)行shellcode的第一條指令正是x66x8cxecx40x04。即subsp，440。

總結(jié)

通過上述分析過程發(fā)現(xiàn)緩沖區(qū)溢出其本質(zhì)就是在程序中對用戶輸入的數(shù)據(jù)長度沒有做限制，最終通過構(gòu)造畸形字符串控制程序的執(zhí)行流向，導(dǎo)致任意代碼的執(zhí)行。