Winrar4.x的檔案欺騙漏洞利用指令碼

0x00 背景

這幾天仔細研究了winrar4.x系列的副檔名欺騙漏洞的那篇文章，透過一些測試對其有了一些新的想法和建議。（準確的說應該不能算副檔名欺騙漏，不止副檔名，整個檔名都是可以欺騙的）

具體的漏洞成因相信文章中都很清楚了，簡單說一下：

zip格式中有2個filename，一般情況下，一般應用程式開啟zip時，預覽使用的是filename2，點選預覽也是以filename2方式開啟的，只有在解壓的時候才會使用filename1。然而在winrar4.x中，點選預覽是以預覽filename1方式開啟的。

這會造成什麼結果呢？當第一個filename為readme.exe，第二個filename為readme.txt時，用winrar4.x開啟時，你在程式視窗看到的檔名為readme.txt，然後你再點選檔案時卻是以readme.exe方式開啟，這就形成漏洞了。

文章給出瞭如何利用這個bug的方法，更改filename2即可。但是作者是手動操作的，那麼能不能寫成利用指令碼呢？這個filename2的長度有沒有要求，需不需要和filename1長度相同？這正是本文要研究的。

0x01 細節

在研究這個問題以前，先科普一下zip格式（想看詳細版的去網上下載APPNOTE.TXT）。

zip格式由3部分組成：

1.檔案內容源資料
2.目錄源資料
3.目錄結束標識結構

以只壓縮了一個檔案的zip檔案為例，大致格式為：

[file header]
[file data]
[data descriptor]
[central directory file header]
[end of central directory record]

其中關鍵的幾個欄位為：

[file header]: 

Offset           Bytes               Description 
18                 4                   Compressed size 
26                 2                   File name length (n) 
28                 2                   Extra field length (m) 
30                 n                   File name 
30+n               m                  Extra field 


[central directory file header]: 

Offset           Bytes            Description 
28                 2                   File name length (n) 
30                 2                   Extra field length (m) 
34                 2                   File comment length (k) 


[end of central directory record]: 

Offset           Bytes                Description 
12                 4                   Size of central directory (bytes) 
16                 4                   Offset of start of central directory, relative to start of archive 

在瞭解了zip基本格式後，我對winrar壓縮生成的zip檔案和用windows生成的zip檔案進行了分析，它們的區別是winrar的zip檔案在Extra field區段都進行了一些資料填充。

由於不清楚Extra field這部分的值會不會影響到winrar的校驗，所以根據不同情況做了幾個測試，當filename2長度改變時，並且對受filename2長度影響的所有欄位（除Extra field）進行修改後，檔案可以正常開啟。測試結果證明Extra field的值並不會影響winrar開啟zip檔案。

這樣一來，只要按照zip的格式，更改和filename2有關的所有欄位，就可以寫出一個利用指令碼了。

等等，該文章中同時提到了，這個漏洞存在有一個限制：解壓。如果你是以右鍵解壓開啟這個壓縮包的話，那麼只會使用filename1，和filename2無關，也就不存在這個漏洞了。作者在文章最後提到了可以利用LRO解決這個限制，那應該如何結合利用RLO呢？

用WinHex對正常zip檔案、使用了字元反轉的zip檔案進行分析：

透過對比分析可以看到，當使用含有RLO檔名的檔案進行壓縮時，壓縮的格式有點區別，繼續做了幾個測試，發現winrar在Extra field新增的資訊，不會影響到漏洞的利用。

據此可以將這兩個漏洞完美的結合在一起，寫成一個利用指令碼。

以python為例，具體思路為：

1．生成一個帶LRO的檔名的檔案，並用winrar壓縮為zip。在python中可以使用u'\u202e'來構造字串反轉，用os.system()函式來執行winrar命令。 
2．處理zip檔案中的資料，將filename2更改為自己需要定義的字串。按照zip格式依次讀取，修改filename2為新的字串，計算出新的長度，並且修改File name length2欄位，Sizeofcentraldirectory 和Offsetofstartofcentraldirectory欄位，處理好它們新的偏移位置。 
3．重新生成新的zip。 

在文章最後附上完整的利用指令碼WinrarExp.py

本程式只用於測試，僅供安全學習、研究所用，請勿用於非法用途，否則造成的一切後果自負。

使用方法：

#!bash
WinrarExp.py [-f <open file>][-s <forged name>][-v <reversed string>] 

-f表示要壓縮的檔案，比如1.exe -s表示要偽裝的檔名，比如readme.txt -v表示需要反轉的字串，該引數為選用。比如想要檔名反轉變成readmeEXE.jpg則引數只要設定為EXE.jpg

下載地址：WinrarExp.py