“最近Log4J中爆出的一個風險較大的安全漏洞，很多客戶給予了前所未有的重視。車庫創新(Client Engineering) GCG團隊，急客戶之所急，從產品的全生命周期出發，提出的一套防漏補缺的組合拳，可消除風險于無形。車庫創新團隊立足于市場最前沿，和客戶肩并肩，梳理痛點，共創方案，迅速驗證，并以此為契機，全面賦能客戶創新實踐與數字化轉型。”

— 魚棟

即使你并非身處安全圈，最近也可能頻繁看到Log4Shell這個詞。很多媒體將其描述為“讓互聯網著火”“危機數百萬Java應用”“過去十年最嚴重的漏洞”。

什么是Log4Shell

2021 注定是不平凡的一年，有機遇也有挑戰，我們在挑戰中蛻變，在蛻變中前行。時至歲末，IT界爆出了一個“核彈級”的漏洞: Log4Shell，至今已有一個多月，其影響依然在持續發酵，相關聯的新漏洞也接連出現，很多企業給予前所未有的重視，給 IT 界帶來了巨大的沖擊。

何為Log4Shell? 簡而言之，Log4Shell是Java日志框架log4j支持的Lookup JNDI(JAVA命名和目錄接口)造成的漏洞。此JNDI支持LDAP數據源，可以通過LDAP, 根據用戶指定的Key來獲取相應的內容（數據或者對象），如果獲取的內容是從第三方的服務器下載的Java對象（此對象可能具有破壞性），那么在加載這個Java對象并執行代碼時，可能對應用程序造成不可估量的破壞。因為log4j應用廣泛，涉及面廣，一時之間，激起了千層浪。

Log4Shell全周期防補一體化

IBM作為安全領域的領軍者，一直以來，視用戶應用和數據安全為生命。作為一線團隊IBM Client Engineering，從產品的全生命周期出發，提出了防漏補缺的一套組合拳，可使此漏洞風險消除于無形。

如下圖所示，下文分別從產品研發到上線應用全生命周期：開發、部署、使用和維護三個階段進行了探討，從漏洞的預防、探測、管理和響應四個方面著手，對用戶的應用程序全方位保駕護航。

組合拳之一：Instana和QRadar雙劍合璧

Instana是現代化的應用性能管理工具，在亞秒級的鏈路追蹤和非采樣不丟失任何鏈路請求方面有著絕對的領導地位，而Log4Shell正是由發起API請求配合log4j的JNDI:LDAP 漏洞達到攻擊的目的，這也是Instana可以發現該漏洞攻擊的天然優勢。

同時，QRadar能夠提供快速而精準的態勢感知，檢測企業內部和云環境中的威脅并評估其安全風險，并提供快速展開調查所需的實時分析與管理。所以Instana和QRadar的結合可以對用戶安全起到更加全面的評估和響應。

Log4Shell漏洞攻擊剖析

為了清晰化Instana發現Log4Shell漏洞攻擊的原理及方法，我們進行了Log4Shell漏洞模擬攻擊實驗，得出了如下兩條結論：

• Instana可以實時發現服務被Log4Shell漏洞發起的任何攻擊。
• Instana可以發現含有Log4Shell漏洞的應用/服務。

這個結論是如何得出來的呢？首先，讓我們通過下圖來回顧如何通過Log4Shell的漏洞發起攻擊的。

從上面的流程，我們可以看出，應用需要同時滿足以下幾個條件，才可能被攻擊，否則該漏洞將對系統不構成威脅：

• Java 應用
• 使用了log4j (版本<2.15)，且lookup 功能為打開狀態
• Logger打印變量包含外部請求變量
• Instana和QRadar對漏洞攻擊的監控和響應

如下圖，如果該漏洞被利用而受到攻擊，我們可以輕易從Instana界面或者Trace Data 獲取到相關攻擊數據和信息。

另外，我們開發出了一個腳本，它可以通過Instana API 拿到Trace Data, 實時分析并且告警當前系統有無受到攻擊，也可以告知用戶當前系統是否有Log4Shell 漏洞， 運行結果展示如下：

QRadar 可以監控接入服務的網絡流量和日志。也可以通過接入第三方的漏洞掃描結果從而更具體的發現相關漏洞。所以QRadar也同樣可以通過Instana API拿到相應的Trace Data， 指定相應的規則實時監控是否有人正在利用漏洞對我們的系統進行攻擊，指定相關腳本，對漏洞或者攻擊做出相應舉措。同時可以Qradar SOAR安全編排自動化響應，來對漏洞做出自動而及時的補救措施。

組合拳之二：PAAS保駕護航之RHACS

RHACS（Red Hat Advanced Cluster Security）是企業級的 Kubernetes 原生容器安全防護解決方案，可幫助用戶更安全地構建、部署和運行云原生應用，能讓用戶及時洞察基于OpenShift 環境的關鍵漏洞和威脅。RHACS 默認配備了多種部署時和運行時策略，能有效防止有風險的工作負載部署或運行。同時，RHACS 可以監控、收集和評估系統級事件，如作業執行、網絡連接和網絡流，以及 Kubernetes 環境中每個容器內的權限提升等，并及時洞察問題，并根據既定規則判斷出危險的級別。

RHACS漏洞管理功能非常全面，可以在整個軟件開發生命周期中，識別并修復容器鏡像和 Kubernetes 的漏洞。如下圖中，RHACS在應用鏡像中識別出了Log4Shell漏洞，并標記為Critical級別。

