全公司最大的黑阔在群里发了一张截图是老外发的关于这个漏洞复现的截图,于是我昨天看了很久他的源码,开始还是很难受的,可以知道的信息就是这是一个文件上传漏洞,看了最新发布的版本的修改
https://github.com/wso2/carbon-kernel/pull/3152/files
这部分是对文件上传的实现代码的修改,其实我看了感觉这儿其实还并不重要,因为也没修改啥内容,另一处修改就是添加了权限验证的代码
https://github.com/wso2/carbon-identity-framework/pull/3864/files
我一开始很疑惑,因为不知道这里面每个标签的具体功能,标签属性的定义是啥,这就很无耐。这应该是一个权限控制的xml文件 resource标签的context为路由, secured为是否开启权限认证,如果为false的话则不开启,也就是可以未授权访问。这里注意到红色部分,对"(.*)/fileupload(.*)
的定义是设置的为false
的,也就是这个接口是可以未授权访问的,看名字很明显是一个未授权访问的接口。但是关于这个接口的映射关系,最终调用的是哪个类我开始一直很迷惑,因为这个的项目结构没有接触过,每个xml文件的作用域调用过程我都不是很熟悉,就很烦。 最新版还有一处修改就是
https://github.com/wso2-extensions/identity-carbon-auth-rest/pull/167/files
阅读代码可以发现其实并没有什么打的变化,这里就是判断cookie是否是有效的,换了一种实现方式而已,对漏洞的修复感觉影响不大。这里去到最重要的部分,也就是第一处的修改 这里删除了很多的映射关系,可以看到是两个文件上传的执行器,那么我们其实可以去看看这连个执行器是怎么写的,当然现在我们不看这个,还有另一个文件被修改了
主要的修改有两处 这里对uploadFile
的赋值进行了修改,添加了一个函数verifyCanonicalDestination
对fileName
进行检查,这个函数是新增加的, 大概的意思就是 首先使用getCanonical
函数对dirs
进行规范化,这个函数处理会将类似’../../../../‘这种给干掉直接获取最终的路径,这种时候如果我们使用目录穿越将会使得最终获取的路径产生变化,然后使用extraFileLocation
变量新建一个File对象,然后也调用getCanonicalPath
函数进行规范化,然后调用startsWith
函数判断后生成的canonicalDestinationFile
是否以canonicalDestinationPath
开头,如果不是的话就抛出异常,很明显如果我们对canonicalDestinationPaht
使用了目录穿越的话那么将必然导致抛出异常,那么文件上传也就失败了。但是这里我还有个疑惑,这里canonicalDestinationPath
的获取是使用extraFileLocation
拼接了fileName
的我们可以控制的只有fileName
,我们看看fileName
怎么来的
String fileName = getFileName(fileItem.getFileName());
这里首先使用fileItem.getFileName()
获取了一遍,这时候获去的文件名如果有目录穿越的特征是会影响到上传目的地的,但是这里还调用了当前类的方法getFileName
就不一样了,我们看看这个函数怎么定义的 最新的代码只是修改了实现方式,当然还是有一点区别,主要是新的代码里对空字节截断进行了处理,当然这并不影响什么,这里只取了最后一个\\
或者/
后面的内容,也就是说目录穿越在这里就已经被避免掉了,我实在没想明白为什么后面要再进行一次处理。 当然走到这里其实我的思路已经出了问题,我看的这个文件是FielUploadServer.java
而我们在路径映射文件中看到的实际处理文件上传的类为 害,所以我们应该去找到这个类:
https://github.com/bhagyasakalanka/carbon-kernel/blob/release-4.4.9/core/org.wso2.carbon.ui/src/main/java/org/wso2/carbon/ui/transports/fileupload/ToolsAnyFileUploadExecutor.java
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 package org.wso2.carbon.ui.transports.fileupload;import org.apache.commons.collections.bidimap.TreeBidiMap;import org.wso2.carbon.CarbonException;import org.wso2.carbon.utils.FileItemData;import org.wso2.carbon.utils.ServerConstants;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;import java.io.File;import java.io.FileOutputStream;import java.io.IOException;import java.io.PrintWriter;import java.util.List;import java.util.Map;public class ToolsAnyFileUploadExecutor extends AbstractFileUploadExecutor { @Override public boolean execute (HttpServletRequest request, HttpServletResponse response) throws CarbonException, IOException { PrintWriter out = response.getWriter(); try { Map fileResourceMap = (Map) configurationContext .getProperty(ServerConstants.FILE_RESOURCE_MAP); if (fileResourceMap == null ) { fileResourceMap = new TreeBidiMap (); configurationContext.setProperty(ServerConstants.FILE_RESOURCE_MAP, fileResourceMap); } List<FileItemData> fileItems = getAllFileItems(); for (FileItemData fileItem : fileItems) { String uuid = String.valueOf( System.currentTimeMillis() + Math.random()); String serviceUploadDir = configurationContext .getProperty(ServerConstants.WORK_DIR) + File.separator + "extra" + File .separator + uuid + File.separator; File dir = new File (serviceUploadDir); if (!dir.exists()) { dir.mkdirs(); } File uploadedFile = new File (dir, fileItem.getFileItem().getFieldName()); try (FileOutputStream fileOutStream = new FileOutputStream (uploadedFile)) { fileItem.getDataHandler().writeTo(fileOutStream); fileOutStream.flush(); } response.setContentType("text/plain; charset=utf-8" ); fileResourceMap.put(uuid, uploadedFile.getAbsolutePath()); out.write(uuid); } out.flush(); } catch (Exception e) { log.error("File upload FAILED" , e); out.write("<script type=\"text/javascript\">" + "top.wso2.wsf.Util.alertWarning('File upload FAILED. File may be non-existent or invalid.');" + "</script>" ); } finally { out.close(); } return true ; } }
这里主要是调用execute
函数来处理文件上传请求。这里就不是获取的文件名而是FieldName
也就是文件上传请求的name
参数的值进行拼接 这里很明显是有路径穿越的问题的,所以到这里所有的问题基本就被打通了。但还有一个困扰我的问题,就是这个路由的写法,可能只有对这个产品比较了解的人才能很好的把这个高清楚吧,放一张复现的截图 不用管那个403,我做了别的测试,具体的poc就不发了,没意义,还是要懂原理才好。
当然其实在github上已经有大哥进行了详细的分析,但我还没有仔细去看
https://github.com/hakivvi/CVE-2022-29464
官方说明
https://docs.wso2.com/display/Security/Security+Advisory+WSO2-2021-1738