MS10-046_LNK檔案快捷方式漏洞的原理分析(多圖殺貓)
檔案快捷方式漏洞MS10-046是除了n年前的動畫游標(.ani)漏洞之外另一個讓我覺得比較有趣的漏洞,畢竟是本機執行任意程式碼的許可權,當然,n年前我還只是一個菜鳥,神馬都不懂.
入正題吧,歡迎拍磚,大家一起進步.(後面我會把一些參考文章貼出來的)
由於MS10-046的漏洞是在shell32.dll當中,windows出於美化的目的,會現實快捷方式的圖示,這個圖示可能是程式本身自帶的ico,也可能是系統預設的那些圖示,對於一個快捷方式,系統會對它進行解析從而獲取他要顯示的那個圖示,但是在解析的時候沒有做好引數驗證工作,我覺得在設計上也是有一定缺陷的,後面會詳細說.
首先必須解決的問題是除錯,怎麼去調系統的解析操作,當然是用windbg啦,ring0還是比較勁的,但是預設的情況下,windbg是不會載入ring3的符號的,怎麼解決這個問題,讓windbg能夠除錯應用層的程式,步驟如下:
1.!process 0 0 explorer.exe //主要是獲取explorer.exe的_EPROCESS地址,上下文切過去
2..process /p _EPROCESS地址 //這是點命令,切到指定的程序上下文去
3..reload /user [/f] [dll名稱] //也是點命令,用於載入應用層的符號,如.reload /user shell32.dll
之後就可以使用bp下斷了,如bp shell32!_LoadCPLModule
解決了除錯問題之後,我們來研究一下這個惡意構造的lnk檔案是如何構造出來的.
作業系統能夠讓我們自己對控制面板裡面的程式進行擴充套件,如圖
快捷方式跟控制面板的這些程式還是有點關係的.這些程式被稱為Control panel applets,他們的實質就是一個字尾名為.cpl的檔案,如圖,VMware Tools對應的.cpl
雖然後綴名是.cpl,但是實質上他是一個dll,至於怎麼判斷出來的,我們都知道,dll和exe都是PE檔案格式,具有相似性,並且,exe檔案也是可以具有匯出目錄的,那麼如何在PE格式的這個角度判斷一個檔案是exe還是dll,這個下午也花了點時間去找資料,在<An In-Depth Look into the Win32 Portable Executable File Format>這篇文章中提到:"The distinction between EXE and DLL files is entirely one of semantics. They both use the exact same PE format. The only difference is a single bit that indicates if the file should be treated as an EXE or as a DLL. Even the DLL file extension is artificial. You can have DLLs with entirely different extensions—for instance .OCX controls and Control Panel applets (.CPL files) are DLLs.",區分dll和exe就靠一個bit,然後很坑爹的至於哪個bit他又不說,沒找到資料,自己對著FFI看,最後找到了,就在PE頭部的characteristics成員當中,同時文章也說了cpl是一個dll.有圖有真相:
dll是可以包含自己的圖示資源的,在控制面板裡面現實出來的就是封裝在dll裡面的圖示資源.好吧,回顧一下:1.我們現在知道了,系統他會解析快捷方式看看需要載入神馬圖示資源;2.作為一個cpl,實質上就是一個dll,他本身可以包含圖示資源.我建立一個cpl檔案的快捷方式,如上面的VMware Tools的快捷方式,我看到的圖示是
現在可以很自然的聯絡起來,MS10-046能夠執行任意程式碼,同時跟lnk檔案有關,可能性在哪裡?一種合理的思路:在系統解析lnk載入圖示的時候,如果是存在於程式當中如dll當中的圖示,系統會把這個dll載入進入記憶體,之後再獲取相關的圖示資源,顯示出來,並且,系統在載入這樣的一個dll時候並沒有做過多的安全性判斷,從而導致了MS10-046的漏洞(這樣描述只是為了方便理解).
為了更好的理解這個漏洞,我找了跟快捷方式檔案格式相關的一些文章,花了很久的時間.結果發現,這是一個很蛋疼的行為,微軟對於lnk檔案的內部細節並非公開的很徹底,這裡我們針對cpl的快捷方式來說,如圖:
在[MS-SHLLINK]Shell Link(.LNK) Binary File Format當中,有愛的同學自己研究吧,paper我待會傳上來,前面的格式都是對的上的,沒有問題,但是從偏移0x4C開始,按照微軟的說法,這個是Shell item ID list段,00 F4是表示這個段的長度,計算一下可以知道,段的結束是到0x140之前,也就是說,建立的cpl快捷方式只有一個段,而對於這個段裡面的內容卻沒有詳細的說明,稍微說一下,圖中總共有3個ItemID的結構(不包括最後的空結構),前兩個ItemID的結構是"我的電腦"和"控制面板"的CLSID值,但是第3個結構,完全沒有頭緒的,路徑這個我們容易猜測,但是這個結構裡面還有一個DWORD的值與lnk構造的成功與否是有比較大的關係的.微軟還是比較坑爹的.過程中我也找到同樣認為微軟這樣做很坑爹的兩篇文章,對lnk的檔案結構進行了比較深刻的分析,有愛的同學請猛擊http://blog.0x01000000.org/ LNK Parsing的那兩篇就是了.
看看修改後的而已LNK檔案是什麼樣的,如圖:
圖上我們可以看到,我們的而已dll是C:/FuckLNK.dll,這些是Unicode字元,注意另外圈起來的94 FF FF FF這個DWORD,記得之前我們說過的一個有重大影響的DWORD就是這個同學了,需要將它改為00 00 00 00才能順利觸發漏洞,至於為什麼是這個地方的這個值,難道特麼是一個個試出來的?當然不是,通過除錯加上一點點運氣是能夠發現的,當然也要足夠的細心,後面會提到的.
這樣成功構造了一個LNK檔案,測試一下,是成功的,我的環境是WindowsXP+SP2,沒打補丁(廢話..)
圖很清晰,_LoadCPLModule直接呼叫的LoadLibraryW的,我們先對它下斷點,然後通過棧回溯進行觀察,如果要觀察到如剛才說的怎麼知道那個關鍵的DWORD值還要再往上一層才能看到.
成功在_LoadCPLModule()斷下來之後,找LoadLibraryW(),LoadLibraryW()引數只有一個字串,通過db檢視.圖上很清晰,我就不囉嗦了.執行到這裡,利用kn進行棧回溯,如圖
可以看到,在_LoadCPLModule之前的函式呼叫過程,一個個的下斷點回溯上去,利用能出發漏洞和沒有修改94 FF FF FF DWORD值的LNK分別進行測試(沒錯,這是一個體力活),當然也有結合靜態分析,最終找到判斷DWORD值的地方,是CEtrlExtIconBase::_GetIconLocationW()這個函式裡面,如圖:
可以看到這裡的彙編語句是cmp ecx,edx,ecx的值是0xffffff94(注意高高低低原則,94 FF FF FF讀為DWORD的值),然後edx的值是0(xor edx, edx),最終如果兩者不想等的話是跳到0x775224e3的地址繼續執行,而往下0x775224d0呼叫了CPL_FindCPLInfo(),就是說,如果那個DWORD不為0的話,系統就不會執行CPL_FindCPLInfo(),按照上面的控制流圖,只有呼叫了CPL_FindCPLInfo才有機會呼叫LoadLibraryW(),最終執行程式碼.
這個DWORD值應該是描述圖示資源在cpl檔案當中的一個狀態,我測試了幾個控制面板程式的快捷方式,發現防火牆的快捷方式的DWORD一開始就是00 00 00 00,檢視cpl檔案之後發現,防火牆的cpl檔案自身是不帶有圖表資源的,需要從其他地方引入圖表,這個也從一定側面說明了這個DWORD的作用.
這樣回到我們一開始說的那個思路,應該要調整為:如果DWORD為0,那麼我清楚需要引用外部圖示,需要載入dll,而對於非零值則可以通過另外的方式來獲取到圖示資源,具體可以參考老外提供的流程圖.
-----------------------------------------------------------------------------------------------------------------------------------
參考資料:
1.http://blog.csdn.net/flyingstarwb/archive/2009/05/16/4191762.aspx
2.http://www.exploit-db.com/exploits/16574/
3.http://www.docin.com/p-218001483.html
4.http://f4u5t.blog.163.com/blog/static/9339722120107944447390/
5.http://community.websense.com/blogs/securitylabs/archive/2010/07/20/microsoft-lnk-vulnerability-brief-technical-analysis-cve-2010-2568.aspx
6.http://xcf007.blog.51cto.com/471707/367275
7.http://www.exploit-db.com/exploits/14403/
8.http://blog.0x01000000.org/
9.http://msdn.microsoft.com/en-us/magazine/cc301805.aspx