前言
近日，被全球廣泛應用的組件Apache Log4j被曝出一個已存在在野利用的高危漏洞，攻擊者僅需一段代碼就可遠程控制受害者服務器，幾乎所有行業都受到該漏洞影響，包括全球多家知名科技公司、電商網站等，漏洞波及面和危害程度均堪比 2017年的“永恒之藍”漏洞，
據奇安信集團透露，根據安域云防護的監測資料顯示，截至2021年12月10日中午12點，已發現近1萬次利用該漏洞的攻擊行為，奇安信應急回應中心已接到十余起重要單位的漏洞應急回應需求，奇安信已于2021年12月9日晚間將漏洞資訊上報了相關主管部門，補天漏洞回應平臺負責人介紹，2021年12月9日深夜，僅一小時內就收到白帽黑客提交的百余條該漏洞的資訊，
經專家研判，該漏洞影響范圍極大，且利用方式十分簡單，攻擊者僅需向目標輸入一段代碼，不需要用戶執行任何多余操作即可觸發該漏洞，使攻擊者可以遠程控制用戶受害者服務器，90%以上基于java開發的應用平臺都會受到影響，
（以上內容來自百度👆）
不知道各位小伙伴有沒有被 Log4j 爆出的漏洞震驚到，Log4j 作為 Apache 的一個開源專案幫助我們輕易的實作了日志列印、日志記錄等等功能，但是就是這么一個“婦孺皆知”的日志組件，卻在程式猿的圈子里引起了一場巨大的風波，可能有很多小伙伴在2021年12月10日的凌晨就收到了甲方爸爸的電話，然后就開始馬不停蹄的修復漏洞，其實這個漏洞并不算大，修復起來也不算麻煩（修復漏洞的辦法在文章最后面哦~），但是卻真的打了我們一個措手不及😭
Log4j 漏洞到底是怎么一回事？
首先引入一個低版本的 Log4j 依賴👇
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.0</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.14.0</version>
</dependency>
然后我們寫一個測驗方法👇
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
/**
* Log4j 漏洞復現
* @description: Log4jTest
* @author: 莊霸.liziye
* @create: 2021-12-18 23:17
**/
public class Log4jTest {
private static final Logger log = LogManager.getLogger();
public static void main(String[] args) {
String info = "${java:os}";
log.info("日志資訊----> {}!", info);
}
}
然后執行一下代碼，我們看看會出現什么情況~
對！沒有錯！漏洞被修復了！！！
本來想給大家復現一下 Log4j 的漏洞，但是漏洞已經被修復了（低版本的 Log4j 依賴也都被修復了），這里就只能靠文字來給大家簡單說一說了😅
多少有點尷尬，哈哈哈哈哈…
官方給出的漏洞描述是：Apache Log4j2 中存在JNDI注入漏洞，當程式將用戶輸入的資料進行日志記錄時，即可觸發此漏洞，成功利用此漏洞可以在目標服務器上執行任意代碼，
其實這個漏洞的原理也非常簡單：在列印日志的時候，如果你的日志資訊中存在 ${} 占位符，那么攻擊者就可以利用這個占位符所對應的變數來進行攻擊，以上面的代碼為例，在漏洞沒有修復之前，控制臺會輸出我們的系統資訊，而不是一個簡簡單單的 “ ${java:os} ” 字串， 那么如果說攻擊者此時傳入了一個類似于“jndi:ldap//惡意鏈接”、“jndi:rmi//惡意鏈接” 形式的引數，這時候就會觸發這個漏洞，從而執行攻擊者自定義的程式，達到其不可告人的秘密🆘
到這里我們應該也就明白了，這個漏洞的根本原因就是字符替換導致的，
Apache Log4j2 組件通過 lookup 擴展的實作類 JndiLookup 來實作的這個功能，這個類存在于 log4j-core-xxx.jar 中，所以只有 log4j-core jar 檔案受此漏洞影響，僅使用 log4j-api jar 檔案而不使用 log4j-core jar 檔案的應用程式依然是安全的，所以各位小伙伴就不用這么驚慌啦~
修復 Log4j 漏洞
如果我們的應用程式不小心中招了該怎么辦呢？其實修復此漏洞的辦法也跟簡單👇
- 升級 Log4j 版本，將依賴或者jar包升級至最新的2.16.0版本
- 直接不用 Log4j （最簡單粗暴的辦法，直接斬草除根）
有些小伙伴會問了：不是升級到2.15.0就行嗎？而且不是還有通過修改配置引數來修復漏洞的方式嗎？
各位稍安勿躁，聽我娓娓道來~
首先先解釋一下第一個問題：為什么不是升級到2.15.0版本呢？
原因也很簡單，Apache 官網給出了一個解釋👇
翻譯過來就是：發現Apache Log4j 2.15.0中針對CVE-2021-44228的修復在某些非默認配置中不完整，當日志配置使用帶有背景關系查找的非默認模式布局（例如，$${ctx:loginId}）時，控制執行緒背景關系映射 (MDC) 輸入資料的攻擊者可以使用 JNDI 查找模式制作惡意輸入資料，導致部分環境資訊泄露和遠程代碼執行，
說白了就是2.15.0也不靠譜了，還是存再一些問題，所以我們需要升級到2.16.0版本，
接下來再解釋一下第二個問題：為什么不用修改組態檔的辦法去修復漏洞？
原因就更簡單了，通過修改引數的辦法去修復漏洞屬于治標不治本的辦法，更不靠譜，所以個人非常不推薦通過此方法來修復漏洞，為了避免“按下葫蘆浮起瓢”，我們還是選擇使用上面的兩種辦法更保險一些💪
小結
本人經驗有限，有些地方可能講的沒有特別到位，如果您在閱讀的時候想到了什么問題，歡迎在評論區留言，我們后續再一一探討🙇?
希望各位小伙伴動動自己可愛的小手，來一波點贊+關注 (????) 讓更多小伙伴看到這篇文章~ 蟹蟹呦(●’?’●)
如果文章中有錯誤，歡迎大家留言指正；若您有更好、更獨到的理解，歡迎您在留言區留下您的寶貴想法，
你在被打擊時，記起你的珍貴，抵抗惡意；
你在迷茫時，堅信你的珍貴，拋開蜚語；
愛你所愛 行你所行 聽從你心 無問東西
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/386800.html
標籤：其他