Iog4j2漏洞相關技術分析

背景
2021年12月初，極光安全團隊通過安全威脅輿情發現Apache Log4j2 存在遠程代碼執行漏洞，迅速對該漏洞危害性評估和涉及面漏斗分析，制定了應急響應方案，對涉及到的代碼組件類和主機資產類快速整理，外部安全掃描對該漏洞進行優先級掃描，避免威脅進一步擴大和阻斷，對內推動該漏洞版本組件的修復進度，持續關注該漏洞組件的後續發展。
本文通過構造環境復現漏洞，瞭解這個漏洞產生的原因，分析修復漏洞方法，研究學習背後的相關技術。
漏洞影響
Log4j2作爲java代碼項目中廣泛使用的開源日誌組件，漏洞影響範圍極廣，堪稱史詩級、核彈級漏洞。
直接和間接依賴Log4j2的開源組件總計有17萬個，也就是說有至少17萬個開源組件是受Log4j2漏洞影響GitHub作爲全球最大的開源代碼託管平臺，抽樣分析發現至少5.8%的java開源項目受該漏洞影響
在java語言的開源組件流行度排行中，Log4j2列第13位
漏洞復現
利用漏洞攻擊過程

復現代碼
github地址https://github.com/zheng93775/log4j2-attack 按照README.md裏面的步驟可以完整運行整個流程模塊說明

模塊說明

business-app 正常的業務應用
marshalsec 攻擊方搭建，用於啓動LDAP服務的開源工具
evil-http-server 攻擊方搭建，啓動Http服務，提供惡意代碼下載
evil-http-server
首先我們準備一個含有惡意執行代碼的類，惡意代碼執行時會在Windows下啓動計算器

使用SpringMVC的Controller，http請求返回的相應是惡意類的二進制字節碼

編譯後，啓動服務，監聽9090端口

marshalsec
marshalsec是一款開源的工具，可以用於快速啓動LDAP服務github地址：https://github.com/mbechler/marshalsec
首先編譯項目，然後運行jar啓動LDAP服務

business-app
business-app代表正常的業務方java應用，爲了方便復現，跳過正常http服務請求過程，啓動後直接記錄日誌

符合漏洞條件的Windows系統環境下運行Main.java，就會成功打開計算器

相關技術
JNDI
什麼是JNDI
JNDI 全稱爲 Java Naming and Directory Interface，即 Java 名稱與目錄服務接口。是SUN公司提供的一種標準的Java命名系統接口，在J2EE規範中是重要的規範之一。JNDI提供統一的客戶端API，爲開發人員提供了查找和訪問各種命名和目錄服務的通用、統一的接口。
JNDI中的命名（Naming），就是將Java對象以某個名稱的形式綁定（binding）到一個容器環境（Context）中，以後調用容器環境（Context）的查找（lookup）方法就可以查找出某個名稱所綁定的Java對象。

JNDI架構
JNDI 架構上主要包含兩個部分，Java 的應用層接口和 SPI。

SPI 全稱爲 Service Provider Interface，即服務供應接口，主要作用是爲底層的具體目錄服務提供統一接口，從而實現目錄服務的可插拔式安裝。在 JDK 中包含了RMI、LDAP、CORBA等內置的目錄服務
爲什麼要用JNDI
JNDI是java語言產生漏洞的一個比較大的因素，我們平時在業務開發中基本沒有使用到，那麼爲什麼log4j2的代碼要支持jndi呢？

1.JNDI 提出的目的是爲了解耦，是爲了開發更加容易維護，容易擴展，容易部署的應用。
2.JNDI 是一個Sun提出的一個規範(類似於JDBC)，具體的實現是各個廠商實現的，可以看出，老外還是非常認可這個規範，很多地方做了很多解耦的設計，包括Log4J。
3.JNDI 在J2EE系統中的角色是“交換機”，是J2EE組件在運行時間接地查找其他組件、資源或服務的通用機制。
4.JNDI 是通過資源的名字來查找的，資源的名字在整個J2EE應用中是唯一的。
除了Log4j，還有很多組件用了JNDI，比如：Hibernate、JTA、Tomcat、WebLogic、WebSphere
LDAP
全稱爲 Lightweight Directory Access Protocol，即輕量級目錄訪問協議。
LDAP是開放的Internet標準，支持跨平臺的Internet協議，在業界中得到廣泛認可的，並且市場上或者開源社區上的大多產品都加入了對LDAP的支持，因此對於這類系統，不需單獨定製，只需要通過LDAP做簡單的配置就可以與服務器做認證交互。
修復漏洞方法分析
升級log4j2
log4j漏洞受影響的版本爲2.0至2.15.0.rc1，建議升級至2.17.0及以上正式版本

