【分析】Windows Workstation Service遠程溢出的再次分析

Windows Workstation Service遠程溢出的再次分析

建立時間：2003-12-01
文章屬性：轉載
文章提交：stardust (stardust_at_xfocus.org)

By snake. snake@cnns.net

Company page: http://www.cnns.net

第一次分析：http://www.cnns.net/news/db/3796.htm

本人前兩個星期發表的《Windows Workstation Service遠程溢出的分析》，其實，裡面有不少細節的地方沒有寫清楚，特別是關於如何利用vsprintf輸出到大小不正確定義的緩衝區，進行攻擊的部分。借周末的機會，我再詳細的研究了一下，下面是本人的一些研究心得。同樣的，裡面沒有具體的攻擊原始碼，只是在技術的原理上進行分析和探討，涉及具體化的東西，例如原始碼，sorry，我就不能貼出來了，大家如果真的對這些技術感興趣，那麼，自己構造一下相應的資料包，應該是有比較大的成功率的。

要完全理解本文，需要3個方面的預備知識：

1．  理解堆疊溢位的原理

2．  Windows Unicode和 多位元組之間的轉換知識

3．  閱讀理解了上一篇文章 <<Windows Workstation Service遠程溢出的分析>>

好了，轉入正題。這裡研究的系統對象還是Windows 2000簡體中文版，其他多位元組語言的版本道理上相通的，只是實現的具體不一樣罷了。

參考上次的文章，可以看到問題主要是出在msvcrt.dll的vsprintf(下面所有提到的vsprintf，都是msvcrt.dll的vsprintf函數，非LIBC的vsprintf)字元格式設定化輸出的結果上。在攻擊端輸入 NetValidateName(L”//IP”, “attack string”,L “”,L””, NetSetupUnknown); ，那麼，服務端就會進行相應的日誌紀錄(當然，這些都是在許可權等條件都符合的情況下。)。 函數定義了輸出緩衝字串的變數，只有 0x804 的大小，vsprintf格式化輸出內容到該變數中，如果大小超過了0x804，那麼，就會覆蓋其頂部的堆棧資料，包括變數和函數返回地址，造成緩衝區溢位。

Vsprintf格式化的字串為：[NetpValidateName: checking to see if '%ws' is valid as type %d name.]。 可以看到，輸入字串到輸出緩衝的轉換是 %ws的轉換。跟蹤進去 msvcrt.dll的vsprintf時，發現流程是這樣的：（分析的彙編代碼略去，大家可以看msvcrt.dll的vsprintf原始碼）

1．  逐個格式化字元讀取，進行處理。

2．  如果字元的ASCII不是 0x20~0x78的範圍，那麼，跳轉，這裡我不關心它是如何處理的，跳過。。。

3．  根據當前的字元的ASCII值到轉換表格中尋找，然後，得到轉換值。

4．  根據轉換值，再次查表，得到實際的處理函數地址，處理如下：

a)         不同的字母，跳到不同的處理函數地址，例如。%，w，s，d，f，p等的跳轉地址是不一樣的。

b)        如果是%，則設定開始轉換的標誌位。

c)        如果是w，則設定寬位元組處理標誌為1。

d)        如果是s，則開始取後面的參數，進行字串複製。

e)         其他的參數，不關心，跳過。

5．  當前字元處理完，繼續讀取下一個位元組，直到長度超過 0x7fffffff，或者碰到0字元作為結束。否則，跳到1迴圈處理。

這裡詳細分析vsprintf中對 %ws的處理，也是上面流程中 4->d的分析。

通過跟蹤，發現vsprintf的是調用 wctomb進行寬位元組轉換，wctomb的msdn解析是將寬位元組的字元轉成多位元組的字元。傳回值是轉換的字元數。如果轉換的內容是位元組0，那麼，傳回值是1，如果轉換失敗，那麼，返回-1。

針對wctomb再分析，跟蹤進去，最後發現是調用 WideCharToMultiByte進行轉換。（倒！又是和系統語言相關的功能。這樣可能意味著不同系統之間，不能做到完全通用，而且，E文的字母沒有多位元組，怎麼轉換呢。。。？）。如果WideCharToMultiByte轉換失敗，那麼，wctomb就返回-1。

Vsprintf中，當碰到轉換失敗的寬位元組字元時，轉換立刻停止，不管後面還有沒有更多等待轉換的字元，均不進行處理。所以，就要求在作為參數輸入的所有攻擊資料中，字元都必須是可以被轉換的寬位元組字元。

根據上面的分析結果，和上一篇文章，構造如下的攻擊包。

