大家好，我是周杰倫。
相信大家這兩天應該被這麼一條新聞刷屏了：
這個漏洞到底是怎麼回事？
核彈級，真的有那麼厲害嗎？
怎麼利用這個漏洞呢？
我看了很多技術分析文章，都太過專業，很多非Java技術棧或者不搞安全的人只能看個一知半解，導致大家只能看個熱鬧，對這個漏洞的成因、原理、利用方式、影響面理解的不到位。
這篇文章，我嘗試讓所有技術相關的朋友都能看懂：這個註定會載入網路安全史冊上的漏洞，到底是怎麼一回事！
log4j2
不管是什麼程式語言，不管是前端後端還是客戶端，對打日誌都不會陌生。
通過日誌，可以幫助我們瞭解程式的執行情況，排查程式執行中出現的問題。
在Java技術棧中，用的比較多的日誌輸出框架主要是log4j2和logback。
今天討論的主角就是log4j2。
我們經常會在日誌中輸出一些變數，比如：
logger.info("client ip: {}", clientIp)現在思考一個問題：
假如現在想要通過日誌輸出一個Java物件，但這個物件不在程式中，而是在其他地方，比如可能在某個檔案中，甚至可能在網路上的某個地方，這種時候怎麼辦呢？
log4j2的強大之處在於，除了可以輸出程式中的變數，它還提供了一個叫Lookup的東西，可以用來輸出更多內容：
lookup，顧名思義就是查詢、搜尋的意思，那在log4j2中，就是允許在輸出日誌的時候，通過某種方式去查詢要輸出的內容。
lookup相當於是一個介面，具體去哪裡查詢，怎麼查詢，就需要編寫具體的模組去實現了，類似於物件導向程式設計中多型那意思。
好在，log4j2已經幫我們把常見的查詢途徑都進行實現了：
具體每一個的意思，這裡就不詳述了，這不是本文的重點。
JNDI
主要來看其中那個叫JNDI的東西：
JNDI即Java Naming and Directory Interface（JAVA命名和目錄介面），它提供一個目錄系統，並將服務名稱與物件關聯起來，從而使得開發人員在開發過程中可以使用名稱來訪問物件。看不懂？看不懂就對了！
簡單粗暴理解：有一個類似於字典的資料來源，你可以通過JNDI介面，傳一個name進去，就能獲取到物件了。
那不同的資料來源肯定有不同的查詢方式，所以JNDI也只是一個上層封裝，在它下面也支援很多種具體的資料來源。
LDAP
繼續把目光聚焦，我們們只看這個叫LDAP的東西。
LDAP即Lightweight Directory Access Protocol（輕量級目錄訪問協議），目錄是一個為查詢、瀏覽和搜尋而優化的專業分散式資料庫，它呈樹狀結構組織資料，就好象Linux/Unix系統中的檔案目錄一樣。目錄資料庫和關聯式資料庫不同，它有優異的讀效能，但寫效能差，並且沒有事務處理、回滾等複雜功能，不適於儲存修改頻繁的資料。所以目錄天生是用來查詢的，就好像它的名字一樣。看不懂？看不懂就對了！
這個東西用在統一身份認證領域比較多，但今天也不是這篇文章的重點。你只需要簡單粗暴理解：有一個類似於字典的資料來源，你可以通過LDAP協議，傳一個name進去，就能獲取到資料。
漏洞原理
好了，有了以上的基礎，再來理解這個漏洞就很容易了。
假如某一個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檔案，然後下載後載入起來構建物件。
PS：有時候Java物件比較大，直接通過LDAP這些儲存不方便，就整了個類似於二次跳轉的意思，不直接返回物件內容，而是告訴你物件在哪個class裡，讓你去那裡找。
注意，這裡就是核心問題了：JNDI可以遠端下載class檔案來構建物件！！！。
危險在哪裡？
如果遠端下載的URL指向的是一個黑客的伺服器，並且下載的class檔案裡面藏有惡意程式碼，那不就完犢子了嗎？
還沒看懂？沒關係，我畫了一張圖：
這就是鼎鼎大名的JNDI注入攻擊！
其實除了LDAP，還有RMI的方式，有興趣的可以瞭解下。
JNDI 注入
其實這種攻擊手法不是這一次出現了，早在2016的blackhat大會上，就有大佬披露了這種攻擊方式。
回過頭來看，問題的核心在於：
Java允許通過JNDI遠端去下載一個class檔案來載入物件，如果這個遠端地址是自己的伺服器，那還好說，如果是可以被外界來指定的地址，那就要出大問題！
前面的例子中，一直用的127.0.0.1來代替LDAP伺服器地址，那如果輸入的User-Agent字串中不是這個地址，而是一個惡意伺服器地址呢？
影響規模
這一次漏洞的影響面之所以如此之大，主要還是log4j2的使用面實在是太廣了。
一方面現在Java技術棧在Web、後端開發、大資料等領域應用非常廣泛，國內除了阿里巴巴、京東、美團等一大片以Java為主要技術棧的公司外，還有多如牛毛的中小企業選擇Java。
另一方面，還有好多像kafka、elasticsearch、flink這樣的大量中介軟體都是用Java語言開發的。
在上面這些開發過程中，大量使用了log4j2作為日誌輸出。只要一個不留神，輸出的日誌有外部輸入混進來，那直接就是遠端程式碼執行RCE，滅頂之災！
修復
新版的log4j2已經修復了這個問題，大家趕緊升級。
下面是log4j2官網中關於JNDI lookup的說明：
我通過搜尋引擎找到了快取的12月10號前的快照，大家對比一下，比起下面這個快取，上面那一版多了哪些東西？答案是：修復後的log4j2在JNDI lookup中增加了很多的限制：
答案是：修復後的log4j2在JNDI lookup中增加了很多的限制：
預設不再支援二次跳轉（也就是命名引用）的方式獲取物件
只有在log4j2.allowedLdapClasses列表中指定的class才能獲取。
只有遠端地址是本地地址或者在log4j2.allowedLdapHosts列表中指定的地址才能獲取
以上幾道限制，算是徹底封鎖了通過列印日誌去遠端載入class的這條路了。
最後，手機前的各位Java小夥伴兒們，你們寫的程式中有用到log4j2嗎，有沒有某個地方的輸出，有外部的引數混進來呢？
趕緊檢查檢查哦！
另外有想自己復現這個漏洞的同學可以領取一份漏洞復現，修復資料，程式碼工具的資料
點選下方傳送門即可免費領取
大家弄懂這個漏洞了嗎？如果覺得寫得還不錯，歡迎分享轉發，順便給俺點個贊，感謝大家的閱讀。