AWS多个Log4Shell热补丁可导致容器逃逸和权限提升
随着Log4Shell漏洞威胁愈演愈烈，为了帮助用户应对该问题，AWS发布了三个热补丁解决方案以监测存在漏洞的Java应用程序和容器，并在运行中安装补丁。每个解决方案适用于不同的环境，涵盖独立服务器、Kubernetes集群、Elastic Container Service（ECS）集群和Fargate。热补丁是一种向存在漏洞并且正在运行的应用程序注入修复程序的进程，可以作为在部署应用程序最新修复版本前的短期解决方案。它们并非AWS环境所独有，而是可以安装在任何云或本地环境中。
然而，Palo Alto Networks（派拓网络）威胁情报团队Unit 42的研究人员发现这些补丁解决方案存在严重的安全问题，并随后与AWS合作对其进行修复。在为服务器或集群安装补丁服务后，该环境中的每个容器都可以利用其接管其底层主机。在装有热补丁服务或热补丁Daemonset的主机上，现有容器也可以逃逸。例如，如果给一个Kubernetes集群安装热补丁，那么集群中的每个容器都可以逃逸，直到禁用该热补丁或升级至修复后的版本为止。除了容器，无权限的进程也可以利用该补丁来提升特权，获得根代码执行。
无论容器是否运行Java应用程序，或其底层主机是否运行Bottlerocket（AWS为运行容器而构建的Linux发行版），容器都可以逃逸。使用用户命名空间或以非root用户身份运行的容器也会受到影响。Unit 42指定CVE-2021-3100、CVE-2021-3101、CVE-2022-0070和CVE-2022-0071来追踪这些漏洞。
恶意“java”——欺骗热补丁的罪魁祸首
AWS的热补丁解决方案会持续搜索Java进程，并在运行中针对Log4Shell安装补丁。无论是在容器内部还是外部，任何运行名为“java”的二进制文件的进程都被认为是热补丁的候选对象。
为了修补容器内的Java进程，热补丁解决方案会调用特定的容器二进制文件。例如，它们会运行容器的“java”二进制文件两次：一次是检索Java版本，另一次是注入热补丁。问题在于它们调用了容器二进制文件，却没有正确地将它们容器化，即未对运行的新进程施加适用于容器进程的限制。
例如，通过nsenter命令在容器命名空间中调用“java”二进制文件（不包括用户命名空间）。但除此之外，它是由所有Linux功能衍生的，没有通常限制容器的隔离技术，比如seccomp和cgroups。它还以根用户的身份运行，不受容器用户的影响。
因此，一个恶意容器可能包含一个名为“java”的恶意二进制文件。该文件可以欺骗热补丁解决方案并以较高的权限调用它。然后，恶意“java”进程就能滥用权限逃离容器并接管底层主机。目前，修复后的热补丁解决方案可以在容器二进制文件运行之前先将它们容器化。
除了容器，热补丁服务也以类似的方式修复主机进程。没有权限的恶意进程可以通过创建并运行一个名为“java”的恶意二进制文件，欺骗热补丁服务并以高权限执行它。现在，修复后的热补丁服务产生的“java”二进制文件与修复后的Java进程权限相同。
Log4Shell影响深远，不容小觑
鉴于Log4Shell漏洞的危害迫在眉睫，多数用户已经大规模部署了热补丁，不经意间将容器环境置于危险之中。甚至在Java应用程序安装了针对Log4Shell的补丁后，用户仍有可能因为缺乏足够的移除动机而继续运行热补丁进行深度防御。
容器通常被视作同一机器上运行的不同应用程序之间的安全边界。容器逃逸使攻击者可以将活动扩展到单个应用程序之外，损害相邻服务。以Kubernetes集群为例，单个容器逃逸有时就足以接管整个集群。无论容器配置如何，这些漏洞都可能被利用。所以即使是启用了高级隔离技术的环境（如在用户命名空间中或作为非root用户运行容器）也会受到影响。除容器之外，无权限进程也可以利用这些漏洞提升权限并获得对其底层服务器的完全控制。
运行修复版本，杜绝容器逃逸和权限提升
Unit 42建议任何安装了这些热补丁的用户升级到修复版本。AWS为每个热补丁解决方案发布了一个修复方案。一旦主机运行修复版本，就能彻底杜绝容器逃逸和权限提升。
1. 在Kubernetes集群中，可以通过部署AWS提供的最新Daemonset来安装修复后的热补丁版本——kubernetes-log4j-cve-2021-44228-node-agent Daemonset 1.1-16版，该版本安装了更新后的程序包。值得注意的是，仅删除热补丁Daemonset并不能删除节点中的热补丁服务。
2. 在独立主机上，可以通过运行 log4j-cve-2021-44228-hotpatch程序包1.1-16版进行升级，该版本捆绑了热补丁服务。
3. Hotdog用户需要升级到最新版本——Hotdog 1.02版。这是一个基于开放容器倡议（OCI）hook的Bottlerocket主机的热补丁解决方案。
另外，如果确认环境已经安装了针对Log4Shell的补丁，可以通过运行sudo touch /etc/log4j-cve-2021-44228-hotpatch.kill来禁用主机上的热补丁服务。若要禁用Hotdog，可以运行apiclient set oci-hooks.log4j-hotpatch-enabled=false。
Prisma Cloud用户可以在漏洞选项卡下识别受影响的主机。平台会检测热补丁程序包，并对运行漏洞版本的虚拟机发出警报。如要搜索这些漏洞，可以使用相关的Amazon Linux Security Advisories（ALAS）ID：ALAS-2021-1554、ALAS-2021-1732、ALAS-2022-1580和ALAS-2022-1773。
Prisma Cloud检测到有漏洞的log4j-cve-2021-44228-hotpatch版本并发出警报
派拓网络的Prisma Cloud、Cortex XDR和下一代防火墙（NGFW）可以检测到后续的攻击行为并破坏命令和控制通信。
提高警惕，与容器安全交互
CVE-2021-3100、CVE-2021-3101、CVE-2022-0070和CVE-2022-0071增加了大量容器逃逸漏洞。这些漏洞源自主机进程与运行容器的直接交互。在有恶意容器的情况下，即使像复制文件或生成一个新的容器化进程这样简单的任务，都可能产生意想不到的后果。
如果用户正在围绕容器构建软件，那么当涉及容器进程或文件系统操作时，需要遵循runc等成熟的容器运行时。虽然容器运行时自身也存在漏洞，但它们仍是迄今为止经历过最多审查且最成熟的容器安全交互程序。
结语
随着Log4Shell漏洞的威胁日趋严峻，对用户而言最好的办法是尽快升级到修复后的热补丁版本。相比之下，多租户容器环境和运行不可信镜像的集群面临的风险更大。
如果用户正在安装针对Log4Shell的补丁，可以优先完成这项任务。尽管目前出现的问题可能导致针对容器环境的严重攻击，但作为有史以来威胁最大的漏洞之一，Log4Shell仍被频繁利用。
值得庆幸的是，AWS的热补丁帮助社区阻止了无数攻击。随着这些漏洞的修复，现在已经可以在保证容器环境安全性的前提下，通过热补丁来应对Log4Shell漏洞。
