Winrar4.x的文件欺骗漏洞利用脚本

Xcode 2014-03-31 14:24:00

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

本程序只用于测试,仅供安全学习、研究所用,请勿用于非法用途,否则造成的一切后果自负。

使用方法:

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

-f表示要压缩的文件,比如1.exe -s表示要伪装的文件名,比如readme.txt -v表示需要反转的字符串,该参数为选用。比如想要文件名反转变成readmeEXE.jpg则参数只要设置为EXE.jpg

下载地址:WinrarExp.py

评论

A

adm1n 2014-03-31 14:51:44

学习了

Z

zzR 2014-04-02 09:55:05

看到这个突然想回山里生活去了,现代文明已经不适合我了

刘大硕 2014-04-02 15:42:41

学习了学习了

小贱人 2014-04-24 13:50:35

mark

路人甲 2015-01-22 11:50:03

这个怎么用啊,我桌面有个123.exe想伪装打包怎么弄

L

llkoio 2016-03-23 11:21:37

为什么有时候显示的文件名字会被分割成两部分

X

Xcode

just Xcode!

twitter weibo github wechat

随机分类

逻辑漏洞 文章:15 篇
Java安全 文章:34 篇
二进制安全 文章:77 篇
Exploit 文章:40 篇
Web安全 文章:248 篇

扫码关注公众号

WeChat Offical Account QRCode

最新评论

K

k0uaz

foniw师傅提到的setfge当在类的字段名成是age时不会自动调用。因为获取

Yukong

🐮皮

H

HHHeey

好的,谢谢师傅的解答

Article_kelp

a类中的变量secret_class_var = "secret"是在merge

H

HHHeey

secret_var = 1 def test(): pass

目录