隨著Log4Shell漏洞威脅愈演愈烈，為了幫助用戶應對該問題，AWS發(fā)布了三個熱補丁解決方案以監(jiān)測存在漏洞的Java應用程序和容器，并在運行中安裝補丁。每個解決方案適用于不同的環(huán)境，涵蓋獨立服務器、Kubernetes集群、Elastic Container Service（ECS）集群和Fargate。熱補丁是一種向存在漏洞并且正在運行的應用程序注入修復程序的進程，可以作為在部署應用程序最新修復版本前的短期解決方案。它們并非AWS環(huán)境所獨有，而是可以安裝在任何云或本地環(huán)境中。

然而，Palo Alto Networks（派拓網絡）威脅情報團隊Unit 42的研究人員發(fā)現這些補丁解決方案存在嚴重的安全問題，并隨后與AWS合作對其進行修復。在為服務器或集群安裝補丁服務后，該環(huán)境中的每個容器都可以利用其接管其底層主機。在裝有熱補丁服務或熱補丁Daemonset的主機上，現有容器也可以逃逸。例如，如果給一個Kubernetes集群安裝熱補丁，那么集群中的每個容器都可以逃逸，直到禁用該熱補丁或升級至修復后的版本為止。除了容器，無權限的進程也可以利用該補丁來提升特權，獲得根代碼執(zhí)行。

無論容器是否運行Java應用程序，或其底層主機是否運行Bottlerocket（AWS為運行容器而構建的Linux發(fā)行版），容器都可以逃逸。使用用戶命名空間或以非root用戶身份運行的容器也會受到影響。Unit 42指定CVE-2021-3100、CVE-2021-3101、CVE-2022-0070和CVE-2022-0071來追蹤這些漏洞。

惡意“java”——欺騙熱補丁的罪魁禍首

AWS的熱補丁解決方案會持續(xù)搜索Java進程，并在運行中針對Log4Shell安裝補丁。無論是在容器內部還是外部，任何運行名為“java”的二進制文件的進程都被認為是熱補丁的候選對象。

為了修補容器內的Java進程，熱補丁解決方案會調用特定的容器二進制文件。例如，它們會運行容器的“java”二進制文件兩次：一次是檢索Java版本，另一次是注入熱補丁。問題在于它們調用了容器二進制文件，卻沒有正確地將它們容器化，即未對運行的新進程施加適用于容器進程的限制。

例如，通過nsenter命令在容器命名空間中調用“java”二進制文件（不包括用戶命名空間）。但除此之外，它是由所有Linux功能衍生的，沒有通常限制容器的隔離技術，比如seccomp和cgroups。它還以根用戶的身份運行，不受容器用戶的影響。

因此，一個惡意容器可能包含一個名為“java”的惡意二進制文件。該文件可以欺騙熱補丁解決方案并以較高的權限調用它。然后，惡意“java”進程就能濫用權限逃離容器并接管底層主機。目前，修復后的熱補丁解決方案可以在容器二進制文件運行之前先將它們容器化。

除了容器，熱補丁服務也以類似的方式修復主機進程。沒有權限的惡意進程可以通過創(chuàng)建并運行一個名為“java”的惡意二進制文件，欺騙熱補丁服務并以高權限執(zhí)行它?，F在，修復后的熱補丁服務產生的“java”二進制文件與修復后的Java進程權限相同。

Log4Shell影響深遠，不容小覷

鑒于Log4Shell漏洞的危害迫在眉睫，多數用戶已經大規(guī)模部署了熱補丁，不經意間將容器環(huán)境置于危險之中。甚至在Java應用程序安裝了針對Log4Shell的補丁后，用戶仍有可能因為缺乏足夠的移除動機而繼續(xù)運行熱補丁進行深度防御。

