檢測環境是否含有 Log4j 風險

Published in

eCloudture

9 min readJan 6, 2022

從 12 月中上旬開始爆出 Apache Log4j 漏洞後，各家開發仔、維運、SRE 都在這一陣子當中奮力盤查有哪些 Service、Application、Server 上面有相關的問題，並且開始著手做 dependency update 來加以排解 RCE 的可能性。

瑞士政府也有提出 Apache Log4j 的防護方式分為幾個階段，詳見下圖

Zero-Day Exploit Targeting Popular Java Library Log4j (govcert.ch)

本文將會介紹幾個可以加快大家做應用盤查的工具，應急的話也可以透過 WAF Rules 先 Filter & Drop 埋藏在 Header 中的有害 Request！

有關於 Apache Log4j 與其漏洞的資訊，可以參閱另一篇專題：Log4Shell / Apache Log4j 日誌框架系統重大漏洞（CVE-2021–44228） | Medium

環境建置 — 如果你沒有環境

BabooPan/Log4Shell-CVE-2021–44228-Demo: Log4Shell Demo with AWS (github.com)

Application 建置請參閱 README.md
基於 EC2 搭配 AWS ALB & AWS WAF 寫在 demo-aws-mitigation.md 中

準備好環境後，便能著手利用各種工具來檢測／驗證應用程式、Server 上是否有 apache log4j 的漏洞囉！

AWS WAF / Filter Injection Attack

在 AWS WAF — Web 應用程式防火牆 — eCloudture — Medium 中，我們認識 AWS WAF 基於 Application Layer 針對所設立之 WAF Rules 做 HTTP/S Request Filte；若有和 WAF Rules 相符之 Request，能進一步決定要讓該 Request pass throught / deny，在 Application 的最外層做檢驗與放行。

在 AWS WAF 中有提供兩條 AWS Managed Rules：

AWSManagedRulesKnownBadInputsRuleSet 針對 HTTP Request URI、Body 和 Header 做透過 Regex 表示式，檢測是否含有已知的有害 Injection；詳細可以參閱文件
AWSManagedRulesAnonymousIpList 會檢查 Request Source From 是不是來自於會隱匿使用者來源的區段，包含 VPN、Tor 網路節點、Proxy 代理或是含 AWS 的 Hosting Provider…等，阻擋掉屬於隱匿使用者來源的請求訪問有助於繞掉 Bot 等自動腳本的掃描，降低成為攻擊目標的可能性；詳細可以參閱文件

若使用者的應用場景在短時間內無法異動 log4j 的版本，建議先透過 CloudFront 或 ELB 掛載服務端點、前面再透過 AWS WAF 做一層 Request Filter 來過濾掉有害的請求，也可以利用 WhiteList IP Set 加入受信任的來源位置，來確保服務與應用如以往運作的同時，也有效降低 log4j 漏洞的威脅。

AWS WAF 建置流程與測試方式可以參閱：

log4jscanner / Code and Package Analyzer

log4jscanner 是由 Google 推出針對整個 Application Package 與原始碼做檢測的靜態分析工具。透過 log4jscanner 可以找出目錄中是否含有 Apache Log4j 漏洞的 JAR 檔，還能透過 --rewrite 的參數來自動將 JndiLookup.class 從 Package 中移除，此為其中一個 Remediation 方式。

在 GitHub 上有詳細描述是如何檢測 JAR 檔、盤查出是否有漏洞風險，有興趣可以參考看看！

log4j-scan / Vulnerabilities Scan

log4j-scan 由資訊安全公司 FullHunt 開發針對 CVE-2021–44228 漏洞的開源掃描工具，協助管理人員可以利用 log4j-scan 工具對 Service Endpoint、URL、虛擬主機的 IP 位址做掃瞄，以檢測出是否有 log4j RCE 的潛在威脅。

log4j-scan 在使用上僅需要 git pull 下來、皆換至該目錄中執行 python3 log4j-scan.py 便能開始檢測，log4j-scan 也提供了下列功能：

支援 -u 針對一個、或是 -l 多個 URLs 做清單掃描

# 針對一個 Service Endpoint 做檢測
$ python3 log4j-scan.py -u ENDPOINT# 想要一次針對多個 Service Endpoints 做檢測，則可以透過 `-l` 帶入 txt list
$ python3 log4j-scan.py -l urls.txt

支援 --headers-file 參數帶入 HTTP Request Headers 做測試，提供三種範圍 headers、headers-minimal、headers-large 最高達一千多種！
以範例應用做測試，要帶入 X-Api-Version 才會有 Response，與單純檢測 Service Endpoint 的結果便有所差異，發現在 Header 上是有風險的！

支援 --request-type 參數送出 HTTP Post Request、以 JSON 送入 Request data
支援 —-test-CVE-2021-45046 參數針對 CVE-2021–45046 測試會不會有 infinite loop 導致應用中斷的風險
支援 --waf-bypass 參數來嘗試繞過 WAF 的檢查邏輯
支援 --dns-callback-provider參數來檢查確認 DNS callback 是否有異常
懶人參數 --run-all-test 一次測試針對 Service Endpoint 跑 log4j-scan 支援的檢測項目

log4j-scan 也被美國網路安全暨基礎安全局 CISA 用來封裝、推出 GitHub 開元項目 log4j-scanner ，協助各個政府機構與民間使用者來掃描 Web Service 是否 Apache Log4j RCE 潛在風險。

Amazon Inspector / Vulnerabilities Scan

Amazon Inspector 是一項安全性評估服務，協助使用者改善部署於 EC2 Instances 之應用程式、放置於 ECR Repository Container Images 的安全及合規，透過 Inspector 評估是否有弱點、漏洞，並提供改善意見給使用者作參考。

詳細關於 Inspector 的介紹可以參閱：Amazon Inspector v2 發布！漏洞檢測服務全新體驗 — eCloudture — Medium

只要確保待掃描的 Instances 配有 ssm agent 以及 AmazonEC2RoleforSSM Policy 的權限，Inspector 便會自動掃描對應的虛擬主機，如下圖 by Instances 呈現虛擬主機上有哪些需要改善的項目：

若主機或是放置在 ECR 上的 Container Images 有對應的漏洞，這邊以 CVE-2021–44228 為例，Inspector 會盤查出有哪些受影響的 Packages、Package manager 層級為 Application 或是 OS、CVSS 評分等資訊

並且針對不同的 Vulnerable 弱點，提供對應的 Remediation 排解方式給使用者／管理員參考，以下圖為例有：更新 log4j 版本、移除 JNDI Lookup Class、更改套件變數等方式

Inspector 改版上線後，不僅大幅度降低 Vulnerable Scanning 的執行成本，還隨時提供最新的弱點資訊給使用者做 Review，也能再串接 EventBridge 來通知管理人員在第一時間收到通知，大大地縮短弱點暴露到改善的時間。