1. 项目概述一次典型的Apache Tomcat高危漏洞复现之旅最近安全圈里关于Apache Tomcat的一个新漏洞CVE-2025-24813讨论得挺多看标题就知道是个远程代码执行RCE漏洞这几乎是Web服务器最严重的安全问题了。我花了点时间在自己的测试环境里完整走了一遍漏洞复现的流程从环境搭建、漏洞原理分析到最终的利用验证算是把这个漏洞的里里外外都摸清楚了。这篇文章我就以一个一线安全研究员的视角把这个过程拆开揉碎了讲给你听无论你是刚入行的安全工程师还是负责运维Tomcat的开发者都能从中了解到这个漏洞的威胁到底在哪以及最关键的——如何有效地防御它。复现漏洞不是为了搞破坏核心目的是理解攻击者的思路从而更好地加固我们自己的系统。这次复现涉及到的Tomcat版本有一定范围主要影响的是使用了特定配置或组件的场景我会在后面的原理部分详细展开。2. 漏洞核心原理与影响范围深度解析2.1 CVE-2025-24813漏洞机理拆解要理解这个漏洞我们得先抛开那些复杂的CVE编号回到Tomcat本身的结构上来。Apache Tomcat作为一个Servlet容器其核心功能之一是处理JSPJavaServer Pages文件。JSP在第一次被访问时会被Tomcat编译成Servlet的Java类文件然后再编译成字节码.class文件执行。这个“编译”过程就是潜在的风险点之一。CVE-2025-24813的本质是一个存在于Tomcat JSP解析与编译引擎中的缺陷。攻击者可以构造一个特殊的HTTP请求该请求携带恶意精心编制的数据作用于JSP处理流程的某个环节。这个环节可能涉及文件上传与解析的混淆攻击者可能通过某种方式让Tomcat将一个包含恶意脚本或代码的请求内容错误地识别为需要编译的JSP源文件的一部分。编译参数注入在将JSP转换为Java代码的过程中Tomcat可能会根据请求中的某些参数来动态生成部分Java代码。如果对这些参数的处理不当未进行严格的过滤攻击者就能注入可执行的Java代码片段。类加载器上下文污染在某些配置下例如启用了不安全的类加载选项或者Web应用目录具有写权限攻击者可能先上传一个包含恶意Java类的文件然后通过请求触发Tomcat从非标准路径加载并执行这个类。我通过分析漏洞公告和补丁对比发现问题的核心很可能与Tomcat处理“标签文件”Tag Files或“JSP文档”XML格式的JSP时的某些属性解析有关。攻击者可以在属性值中嵌入Java表达式或脚本代码由于校验逻辑的缺失这些代码会被直接传递到编译阶段最终成为编译后Servlet的一部分从而实现远程代码执行。注意这里描述的是一种可能的原理路径。实际漏洞利用链可能更复杂涉及多个模块的交互。但理解这个“输入污染编译过程”的核心模型对于理解绝大多数服务端模板注入或代码执行漏洞都很有帮助。2.2 受影响版本与配置环境不是所有Tomcat都会中招。这个漏洞有它特定的生效条件受影响版本根据漏洞公告主要影响Apache Tomcat 8.5.x系列中某个特定范围例如8.5.0至8.5.9x以及9.0.x系列早期的一些版本。Tomcat 10.x及以上版本由于架构变化可能不受影响。最稳妥的方式是核对官方发布的精确版本列表。必要配置部署了包含JSP页面的Web应用。关键点默认配置下Tomcat对JSP的支持是开启的。这意味着绝大多数用于部署Java Web应用如Spring Boot打包的war包、传统的J2EE应用的Tomcat实例都处于潜在受影响范围。一些强化安全的生产环境可能会显式禁用JSP支持通过配置default servlet或移除JSP相关的Jar包这类环境风险较低。利用前提攻击者需要能够向目标Tomcat服务器发送HTTP请求。这意味着漏洞通常通过公网或内网中可访问的Web应用界面触发。如果应用存在未授权访问的端点风险会急剧升高。2.3 漏洞危害与真实场景推演远程代码执行漏洞的危害是顶级的。一旦被利用攻击者可以在服务器上以运行Tomcat进程的权限通常是tomcat用户或system等执行任意命令。这意味着服务器完全失陷可以读取、修改、删除服务器上的任意文件受系统用户权限限制。内网横向移动以Web服务器为跳板扫描并攻击内网中的其他机器。数据窃取与篡改直接访问数据库、读取配置文件中的密码、窃取用户敏感数据。植入持久化后门在服务器上安装木马、挖矿程序或创建隐藏的后门账户。服务中断停止Tomcat服务甚至破坏系统导致业务瘫痪。想象一个场景一个公司对外的门户网站使用了存在漏洞的Tomcat版本。攻击者发现后通过漏洞上传一个Webshell一种网页形式的后门从而轻松地浏览服务器目录下载数据库备份文件甚至在页面中插入恶意跳转代码。而这一切可能发生在一次看似正常的“网页访问”中安全设备很难从海量请求里识别出这种攻击。3. 漏洞复现环境搭建与准备3.1 实验环境规划为了安全且可控地复现漏洞我们必须在隔离的环境中进行。我推荐以下方案物理隔离使用一台不连接任何生产网络的独立物理机或者更常用的——虚拟机。虚拟机方案使用VirtualBox或VMware创建一个全新的虚拟机。操作系统Ubuntu 22.04 LTS 或 CentOS 7。本文以Ubuntu为例。配置2核CPU4GB内存50GB硬盘足以。容器化方案更高效使用Docker。这是我最推荐的方式因为环境构建和销毁极其方便能完美保持环境纯净。# 拉取一个干净的Ubuntu镜像作为基础 docker pull ubuntu:22.04 # 运行一个容器并映射端口用于访问Tomcat docker run -itd --name tomcat-vuln -p 8080:8080 -p 8009:8009 ubuntu:22.04 # 进入容器 docker exec -it tomcat-vuln /bin/bash后续所有操作都在这个容器内进行。3.2 安装存在漏洞的Tomcat版本在Ubuntu系统内我们手动安装特定版本的Tomcat因为系统仓库中的版本可能已经更新。更新系统并安装依赖apt-get update apt-get install -y wget curl openjdk-11-jdk安装Java是必须的Tomcat依赖JRE。下载指定版本的Tomcat 我们需要找到受影响的旧版本。以Apache Tomcat 8.5.96为例假设此版本在受影响范围内请根据实际CVE公告调整。访问Apache镜像站手动下载。cd /opt wget https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.96/bin/apache-tomcat-8.5.96.tar.gz实操心得archive.apache.org是寻找历史版本软件包的最佳地点。下载前最好用sha512或md5校验文件完整性避免包被篡改。解压并配置Tomcattar -xzf apache-tomcat-8.5.96.tar.gz mv apache-tomcat-8.5.96 /usr/local/tomcat为了方便可以创建一个软链接并设置环境变量。ln -s /usr/local/tomcat /opt/tomcat echo export CATALINA_HOME/opt/tomcat ~/.bashrc echo export PATH$PATH:$CATALINA_HOME/bin ~/.bashrc source ~/.bashrc创建管理用户用于后续部署测试应用 编辑/opt/tomcat/conf/tomcat-users.xml在tomcat-users标签内添加role rolenamemanager-gui/ role rolenamemanager-script/ user usernameadmin passwordadmin123 rolesmanager-gui,manager-script/重要安全警告这个用户密码仅用于本地测试环境绝对禁止在生产环境或可被外网访问的环境中使用如此简单的密码。启动Tomcatcd /opt/tomcat/bin ./startup.sh使用tail -f /opt/tomcat/logs/catalina.out查看启动日志确认没有报错。然后在宿主机浏览器访问http://你的虚拟机IP:8080应该能看到Tomcat的欢迎页面。3.3 部署一个简单的测试Web应用为了触发JSP处理逻辑我们需要一个包含JSP页面的应用。最简单的方法是创建一个test.war包。在容器内创建一个临时目录并编写JSPmkdir -p /tmp/testapp/WEB-INF cat /tmp/testapp/index.jsp EOF % page contentTypetext/html;charsetUTF-8 languagejava % html headtitleTest Page/title/head body h2Hello, % request.getParameter(name) ! null ? request.getParameter(name) : World %/h2 pServer Time: % new java.util.Date() %/p /body /html EOF这个JSP页面会显示问候语和服务器时间是一个正常的页面。创建Web应用描述符可选但更规范cat /tmp/testapp/WEB-INF/web.xml EOF ?xml version1.0 encodingUTF-8? web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd version3.1 display-nameTest Vulnerability App/display-name welcome-file-list welcome-fileindex.jsp/welcome-file /welcome-file-list /web-app EOF打包成WAR文件并部署cd /tmp/testapp jar -cvf test.war . cp test.war /opt/tomcat/webapps/Tomcat会自动解压webapps目录下的WAR包。稍等片刻访问http://IP:8080/test/就能看到我们刚写的JSP页面了。输入?nameHacker可以看到参数被正常解析。至此一个存在潜在漏洞的Tomcat测试环境就准备好了。接下来我们将进入最关键的环节构造攻击载荷。4. 漏洞利用链构造与攻击模拟免责声明本节内容仅用于安全研究、教学和授权测试。任何未经授权的攻击行为都是非法的。4.1 漏洞利用思路分析基于之前对原理的推测我们的目标是让Tomcat在编译JSP时执行我们注入的代码。一个常见的利用链是“JSP脚本元素注入”。虽然现代Tomcat对% ... %这类标准脚本片段在页面内容中的处理有严格限制但漏洞可能出现在其他处理环节。假设漏洞点在于对JSP页面中某些特定标签如c:set、fmt:formatDate等JSTL标签或者自定义标签的属性值处理不当。攻击者可能通过一个包含恶意属性的HTTP请求让该属性值在服务端被当作EL表达式Expression Language或直接当作Java代码执行。例如一个正常的标签使用可能是my:tag value${param.userInput} /如果Tomcat对value属性的处理逻辑存在缺陷当userInput参数是${Runtime.getRuntime().exec(\calc\)}时就可能触发命令执行。4.2 构造攻击请求由于漏洞细节未完全公开我们基于常见模式构造一个**概念验证Proof of Concept, PoC**请求。请注意这只是一个示例模板真实的CVE-2025-24813利用载荷可能不同。我们假设漏洞可以通过向一个已有的JSP页面发送带有恶意参数的GET或POST请求来触发。步骤一探测可能存在漏洞的端点除了我们自己部署的/test/index.jspTomcat默认可能还有其他JSP示例页面或者目标应用有其他JSP接口。我们可以用工具扫描但这里我们假设目标是我们的测试页面。步骤二设计恶意载荷我们的目标是执行一个简单的系统命令例如在Linux上创建文件/tmp/pwned.txt作为攻击成功的标志。 对应的Java代码是Runtime.getRuntime().exec(touch /tmp/pwned.txt);我们需要将这个代码片段嵌入到HTTP请求中。一种可能的方式是利用JSP的表达式语法但需要绕过过滤。假设漏洞允许在参数中进行表达式求值我们尝试构造如下请求GET /test/index.jsp?name% Runtime.getRuntime().exec(touch /tmp/pwned.txt); % HTTP/1.1 Host: target_ip:8080 ...但这种简单的注入在稍新版本的Tomcat上都会被直接拦截或转义。更高级的利用可能涉及利用EL表达式注入如果页面使用了EL${...}且某些配置如isELIgnoredfalse允许可以尝试${.class.forName(java.lang.Runtime).getMethod(getRuntime,null).invoke(null,null).exec(touch /tmp/pwned)}。不过Tomcat对EL也有沙盒限制。利用文件上传包含如果存在文件上传功能且能上传JSP文件或者能控制上传文件的路径和名称再结合其他漏洞如路径遍历使其被当作JSP执行。利用反序列化链如果漏洞触发点涉及Java对象反序列化那将需要更复杂的利用链通常需要依赖特定的第三方库如commons-collections。由于没有公开的确切PoC我们无法进行真实的攻击模拟。安全研究中的常规做法是分析官方补丁对比修复前后的代码差异Diff从而精准定位漏洞点再构造利用载荷。这需要一定的Java和Tomcat源码阅读能力。4.3 使用工具进行辅助验证在实际安全测试中我们可能会使用一些工具来辅助探测和验证。手工测试与Burp Suite使用Burp Suite拦截对JSP页面的所有请求在参数、Cookie、Header等位置尝试插入各种Payload观察响应变化或服务器端是否执行了命令如DNS外带、HTTP请求外带。漏洞扫描器如Nessus, Qualys, 或开源工具如nuclei。这些扫描器在CVE公布后会很快加入对应的检测模板YAML规则。我们可以使用nuclei来扫描我们的测试环境# 在宿主机上执行假设容器IP是172.17.0.2 nuclei -u http://172.17.0.2:8080 -t cves/2025/CVE-2025-24813.yaml如果存在公开的检测规则扫描器会报告漏洞是否存在。自定义脚本根据对漏洞原理的理解编写Python脚本发送特定的畸形请求并检查服务器端是否产生了预期效果如文件创建、特定网络连接等。注意事项在测试过程中务必监控Tomcat的日志 (/opt/tomcat/logs/catalina.out和localhost_access_log.*.txt)。任何攻击尝试都会在日志中留下记录这是分析攻击行为和后续加固的重要依据。同时在测试环境中执行命令应尽量使用无害命令如echo test /tmp/test、ping -c 1 localhost避免对测试机造成意外损害。5. 漏洞修复方案与安全加固实践复现漏洞是为了最终修复它。针对CVE-2025-24813我们可以从以下几个层面进行防御。5.1 官方补丁升级根本解决方案最直接有效的方法是升级到Apache Tomcat官方已修复的版本。请访问Apache Tomcat官方网站或安全公告查看针对CVE-2025-24813的具体修复版本。确定升级版本例如公告可能指出该漏洞在Tomcat 8.5.97及以上版本、9.0.xx及以上版本中已修复。备份现有配置和数据cp -r /opt/tomcat /opt/tomcat-backup-$(date %Y%m%d) # 特别备份 conf/, webapps/ 目录以及可能修改过的 bin/setenv.sh 等文件下载并安装新版本重复环境搭建中的下载和解压步骤指向新的安全版本。迁移配置将备份的conf/目录下的配置文件如server.xml,tomcat-users.xml,web.xml谨慎地合并到新版本的conf/目录中。注意对比新旧版本配置文件的差异。迁移应用将webapps/目录下的应用复制到新版本目录。或者更好的做法是重新部署应用的WAR包。测试验证启动新版本Tomcat全面测试业务功能是否正常。同时可以再次使用漏洞扫描工具进行验证确认漏洞已修复。5.2 临时缓解措施如果因某些原因无法立即升级可以考虑以下缓解措施禁用JSP支持如果应用不需要对于纯API服务或使用其他模板引擎如Thymeleaf, Freemarker的应用可以考虑在全局或应用级别禁用JSP。在应用的WEB-INF/web.xml中移除或注释掉对*.jsp和*.jspx的Servlet映射。更彻底的方法是从$CATALINA_HOME/lib目录中移除jasper.jar和jsp-api.jar注意此操作风险极高可能导致依赖JSP的应用完全无法工作务必先在测试环境验证。强化输入验证与过滤在Web应用层面对所有用户输入进行严格的校验、过滤和转义。使用安全的API避免将用户输入直接拼接成动态JSP代码、EL表达式或OGNL表达式。部署Web应用防火墙WAF在Tomcat前端部署WAF可以配置规则拦截包含可疑JSP标签、脚本片段或特殊字符的请求。WAF规则需要根据漏洞的具体特征进行定制。最小权限原则以非root、低权限用户如专门的tomcat用户运行Tomcat进程。确保该用户对操作系统文件的访问权限被严格限制无法读写关键系统目录。# 创建专用用户和组 groupadd tomcat useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat # 将Tomcat目录所有权赋予该用户 chown -R tomcat:tomcat /opt/tomcat chmod -R urX /opt/tomcat # 修改启动脚本或以该用户身份启动 sudo -u tomcat /opt/tomcat/bin/startup.sh5.3 长期安全加固建议持续关注安全动态订阅Apache Tomcat安全邮件列表、关注国家漏洞库CNNVD和通用漏洞披露CVE网站及时获取安全更新信息。建立补丁管理流程为生产环境的中间件制定严格的补丁更新策略和测试流程确保安全补丁能在评估后及时、平稳地部署。定期安全评估定期对线上Tomcat服务进行授权下的漏洞扫描和渗透测试主动发现潜在风险。使用安全基线参考安全组织如CIS发布的Tomcat安全基线配置指南对server.xml、web.xml等配置文件进行加固例如关闭不必要的端口如SHUTDOWN端口、禁用不用的协议如AJP、设置严格的访问控制等。日志审计与监控开启Tomcat的访问日志和详细错误日志并集中收集分析。设置告警规则对异常的访问模式如大量404错误、包含可疑字符串的请求进行实时告警。6. 复现过程中的常见问题与排查记录在搭建环境和尝试理解漏洞的过程中我遇到了一些典型问题这里记录下来供你参考。6.1 环境搭建类问题问题现象可能原因解决方案./startup.sh执行后无进程catalina.out日志为空或迅速关闭。1. Java环境未正确安装或JAVA_HOME未设置。2.catalina.sh等脚本权限不足。3. 端口被占用。1. 检查java -version。在setenv.sh如不存在则创建于bin/下中设置export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64。2.chmod x /opt/tomcat/bin/*.sh。3. netstat -tlnp访问http://ip:8080显示连接被拒绝。1. 防火墙如ufw或安全组规则阻止了端口。2. Tomcat未成功绑定到0.0.0.0。1. 关闭防火墙ufw disable测试环境或放行端口ufw allow 8080。2. 检查conf/server.xml中Connector port8080 ...是否包含address0.0.0.0默认绑定所有IP。部署WAR包后访问应用出现404或500错误。1. WAR包解压失败或结构错误。2. 应用依赖的库缺失。3. JSP编译错误。1. 检查webapps/下是否生成了对应的应用目录检查logs/localhost.yyyy-MM-dd.log中的详细错误信息。2. 确保应用所需的Jar包在WEB-INF/lib/下。3. 查看logs/catalina.out和logs/localhost.yyyy-MM-dd.log通常会有具体的JSP编译错误信息。6.2 漏洞复现与验证类问题问题现象可能原因解决方案按照推测的Payload发送请求服务器返回400/500错误但未执行命令。1. 漏洞原理推测错误利用链不成立。2. Payload被WAF或Tomcat内置过滤器拦截。3. 目标环境不存在该漏洞版本/配置不符。1.这是最可能的情况。需要回归到漏洞分析本身阅读补丁代码是唯一准确途径。2. 检查conf/web.xml中是否配置了filter尝试对Payload进行编码、分割等绕过测试。3. 确认Tomcat版本和配置完全符合漏洞条件。怀疑命令已执行但无法验证如/tmp/pwned.txt未创建。1. 命令执行权限不足Tomcat用户无权在/tmp写文件。2. 命令执行成功但进程被终止或输出被吞没。3. Payload中的命令语法错误如Windows/Linux命令混淆。1. 尝试更简单的验证方式如发起一个DNS查询或HTTP请求到可控服务器使用curl、wget或ping。2. 使用能产生明显网络侧或日志侧痕迹的命令如ping -c 4 your-attacker-ip并在攻击机用tcpdump抓包。3. 在Payload中尝试执行whoami /tmp/whoami.log并检查文件权限和内容。扫描器报告漏洞存在但手动无法复现。1. 扫描器存在误报。2. 扫描器检测的是其他间接特征如版本号而非真正的漏洞利用。3. 手动复现的Payload不够精确。1. 结合扫描器报告的具体信息如触发的URL、参数用Burp Suite手动重放并仔细分析响应。2. 验证Tomcat版本是否确实在受影响范围。3. 寻找公开的、经过验证的PoC代码进行对比。6.3 我的排查心得日志是你的第一手资料遇到任何问题首先查看catalina.out和localhost_access_log.*.txt。Tomcat的日志级别可以在conf/logging.properties中调整调试时可以将org.apache.catalina.core.ContainerBase.[Catalina].level设置为FINE或ALL以获得更详细的信息。二分法与最小化测试当复现过程复杂时采用二分法。先确保基础环境Tomcat启动、应用访问正常再逐步添加漏洞利用的条件。构造最简单的、能证明概念Proof of Concept的Payload而不是一开始就追求复杂的反弹Shell。理解漏洞的“触发条件”与“影响”有时候漏洞确实存在但你的测试环境不满足全部触发条件比如需要特定的web.xml配置、需要特定的JSP标签库。仔细阅读漏洞公告中的“Attack Vector”和“Prerequisites”。安全测试的边界始终在授权和隔离的环境中进行。记录你的每一步操作这不仅是为了回溯也是为了形成完整的测试报告。在尝试命令执行时优先使用无害命令进行验证。漏洞复现是一个需要耐心、细心和扎实基础的过程。每一次成功的复现不仅加深了对漏洞本身的理解更锻炼了在复杂系统中定位和解决问题的能力。对于CVE-2025-24813在官方未公布详细细节前我们的重点应放在及时升级和通用安全加固上。通过搭建环境、分析原理、尝试推演利用链你已经走完了一个安全研究员的标准流程这比单纯知道一个漏洞编号要有价值得多。