大家好，我是周杰伦。相信大家这两天应该都被这样一则新闻刷屏过：这个漏洞是怎么回事？核弹级别，真的有那么厉害吗？如何利用这个漏洞？看了很多技术分析文章，都太专业了。很多没有Java技术栈或者不搞安全的人只能略读，所以大家只能看热闹。该漏洞的产生原因、原理、利用方法、影响面了解不到位。在这篇文章中，我试图让所有与技术相关的朋友们明白：这个注定要被载入网络安全史册的漏洞到底是怎么回事！不管log4j2是什么编程语言，无论是前端、后端还是客户端，对日志记录都不陌生。通过日志，可以帮助我们了解程序的运行状态，排查程序运行过程中出现的问题。在Java技术栈中，比较常用的日志输出框架主要有log4j2和logback。今天讨论的主角是log4j2。我们经常会在日志中输出一些变量，比如：logger.info("clientip:{}",clientIp)现在想一个问题：如果想通过日志输出一个Java对象，但是这个对象不在程序，如果它在其他地方怎么办，可能在文件中，甚至可能在网络上的某个地方？log4j2的强大之处在于，除了在程序中输出变量外，它还提供了一个叫做Lookup的东西，可以用来输出更多的内容：lookup，顾名思义，就是查找、查找的意思。在log4j2中，允许在输出日志的时候，通过一些方法找到要输出的内容。Lookup相当于一个接口。在哪里查找，如何查找，需要自己写一个具体的模块来实现，这类似于面向对象编程中多态的意思。好在log4j2已经帮我们实现了常用的查找方法：各个的具体含义这里不再详述，这不是本文的重点。JNDI主要看这个叫JNDI的东西：JNDI是Java命名和目录接口（JAVANamingandDirectoryInterface），它提供了一个目录系统，将服务名和对象关联起来，方便开发者在开发过程中使用。使用名称访问对象。无法阅读？就是不明白！简单粗略的理解：有一个类似字典的数据源，你可以通过JNDI接口传入一个名字，就可以得到对象。不同的数据源必然有不同的查找方式，所以JNDI只是一个上层包，它还支持很多特定的数据源。LDAP继续关注，我们就来看看这个叫LDAP的东西吧。LDAP代表轻量级目录访问协议（LightweightDirectoryAccessProtocol）。名录是为查询、浏览和搜索而优化的专业分布式数据库。它以树状结构组织数据，就像Linux/Unix系统中的文件一样目录。与关系型数据库不同，目录型数据库读取性能优异，但写入性能较差，不具备事务处理、回滚等复杂功能，不适合存储频繁修改的数据。所以目录就是为查询而生的，就像它的名字一样。无法阅读？就是不明白！这个东西在统一身份认证领域用的比较多，不过不是今天本文的重点。你只需要简单粗略的了解一下：有一个类似字典的数据源，你可以通过LDAP协议向其中传入一个名字来获取数据。漏洞的原理是好的。有了上面的基础，就很容易理解这个漏洞了。如果在某个Java程序中，log中记录了浏览器的类型：StringuserAgent=request.getHeader("User-Agent");logger.info(userAgent);网络安全有一条规则：不要相信用户输入的任何信息。其中，User-Agent属于外界输入的信息，而不是自己程序中定义的。只要是外界输入的，就可能存在恶意内容。如果有人发送HTTP请求，他的User-Agent就是这样一个字符串：${jndi:ldap://127.0.0.1/exploit}接下来，log4j2会解析这一行要输出的字符串。首先，它在字符串中找到了${}，知道里面包裹的内容要单独处理。进一步分析，发现是JNDI扩展内容。进一步分析发现是LDAP协议，LDAP服务器地址为127.0.0.1，查找key为exploit。最后调用负责LDAP的模块请求相应的数据。如果你只是请求普通的数据，那还好，但问题是你也可以请求Java对象！Java对象一般只存在于内存中，但也可以通过序列化的方式存储在文件中，或者通过网络传输。如果是自定义的序列化方式还好，但更危险的是：JNDI还支持一种叫做NamingReferences的方式，可以远程下载一个类文件，下载完之后再加载构建对象。PS：有时候Java对象比较大，直接通过LDAP存储不方便。它类似于二次跳跃。它不直接返回对象内容，而是告诉你这个对象在哪个类，让你去那里。尝试去找。注意这里是核心问题：JNDI可以远程下载类文件构建对象！！！.危险在哪里？如果远程下载地址指向黑客的服务器，下载的类文件中包含恶意代码，那岂不是完蛋了？还没看懂？没关系，我画了一张图：这就是著名的JNDI注入攻击！其实除了LDAP，还有RMI的方式，有兴趣的可以了解一下。其实这次并没有出现JNDI注入。早在2016年黑帽大会上，就有大佬公开了这种攻击方式。回过头来看，问题的核心在于：Java允许通过JNDI远程下载一个class文件来加载对象。大问题！在前面的例子中，已经用127.0.0.1替换了LDAP服务器地址，那么如果输入的User-Agent字符串不是这个地址，而是一个恶意的服务器地址怎么办？影响规模这个漏洞的影响之所以这么大，是因为log4j2的使用范围太广了。一方面，Java技术栈现在广泛应用于Web、后端开发、大数据等领域。除了阿里巴巴、京东、美团等以Java为主要技术栈的企业外，选择Java的中小企业也不在少数。另一方面，用Java语言开发的kafka、elasticsearch、flink等中间件非常多。在上述开发过程中大量使用了log4j2作为日志输出。只要一不小心，输出的日志和外部输入混在一起，直接就是远程代码执行RCE，那就是灾难！修复新版log4j2已经解决了这个问题，大家赶紧升级吧。以下是log4j2官网JNDIlookup的说明：通过搜索引擎找到了12月10日之前的缓存快照。让我们比较一下。和下面的缓存相比，上面的版本多了什么？答案是：修复后的log4j2在JNDI查找中增加了很多限制：答案是：修复后的log4j2在JNDI查找中增加了很多限制：默认不再支持二次跳转的方式（即命名引用)获取的对象只能获取log4j2.allowedLdapClasses列表中指定的类。只有远程地址是本地地址或者log4j2.allowedLdapHosts列表中指定的地址才能获得以上限制，彻底阻断了通过打印日志的方式远程加载类。最后，各位手机前的Java小伙伴们，你们写的程序中是否使用了log4j2？有没有什么地方有输出，有没有混入外部参数？现在检查一下！另外，想要自行复现此漏洞的同学，可获赠漏洞复现、修复材料、代码工具一份。点击下方传送门免费领取【漏洞复现、修复资料、代码工具】大家了解这个漏洞吗？如果觉得文笔还不错，欢迎分享转发，顺便给个赞，谢谢阅读。
