1. 项目概述从“Day80”看企业安全实战的纵深防御看到“Day80”这个标题很多安全圈的朋友会心一笑这大概率是某个安全团队或个人在进行百日安全挑战或HW网络安全实战演练复盘中的一个节点。这个标题本身就充满了实战气息它把“服务攻防”和“中间件安全”这两个在红蓝对抗中至关重要的领域直接关联起来并点名了WPS、Weblogic、Jetty、Jenkins这几个在近年HW和日常渗透测试中频繁“出镜”的重量级选手。这不仅仅是一个学习笔记的标题更像是一份浓缩的实战检查清单。对于甲方安全工程师、渗透测试人员甚至开发运维来说理解这些中间件的安全特性与常见漏洞是构建有效纵深防御、快速应急响应的基本功。中间件简单来说就是位于操作系统和应用程序之间的“软件胶水”。它不直接处理业务逻辑但为业务应用提供运行环境、通信、数据交换等关键服务。正因为其承上启下的核心位置一旦中间件出现安全问题往往意味着其上运行的所有业务应用都暴露在风险之下可能造成数据泄露、服务中断甚至服务器被完全控制。HW2023中曝出的WPS分析案例以及常年占据漏洞榜单的Weblogic反序列化、Jenkins未授权访问等都是攻击者最青睐的“突破口”。本次分享我将结合自身在多次红蓝对抗和日常安全运营中的经验对这些中间件的攻防要点进行一次深度拆解重点不在于复现某个具体CVE的步骤而在于梳理攻击者的利用思路、防守方的检测与修复逻辑以及如何在日常工作中系统性降低这类风险。2. 核心思路攻击链视角下的中间件弱点剖析面对五花八门的中间件和层出不穷的CVE新手容易陷入“追漏洞”的疲于奔命状态。更有效的思路是建立攻击链视角攻击者是如何一步步利用中间件弱点达成目标的理解了这条链防守就能有的放矢。2.1 攻击入口的常见分类中间件暴露的攻击面大体可以归为以下几类这也是我们分析WPS、Weblogic、Jetty、Jenkins的通用框架默认配置与弱口令这是最古老也最有效的入口。许多中间件安装后存在默认的管理员账户/密码如Admin/Admin、开启不必要的调试或管理端口如Weblogic的7001控制台、使用默认的密钥文件。攻击者通过扫描和爆破可以轻易获得初始立足点。Jenkins的未授权访问漏洞CVE-2018-1000861等本质上就是访问控制配置不当。反序列化漏洞这是Java生态中间件如Weblogic、Jenkins、Jetty的某些组件的“头号杀手”。当中间件接收并反序列化不可信的二进制数据时攻击者可以构造恶意序列化对象在目标服务器上执行任意代码。Weblogic历史上多个严重RCE漏洞如CVE-2017-10271, CVE-2019-2725等皆源于此。组件依赖漏洞现代中间件大量使用第三方库。这些库的漏洞会直接传导给中间件。例如Jetty作为一个轻量级Servlet容器其安全性与它使用的组件如解析HTTP请求的库紧密相关。Spring框架的漏洞也会影响到使用Spring Boot内嵌Jetty的应用。功能滥用与逻辑缺陷中间件提供的某些功能在特定条件下可能被滥用。例如WPS Office提供的在线预览或格式转换服务如果对上传文件处理不当可能造成XXEXML外部实体注入或RCE。Jenkins的Pipeline脚本功能强大但若允许低权限用户创建或修改流水线就可能导致代码执行。信息泄露中间件默认的报错信息、状态页面、目录列表可能泄露版本号、内部路径、配置文件片段等敏感信息为攻击者后续攻击提供情报。注意在实际HW或渗透测试中攻击者很少只依赖一种方法。通常是“信息收集发现WPS/Weblogic服务→ 扫描探测找管理入口、测已知漏洞→ 利用尝试爆破、反序列化payload→ 权限提升与横向移动”的组合拳。防守方需要在这条链的每一个环节设置检测和阻断点。2.2 HW2023-WPS案例的启示HW2023中曝出的WPS相关安全问题是一个典型的“非传统”中间件案例。WPS作为办公软件其云服务或协作功能可能以API或服务的形式嵌入企业内网。攻击思路可能围绕文件解析漏洞上传恶意文档如包含恶意宏、利用旧版解析引擎漏洞的文档到WPS在线预览或转换服务触发RCE或信息泄露。API未授权访问WPS集成的协作编辑、文档分享API接口如果鉴权不严可能导致未授权访问、下载内部文档。SSRF服务器端请求伪造如果WPS服务端存在SSRF漏洞攻击者可以将其作为跳板扫描或攻击内网其他更敏感的服务。这个案例提醒我们安全资产清单不能只盯着Web服务器、数据库这些“典型”目标任何能处理外部输入、提供网络服务的软件都应纳入中间件安全的管理范畴。3. 靶场环境搭建与工具准备“工欲善其事必先利其器”。要深入理解漏洞一个隔离的、可反复测试的靶场环境必不可少。这里我推荐使用Docker来快速搭建漏洞环境它比在物理机或虚拟机上安装配置要高效、干净得多。3.1 Docker化漏洞环境部署以部署一个存在CVE-2017-10271漏洞的Weblogic 12.2.1.3环境为例# 1. 搜索现成的漏洞镜像 docker search weblogic CVE-2017-10271 # 通常会有社区维护的镜像例如从Vulhub项目获取 # 首先克隆Vulhub仓库如果尚未拥有 # git clone https://github.com/vulhub/vulhub.git # cd vulhub/weblogic/CVE-2017-10271 # 2. 使用docker-compose一键启动环境 docker-compose up -d # 3. 查看容器状态和映射端口 docker ps # 输出会显示容器ID和端口映射例如 0.0.0.0:7001-7001/tcp # 4. 访问Weblogic控制台通常用户密码为weblogic/Oracle123 # 浏览器打开 http://your-host-ip:7001/console对于Jenkins可以部署一个包含经典未授权漏洞的旧版本# 使用官方旧版本镜像 docker run -p 8080:8080 -p 50000:50000 --name jenkins-vuln jenkins/jenkins:2.138-slim # 启动后访问 http://your-host-ip:8080 可能无需密码即可访问管理界面取决于具体版本配置实操心得强烈建议在虚拟机或独立的云服务器中搭建这类靶场并与生产网络物理隔离。所有操作仅用于合法安全研究和学习。容器的便利性在于测试完成后一句docker-compose down就能彻底清理不留痕迹。3.2 核心安全工具链在靶场中我们需要一套工具来辅助分析、验证和利用漏洞。侦察与扫描Nmap端口扫描、服务识别。nmap -sV -p 1-65535 target_ip可以快速发现开放的7001Weblogic、8080Jenkins/Tomcat/Jetty、8081Jetty常见等端口。Gobuster/DirsearchWeb路径/目录爆破用于寻找管理后台、测试页面等。浏览器开发者工具手动测试时用于观察请求响应、寻找API端点、分析会话Cookie。漏洞利用与验证Metasploit Framework (MSF)包含大量成熟的Weblogic、Jenkins漏洞利用模块。对于CVE-2017-10271可以使用use exploit/multi/misc/weblogic_deserialize_asyncresponseservice。专门漏洞利用工具社区有很多单点漏洞的EXP工具例如针对Weblogic反序列化的各种“神器”。使用前务必在靶场验证理解其原理。Burp Suite手动测试神器。用于拦截、重放、修改HTTP请求测试反序列化、未授权访问等漏洞。其Intruder模块可用于密码爆破Repeater模块用于精细化的漏洞验证。分析与调试Java反序列化利用工具 (ysoserial)用于生成针对不同Java库CommonsCollections, Jdk7u21等的恶意反序列化Payload。这是理解Weblogic、Jenkins反序列化漏洞的关键。JD-GUI 或 FernFlower用于反编译分析从靶场中获取的Jar包寻找敏感逻辑或硬编码密钥。工具选型逻辑在HW或真实渗透中优先使用MSF等成熟框架因其稳定且免杀性相对较好但并非绝对。在深度分析和研究时则需使用ysoserial等工具手动构造Payload并利用Burp Suite进行精细调试。对于WPS这类办公软件相关的测试可能需要结合文件格式分析工具如ole-tools和传统的Web漏洞测试方法。4. 核心中间件安全漏洞深度解析与实操下面我们进入核心环节逐一拆解这几个中间件的典型安全问题。我会以“漏洞原理 - 攻击手法 - 防御措施”的逻辑展开并穿插实操中的关键点。4.1 Weblogic反序列化的“重灾区”Weblogic的安全史几乎就是一部Java反序列化漏洞的斗争史。漏洞原理精讲 Weblogic的T3协议用于集群通信和HTTP服务在处理特定接口如wls-wsat、AsyncResponseService的请求时会接收序列化的Java对象。如果服务端在反序列化过程中没有严格校验对象的来源和类型并且ClassPath中包含可利用的链如commons-collections库攻击者发送精心构造的序列化数据就能触发远程代码执行。以CVE-2017-10271为例漏洞存在于Weblogic的wls-wsat组件中。该组件提供了一个基于XML的Web服务其中AsyncResponseService端口接收XML数据其中的work:WorkContext标签内容会被直接反序列化。攻击实操步骤信息收集使用Nmap扫描发现7001端口开放访问/wls-wsat/CoordinatorPortType等端点确认存在漏洞组件。构造Payload使用ysoserial生成恶意序列化对象。例如生成一个执行calc.exeWindows或touch /tmp/successLinux的Payload。java -jar ysoserial.jar CommonsCollections1 touch /tmp/success payload.bin组装HTTP请求将生成的二进制Payload进行Base64编码嵌入到特定的SOAP XML请求体中发送给目标漏洞端点。发送利用请求使用curl、Burp Suite Repeater或Python脚本发送恶意HTTP POST请求。验证利用结果检查目标服务器上是否成功创建了文件或执行了命令。防御与修复方案立即措施临时禁用或删除wls-wsat应用对应$DOMAIN_HOME/servers/AdminServer/tmp/_WL_internal/wls-wsat目录或通过防火墙策略限制对/wls-wsat/*路径的访问。根本解决第一时间安装Oracle官方发布的安全补丁。Weblogic的补丁通常以季度更新的形式发布CPU需要持续跟进。安全加固修改控制台默认端口和强密码。限制T3协议仅在内网可信IP间使用或在外网禁用T3协议通过Weblogic控制台或修改配置文件。使用Java安全策略文件限制反序列化操作。从ClassPath中移除存在危险链的第三方库如旧版commons-collections但这可能影响应用功能需充分测试。踩坑记录不同版本的Weblogic和不同的JDK版本可利用的反序列化链Gadget Chain可能不同。在实际测试中经常遇到ysoserial的Payload不生效的情况。这时需要根据目标环境尝试其他链如CommonsCollections2, 3, 5, 6, 7或Jdk7u21或者使用更高级的工具如marshalsec。此外某些补丁只是黑名单了部分类可能存在绕过因此打补丁后仍需进行安全测试验证。4.2 Jenkins自动化构建背后的安全危机Jenkins以其强大的流水线功能成为DevOps核心但其安全配置往往被忽视。漏洞原理精讲 Jenkins的安全问题主要集中于访问控制和脚本沙箱绕过。未授权访问早期版本默认安装后可能未开启任何安全设置导致任何人都可以访问管理界面并执行操作。即使后来版本默认要求安装时设置密码但管理员可能错误配置了“任何用户可以做任何事”的权限矩阵。脚本命令行漏洞Jenkins的“脚本命令行”Script Console功能允许拥有“Administer”权限的用户执行Groovy脚本。如果低权限用户通过其他漏洞如某些插件漏洞获得了脚本执行权限或管理员误配置将导致直接RCE。Pipeline/Job配置漏洞在Job配置中可以执行Shell、Batch、Groovy等脚本。如果允许低权限用户创建或修改Job或者通过参数化构建传入未过滤的参数就可能造成命令注入。攻击实操步骤以未授权访问创建管理员用户为例发现目标扫描发现8080端口开放Jenkins服务。访问管理界面直接访问http://target:8080/manage或/script。如果未授权可能会直接进入。利用脚本命令行访问/script页面输入Groovy脚本创建管理员用户。import jenkins.model.* import hudson.security.* def instance Jenkins.getInstance() def hudsonRealm new HudsonPrivateSecurityRealm(false) hudsonRealm.createAccount(attacker, password123) instance.setSecurityRealm(hudsonRealm) def strategy new FullControlOnceLoggedInAuthorizationStrategy() instance.setAuthorizationStrategy(strategy) instance.save()执行脚本点击“Run”成功后即可用新账号attacker/password123登录并拥有完全控制权。防御与修复方案最小权限原则必须启用安全设置“启用安全”。使用“登录用户可以做任何事”或更细粒度的“项目矩阵授权策略”。永远不要给匿名用户任何写权限。定期更新保持Jenkins核心和所有插件为最新版本。安全漏洞经常在插件中被发现。加固脚本环境严格控制对“脚本命令行”的访问权限仅限最高信任级别的管理员。在Pipeline中对于从外部传入的参数必须进行严格的验证和清理。网络隔离将Jenkins管理界面限制在内网访问或通过VPN访问。构建节点Agent与Master之间的通信也应加密并限制网络范围。审计日志开启并定期检查Jenkins的访问日志和系统日志。4.3 Jetty轻量级容器的不轻量风险Jetty常作为嵌入式Servlet容器用于Spring Boot等框架。其风险主要来自其自身漏洞和错误配置。漏洞原理精讲Jetty Server信息泄露 (CVE-2021-28169等)某些版本的Jetty在发送特制的请求时可能会将未初始化的内存内容可能包含敏感信息返回给客户端。HTTP请求走私由于对HTTP协议头处理的差异攻击者可能构造特殊的请求使前端代理如Nginx和后端Jetty服务器对请求边界的理解不一致从而“走私”恶意请求。依赖组件漏洞Jetty使用的第三方库如javax.servlet-api、jetty-http、jetty-io等其漏洞会影响Jetty本身。Spring Boot Actuator端点暴露当使用Spring Boot内嵌Jetty时如果未正确配置Actuator端点如/env,/heapdump,/trace可能导致配置信息、内存数据泄露。攻击实操与防御信息泄露检测使用工具扫描Jetty服务尝试发送畸形的请求头观察响应中是否包含异常数据。请求走私测试使用专门的HTTP请求走私测试工具如smuggler或手动构造Transfer-Encoding: chunked与Content-Length头并存的请求测试代理与Jetty之间的解析差异。防御措施升级版本及时将Jetty升级到已修复已知安全漏洞的最新稳定版。安全配置对于Spring Boot应用在生产环境中务必通过management.endpoints.web.exposure.include属性严格控制暴露的Actuator端点通常只保留health和info。使用spring.security为管理端点配置强认证。最小化依赖在Maven或Gradle中定期运行dependency:check或使用OWASP Dependency-Check等工具扫描项目依赖及时更新有漏洞的Jetty相关组件。4.4 漏洞复现CVE的通用方法论面对一个陌生的CVE编号如何快速分析并验证其影响这里分享我的通用流程情报收集阅读公告在NVD、CNVD、厂商安全公告等权威来源查看漏洞描述、CVSS评分、影响版本。寻找分析文章在安全社区如Seebug、先知、安全客寻找技术分析文章理解漏洞的触发点、利用条件和原理。查找PoC/EXP在GitHub、Exploit-DB等平台搜索非官方的概念验证代码。重要永远先在隔离环境中测试PoC环境搭建根据影响版本使用Docker、虚拟机快速搭建一个与描述一致的有漏洞环境。Vulhub、VulnApp等开源项目是极佳的漏洞环境集合。分析与调试运行PoC确认漏洞可触发如弹出计算器、创建文件。使用Java调试工具如IDEA Remote Debug附加到靶场进程在关键函数如readObject,doFilter处下断点单步跟踪攻击Payload是如何被解析、传递并最终触发漏洞的。这是从“会用”到“懂原理”的关键一步。影响评估与修复验证在理解漏洞后评估它对自身业务系统的影响范围哪些服务器、什么版本。根据官方指南实施修复打补丁、升级、修改配置。最关键的一步修复后在测试环境用同样的PoC进行验证确保漏洞已真正被修复避免“假升级”或配置未生效的情况。5. 企业级防御体系构建与HW实战思考单个漏洞的修复是“点”而企业需要的是“面”的防御。结合HW实战经验我总结出以下多层次防御建议。5.1 事前预防安全左移与基线加固资产管理与漏洞扫描建立动态的CMDB配置管理数据库自动发现网络中的Weblogic、Jenkins、Jetty等服务及其版本。定期如每周使用Nexpose、Nessus或开源工具如Goby进行漏洞扫描及时纳入漏洞工单系统。安全基线固化为每一种中间件制定并强制执行安全基线配置标准。Weblogic修改默认端口、强密码、删除示例应用、限制T3协议、部署WLS安全组件。Jenkins强制开启安全矩阵、禁用匿名访问、定期更新插件、审计用户权限。Spring Boot with Jetty关闭不必要的Actuator端点、设置强密码、使用HTTPS。这些基线可以通过Ansible、SaltStack等自动化工具批量部署和检查。最小化部署在Dockerfile或服务器镜像中只安装必要的组件和库。移除默认的文档、示例程序和测试页面。5.2 事中检测实时监控与威胁狩猎WAF/IDS/IPS规则针对已知的漏洞利用特征如Weblogic反序列化Payload中的特定类名、Jenkins脚本命令行访问路径在WAF或网络IDS上部署相应的拦截规则。HIDS主机入侵检测在服务器上部署Agent监控关键文件的异常修改如Weblogic的startWebLogic.sh被篡改、异常进程的启动如突然出现的bash或powershell反向连接、以及针对特定日志关键词的告警如日志中出现“AsyncResponseService”和异常栈信息。日志集中分析将中间件的访问日志、错误日志统一收集到SIEM如Elastic Stack中。建立关联分析规则例如“短时间内多次登录Jenkins失败后成功登录”可能为爆破成功“访问了/wls-wsat/CoordinatorPortType路径”应立即告警。5.3 事后响应应急流程与溯源分析当监控告警或HW中被通报存在漏洞时需要有一套清晰的应急响应流程IRP隔离与遏制立即将受影响服务器从网络中断开或通过防火墙策略进行隔离防止攻击者横向移动。影响评估检查该服务器上存放的数据敏感性、业务重要性。查看日志确定漏洞是否已被利用、首次攻击时间、攻击者可能执行的操作如是否创建了后门账户、下载了数据。漏洞修复根据预案在测试环境验证补丁或加固方案后对生产环境进行修复。修复后务必再次验证。溯源与复盘提取攻击IP、Payload、攻击路径等信息。复盘漏洞为何存在是未及时打补丁基线未落实、为何未被及时发现监控规则缺失。将经验更新到安全基线和监控规则中。在HW实战中蓝队防守方的核心任务就是将上述“事前、事中、事后”的流程高效运转起来。重点在于收敛攻击面关闭不必要的服务、加强监控让所有攻击行为留下痕迹、快速响应在攻击者造成实质性损害前阻断。对于红队攻击方发现的漏洞不仅要修复更要举一反三进行全网同类问题的排查。安全是一个持续的过程没有一劳永逸的银弹。对中间件安全的深入理解是连接漏洞情报和有效防御行动的那座桥。从理解一个CVE的原理到制定一条检测规则再到固化一项安全基线每一步都是在为企业的数字资产增添一块坚实的砖瓦。