Weblogic SSRF 漏洞是一个比较经典的 SSRF 漏洞案例,该漏洞存在于 http://127.0.0.1:7001/uddiexplorer/SearchPublicRegistries. jsp 页面中,如图 1 -1 所示
Weblogic SSRF 漏洞可以通过向服务端发送以下请求参数进行触发,如果该 IP和端口存在并且开放,则返回以下信息,如图 1-2 所示
rdoSearch=name&txtSearchname= sdf&txtSearchkey=&txtSearchfor=&selfor=
Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001
如果该
IP
不存在或者端口不存在,则返回以下信息,如图
6-13
所示
根据请求的 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
所示。
在第 102 行调用 search.setOperator 方法并将 operator 作为参数传入,并在第 107行调用 search.getResponse 方法,如图 1 -5 所示
getResponse方法的第 65 和 66 行分别调用了一个 Http11ClientBinding 对象的 send方法和 receive 方法,当探测的 IP 存在且端口开放时,会在 receive 方法处抛出异常,异常类型为 IOException 。当探测的 IP 不存在或者端口不开放时,会在 send 方法处抛出异常,异常类型为 IOException 。如图 1 -6 所示
抛出的异常在第 88 行被封装成一个 XML_SoapException 对象返回给客户端,如图 1-7 所示
异常内容就是 var18.getMessage 方法返回的结果,如图 1 -8 所示
小结
SSRF 漏洞犹如一位隐形杀手,常年隐匿于大型站点中不起眼的角落,有非常大的威胁。国内的互联网科技公司如腾讯、阿里巴巴、华为、百度等,均出现过 SSRF漏洞,且具有一定的危害。在安全问题愈发得到重视的现在,SSRF 漏洞也得到了“特别关注”。因此对于安全审计人员来说,更应注意 SSRF 漏洞的挖掘,除了基本的搜索关键函数审计的方法外,还要注意源程序对于 SSRF 的防御策略是否存在漏洞,攻击者是否可以绕过其防御策略,或者能否配合特殊环境下的配置,形成漏洞利用链。另外需要注意的是,代码审计绝不意味着纯白盒审计。SSRF 漏洞也可以通过黑盒的方式去挖掘、测试,能挖掘出漏洞且不影响正常业务的方式都是好方式。