2019年4月，漏洞CNVD公开了一个WebLogic的漏洞SSRF漏洞，编号CNVD-2019-07810。漏洞当时圈子里讨论热度不低，漏洞因为这个漏洞不需要认证，漏洞直接就能打。漏洞影响范围覆盖了WebLogic 10.3.6.0、漏洞12.1.3.0、漏洞12.2.1.0、漏洞12.2.1.1、漏洞12.2.1.2、漏洞12.2.1.3多个版本。漏洞说白了，漏洞只要你的漏洞WebLogic对外开放了管理端口，攻击者就能拿它当跳板。漏洞

漏洞出在 uddiexplorer 这个war包上。WebLogic默认会部署一个叫 uddiexplorer 的应用，路径通常是 /uddiexplorer/。里面有个 SearchPublicRegistries.jsp 页面，接收一个叫 operator 的参数。问题就在这儿——这个参数的值会被拼进一个URL请求里，服务端直接去请求这个URL，没有任何白名单或协议限制。

构造起来很简单。浏览器访问：

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

如果目标存在这个漏洞，页面返回的内容里会包含请求结果。请求成功和失败返回的信息不一样，这就给了攻击者判断内网端口开放情况的能力。比如把 operator 换成 http://192.168.1.1:22，返回报错说明端口不通；返回连接被拒绝又是另一种信息。靠这个差异，内网探测就做起来了。

能干什么

SSRF本身不是直接拿shell的漏洞，但它的价值在于探测和内网穿透。攻击者可以用它扫描内网存活主机、探测端口开放情况、读取部分服务返回的banner信息。如果内网有Redis、Memcached、Elasticsearch这类没做认证的服务，配合SSRF还能进一步利用。更关键的是，WebLogic的SSRF可以请求 file:// 协议吗？不能。它只支持 http://，但这也够用了。

实际渗透中，我见过有人拿这个漏洞探测内网Redis，然后通过HTTP协议往Redis写cron任务反弹shell。路径是：SSRF探测到内网Redis端口→用 http:// 协议构造Redis命令→写入计划任务→拿到服务器权限。当然这需要一定的条件和运气。

怎么修

Oracle在2019年4月的CPU补丁里修了这个漏洞。补丁对 operator 参数做了校验，限制了可请求的地址范围。如果你没法立刻打补丁，临时缓解方案是删掉 uddiexplorer 这个war包，或者限制 /uddiexplorer/ 路径的访问权限。具体操作：找到 $DOMAIN_HOME/servers/AdminServer/tmp/_WL_internal/uddiexplorer/ 目录，把里面的内容清掉，然后重启。或者直接在WebLogic控制台里把uddiexplorer应用停掉、删除。

不过说实话，临时方案都是治标。WebLogic的历史漏洞太多了，反序列化、SSRF、任意文件上传，隔三差五就爆一个。真正靠谱的做法是别把管理端口暴露在公网，内网也做好访问控制。我见过太多生产环境把7001端口直接扔在公网上，这跟裸奔没区别。

检测脚本思路

写个简单的Python检测脚本，核心逻辑就是发请求、看返回。请求上面那个URL，检查响应里有没有 No route to host、Connection refused 这类关键字。有的话说明SSRF存在。更精确一点，可以请求一个外部可控的HTTP服务，看对方有没有收到回连。这样误报率最低。

WebLogic SSRF这个漏洞技术含量不算高，但实战中很实用。内网探测这一环，很多时候比直接拿权限还重要。信息收集做得好，后面的路才好走。