Weblogic SSRF 漏洞（CVE-2014-4210）分析

Weblogic SSRF 漏洞是一个比较经典的 SSRF 漏洞案例，该漏洞存在于 http://127.0.0.1:7001/uddiexplorer/SearchPublicRegistries. jsp 页面中，如图 1 -1 所示

图 1-1 Weblogic SSRF 漏洞

Weblogic SSRF 漏洞可以通过向服务端发送以下请求参数进行触发，如果该 IP和端口存在并且开放，则返回以下信息，如图 1-2 所示

rdoSearch=name&txtSearchname= sdf&txtSearchkey=&txtSearchfor=&selfor= 
Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001

图 1-2 IP 或端口存在且开放时返回的信息

 

如果该 IP 不存在或者端口不存在，则返回以下信息，如图 6-13 所示

图 1-3 IP 或端口不存在时返回的信息

     根据请求的 URI 可以看到请求的是 SearchPublicRegistries.jsp ，该文件的存储路径为

user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/ uddiexplorer/

5f6ebw/war/SearchPublicRegistries.jsp 。

        从请求的 URL 中可以发现最关键的参数是 operator 参数，在 SearchPublic Registries.JSP 文件的第 48 行获取了该参数，如图 1 - 4  所示。

图 1-4 operator 参数

        在第 102 行调用 search.setOperator 方法并将 operator 作为参数传入，并在第 107行调用 search.getResponse 方法，如图 1 -5 所示

图 1-5 调用 search.getResponse 方法

        getResponse方法的第 65 和 66 行分别调用了一个 Http11ClientBinding 对象的 send方法和 receive 方法，当探测的 IP 存在且端口开放时，会在 receive 方法处抛出异常，异常类型为 IOException 。当探测的 IP 不存在或者端口不开放时，会在 send 方法处抛出异常，异常类型为 IOException 。如图 1 -6 所示

图 1-6 调用 send 方法和 receive 方法

抛出的异常在第 88 行被封装成一个 XML_SoapException 对象返回给客户端，如图 1-7 所示

图 1-7 XML_SoapException 对象

 

异常内容就是 var18.getMessage 方法返回的结果，如图 1 -8 所示

图 1-8 var18.getMessage 方法返回的结果

 

小结

        SSRF 漏洞犹如一位隐形杀手，常年隐匿于大型站点中不起眼的角落，有非常大的威胁。国内的互联网科技公司如腾讯、阿里巴巴、华为、百度等，均出现过 SSRF漏洞，且具有一定的危害。在安全问题愈发得到重视的现在，SSRF 漏洞也得到了“特别关注”。

        因此对于安全审计人员来说，更应注意 SSRF 漏洞的挖掘，除了基本的搜索关键函数审计的方法外，还要注意源程序对于 SSRF 的防御策略是否存在漏洞，攻击者是否可以绕过其防御策略，或者能否配合特殊环境下的配置，形成漏洞利用链。另外需要注意的是，代码审计绝不意味着纯白盒审计。SSRF 漏洞也可以通过黑盒的方式去挖掘、测试，能挖掘出漏洞且不影响正常业务的方式都是好方式。