复盘Weblogic ssrf(cve-2014-4210)漏洞挖掘过程

本文通过扫描weblogic服务器，分析weblogic日志信息，逆向weblogic java二进制类，java源码分析等步骤，重现了weblogic ssrf类漏洞的发现过程。根据漏洞复现过程，总结了weblogic类漏洞挖掘的一般思路。

1. 建立weblogic漏洞研究环境

使用vulhub漏洞环境（git clone https://github.com/vulhub/vulhub.git下载漏洞的docker环境，操作系统使用ubuntu14.04）

进入vulhub/weblogic/CVE-2017-10271,运行如下命令：

docker-compose up > 日志文件名 （将weblogic控制台产生的日志保存到日志文件）

待weblogic server启动完毕，如下图：

Weblogic日志信息会自动写入日志文件。

2. 访问weblogic uudiexplorer

手动或工具扫描：http://IP:7001/uddiexplorer/

当访问url:

http://IP:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=输入数据时 产生日志中会出现类似信息（信息作用后续细说）

3.  逆向weblogic jar包文件

然后将wls10.3.6_generic.jar文件解压到wls10.3.6_generic目录，启动iotsploit框架进行wls10.3.6_generic文件夹内所有class文件进行自动逆向成java源码。框架中java_jar_dec插件会递归解压目录中jar包和war包，并递归逆向所有class文件成java文件。逆向文件以后用于源码分析。

4.  审查日志文件及静态代码分析结果发现ssrf漏洞

我们根据日志文件，发现程序运行异常点：

这说明在SearchPublicRegistries.jsp中与www-3.ibm.com值相关的参数触发了异常。首先找到SearchPublicRegistries.jsp发送请求的数据，可以看到异常由operator数据产生。

然后手工更改operator参数数据，看能否复现类似异常信息

http://IP:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http

复现异常信息后，根据异常点及异常后函数栈追踪信息。从web处理入口点，人工分析前面逆向的源码，查看外部数据传输流程。

在SearchPublicRegistries.jsp程序中可以看到程序将operator参数数据传递给search.java的代码如下：

search.setOperator(operator);

session.setAttribute("operator", operator);

try

{

bl = search.getResponse(rdoSearch, name, key, sfor, option);

请求的后台类程序执行流程：

com.bea.uddiexplorer.Search.getResponse(Search.java:172)

com.bea.uddiexplorer.Search.findBusinessListByName(Search.java:325)

weblogic.uddi.client.service.Inquiry.findBusiness(Inquiry.java:101)

weblogic.uddi.client.service.UDDISoapMessage.sendMessage(UDDISoapMessage.java:115)

此后抛出异常信息。

分析search.java的代码发现：

search.setOperator(operator); 通过setUDDIInquiryURL完成使用外部输入的operator参数值对Inquiry类的URL属性赋值。

调用了UDDISoapMessage类的sendMessage（在weblogic.uddi.client.service包的UDDISoapMessage.java类）函数，并将inquiry类的URL属性传递给sendMessage函数。也即将operater传递给了sendMessage函数。

然后看sendMessage(UDDISoapMessage.java)处代码：

sendMessage函数先将operator传递过来的数据，也就是inquery的URL属性，赋值给了BindingInfo的实例。然后通过BindingFactory工厂，使用Bindinfo实例创建了一个Binding实例。BindingFactory工厂提供了HttpClientBinding、HttpsClientBinding、Http11ClientBinding、Http11ClientBinding、JMSClientBinding接口，并通过operator参数的url协议关键字（http、https、http11、jms）决定当前使用哪个接口。而接口的send方法将使用socket函数，及operator参数传入的url创建socket并发送请求。而这里调用socket产生了ssrf漏洞。

如果不清楚这里createSoket将产生哪类型的漏洞，可以使用iotsploit的java_src_audit java源码分析插件分析该处漏洞类型（可通过“HttpClientBinding.java  487”定位到漏洞类型）。插件使用方法：

在iotploit\iotsploit\wordlists目录下有个java_src_path.txt文件，在这个文件里放置你要扫描的源码目录

使用use scaners/java_src_vul_scan加载插件

使用run运行插件（插件运行完毕结果存储在iotsploit目录的java_src_vul.txt文件中，由四列组成：漏洞类型 产生漏洞的函数 所在文件 在文件中的行号）

如下图java_src_audit审计分析的漏洞类型及代码所在行：

5.  Weblogic ssrf类漏洞挖掘方法总结

首先开启weblogic并将日志导出到日志文件。

使用扫描工具或手工访问web目录（web可访问路径或文件通过逆向后的web.xml文件或web目录下的文件获取）。

检查日志文件中的”exception”关键字，并确定异常入口点。

根据日志文件中找到的异常入口点确定产生异常的web请求，并手工修改对应输入参数数据复现。

根据日志文件中的异常函数栈调用信息，分析源码，定位异常产生过程及异常最终函数调用位置。根据最终触发异常的函数确定漏洞类型（可以把定位到的函数所在源文件，使用iotsploit的java_src_audit插件审计确定漏洞类型）。

根据漏洞类型，设计利用载荷，并进行利用实验，确定漏洞的可利用性。

web前端 Java

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。