容器通常被視作同一機器上運行的不同應用程序之間的安全邊界。容器逃逸使攻擊者可以將活動擴展到單個應用程序之外，損害相鄰服務。以Kubernetes集群為例，單個容器逃逸有時就足以接管整個集群。無論容器配置如何，這些漏洞都可能被利用。所以即使是啟用了高級隔離技術的環(huán)境（如在用戶命名空間中或作為非root用戶運行容器）也會受到影響。除容器之外，無權限進程也可以利用這些漏洞提升權限并獲得對其底層服務器的完全控制。

運行修復版本，杜絕容器逃逸和權限提升

Unit 42建議任何安裝了這些熱補丁的用戶升級到修復版本。AWS為每個熱補丁解決方案發(fā)布了一個修復方案。一旦主機運行修復版本，就能徹底杜絕容器逃逸和權限提升。

在Kubernetes集群中，可以通過部署AWS提供的最新Daemonset來安裝修復后的熱補丁版本——kubernetes-log4j-cve-2021-44228-node-agent      Daemonset 1.1-16版，該版本安裝了更新后的程序包。值得注意的是，僅刪除熱補丁Daemonset并不能刪除節(jié)點中的熱補丁服務。

在獨立主機上，可以通過運行      log4j-cve-2021-44228-hotpatch程序包1.1-16版進行升級，該版本捆綁了熱補丁服務。

Hotdog用戶需要升級到最新版本——Hotdog 1.02版。這是一個基于開放容器倡議（OCI）hook的Bottlerocket主機的熱補丁解決方案。

另外，如果確認環(huán)境已經安裝了針對Log4Shell的補丁，可以通過運行sudo touch /etc/log4j-cve-2021-44228-hotpatch.kill來禁用主機上的熱補丁服務。若要禁用Hotdog，可以運行apiclient set oci-hooks.log4j-hotpatch-enabled=false。

Prisma Cloud用戶可以在漏洞選項卡下識別受影響的主機。平臺會檢測熱補丁程序包，并對運行漏洞版本的虛擬機發(fā)出警報。如要搜索這些漏洞，可以使用相關的Amazon Linux Security Advisories（ALAS）ID：ALAS-2021-1554、ALAS-2021-1732、ALAS-2022-1580和ALAS-2022-1773。

圖1 Prisma Cloud檢測到有漏洞的log4j-cve-2021-44228-hotpatch版本并發(fā)出警報

派拓網絡的Prisma Cloud、Cortex XDR和下一代防火墻（NGFW）可以檢測到后續(xù)的攻擊行為并破壞命令和控制通信。

提高警惕，與容器安全交互

CVE-2021-3100、CVE-2021-3101、CVE-2022-0070和CVE-2022-0071增加了大量容器逃逸漏洞。這些漏洞源自主機進程與運行容器的直接交互。在有惡意容器的情況下，即使像復制文件或生成一個新的容器化進程這樣簡單的任務，都可能產生意想不到的后果。

如果用戶正在圍繞容器構建軟件，那么當涉及容器進程或文件系統(tǒng)操作時，需要遵循runc等成熟的容器運行時。雖然容器運行時自身也存在漏洞，但它們仍是迄今為止經歷過最多審查且最成熟的容器安全交互程序。

結語

隨著Log4Shell漏洞的威脅日趨嚴峻，對用戶而言最好的辦法是盡快升級到修復后的熱補丁版本。相比之下，多租戶容器環(huán)境和運行不可信鏡像的集群面臨的風險更大。

如果用戶正在安裝針對Log4Shell的補丁，可以優(yōu)先完成這項任務。盡管目前出現的問題可能導致針對容器環(huán)境的嚴重攻擊，但作為有史以來威脅最大的漏洞之一，Log4Shell仍被頻繁利用。

值得慶幸的是，AWS的熱補丁幫助社區(qū)阻止了無數攻擊。隨著這些漏洞的修復，現在已經可以在保證容器環(huán)境安全性的前提下，通過熱補丁來應對Log4Shell漏洞。