<dd id="sga4y"><optgroup id="sga4y"></optgroup></dd>
<nav id="sga4y"><code id="sga4y"></code></nav>
  • <optgroup id="sga4y"></optgroup>

    原文地址:http://drops.wooyun.org/tips/1346

    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區段都進行了一些數據填充。

    2014033020212771177.jpg

    由于不清楚Extra field這部分的值會不會影響到winrar的校驗,所以根據不同情況做了幾個測試,當filename2長度改變時,并且對受filename2長度影響的所有字段(除Extra field)進行修改后,文件可以正常打開。測試結果證明Extra field的值并不會影響winrar打開zip文件。

    這樣一來,只要按照zip的格式,更改和filename2有關的所有字段,就可以寫出一個利用腳本了。

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

    用WinHex對正常zip文件、使用了字符反轉的zip文件進行分析:

    2014033020214732907.jpg

    通過對比分析可以看到,當使用含有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

    97av