记Log4j(CVE-2021-44228)核弹级漏洞应急响应之旅

可能大家都知道了Log4j的远程代码执行漏洞（ CVE-2021-44228），又造成了很多安全运维和开发团队的不眠之夜。下面是参加此次应急响应的过程，简单写下来，以供将来改善。

收到此漏洞之后，公司的团队做了以下紧急安排：

首先，联系Blue Team，根据攻击特征制定相应的防火墙规则，先挡一阵子。事实证明也只能挡一阵子，很快各种绕过就出来了，例如：https://github.com/SecuProject/Pentest-Cheat-Sheet/blob/master/Discovery/HTTP-HTTPS/WebAttacks/CVE/Log4shell.md

不过，虽然有各种绕过，还是可以更新规则，继续挡住。这个时候blue team及时检测并且适时更改规则，非常重要。 

其次，使用购买的SCA工具快速扫描公司内部所有的Repo，得到所有的收到影响的项目列表，如果没有购买SCA工具，针对java的也可以使用OWASP 的DependencyChecker，并且根据是否对外开放的项目进行分开，优先处理对外开放的项目；

同时，有安全开发团队的人及时跟进根据漏洞的产生的原因，提供合理的解决方案；也调查收到log4j影响的库或者工具，例如：logstash 也收到影响， Logstash is vulnerable due to log4j CVE-2021-44228 · Issue #13501 · elastic/logstash · GitHubHi Elastic, A 0-day exploit CVE-2021-44228 in log4j package has been published and all Logstash versions 7.x are affected by a vulnerable version. Vulnerability: apache/logging-log4j2#608 Please look at it and advice on the best course o...https://github.com/elastic/logstash/issues/13501；

接着，根据每个项目预留的负责人，及时联系说明情况，同时在内部bug管理系统针对每一个项目报一个安全的ticket，在ticket里把漏洞的情况和解决方案一一说明清楚，同时在所有的ticket都挂在一个总的ticket下面，这样有利于跟踪；这一步很重要，但是如果有些公司平时没有注意维护好这样一个联系人列表的话，可能就很痛苦了，所以，要想应急做得好，平时就必须要把所有的准备工作准备到位，准备工作包括：流程、工具和联系人。

然后，就是及时跟开发团队保持沟通，跟踪解决状况，及时关闭ticket，并查阅总的ticket的状态是否子ticket解决了。

最后，经过几天的努力终于所有的受影响的项目的都安全地解决并且deploy到产品线上。

终于可以睡一个好觉了！ 

此漏洞log4j的1.x版本并未受影响，遇到如此的漏洞，有时在想，对于第三方开源库的使用上，是不是一定要跟进使用最新的版本呢？ 不过，一般新版本的功能都会更加全面，而且，也会修复一些旧版本中的安全问题，所以，该使用新的还是要继续使用，不能因为一两次的0day漏洞对新版本持怀疑态度。

后记： 在将补丁升级到2.15.0之后，log4j又陆续出了两个版本，2.16.0和2.17.0，有点跟不上的节奏，而且开发在连续打补丁也会有受挫感。 还好这次有人出了一个工具【https://github.com/logpresso/CVE-2021-44228-Scanner】将jndi的lookup的类直接删除，以绝后患。 这次采取的措施是：将log4j直接升级到2.17.0同时使用工具将jndi的lookup类删掉。