在本周末，很多企業的網絡安全人員正忙得不可開交。Log4j漏洞出現了另外一種攻擊載體，它通過使用底層的Javascript WebSocket連接，通過驅動式的破壞，在本地服務器上觸發遠程代碼執行(RCE)漏洞進行攻擊。

換句話說，攻擊者可以利用漏洞攻擊那些并不暴露于任何網絡內部系統中的以localhost運行的服務。

Blumira公司的研究人員指出，這一發現推翻了Log4Shell攻擊僅限于暴露的有漏洞的網絡服務器的說法。

研究人員在周五的評論中說："這個最新攻擊載體的出現意味著任何使用有漏洞的Log4j版本的用戶都可以通過他們機器上的監聽服務器的路徑，或通過瀏覽本地網絡從而觸發該漏洞。”

這意味著還有更多新的惡意攻擊方式的存在，而不僅僅是通過使用一行代碼來獲得一個shell，從而在面向互聯網的服務器上投放惡意軟件進行攻擊。

利用WebSockets進行攻擊

WebSockets實現了網絡瀏覽器和網絡應用之間的通信，如網站上的聊天和各種警報。它們通常會允許瀏覽器向這些類型的應用程序發送數據，但它們也常被用于主機指紋識別和端口掃描。

研究人員在帖子中解釋說，WebSockets同樣也充滿了各種安全風險。WebSockets不像普通的跨域HTTP請求那樣受到同源策略的限制。他解釋說："它們期望服務器本身能夠驗證請求的來源。雖然它們有時候很有用，但它們也引入了相當多的風險，因為沒有任何安全控制來限制它們的使用。"

在Log4j的案例中，攻擊者將通過WebSockets向可能含有漏洞的localhost或本地網絡服務器發出惡意請求。但這些目標不一定是要暴露在互聯網上。

BreachQuest的聯合創始人兼首席技術官在電子郵件中說：" WebSockets以前曾被用來對內部系統進行端口掃描。企業應該及時對應用程序進行打補丁，并防止潛在的易受攻擊的服務向外進行連接。"

Log4Shell的本地攻擊場景

研究人員在帖子中對他的攻擊概念證明(PoC)進行了詳細的分解;下面是研究人員的解釋。

第一步：在安裝了含有Log4j2漏洞的服務器上，攻擊者會通過WebSocket連接從瀏覽器觸發一個文件路徑的URL。Blumira在PoC中使用了一個基本的Javascript WebSocket連接，但研究人員指出，這不一定必須是localhost;WebSockets則允許連接到任何IP，這很容易在私有IP空間內進行利用。

第二步：當頁面加載時，它將會啟動一個本地WebSocket連接，連接到易受攻擊的監聽服務器上，并通過基于Java命名和目錄接口(JNDI)連接字符串來連接出去。這種技術類似于WebSockets的本地主機端口掃描，用于主機的指紋識別。

第三步：一旦受害者的主機連接到本地服務或主機本身可訪問的服務的開放端口，攻擊者就可以在文件路徑或參數中放置一個漏洞字符串。當這種情況發生時，含有漏洞的主機會和漏洞服務器進行連接，加載攻擊者的類，并以java.exe為父進程來執行它。

漏洞的檢測和處理

但是壞消息是，根據分析，這是一種很隱蔽的攻擊方法。主機內的WebSocket連接可能很難進行深入的掃描，這也增加了這種攻擊檢測的復雜性。這是因為WebSocket在網頁加載時會悄悄進行連接，客戶端則沒有方法進行直接控制。然而，安全研究人員指出，還是有一些方法來繞過這一點的。

為了檢測可能存在的攻擊，研究人員建議尋找".*/java.exe "被用作 "cmd.exe/powershell.exe "父進程的實例。

研究人員說："這樣檢查出來的可能是非常雜亂的"。最后，企業還應該確保他們設置了檢測Cobalt Strike、TrickBot和相關常見攻擊工具的設備。

研究人員指出，為了及時檢測出本地環境中使用Log4j的地方，現在有公開可用的掃描腳本，

為了完全避免這些風險，企業應該盡快將所有的本地開發工作、內部應用程序和面向互聯網的網絡環境更新到Log4j 2.16，其中包括了任何自定義應用程序。

同時，用戶也可以采用流量出口過濾的措施，這也可以限制在實際漏洞利用過程中所需的回調，還可以在不受信任的外部網站上使用NoScript Java攔截器等工具，避免Javascript觸發WebSocket連接。

Netenrich公司的安全專家通過電子郵件說："這一消息確實意味著，依靠網絡應用程序防火墻或其他網絡防御系統不再是有效的攻擊緩解措施。打補丁仍然是一個組織可以采取的唯一的步驟"。

本文翻譯自：https://threatpost.com/new-log4shell-attack-vector-local-hosts/177128/如若轉載，請注明原文地址。