WebLogic 两处任意文件上传漏洞动态分析（CVE-2018-2894）
0x01 前言
CNCERT前几天发公告称发现Oracle公司出品的基于JavaEE结构的中间件WebLogic产品存在一个远程上传漏洞，并得到了厂商的确认，危害程度评分高达9.8分。鉴于厂商已进行了安全修复，笔者对该漏洞进行了一次分析。WebLogic管理端未授权的两个页面存在任意上传getshell漏洞，可直接获取权限。两个页面分别为/ws_utc/begin.do，/ws_utc/config.do；漏洞的影响范围 Oracle WebLogic Server，版本10.3.6.0，12.1.3.0，12.2.1.2，12.2.1.3；相关链接： http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html#AppendixFMW , 下文笔者从这两个文件入手来系统调试跟踪找出漏洞产生的原理和位置。
0x02 漏洞流程
笔者首先访问了一下 http://IP/ws_utc/config.do 并且将默认的目录WSTestPageWorkDir修改了为 user_projects\domains\base_domain\tmp\sd\ 如下图
工作台设置一个新的目录后，weblogic会将原来目录下的子目录和文件一起转移到新设定的目录下，但旧的目录依然保留。因为不是重点，笔者对这块的分析就此略过。笔者从攻击者的维度简单的画了一个草图，最初攻击者肯定需要配置工作目录，因为默认的工作目录在URL访问的时候不可达，然后攻击者考虑是从config.do页面上传keystore文件还是从begin.do上传，最终都是成功上传小马，只是小马的访问格式和路径不尽相同。如下图
如果要从原理上彻底搞清楚weblogic漏洞产生的过程还需要看下图，简单的描述一下，攻击者开始攻击后，Weblogic在服务端做了很多的判断，如果设定了新的工作目录，那么程序会自动拷贝所有旧目录下的子目录和文件到新的设定目录里，并且设定新的目录作为工作目录，如果攻击者通过begin.do上传的话，Weblogic在服务端会判断有没有upload目录，如果不存在会自动创建，再接着在upload目录下创建Rs_Upload_格式化后的作为目录名，紧接着获取到import_file_name字段名作为后续的文件名拼接的一部分；如果通过config.do上传的话就获取GET请求中的timestamp参数作为后续webshell的文件名中的一部分，还是看下图吧：
0x03 begin.do页面上传漏洞
首先在IDE里搭建好WebLogic环境，把应用跑起来后点击页面右上方的文件夹按钮，这里实现的是一个导入的功能
选择任意文件上传，笔者选择上传jsp文件
抓取数据包可以看到其实真正存在上传漏洞的地址是
http://IP:7001/ws_utc/resources/ws/config/import?timestamp=1532403983779
因为是漏洞复现和分析，笔者一边上传的时候就一边把数据包抓取下来，得到下图的HTTP
这段没什么可说的就是一个简单的上传数据流，表单字段import_file_name是关键值，从产品防御的角度来看检测它们也是关键的特征之一。
接下来就需要在IDE里动态定位到漏洞的触发点，因为weblogic大多数漏洞都和T3协议有关联，根据之前分析过的weblogic漏洞定位的调试断点是在com.bea.core.weblogic.rmi.client_4.0.0.0.jar包里，多次调试后一步步跳转到了漏洞触发的核心包
\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\com.oracle.webservices.wls.ws-testclient-app-wls_12.1.3\cmprq0\war\WEB-INF\lib\ws-testpage-impl.jar
并且查到了对应的触发漏洞类名的位置 ： \com\oracle\webservices\testclient\ws\util\RSDataHelper.class
定位到的方法convertFormDataMultiPart，代码如下：
public KeyValuesMapString, String> convertFormDataMultiPart(FormDataMultiPart formPartParams, boolean isExtactAttachment) {
File pathFile = new File(TestClientRT.getUploadDir());
if (!pathFile.exists()) {
pathFile.mkdirs();
}
this.cleanObsoleteFile(pathFile);
String dirName = "RS_Upload_" + df.format(new Date());
String uploadPath = (new File(pathFile, dirName)).getAbsolutePath();
return this.convertFormDataMultiPart(formPartParams, isExtactAttachment, uploadPath);
}
代码中检查了当前工作目录下是否存在upload目录，如果没有的话则创建，并且调用了cleanObsoleteFile方法强制遍历了一次目录中所有的文件，并且发现文件就删除掉，调试过程如下图
0x01 前言
CNCERT前几天发公告称发现Oracle公司出品的基于JavaEE结构的中间件WebLogic产品存在一个远程上传漏洞，并得到了厂商的确认，危害程度评分高达9.8分。鉴于厂商已进行了安全修复，笔者对该漏洞进行了一次分析。WebLogic管理端未授权的两个页面存在任意上传getshell漏洞，可直接获取权限。两个页面分别为/ws_utc/begin.do，/ws_utc/config.do；漏洞的影响范围 Oracle WebLogic Server，版本10.3.6.0，12.1.3.0，12.2.1.2，12.2.1.3；相关链接： http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html#AppendixFMW , 下文笔者从这两个文件入手来系统调试跟踪找出漏洞产生的原理和位置。
0x02 漏洞流程
笔者首先访问了一下 http://IP/ws_utc/config.do 并且将默认的目录WSTestPageWorkDir修改了为 user_projects\domains\base_domain\tmp\sd\ 如下图
工作台设置一个新的目录后，weblogic会将原来目录下的子目录和文件一起转移到新设定的目录下，但旧的目录依然保留。因为不是重点，笔者对这块的分析就此略过。笔者从攻击者的维度简单的画了一个草图，最初攻击者肯定需要配置工作目录，因为默认的工作目录在URL访问的时候不可达，然后攻击者考虑是从config.do页面上传keystore文件还是从begin.do上传，最终都是成功上传小马，只是小马的访问格式和路径不尽相同。如下图
如果要从原理上彻底搞清楚weblogic漏洞产生的过程还需要看下图，简单的描述一下，攻击者开始攻击后，Weblogic在服务端做了很多的判断，如果设定了新的工作目录，那么程序会自动拷贝所有旧目录下的子目录和文件到新的设定目录里，并且设定新的目录作为工作目录，如果攻击者通过begin.do上传的话，Weblogic在服务端会判断有没有upload目录，如果不存在会自动创建，再接着在upload目录下创建Rs_Upload_格式化后的作为目录名，紧接着获取到import_file_name字段名作为后续的文件名拼接的一部分；如果通过config.do上传的话就获取GET请求中的timestamp参数作为后续webshell的文件名中的一部分，还是看下图吧：
0x03 begin.do页面上传漏洞
首先在IDE里搭建好WebLogic环境，把应用跑起来后点击页面右上方的文件夹按钮，这里实现的是一个导入的功能 无奈人生安全网
选择任意文件上传，笔者选择上传jsp文件
抓取数据包可以看到其实真正存在上传漏洞的地址是
http://IP:7001/ws_utc/resources/ws/config/import?timestamp=1532403983779
因为是漏洞复现和分析，笔者一边上传的时候就一边把数据包抓取下来，得到下图的HTTP
这段没什么可说的就是一个简单的上传数据流，表单字段import_file_name是关键值，从产品防御的角度来看检测它们也是关键的特征之一。
接下来就需要在IDE里动态定位到漏洞的触发点，因为weblogic大多数漏洞都和T3协议有关联，根据之前分析过的weblogic漏洞定位的调试断点是在com.bea.core.weblogic.rmi.client_4.0.0.0.jar包里，多次调试后一步步跳转到了漏洞触发的核心包
www.wnhack.com
\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\com.oracle.webservices.wls.ws-testclient-app-wls_12.1.3\cmprq0\war\WEB-INF\lib\ws-testpage-impl.jar
并且查到了对应的触发漏洞类名的位置 ： \com\oracle\webservices\testclient\ws\util\RSDataHelper.class
定位到的方法convertFormDataMultiPart，代码如下：
public KeyValuesMapString, String> convertFormDataMultiPart(FormDataMultiPart formPartParams, boolean isExtactAttachment) {
File pathFile = new File(TestClientRT.getUploadDir());
if (!pathFile.exists()) {
pathFile.mkdirs();
}
this.cleanObsoleteFile(pathFile);
String dirName = "RS_Upload_" + df.format(new Date());
String uploadPath = (new File(pathFile, dirName)).getAbsolutePath();
return this.convertFormDataMultiPart(formPartParams, isExtactAttachment, uploadPath); copyright 无奈人生
}
代码中检查了当前工作目录下是否存在upload目录，如果没有的话则创建，并且调用了cleanObsoleteFile方法强制遍历了一次目录中所有的文件，并且发现文件就删除掉，调试过程如下图