同時，RHACS具有強悍的檢測和響應能力，可以使用規則、允許列表和基線來識別可疑活動，并采取行動阻止攻擊，強化用戶的 Kubernetes 環境和工作負載，確保應用更安全和更穩定。如下圖，我們定義了一個系統規則來識別Log4Shell漏洞。

當此規則被激活之后，用戶創建的應用容器如果有Log4Shell的漏洞，就會被攔截。從如下錯誤提示信息中，可以看出，由于容器鏡像包含了Log4Shell的漏洞，同時在RHACS的Violations界面，我們可以看到阻止應用創建的事件。

組合拳之三：DevSecOps防漏于未然

DevSecOps是開發、安全性和運維的縮寫，從初始設計到集成、測試、部署和軟件交付，在軟件開發生命周期的每個階段自動化的集成安全檢查功能。DevSecOps通過主動改進安全措施，加速安全漏洞修補，快速、高效的軟件交付，可以防漏洞于未然。

在以下實踐中，DevSecOps在現有CI/CD Pipeline中為開發人員提供自動化安全防護，提供持續的鏡像掃描和保障。鏡像構建之后，需要對鏡像進行掃描來檢查漏洞，如果有Critical的漏洞，在部署之前，需要先對漏洞進行修復。

如下圖中的鏡像掃描日志中，我們可以看出由于檢測到了Log4Shell的漏洞，所以導致此步驟檢測失敗。

同時，在CD階段，我們基于開源的Starboard，開發了一個掃描用戶運行容器漏洞的工具：Starboard Report。當容器創建或者升級的時候，Starboard Report就會自動的探測器漏洞，并實時的展示給用戶，如下。

點擊其中的一個運行容器的報告，就可以看到漏洞掃描的詳細信息，如下所示。

組合拳之四：Hot Mitigation（熱舒緩）補漏趁天晴

Log4Shell 漏洞爆發以后，開源社區給予了極大的關注，在短時間內就有大量的開源項目不斷的涌現出來，有講如何探測該漏洞的，有講如何Hot Mitigation(熱舒緩)的，有描述漏洞原理的等等，不一而足，完美的體現出開源社區的強大力量和快速響應。下圖是在Github上以star數排名關于log4shell的Repositories， 相當驚人。

本節會介紹一種在開源社區中較為有代表性的Hot Mitigation的方式。該方式有兩個優點：

? 因為官方正式補丁包發布是需要時間和驗證的，在這段時間內漏洞是毫無防護的，除非關停服務，該Hot Mitigation可以有效解決這一點。

? 其他Mitigation方式，如修改JVM參數，都需要重啟JVM，造成了停機時間，但本文介紹的這種方式不需要重啟JVM，就避免了停機時間。

在開始之前，讓我們回顧一下Log4Shell漏洞的原理：

“org/apache/logging/log4j/core/lookup/JndiLookup” 這個Java類的“lookup”方法會在非法的服務器上下載惡意代碼，這樣一次攻擊就達成了。一個顯而易見的想法是，如果把原本的“lookup”方法篡改掉，比如讓“lookup”固定的返回字符串：“Patched JndiLookup::lookup()”不就避免了漏洞嗎？這恰恰就是這種Mitigation的原理，更難能可貴的是這一切都是在無需重啟JVM的情況下做到的，并且無論是本地程序還是Kubernetes下的Container都能搞定。

我們的工作是， 首先使用了開源社區所貢獻的，用于Hot Mitigation的Java Jars，然后輔以Kubernetes的DaemonSet，ClusterRole等，和相應的腳本，讓它能夠很完美的在Kubernetes環境中工作。

簡單描述工作原理，安裝以后（DaemonSet），在每個Kubernetes Node上會啟動一個進程去探測該Node上所有的Java進程（JVM），一旦發現，會嘗試注入一個Java Agent到該JVM，并且嘗試去篡改所有JndiLookup。實例的Lookup方法，讓該方法只是返回一個固定的字符串Patched JndiLookup::lookup()， 如下圖所示：

為了驗證改方案的結果，我們準備了三個實驗對象：本地Java應用程序，不包含有漏洞版本的Log4J庫，Hot Mitigation后Log呈現如下：

因為該Java程序中并未包含log4j庫，所以被告知并未發現相應的漏洞。

本地Java應用程序， 包含有漏洞的log4j版本：

發現了漏洞，并patch，符合我們的預期。運行在Kubernetes Pod中的Java 程序，并未包含相應的log4j庫， 所得與第一個對象相同。

最終，在DeamonSet相關的Pod日志中，我們能看一下信息：

這樣，就實現了在升級官方發布的補丁包之前并且避免的停機時間的Hot Mitigation。

結語：未雨綢繆早當先，居安思危謀長遠

在 IT 行業，應用程序的功能和性能固然重要，但安全運行是基礎，尤其在這種Critical級別的安全漏洞面前，人人當存有戒心。及時的檢測到漏洞，并采取相應的措施，才能保證應用程序不被攻擊和利用，企業的效益才能得到保障。

在此調研過程中，我們開發了一些工具，比如如何探測應用中是否有此漏洞，以及是否已經受到攻擊等。如果您感興趣，請聯系IBM Client Engineering團隊（熱線電話：4006682350），我們可以為您演示以上功能，也可以輔助您提升系統和應用的安全。

最后，筆者想提醒大家，Hot Mitigation或許在短時間內可以防止攻擊，我們注意到，Apache基金會已逐步推出官方補丁，長遠來看，建議用戶給應用程序打上安全有效的補丁，方能防患于未然。

??了解更多IBM相關：http://server.51cto.com/act/ibm/2022q1#box1??