Tomcat AJP文件包含漏洞（CVE-2020-1938）原理、POC与实战防御

1. 项目概述从一次应急响应说起那天晚上我正在处理一个常规的日志分析突然接到一个电话语气很急。客户说他们的一个对外服务门户页面出现了异常部分页面加载出了本不该出现的后台配置文件内容。我第一时间远程连上去查看了Tomcat的访问日志和应用的错误日志并没有发现明显的Webshell上传或异常POST请求。问题显得有点诡异直到我仔细检查了Tomcat的server.xml配置并在AJP连接器的配置旁看到了一个不起眼的、被注释掉但参数值异常的secretRequired属性。那一刻我明白了我们遇到了那个经典的、但时常被忽略的Apache Tomcat AJP文件包含漏洞。攻击者并没有走HTTP端口而是利用了默认开启的8009端口上的AJP协议悄无声息地实现了对服务器上任意文件的读取。这个漏洞编号CVE-2020-1938也常被称为“幽灵猫”Ghostcat。它本质上不是传统Web应用层面的文件包含而是Tomcat作为一款应用服务器在其AJP协议处理模块中存在的一个缺陷。AJP协议主要用于Tomcat与前端的Web服务器如Apache HTTPD、Nginx进行高效通信。当攻击者能够访问到Tomcat的AJP服务端口默认8009时他可以构造恶意的AJP请求通过控制特定参数让Tomcat将Web应用目录之外的任意文件比如WEB-INF/web.xml或系统文件的内容包含到HTTP响应中返回。这对于攻击者来说相当于拿到了一把能读取服务器敏感信息的“万能钥匙”从数据库配置文件到源代码都可能暴露无遗。今天我就从一个防御者和研究者的双重角度带大家彻底拆解这个漏洞。我们不仅会深入其原理亲手编写一个用于安全测试的概念验证脚本更重要的是我会分享一套在企业真实环境中从发现、验证到彻底修复、防御的完整实战经验。无论你是安全运维人员、渗透测试工程师还是对Tomcat内部机制感兴趣的开发者这篇文章都将提供从理论到实操的深度视角。2. 漏洞原理深度剖析AJP协议中的“越界”读取要理解这个漏洞我们得先暂时抛开“文件包含”这个Web安全领域的常见术语深入到Tomcat的网络通信层去看。这更像是一个“协议实现缺陷”导致的信息泄露问题。2.1 AJP协议与请求走私AJP是一个二进制的、面向数据包的协议设计初衷是为了让Tomcat与前端Web服务器能更高效地通信避免HTTP协议的文本解析开销。一个正常的请求流程是用户 - HTTP服务器 - AJP协议 - Tomcat。HTTP服务器负责处理静态文件、负载均衡并将动态请求通过AJP转发给后端的Tomcat容器。在AJP协议中有一个非常重要的数据包类型叫做CPING/CPONG用于保活以及FORWARD_REQUEST用于转发请求。漏洞的关键在于处理FORWARD_REQUEST时对请求属性Request Attributes的处理逻辑。攻击者可以构造一个特殊的AJP请求在其中设置javax.servlet.include.request_uri、javax.servlet.include.path_info等属性。这些属性原本是用于服务器端包含SSI或转发时使用的内部调度标识。Tomcat在处理这些属性时没有充分校验其指向的路径是否在允许的范围内。当javax.servlet.include.request_uri属性被设置为/而javax.servlet.include.path_info属性被设置为一个像WEB-INF/web.xml这样的路径时Tomcat的错误逻辑会将其拼接并尝试将这个路径下的文件内容读取出来并放入HTTP响应体。关键在于这个路径解析过程绕过了应用本身的安全边界检查可以直接定位到Web应用根目录下的任何文件甚至通过目录遍历如../../../../etc/passwd尝试读取系统文件。注意能否读取系统文件取决于Tomcat进程的运行权限。以root权限运行的Tomcat风险极高。在实际测试中由于路径规范化处理直接穿越到根目录的成功率因版本和配置而异但读取WEB-INF下的应用敏感文件是普遍可行的。2.2 漏洞触发的核心条件这个漏洞的利用并非无条件的它需要几个关键环境要素同时满足Tomcat版本在影响范围内主要影响Apache Tomcat 6.x, 7.x 7.0.100, 8.x 8.5.51, 9.x 9.0.31。这些版本在AJP连接器处理相关属性时存在缺陷。AJP服务端口可被访问默认情况下Tomcat的AJP连接器在server.xml中配置监听8009端口并且绑定在0.0.0.0。如果服务器防火墙或安全组未对8009端口做访问限制使得该端口暴露在互联网或内部非信任网络那么漏洞就有了被利用的通道。存在可用的AJP连接器server.xml中必须启用了AJP连接器即相关配置未被注释。这是漏洞利用的必备组件。很多企业环境里Tomcat前面通常会有Nginx或Apache它们通过AJP与Tomcat通信。运维人员可能认为Tomcat本身不直接对外就安全了。但事实上如果网络分区不严格攻击者可能从内网其他位置直接访问到Tomcat的8009端口。“默认配置”和“内部服务不设防”的心态是此漏洞广泛存在的主要原因。3. POC工具编写实战从理解到实现作为一名安全从业者理解漏洞原理后我们往往需要编写或使用POC来验证漏洞是否存在。自己动手写一个简单的POC能极大地加深对漏洞细节的理解。下面我们用Python来实现一个针对此漏洞的验证脚本。3.1 环境准备与协议分析首先我们需要了解AJP协议的基本数据包结构。AJP数据包有一个小的包头包含长度和类型信息后面跟随着数据体。我们不需要完全实现所有AJP功能只需要能构造一个能触发漏洞的FORWARD_REQUEST包即可。关键步骤是设置那些恶意的请求属性。我们可以参考Tomcat的源码和公开的漏洞分析文章找到属性名的具体字节表示。这里我们采用一种更直接的方式使用现成的库来帮助我们处理AJP协议底层的字节序列。但为了彻底理解我们先手动构造核心部分。#!/usr/bin/env python3 Tomcat AJP 文件包含漏洞 (CVE-2020-1938) 简易POC验证脚本 仅用于授权安全测试请勿用于非法用途。 import socket import struct import sys def build_ajp_forward_request(host, port, req_uri, attributes): 构造一个AJP FORWARD_REQUEST 数据包。 这是一个高度简化的实现专注于演示漏洞利用的核心属性设置。 # AJP数据包前缀 magic 0x1234 # AJP魔术字实际上在真实通信中由前端服务器处理这里简化 # 我们跳过完整的AJP握手和前缀构造直接关注如何设置属性 # 实际利用中我们会使用更完整的库如python-ajp。这里展示核心思路 # 1. 建立TCP连接到目标Tomcat的8009端口。 # 2. 发送一个精心构造的AJP请求其中包含 # - 请求方法: GET # - 协议: HTTP/1.1 # - 请求URI: 设置为 / 或任意存在的路径用于通过基础校验 # - 请求属性: 添加 javax.servlet.include.request_uri 和 javax.servlet.include.path_info # 以下为伪代码逻辑真实实现需要处理AJP的二进制格式 print(f[*] 目标: {host}:{port}) print(f[*] 尝试读取文件: {req_uri}) # 实际代码会在这里进行socket连接、组包、发送、接收和解析响应 # 响应中如果包含目标文件内容则说明漏洞存在。 def test_vulnerability(target_host, target_port8009, file_to_read/WEB-INF/web.xml): 测试目标是否存在漏洞。 try: sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(10) sock.connect((target_host, target_port)) print(f[] 成功连接到AJP端口 {target_port}) # 这里应调用完整的build_ajp_forward_request并发送数据 # 为演示我们假设有一个函数send_ajp_exploit能完成攻击请求 # response send_ajp_exploit(sock, file_to_read) # 解析响应判断是否成功 # if ?xml in response or web-app in response: # print(f[!] 漏洞存在成功读取到 {file_to_read} 内容预览:) # print(response[:500]) # 打印前500字符 # return True # else: # print([-] 未检测到漏洞特征可能已修复或文件不存在。) # return False sock.close() except ConnectionRefusedError: print(f[-] 连接被拒绝目标 {target_host}:{target_port} 可能未开启AJP服务或网络不通。) return False except socket.timeout: print([-] 连接超时。) return False except Exception as e: print(f[-] 发生未知错误: {e}) return False # 示例中我们直接给出结论实际应取消注释上面的代码 print([*] 此为原理演示完整POC需实现AJP协议组包/解包。) print([*] 建议使用成熟的测试工具如 metasploit 模块或专门的exp脚本。) return None if __name__ __main__: if len(sys.argv) ! 2: print(f用法: {sys.argv[0]} 目标IP) sys.exit(1) target sys.argv[1] test_vulnerability(target)实操心得自己编写POC是学习漏洞最好的方式但对于AJP这种二进制协议从头实现解析成本较高。在实际工作中我通常会先使用成熟的工具如Metasploit中的auxiliary/admin/http/tomcat_ghostcat模块进行快速验证。自己编写POC的目的在于理解漏洞触发的精确字节流这对于编写WAF规则、入侵检测特征码至关重要。例如你需要知道恶意AJP请求中那些关键属性名和值的十六进制表示是什么。3.2 利用现有工具进行验证对于绝大多数安全测试场景我们不需要重复造轮子。使用经过社区验证的工具更高效、更稳定。以下是常用的验证和利用方法Nmap NSE脚本Nmap的http-tomcat-ghostcat脚本可以快速检测漏洞。nmap -p 8009 目标IP --script http-tomcat-ghostcat这个脚本会尝试读取/WEB-INF/web.xml并在结果中显示文件内容片段。Metasploit框架Metasploit提供了专业的利用模块。use auxiliary/admin/http/tomcat_ghostcat set RHOSTS 目标IP set RPORT 8009 run它可以指定要读取的文件路径输出也更规整。专门的Python EXP脚本GitHub上有很多开源的单文件EXP它们通常直接实现了完整的AJP协议交互使用起来比我们自己从头写方便得多。使用前务必审查代码。使用工具时的注意事项授权绝对只能在拥有明确书面授权的目标上进行测试。影响读取WEB-INF/web.xml或jar文件可能涉及应用敏感信息测试时应评估法律风险。网络可达性确保你的测试机可以访问到目标的8009端口。如果目标在云上安全组规则可能已屏蔽此端口。4. 企业级防御与修复方案验证漏洞存在只是第一步更重要的是如何修复和防御。修复方案需要根据实际环境分层、分级部署。4.1 紧急修复立竿见影的缓解措施如果发现线上系统存在此漏洞需要立即采取以下一种或多种措施升级Tomcat至安全版本这是最根本的解决方案。升级到Tomcat 7.0.100, 8.5.51, 9.0.31 或更高版本。这些版本在AJP连接器中修复了该缺陷。操作要点升级前务必在测试环境充分验证备份现有配置和Web应用。注意新版Tomcat可能对JDK版本有要求。禁用AJP连接器如果业务架构中Tomcat前面没有使用Apache HTTPD或Nginx通过mod_jk或mod_proxy_ajp模块进行连接那么AJP连接器很可能根本没用。可以直接在$CATALINA_HOME/conf/server.xml中找到如下配置并注释掉!-- 找到类似这行在Connector标签前加上注释 -- !-- Connector protocolAJP/1.3 address::1 port8009 redirectPort8443 / --修改后重启Tomcat服务。配置AJP连接器为仅监听本地如果必须使用AJP确保它只监听本地回环地址阻止外部直接访问。将address属性设置为127.0.0.1或::1。Connector protocolAJP/1.3 address127.0.0.1 port8009 redirectPort8443 /设置AJP认证为AJP连接器配置secretRequired和secret属性启用共享密钥认证。只有知道密钥的前端服务器才能连接。这是官方推荐的加固方式。Connector protocolAJP/1.3 address127.0.0.1 port8009 redirectPort8443 secretRequiredtrue secretYourStrongSecretStringHere /重要提示在前端Web服务器如Apache的mod_jk配置中也必须设置相同的密钥。密钥需要足够复杂并定期更换。网络层访问控制在防火墙或安全组策略中严格限制对Tomcat服务器8009端口的访问。只允许前端Web服务器如Nginx/Apache所在IP的IP地址访问该端口。这是纵深防御中非常有效的一环。4.2 常态化防御构建安全运维体系单点修复容易难的是建立持续的防御能力。以下措施应纳入日常安全运维资产与漏洞管理建立完善的资产清单记录所有Tomcat实例的版本、端口、配置。定期如每月使用漏洞扫描器或专门的Tomcat漏洞检测脚本进行扫描。将CVE-2020-1938这类高危漏洞的检测固化为上线前和周期性检查的必选项。最小权限原则永远不要使用root用户运行Tomcat。创建一个专用的、低权限的系统用户来运行Tomcat服务。这可以极大限制即使漏洞被利用攻击者能读取的系统文件范围。使用容器化部署时也要遵循此原则。配置安全基线制定Tomcat安全配置基线并定期审计。基线应包括禁用不必要的管理接口和示例应用。确保server.xml中所有对外Connector的address绑定非0.0.0.0除非必要。日志记录完整并监控异常访问模式。文件系统权限严格控制Web应用目录不应有执行权限。入侵检测与监控在网络层部署IDS/IPS并更新规则以检测针对AJP端口8009的异常流量。在主机层监控Tomcat进程对敏感文件如/etc/passwd,WEB-INF/下的文件的读取行为。任何对WEB-INF/web.xml的非正常HTTP/AJP请求都应产生高优先级告警。WAF规则更新如果企业部署了Web应用防火墙应联系供应商或自行添加针对CVE-2020-1938的虚拟补丁规则。规则应能识别并阻断包含恶意javax.servlet.include.*属性的AJP请求。5. 漏洞排查与应急响应实录当怀疑或确认漏洞已被利用时有序的应急响应至关重要。以下是我根据多次实战总结的排查清单5.1 入侵迹象排查检查网络连接立即检查Tomcat服务器上8009端口的网络连接情况。使用netstat -antp | grep :8009命令查看是否有异常的外部IP连接。与你的前端服务器IP列表进行比对。审查Tomcat访问日志AJP请求默认不会记录在Tomcat的localhost_access_log中那是HTTP访问日志。你需要检查AJP连接器是否配置了独立的访问日志或者查看前端Web服务器如Nginx/Apache的转发日志。如果没有日志这是一个巨大的盲点应立刻补上。审查系统日志和文件变动检查/var/log/messages、dmesg以及Web应用目录下文件特别是WEB-INF/和META-INF/的创建、修改时间。攻击者读取配置文件后下一步可能就是利用其中的信息如数据库密码进行横向移动或上传Webshell。检查是否有后门使用find命令结合webshell特征码扫描工具检查Web目录下是否有可疑的jsp、jspx文件。重点关注最近修改的文件。5.2 应急响应步骤隔离如果确认被入侵立即将受影响服务器从网络中断开拔网线或修改安全组防止攻击者持续访问或进行横向渗透。取证在隔离后对系统内存、磁盘进行镜像备份以备后续法律取证和深度分析。记录下所有排查命令的输出结果。消除影响重置密码立即重置从可能被读取的配置文件中泄露的所有密码包括数据库、中间件、第三方服务等。评估信息泄露范围根据攻击者可能读取的文件评估泄露了哪些敏感数据客户信息、源码、密钥等并按照法律法规和公司政策启动数据泄露应急预案。修复漏洞按照前述“紧急修复”方案立即升级或修改配置。恢复与加固从干净的备份恢复应用和数据或在修复漏洞后重新部署应用。部署后务必实施“常态化防御”中的所有加固措施。复盘事后必须进行复盘回答几个关键问题漏洞为什么存在这么久为什么监控没发现响应流程是否顺畅如何避免类似问题5.3 常见问题与误区误区一“我们用了Nginx反代所以Tomcat的8009端口没暴露”这是最危险的误解。Nginx反代HTTP流量默认8080端口与AJP服务8009端口是两回事。除非你在Nginx上配置了stream模块来代理AJP协议极少见否则8009端口依然独立监听。必须检查网络拓扑和防火墙规则。误区二“升级到最新版就绝对安全了”升级修复了已知漏洞但安全是一个持续的过程。新版本可能有新漏洞错误的配置如弱AJP密钥、过宽的文件权限会引入新的风险。问题内网多个Tomcat如何批量检测和修复可以使用Ansible、SaltStack等配置管理工具编写剧本批量执行以下任务1) 检查Tomcat版本和server.xml配置2) 分发修复后的配置文件或执行升级命令3) 重启服务。务必先在测试环境验证剧本。问题AJP连接器配置了secretRequired但前端服务器忘了配密钥导致服务不可用这是修复过程中常见的业务中断问题。修复动作必须在变更窗口进行并提前准备好回滚方案。先在前端服务器配置好密钥再重启Tomcat启用secretRequired。安全防御从来不是一劳永逸的它是一场攻防双方在技术、流程和意识上的持续较量。像Tomcat Ghostcat这样的漏洞之所以能造成广泛影响往往不是因为技术有多高深而是出于对“默认配置”的信任和对“内部服务”的忽视。真正的安全始于对每一个细节的审视成于一套严谨的运维体系。希望这次深入的拆解不仅能帮你解决一个具体的漏洞更能启发你构建起更稳固的防御 mindset。