緩衝1                     緩衝2（Jmp esp地址）       緩衝3(shellcode)
MultiByte （2023位元組）    4個位元組                    不限制      

無論發送的WideChar 緩衝多大，被轉換的長度必須符合上面的表格要求。

1.       緩衝1被轉換回多位元組的字串以後，長度必須是 0x7e7個位元組。

2.       緩衝2是jmp esp地址，被轉換回多位元組的字串以後，長度必須是4個位元組，並且，在service.exe進程中，記憶體位址指著的內容是應該是：0x54 0xc3（push esp, ret）；或者 0xff 0xe4 (jmp esp)；或者是 0xff 0xd4 (call esp)。

3.       緩衝3是溢出發生時，esp指標的地址，必須是正確shellcode的內容，並且，這些shellcode都是經過 WideCharToMultiByte考驗的，也就是說，全部都能夠被WideCharToMultiByte轉換，並且，不會出現 0x00 的資料。這裡對於其他字元，則不會有特別的限制，例如，不會碰到 <, >, *, ?, ‘, “, +, -, /, / 等符號的限制。

4.       整個轉換後的資料包的長度不能太長（具體多少，我沒有計算，但是，經驗測試，超過5000個位元組就會觸發，這個時候用來觀察現象，定位溢出的原因還是可以的。），否則，就會觸發異常處理函數，這是另外的一個利用辦法了，這裡不詳細敘述，但是，轉換的道理是一樣的。

上面就是條件，如何在上面的架構中，進行穩定的攻擊呢？也就是說，寫出針對同種語言的win2k的通用的攻擊代碼（不分service pack），我們必須找到如下的資料：

1.               最重要的，是有一個完全能夠轉換的shellcode，這個yuange前幾年的文章已經說出一個技術辦法，大家翻一翻，或者找得到。：）

2.               能夠找到一個所有版本都相同的跳轉esp地址，並且，能夠成功被轉換成寬位元組的。以便在vsprintf中轉換，還原。

3.               前面的緩衝1，有2023位元組的長度，可以用來存放攻擊代碼，原始的內容不管，原始長度是多長也不管，但是，在WideCharToMultiByte轉換後，長度必須是2023。

4.               上一篇文章說到，緩衝1末尾的一個地方，會被 WriteFile的參數改寫，這裡不詳細計算，就不要用了。

Ok. 構造完成以後，發送，獲得shell!，嘿嘿，就這麼簡單，可能嗎？當然！

經過這些比較雜亂的分析，大家可以看到，Windows Workstation Service的通用的攻擊，其實並不是不可能的。只是中間費的心事比較多而已。 開始 Webdav也好像很難，但是，畢竟也是出來了。

至於 E文的，由於 WideCharToMultiByte，無法對大於 0x78的位元組成功轉換，暫時想不到有更好的處理方法。也不清楚市面上流行的溢出程式是如何?的，好像對方不用考慮這種轉換的問題。真的不明白，可能是技術的角度不一樣吧。如果哪位朋友理解了，那麼，請告訴本人一下，讓我也可以學習學習。~

Win XP也有這個溢出，但是，我研究的中文xp版本，其WideCharToMultiByte的轉換的codepage竟然是437，也就是說，是E文的方式轉換，很難利用。。。現在還想不到有更好的實現辦法。

本溢出，雖然可以做到通用，但是無法做到多次溢出，因為，rpc函數進入本函數之前，已經至少2個地方出現了 EnterCriticalSection, 進入了臨界區，雖然本溢出函數也進入了，並且函數返回的時候也的確正確退出了當前的臨界區，由於溢出的特性，後面堆棧的資料已經被利用來做shellcode存放區，無法正確的儲存返回地址，所以，溢出利用後，已經無法回到原路，繼續原始代碼的執行了，前面的2個臨界區的進入，也無法退出。下次再進入，也會造成鎖定，長久等待。。。

ps：本溢出攻擊成功後，不能ExitProcess，ExitThread是一個好辦法。否則，Services.exe進程死掉後，系統會保護性的重新啟動。但是，在xp的環境下，由於workstation服務是由svchost.exe啟動的，所以，可以重複溢出攻擊而不會重新啟動。只是，xp到現在還無法成功利用。。。

Ok，討論到此，本文只從技術的角度上來探討實現的可能性，希望悟出來的高手不要放出代碼，畢竟這個漏洞還是很廣泛的存在著的，一個不小心，又會造成蠕蟲泛濫，謹慎，謹慎！

Snake. 2003/11/30 night.