前言 漏洞描述
Apache Log4j2是一款優秀的Java日志框架。2021年11月24日，阿里雲安全團隊向Apache官方報告了Apache Log4j2遠程代碼執行漏洞。由於Apache Log4j2某些功能存在遞歸解析功能，攻擊者可直接構造惡意請求，觸發遠程代碼執行漏洞。漏洞利用無需特殊配置，經阿里雲安全團隊驗證，Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影響。阿里雲應急響應中心提醒 Apache Log4j2 用戶盡快采取安全措施阻止漏洞攻擊。
12 月 10 日凌晨，Apache 開源項目 Log4j 的遠程代碼執行漏洞細節被公開，由於 Log4j 的廣泛使用，該漏洞一旦被攻擊者利用會造成嚴重危害。據悉，Apache Log4j 2.x <= 2.14.1 版本均回會受到影響。可能的受影響應用包括但不限於：Spring-Boot-strater-log4j2、Apache Struts2、Apache Solr、Apache Flink、Apache Druid、Elasticsearch、Flume、Dubbo、Redis、Logstash、Kafka 等。很多互聯網企業都連夜做了應急措施。截至本文發出，斗魚、京東、網易、深信服和汽車產業安全應急響應中心皆發文表示，鑒於該漏洞影響范圍比較大，業務自查及升級修復需要一定時間，暫不接收 Log4j2 相關的遠程代碼執行漏洞。
一、lookup 功能造成的漏洞
Log4j 是一款開源 Java 日志記錄工具。日志記錄主要用來監視代碼中變量的變化情況，周期性的記錄到文件中供其他應用進行統計分析工作；跟蹤代碼運行時軌跡，作為日后審計的依據；擔當集成開發環境中的調試器的作用，向文件或控制台打印代碼的調試信息。因此，對於程序員來說，日志記錄非常重要。在強調可重用組件開發的今天，Apache 提供的強有力的日志操作包 Log4j。Log4j 可以輕松控制 log 信息是否顯示、log 信息的輸出端類型、輸出方式、輸出格式，更加細致地控制日志的生成過程，而其通過配置文件可以靈活地進行配置而不需要大量的更改代碼。因此，很多互聯網企業都選擇使用 Log4j 。
2014 年，Log4j 2 發布。Log4j 2 是對 Log4j 的重大升級，完全重寫了 log4j 的日志實現。Log4j 2 提供了 Logback 中可用的許多改進，同時修復了 Logback 架構中的一些固有問題，目前已經更新到 2.15.0 版本。Log4j2 也支持 SLF4J，可以自動重新加載日志配置，並支持高級過濾選項。此外它還允許基於 lambda 表達式對日志語句進行延遲評估，為低延遲系統提供異步記錄器，並提供無垃圾模式以避免由垃圾收集器操作引起的任何延遲。通過其他語言接口，企業也可以在 C、C++、.Net、PL/SQL 程序中使用 Log4j。
此次漏洞的出現，正是由用於 Log4j 2 提供的 lookup 功能造成的，該功能允許開發者通過一些協議去讀取相應環境中的配置。但在實現的過程中，並未對輸入進行嚴格的判斷，從而造成漏洞的發生。簡單來說，就是在打印日志時，如果發現日志內容中包含關鍵詞 ${，那么這個里面包含的內容會當做變量來進行替換，導致攻擊者可以任意執行命令。詳細漏洞披露可查看：https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-3201?filter=allissues 。由於線上 web 業務的任何數據都可能寫入 Log4j，甚至一些 pre-auth 的地方，比如注冊、登錄，實際攻擊入口取決於業務具體情況。目前百度搜索、蘋果 iCloud 搜索、360 搜索等都出現了該問題。
12 月 10 日上午，阿里雲安全團隊再次發出預警，發現 Apache Log4j 2.15.0-rc1 版本存在漏洞繞過，建議及時更新至 Apache Log4j 2.15.0-rc2 版本。對於這次漏洞，有網友評價說道，“可以說是災難性的漏洞，比之前的 fastjson 和 shiro 還要嚴重，這個漏洞估計在之后三四年內還會繼續存在….”
二、快速檢測及修復方案
針對此次漏洞的一些應急方案。
1. 緊急緩解措施
（1）修改 jvm 參數 -Dlog4j2.formatMsgNoLookups=true
（2）修改配置 log4j2.formatMsgNoLookups=True
（3）將系統環境變量 FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS 設置為 true
2. 檢測方案
（1）由於攻擊者在攻擊過程中可能使用 DNSLog 進行漏洞探測，建議企業可以通過流量監測設備監控是否有相關 DNSLog 域名的請求，微步在線的 OneDNS 也已經識別主流 DNSLog 域名並支持攔截。
（2）根據目前微步在線對於此類漏洞的研究積累，我們建議企業可以通過監測相關流量或者日志中是否存在“jndi:ldap://”、“jndi:rmi”等字符來發現可能的攻擊行為。
3. 修復方案
檢查所有使用了 Log4j 組件的系統，官方修復鏈接如下：https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2
其它方案：
（1） jdk 1.6 無官方平滑升級修復版本，需要自行升級jdk到1.8在升級log4j 到2.17.0 或者 使用logback替換log4j
（2）jdk 1.7 log4j 2.x 相關jar包全家桶 統一升級到 2.12.1 (官方最后一個支持1.7的版本)，並配置JVM啟動參數 -Dlog4j2.formatMsgNoLookups=true 。或logger初始化之前加入代碼
System.setProperty("log4j2.formatMsgNoLookups", "true");
（3）jdk 1.8 相關jar包升級到2.17.0即可
另外注意幾點，
1、 最好要檢查一下編譯后的war包，確認一下，是否有相關依賴，是否有傳遞依賴間接依賴引入，這時需要在pom中排除間接依賴
2、兩個jar的相關引用版本可能需要一並升級
3、打包部署完后，確認一下日志是否在正常輸出
4、沒有使用log4j2，但是間接引入log4j-api 和 log4j-core 2.x，也存在漏洞
5、只有log4j-api 2.x，沒有log4j-core 2.x，不用升級，但需要確認編譯的包里沒有log4j-core 2.x 不僅是在pom里確認
6、2.15.0 版本默認打開-Dlog4j2.formatMsgNoLookups=true 不需要在jvm加了
7、針對ES、Hive、Flink等三方中間件，目前官方還沒有fix版本，暫只能先加上-Dlog4j2.formatMsgNoLookups=true
三、安全應該是一個持續的過程
雖然大家知道安全的重要性，但安全問題還是頻繁發生。
去年 5 月，360 網絡安全響應中心發布“ Fastjson 遠程代碼執行漏洞通告”。通告稱，Java 庫 fastjson <= 1.2.68 版本存在遠程代碼執行漏洞，漏洞被利用可直接獲取服務器權限。該漏洞評定為“高危漏洞”，影響面“廣泛”。 前年，阿里雲應急響應中心監測到，Apach Shiro 官方披露了其 cookie 持久化參數 rememberMe 加密算法存在漏洞，攻擊者利用 Padding Oracle 攻擊手段可構造惡意的 rememberMe 值，繞過加密算法驗證，執行 java 反序列化操作，最終可導致遠程命令執行獲取服務器權限，風險極大。
安全本身並不是一個能夠創造價值的功能，反而更像是需要消耗價值以確保功能穩定的功能。中小企業常常沒有足夠的資金投入安全建設，而有資金的企業也會把這部分預算將到最低。
網絡攻擊成功的可能性以及潛在損失的程度是難以實現估計的，決策者通常是依靠經驗判斷來做決定投入金額。根據 Alex Blau 在哈佛商業評論中的文章中提到的，決策者在作出決定時，會有一下三個誤區：
- 將網絡安全視為一種防御。在這個過程中，強大的防火牆和有能力的工程師可以讓他們遠離威脅。
- 認為遵守 NIST 或 FISMA 等安全框架就足夠安全。
- 以為如果近期沒有發生安全漏洞，那么看起來沒有問題的部分就不需要修復。
這些想法的問題在於，網絡安全不是要解決有限的問題，而應該是一個持續進行的過程。麻省理工學院數字經濟倡議主任 Erik Brynjolfsson 表示，對抗網絡威脅應該被歸到“更高級別的優先考慮項”。他認為，一些修復並不復雜。雖然增加一些額外的小操作會讓整個流程變長，並增加一點成本，但會讓企業和個人更加安全。
Brynjolfsson 提出，在網絡安全方面，使用公開可用的密碼學通常比為特定公司構建的專有系統更加安全。