2.15.0.rc1
漏洞爆出的當天，2.15.0.rc1修復版本就出來了。JndiManager.lookup方法進行了修改，增加了白名單校驗，但是代碼有個問題，catch住異常後代碼仍然可以往下執行，攻擊者在${jndi}的地址中增加一個空格就可以觸發URISyntaxException，繞過白名單校驗。

2.15.0.rc2
這個版本解決了rc1的問題

雖然也有爆出漏洞，但是條件比較苛刻，能利用的可能性很小，還是比較安全的。如果已經升到2.15.0，應用本身不直接對外網提供服務，也可以選擇不升級到更新版本。
在某些非默認配置中，發現Apache Log4j 2.15.0中解決CVE-2021-44228的修復是不完整的。這可能允許攻擊者控制線程上下文映射(MDC)輸入數據，當日志記錄配置使用非默認的模式佈局，使用上下文查找(例
如，$${ctx:loginId})或線程上下文映射模式(%X， % MDC，或%MDC)，使用JNDI查找模式生成惡意的輸入數據，從而導致拒絕服務(DOS)攻擊。

引文：https://github.com/cckuailong/Log4j_CVE-2021-45046
2.16.0
更新內容如下
默認禁用JNDI的訪問，用戶需要通過配置log4j2.enableJndi參數開啓
默認允許協議限制爲：java、ldap、ldaps，並將ldap協議限制爲僅可訪問Java原始對象Message Lookups被完全移除，加固漏洞的防禦
JNDI遠程執行漏洞被徹底封死了，但是還有拒絕服務漏洞
Apache官方發佈了Apache Log4j 拒絕服務攻擊漏洞（CVE-2021-45105），此漏洞需要在非默認配置下才能觸發。當系統日誌配置使用帶有Context Lookups的非默認 Pattern Layout（例如$${ctx:loginId}）時，攻擊者可構造包含遞歸查找的惡意輸入數據，成功利用此漏洞將觸發無限循環，導致系統崩潰。
這個漏洞首要前提條件比較苛刻，已經升級到2.16.0的可以選擇不升級到更新版本
升級JDK小版本
升級 jdk 版本至 6u211 / 7u201 / 8u191 / 11.0.1 以上，可以在一定程度上限制 JNDI 等漏洞利用方式。JDK高版本有什麼不同呢
高版本增加了一個變量com.sun.jndi.ldap.object.trustURLCodebase，這個變量的值默認爲false。除非我們加入如下代碼手動複製爲true，纔可以在高版本復現漏洞。

JDK高版本也存在漏洞
繞過方式：LDAP服務Codebase不返回地址，而是返回一個本地已有的Factory類，通過Factory類創建指定參數的實例實現攻擊。比如Tomcat中存在的org.apache.naming.factory.BeanFactory。LDAP返回示例如下

通過配置關閉log4j的jndi查找功能
有以下幾種方式
設置 jvm 參數 “-Dlog4j2.formatMsgNoLookups=true
在項目 classpath 目錄下添加 log4j2.component.properties 配置文件，設置 log4j2. formatMsgNoLookups=true
設置系統環境變量：“LOG4J_FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS” 設置爲 “true” 注意，由於這個配置項的判斷邏輯是2.10版本才加上的，這種方式對於2.0 <= log4j版本 < 2.10無效

刪除log4j-core-2.x.jar中的JndiLookup類
在以前的版本(<2.16.0)中，可以通過從類路徑中刪除JndiLookup類來緩解這個問題。不建議使用這種方式，某些特殊項目不便升級log4j的情況下可以考慮。

fastjson漏洞分析
2019年fastjson被爆出遠程代碼執行漏洞，當時國內使用了fastjson的項目非常多，影響面也非常廣，並且漏洞的修復持續了N個版本。那麼，fastjson具體是存在什麼漏洞呢？
漏洞和fastjson中的一個AutoType特性，我們先來看看AutoType是什麼。
AutoType
來看一個示例