也許你用過或者正在用著PP點點通這款軟件，因為其出色的基于網絡的服務功能，使得它在現在的網絡軟件中占據了很大的市場。我也是它的一個忠實用戶，可就在幾天前，我的朋友說他發現PP點點通這款軟件有漏洞，而具體的細節他沒有給我說，雖然只是簡單的一句話，可是因為自己對這樣的信息比較感興趣，于是我就自己尋找出現漏洞的地方，所謂自力更生才是正道嘛。我拿出自己編寫的一套測試軟件，在腦力與程序的配合下，終于發現了出現漏洞的地方，其實要成功觸發這個漏洞并不難，可難就難在找到利用的突破口上了，欲知詳情請聽下面分解。
? ?? ???漏洞出現的地方是在對本地一個文件的修改上，這個文件名為“Config.ini”，顧名思義是一個配置文件。很多程序在初始化的時候都是要么從配置文件獲取初始信息，要么從注冊表獲取信息等等，這一點對于安全測試員來說很關鍵。文件“Config.ini”中有很多可以測試的字段，我這里首先選擇了“DownloadPath=”，因為這是一個可以被人明顯注意的地方，一般在程序安裝后，它的默認值是“C:\Program Files\PP31\Downloads”。我們知道，Windows默認的文件夾、文件完整路徑不超過255個字節，而在VC6中有個宏定義標記這個值為260，而PP點點通恰巧是用VC6編寫的，這里我們就不得不考慮是不是會出現什么問題了。利用我的測試軟件，在測試中果真發現PP點點通初始化讀取了這個文件，并且傳遞了“DownloadPath=”參數，一旦我們修改了這個默認的數值，PP點點通將會自動新建一個同名的文件夾作為下載文件夾，那么這就勢必會引起對“DownloadPath=”參數長度的限制。很可惜，PP點點通根本沒有注意到這個，一旦我們將這個參數的值改到超過260個字節時，你就會發現程序出錯了，如圖1所示。
? ?? ?? ? 下載 (41.12 KB)
3?小時前
? ?? ???圖1
現在看起來，漏洞果真是存在的了。你一定開始急得想調試漏洞，尋找跳轉地址，然后放上ShellCode去執行了。且慢，如果你現在調試就會發現，此時程序的執行已經不是簡單的返回地址被覆蓋了，你沒發現上面的報錯內容跟以往的不一樣嗎？程序出現棧溢出的地方早已執行過去了，現在出現的錯誤只是前面棧溢出引發的另一個錯誤而已，傳統的溢出利用這里完全不奏效。怎么辦？別急，有兩個辦法可以幫助我們解決問題。第一個是找到溢出的地方，看能不能引出返回地址被覆蓋的傳統溢出現象，我測試了這個辦法，答案是不能。那么就用第二個辦法，就是所謂“將錯就錯”，既然這個是引發溢出后的另一個錯誤，那么就試圖把它弄成一個能被我們利用的錯誤。還記得我們在傳統溢出中為了執行ShellCode的辦法嗎？一個是利用系統DLL中的jmp xxx（寄存器）或者call xxx（寄存器）的方法，一個是覆蓋SHE。我們現在既然要創建一個能被我們利用的錯誤，那么也就是尋找上述的兩個辦法來執行ShellCode，要么我們弄出一個錯誤，讓程序出現jmp xxx或者call xxx出錯，要么就去覆蓋SHE。這里覆蓋SHE不行，那么就只剩第一個辦法了。經過我仔細的反匯編分析，用了將近一天的時間，終于成功的讓PP點點通程序出現了讓我們興奮的call指令錯誤，如圖2所示。
圖2
看到了嗎？圖中黑色的那一行，“call dword ptr[eax+5c]”指令出錯，而這里的eax是我們能夠控制的指令，勝利的天平已經向我們傾斜了。可是稍等，這里的“call dword ptr[eax+5c]”指令是一個間接尋址指令，也就是說我們必須使得[eax+5c]的值成為一個指向我們ShellCode的指針數值，而此時只有ecx和edi寄存器指向我們可以利用的ShellCode，如圖3所示。
下載 (72.14 KB)
3?小時前
圖3
所以我們要么能讓“[eax+5c]＝edi”或者“[eax+5c]＝ecx”，要么就是讓[eax+5c]指向的地方是一個跳轉語句或者call語句，類似“call edi”或者“jmp ecx”，讓其變成間接的間接尋址，最終還是會跑到我們的ShellCode中去就行。說到這里我提出一個面對這種情況下，如何執行ShellCode的方法，因為這不是傳統的“jmp esp”，esp直接就指向ShellCode，這里的情況是我們得間接執行ShellCode。按照上面的兩個方法，我們為了尋找“[eax+5c]＝edi”，可以在系統的動態庫文件中，尋找一些指令，由這些指令組成一個等于edi值的連續地址。假設在user32中，某地址處的指令為“mov eax,ebx pop eax pop ebx ret”，那么它在內存中的顯示就是“8B C3 58 5B C3”，而且我們需要的edi值就是“0x5B58C38B”，這個地址指向我們的ShellCode，那么我們只需要將eax的值賦值為上面user32[某地址－5c]即可，因為這樣“call dword ptr[eax+5c]”獲取的就是我們ShellCode的執行權。同樣道理，我們也可以找一個“call edi”的指令地址，在系統DLL庫中找指令組合，然后獲得地址，修改我們的跳轉指令。大家仔細看看圖4和圖5的示意圖就會明白了。
下載 (18.49 KB)
3?小時前
圖4
圖5
其實這里最穩定的還是圖5的使用方法，因為如果你使用圖4的方法，所獲得的ShellCode地址是相對穩定的，一旦電腦重新啟動或者因為某些原因，例如堆的參與，很容易造成地址變化，而使用寄存器間接尋址則會保持穩定，因為寄存器的值始終指向我們的ShellCode地址。在接下來的時間里，我們就是尋找這樣的符合我們要求的地址。你可以選擇手工，也可以選擇編個程序自動尋找，總之有了思路，一切皆有可能，最后，我們只需要放上一個符合格式的ShellCode即可。什么叫符合格式的ShellCode？還記得我們這里測試的參數嗎？是一個路徑值參數“DownloadPath”，既然是路徑值，那么就不要在其中出現一些特殊符號啦，不然Windows會報警的，這也會影響我們的ShellCode執行。假設你要尋找符合這樣要求的ShellCode，你可以參考我以前在黑防上發表的那篇關于騰訊安全控件漏洞的文章，那里的ShellCode是符合要求的。
現在為了證明我的理論的正確性，我暫時把ShellCode換成一個執行死循環的代碼，從偽指令角度來說就是：“loop 1＝1”，匯編代碼是“EB FE”，這樣一旦我們的這個ShellCode執行了，那么電腦就會忙得不可開交了。現在我們無非是要找到符合要求的那種所謂的間接再間接尋址指令的地址，我這里尋找的是一個找尋指向call（寄存器）或者jmp（寄存器）指令的地址，并且我為了保證這個地址能是一個比較穩定的地址，把尋找的目標放到了系統的動態庫里面，當然你也可以尋找別的文件里的，只是一旦環境稍變化，恐怕你的地址就會成為錯誤的。手工尋找太累了，自己編寫一個程序自動查找最好，其實這個很好編寫，就是按照將地址加一，然后取出這個地址，利用這個地址找到所指處的十六進制代碼是否是“FF D1”“FF D7”“FF E1”“FF E7”，這幾個代碼其實就是call ecx、call edi、jmp ecx和jmp edi這些指令的十六進制表示，只要我們找到其中的任意一個，我們都是可以利用來執行我們的ShellCode的，因為edi和ecx寄存器都指向了我們的ShellCode。經過大約一分鐘的查找，真是太幸運了，我們找到了四個地址，可正如同我說的那樣，為了穩定最好選擇使用系統動態庫的地址，這樣我們把目標所在了“204D3DE1”，這個地址其實是在Windows XP SP2的一個專門的動態庫文件“xpsp2res.dll”中的，不論怎樣這都非常符合我們的要求。現在趕緊修改我們的過長字符串，將其中控制eax寄存器值的那個字符串值改為“204D3D85”，注意這里，這個值可不直接就是我們剛才找到的那個地址，還記得前面出錯的那個call指令嗎？因為出錯時，利用的是[eax+5c]，所以我們找到的地址一定要減去5c才行，這樣PP點點通出錯時會自動幫我們恢復成真正要利用的地址。修改好跳轉地址后，再修改我們的ShellCode，把我們的死循環這個ShellCode放到離跳轉地址大約100個字節以后，因為edi指向的地址比較靠超常字符串的后面，太前了出錯時會執行不到那里。還需要說的就是，正因為edi指向的地址比較靠后，這樣留給我們放ShellCode的位置就不是很充裕了，如果你要放一個比較長的ShellCode，建議你使用先放小ShellCode，此Code的主要目的是跳轉后遍歷查詢大ShellCode，而大ShellCode就可以直接放到控制eax覆蓋的跳轉字符串的前面任意位置，那里可以放很長的字符串，估計完全夠用。一切就緒后，我們用這個精心構造好的字符串賦值給“config.ini”文件中的“DownloadPath”參數，打開PP點點通，然后選擇“退出系統”，你會發現你的電腦一下子忙到了100％！我為了更加清楚的反映程序出錯時的狀態，給大家截圖如下，先看第一幅，如圖6所示。程序出錯了，還是出錯在call指令上，而此時eax成功被我們控制進入xpsp2res.dll中。再看圖7，看到了嗎？我們成功控制程序流程進入了call edi指令，注意下方的顯示，此時edi就指向了我們的簡單ShellCode。一旦程序進入了我們的ShellCode，電腦就會進入一個死循環，圖8中的任務管理器真實的反應了這一點。
? ?? ?? ? 下載 (57.71 KB)
3?小時前
? ?? ???圖6
圖7
下載 (25.31 KB)
3?小時前
圖8
到這里，表明我們的一切分析確實都是正確的，只是有時利用會出現一定的干擾，這個大家可以自己研究一下，這里我就不再分析了。現在大功告成，我們收工了。最后，我提供給大家一個POC，因為每個版本的Windows環境下利用的跳轉地址不太一樣，我就偷懶不挨個測試了，我直接給出觸發到call指令的畸形文件，依據我上面的思路，自己修改練練手，也許你會有新的發現的。

轉載于:https://blog.51cto.com/yyaidd/309190

總結

以上是生活随笔為你收集整理的PP点点通畸形文件溢出漏洞0Day的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。