转载

Apache Commons Fileupload 漏洞,可恶意操作文件

点击蓝色“ 程序猿DD ”关注我

回复“ 资源 ”获取独家整理的学习资料!

作者 | spoock

来源 |   https://tinyurl.com/y34djpar

双十一虚拟机大促,主打机型大横评!

漏洞的来源是在于 DiskFileItem 中的 readObject() 进行文件写入的操作,这就意味着如果我们对已经序列化的 DiskFileItem 对象进行反序列化操作就能够触发 readObject() 执行从而触发这个漏洞。

这个漏洞的危害是能够任意写、读文件或者目录。但是具体是对文件还是目录操作与FileUpload以及JDK的版本有关。

不同的漏洞环境能够达到的效果不一样。

  1. FileUpload的1.3.1之前的版本配合JDK1.7之前的版本,能够达到写入任意文件的漏洞;

  2. FileUpload的1.3.1之前的版本配合JDK1.7及其之后的版本,能够向任意目录写入文件;

  3. FileUpload的1.3.1以及之后的版本只能向特定目录写入文件,此目录也必须存在。(文件的的命名也无法控制);

影响范围

commons-fileupload<=1.3.2

下面进行详细地分析

Payload构造

我们首先测试的版本是1.3的版本,JDK是1.8版本,所以这种组合只能达到向任意目录的文件写入的漏洞效果。我们测试的payload是 {"write;cve1000031;123456"} ,表示的含义就是向目录 cve1000031 中写入 123456 的内容。在 ysoserial 中最终是由 ysoserial.payloads.FileUpload1::makePayload() 来构建payload。代码如下:

当我们输入我们的Payload, {"write;cve1000031;123456"} ,其中的赋值情况是:

Apache Commons Fileupload 漏洞,可恶意操作文件

thresh 的值就是我们需要写入的内容的长度加1,即 len(123456)+1 结果就是7。其中还有 filePathcve1000031/whatever 是因为在这个漏洞环境中我们最终是向 cve1000031 目录写入,所以后面是什么就没有意义了。最后在代码中还存在几个反序列化的操作:

发序列化的意义是在于我们无法通过 DiskFileItem 的示例进行设置,只能通过反射的方式设置,这几个属性也是我们触发漏洞的必要条件。

之后对我们构造的这个进行序列化操作,反序列化之后就会触发DiskFileItem的 readObject() 从而触发漏洞。

漏洞分析-1

漏洞环境: FileUpload1.3 + JDK1.7

当对 DiskFileItem 的对象进行反序列化操作时,由 org.apache.commons.fileupload.disk.DiskFileItem::readObject() 处理。

跟进 getOutputStream() ,进入到:

由于 dfos==null 满足条件,会执行 FileoutputFile=getTempFile(); 方法。跟踪进入 getTempFile() 到中 Apache Commons Fileupload 漏洞,可恶意操作文件

其中的 tempDir 就是我们设置的 repository ,即 cve1000031tmpFileName 是由 DiskFileItem 是自动生成的。最终和 tempDir 组合得到的文件路径就是 cve1000031/upload_7b496a67_4fc4_4b14_a4e7_ff5aceb82aaf_00000000.tmp

最后返回至 readObject() 方法中写入文件,如下:

Apache Commons Fileupload 漏洞,可恶意操作文件

其中的 cachedContent 就是我们之前在Payload中设置的 123456 。那么Payload的最终的效果就是在 cve1000031/upload_7b496a67_4fc4_4b14_a4e7_ff5aceb82aaf_00000000.tmp 文件中写入了 123456 的内容。

Apache Commons Fileupload 漏洞,可恶意操作文件

漏洞分析-2

由于前面的一个漏洞分析是向任意目录写文件的功能,本次分析的是任意文件写入的功能。本次的漏洞环境是 FileUpload1.3 + JDK1.6

Payload构造

构造的Payload是 {"writeOld;cve1000031.txt;123456"} 。同样会调用 makePayload() 构造Payload。

Apache Commons Fileupload 漏洞,可恶意操作文件

但是其中的 repoPath 最后一位是 /0 ,这个就类似于PHP中的截断,用于截断后面的路径,这样就可以达到任意文件写入的效果。具体的原理说明如下:

JDK7以上在Java的file相关的基础类中都做了空字符的保护,这也是在针对java的string 和 c char的结束方式不一致,在Java中文件的操作中使用String这种char 数组,而C中的char 是以空字符为结束符,所以java操作的文件中很容易通过注入空字符来操作完全不同的文件。比如 JavaFilefile=newFile("/test/test.txt/0.jsp") 看起来再操作 test.txt/0.jsp 实际上在底层调用的(本质还是c读写文件)是在操作test.txt。在JDK7以后的版本File 里面会有一个判断是否有空字符的函数

这个意思就是在JDK7之前可以利用 /0 进行目录截断,和php在5.3.4版本之前也可以进行目录截断是一样的道理。所以这个任意文件写入为什么要求是JDK7以下的版本才可以的原因。

漏洞的执行流程和前面分析的漏洞流程一样,不同是在 getTempFile() 中:

Apache Commons Fileupload 漏洞,可恶意操作文件

其中 this.tempFile 的路径是 cve1000031.txt /upload_6982dc32_8ca4_4d7c_b658_0a9b44a60741_00000000.tmp 。由于是在JDK1.6的环境下,后面的 /upload_6982dc32_8ca4_4d7c_b658_0a9b44a60741_00000000.tmp 在写入文件时会被忽略,所以最终是向 cve1000031.txt 文件中写入内容。

Apache Commons Fileupload 漏洞,可恶意操作文件

漏洞分析-3

漏洞环境: FileUpload1.3.1 + JDK1.7FileUpload1.3.1 中对 readObject() 的功能进行了修改。修改主要是对 repository 进行了校验。

通过对 repository.isDirectory()repository.getPath().contains("/0") 的判断,就阻止了任意的文件写入的漏洞了。所以在这种环境下只能下特定的目录写入文件了。但是这种情况下,你也只能向临时目录写入文件。

本文通过OpenWrite的免费Markdown转换工具发布

-END-

双十一虚拟机大促,主打机型大横评!

留言交流不过瘾

关注我,回复“ 加群 加入各种主题讨论群

Apache Commons Fileupload 漏洞,可恶意操作文件

  • “12306”的架构到底有多牛逼?

  • 必须掌握的六大JVM性能调优监控工具使用详解

  • 优秀Java开发者的10条共性

  • 史上最烂的项目:苦撑 12 年,600 多万行代码

  • 避坑指南:四条使用Spring BeanUtils的总结

朕已阅 

原文  http://mp.weixin.qq.com/s?__biz=MzAxODcyNjEzNQ==&mid=2247488796&idx=3&sn=ac97fe1b8063d35feadef635622dbfce
正文到此结束
Loading...