容器是一种将软件及其依赖项打包到单个工件中的机制，在过去几年中帮助推动了技术的快速进步。 然而，迁移到云和基于容器的技术的潜在安全风险并不总是清楚。本文调查了互联网上暴露的容器编排服务（Container Orchestration）有多少，以及针对它们的攻击。 本研究考虑了三组基于容器的软件：Docker、Kubernetes 和工作流工具。 在测量研究中扫描了互联网，以识别在默认端口上运行的易受攻击的容器和容器编排服务。然后设计了一个高交互蜜罐，以揭示攻击者倾向于攻击的位置以及针对暴露的实例采取的措施。 该蜜罐基于安装在 Ubuntu 服务器上的容器编排工具，位于精心构建的网关后面，并使用默认端口。

蜜罐在启动后几分钟内就吸引了攻击者。总共收集了 94 天的攻击数据并提取了相关的危害指标 (IOC， indicators of compromise)。实证研究衡量了与暴露在互联网上的容器和容器编排系统相关的风险。 该评估是通过利用高交互蜜罐的新颖设计来执行的。 利用观察到的数据，对针对暴露的主机系统使用的恶意工具、策略和程序提出了新的见解。

0x01 简介

现代世界中网络威胁比比皆是，因为它仍在向云发展。 网络犯罪也十分猖獗，云利用在 2022 年增长了 95% 。最近的一次攻击始于错误配置，后来演变为滥用计算资源来生成加密货币，以及随后盗窃知识产权和敏感数据的行为。 安全漏洞屡见不鲜，此类信息泄露的频繁发生对公司和个人都构成威胁。 网络犯罪策略不断变化，需要新的威胁情报来保持相关性。 像 TeamTN-T这样的知名攻击团队在利用新的攻击向量 Docker 和 Kubernetes 对 Linux 和其他操作系统发起持续攻击方面取得了巨大成功。

在本文中研究了网络犯罪的一个特定目标：互联网上暴露的容器编排服务。 虽然一些学术和工业调查试图了解 Kubernetes 等容器编排软件中的漏洞现状，但这些研究在 Google 云平台（GCP）上提供了中等交互蜜罐，或者侧重于分析相关工件来衡量非法使用。 虽然这些都是有价值的方法，但它们只能对攻击者使用的实际策略和技术提供有限的了解。目前还没有全面的研究来衡量容器编排产品在现实世界中的暴露情况，然后将其与高交互蜜罐配对，让攻击者能够感染操作系统。 为了弥补这一差距，本文设计并实现了一个运行工具实际实例的高交互蜜罐，将每个工具的控制平面暴露于互联网，允许记录入站和出站网络通信以跟踪攻击者的行为。

A. 容器

容器提供了一种将软件及其依赖项打包到单个工件中的方法，该工件的正式名称称为容器映像，或更常见的是映像。 单个应用程序的容器化对于离散测试或短期任务很方便。 容器编排涉及许多相互关联的容器的自动化管理。

容器编排生态系统的各个层面都涉及配置； 有些可以在威胁最小的情况下公开曝光； 例如，配置为侦听端口 80 上的 HTTP 流量的 Web 服务器。但是，使用推荐的防火墙解决方案 UFW 的 Ubuntu 管理员可能没有意识到其他应用程序将以不可见的方式更改数据包路由表 IPtables UFW，导致无意中暴露在互联网上。 此类暴露的风险取决于暴露的信息或资源以及可能导致的潜在损害。

B. Docker

Docker一直引领着容器技术的发展，并持续将其项目回馈给开源社区。 尽管还有其他软件产品可以与容器配合使用，但 Docker 仍然是最普遍的解决方案，并且越来越受欢迎。 Docker的初始架构需要一个具有超级用户权限的守护进程来利用主机操作系统资源。 Docker 的典型用法涉及用户通过命令行界面向 Docker 守护进程发出请求。 要启动新容器，用户将通过名称或 URL 请求图像规范，并可选择传递任意数量的命令行参数，其中可以包括要在新容器内运行的二进制文件或初始命令。 这些初始命令也称为入口点。

上图显示了如果 Docker API 端点（默认为端口 2375 TCP）暴露于 Internet，攻击者如何绕过命令行界面（A 部分）并直接访问暴露的 Docker 守护进程（B 部分）。 如果 Docker 以超级用户 (root) 权限运行，攻击者可以滥用 C 部分中所示的低层系统资源，然后攻击主机操作系统。 幸运的是，这不是 Docker 的默认配置，需要有意（或无意）配置才能暴露此端口。

围绕这个守护进程应该受到良好保护这一事实的安全担忧导致了 Docker 的重新架构。 Docker 20.10 于 2020 年 12 月 9 日发布，这是第一个采用无根模式的主要版本。 虽然在无根模式下运行不再是实验性的，但它需要一些额外的工作来安装和配置，以及一系列已知的限制，包括受限的存储驱动程序、设置资源限制的能力有限以及不支持 AppArmor。 Docker 社区中的人们称赞其安全进步，并且似乎并不介意其局限性。 由于实施更改是在主机操作系统内进行的，因此很难获得有关采用无根 Docker 的信息。

C. Kubernetes

Kubernetes是将容器自动化编排为高可用服务的行业标准方法。 从概念上讲，Kubernetes 是覆盖容器领域的另一层服务。 虽然系统本身都是关于容器的，但在 Kubernetes 中创建和管理的最小可部署计算单元是 Pod。 Pod 由一个或多个容器组成，Kubernetes 将容器的概念抽象为容器运行时接口（CRI，container runtime interface）。 Deployments 是一种声明式方式，用于在 yaml 文件中定义由容器和 Pod 组成的应用程序，然后由 Kubernetes 处理。 守护进程集daemonset就像一个部署，但守护进程集不具有可用性扩展等功能，而是确保所有节点都运行 Pod 的副本。

Kubernetes的分布式架构如上图所示，显示了三种类型的用户将在何处使用 Kuber netes。 管理员使用 API 服务器，最终用户通过网络代理使用服务，攻击者可以使用所示的三个攻击点中的任何一个来滥用暴露的系统。 尽管这些攻击点都不应该暴露，但最近对开放 Kubernetes API 服务器的扫描发现超过 380,000 个没有任何访问控制的 API。

在最佳实践下，凭证在 Kubernetes 中被定义为 Secret，并在配置中引用为环境变量或虚拟安装文件的传递。 遵循预期。 不幸的是，一些用户未能将凭证定义为 Kubernetes Secret，而是在 Pod 配置中定义它们。 Secret也可能被错误地用作命令行参数中引用的环境变量。 由于这样的错误配置，这些Secret也会无意中暴露在正在运行的 Pod 的显示中，这些Secret可以通过查询 Kubelet 只读端口（10255）的 pod 端点来获取。

D. 工作流程工具

工作流被广泛地定义为一项工作从开始到结束所经历的一系列阶段。 要完成的工作阶段的规范在有向无环图 (DAG，directed-acyclic graph) 中定义。 DAG 可以为比简单的步骤序列更复杂的工作流指定每个任务的依赖关系。 本研究的工作流程工具是专门的软件产品，用于使用（或通过）容器设计和执行数字工作流程。 建议不要将这些工具安装在操作系统上，而是将它们作为 Docker 容器的组合或在 Kubernetes 部署中运行。本研究考虑了由两个子集组成的整个工作流工具类别：数据流和持续部署。

在调查了该类别中的主要开源工具后，选择了两款数据流工具（Spinnaker 和 Argo Workflows）和一款持续部署工具（Apache Airflow），因为它默认不包含身份验证，并且在同类工具中拥有最多的 Github star。为了提供更多上下文，Spinnaker 和 Argo 通常用于管理 Kubernetes 内的内容，为云部署的应用程序提供可靠的内容交付。 Argo Workflows 是一个用于在 Kubernetes 上启动工作流的工作流引擎，许多知名公司都在使用它。 Apache Airflow 是一种工作流编排工具，可以通过多种方式部署，通常与 Kubernetes 相关联，并且一直是最近攻击的目标。

0x02 扫描

为了衡量错误配置的容器编排系统的范围，需要从互联网上收集了数据。数据收集分两个阶段进行，首先编制了正在侦听某些端口的主机列表。 然后执行有针对性的扫描来检查对每个特定端口的查询响应。

与浏览电话簿或图书馆目录不同，扫描互联网可能会导致正在扫描的网络出现延迟，这被认为是恶意和滥用。 用于安全研究的互联网测量应该谨慎执行，因为测量可能会产生不利影响。 由于研究网络具有极高的吞吐量，即使是仔细限制的扫描也可能显得激进。 幸运的是，像 Censys 和 Shodan 这样的商业服务可以让用户轻松搜索暴露的产品或服务，而无需执行（可能是滥用的）扫描。

A. 网络扫描

应对许多扫描挑战的第一步是限制扫描范围。 本研究没有搜索所有可能的端口，而是将重点限制在下表所示的三种产品的 10 类特定服务的 26 个默认端口上。更广泛的调查可能会发现非默认端口上发生了新的攻击； 然而，这些见解留待后续研究。

就像人群中个体的移动一样，互联网上的主机可以随时改变其配置； 此特性的一个副作用是后续的互联网测量将会有所不同。 考虑到互联网上主机的变化率，任何多部分的测量研究都应该使用当前数据来完成。 为了克服及时获得结果的挑战，研究者决定从数据中心的主机扫描互联网。 尽管很受欢迎，但像 Nmap 这样无处不在的网络工具并不适合对整个 IPv4 IP 范围执行直接扫描，因为它是单线程的并且需要大量时间才能完成。选择了专门的工具masscan，它被设计为使用多个线程来发出数据包以进行异步发送和接收。 此外，在初步扫描中开始采取以下预防措施：

• 从网络扫描收集的数据已加密。

• 扫描速度被限制为2Mb/秒，以避免网络拥塞。

B. 从Shodan收集数据

对于用例，masscan可以有效缩小后续扫描的范围，但可能会提供许多误报。研究考虑了标准端口上配置错误的容器编排工具。 对侦听端口 80 和 443 的所有主机进行扫描将返回许多误报，这些主机正在运行不属于所考虑的软件产品的软件。 为了克服查找相关数据的挑战，利用了 Shodan 搜索引擎的 API。 查询 Shodan 可以产生有价值的结果，而无需扫描 Internet，并且 Shodan 结果中的某些条目足以估计实例是否不需要身份验证。 例如，如果 Shodan 对 Docker 服务器进行索引，则它可能是一个开放实例，因为 Docker 支持的唯一身份验证方案是 TLS 客户端证书。 如果 Docker 实例需要身份验证，Shodan 将无法抓取横幅来索引条目。 同样，使用 Apache Airflow，仔细搜索特定的 HTML 标题可以揭示默认页面是否是 DAG 管理页面而不是登录页面。

C. 扫描感兴趣的主机

Shodan API 和 Masscan 的综合结果被认为是有趣的主机，因为它们可能运行配置错误的容器（或容器编排）软件。 可以知道，在扫描时，一台主机正在侦听前表中的相关端口之一，但尚不知道该主机是否正在运行同表中列出的软件产品的配置错误版本。 Shodan 结果包含元数据，以确保主机有特定软件产品在特定端口上侦听，但在检查之前无法知道主机是否仍然在线。

由于希望扫描数百万个端点以获取应用程序级数据，因此需要另一个专门的扫描工具。 ZGrab2是一个应用程序级网络扫描器，支持最常见的应用程序级协议（如 HTTP 和 HTTPS）。 使用 Masscan 进行扫描就像跑过大厅，敲每一扇门，看看是否有人来开门。 同样，使用 ZGrab2 进行扫描就像敲每一扇门并发起对话（使用 HTTP 或 HTTPS），无论谁回答。 该工具执行完整的网络 TLS 握手，并为通信的每个请求和响应输出详细日志（如对话记录）。 虽然 Masscan 可以可靠地发出主机在线的信号，但 ZGrab2 将发起与主机的对话，以收集有关主机正在运行的服务和协议的信息。 因此，互联网上不太可能存在大量端点来输出它们不支持的协议的误导性信息。

0x03 扫描结果

Masscan 帮助将 IPv4 搜索空间缩小到 300,958,657 台主机，这些主机在线且可通过研究中的端口之一进行访问。 考虑第一阶段扫描这部分结果的各个类别可能会产生误导，因为由于其他服务使用更常见的端口（如 80、443 和 8080）而导致大量误报。 Shodan 可以更准确地表示互联网上运行基于容器的软件的主机的分布。利用 Shodan API 自动收集了 707,134 个在线主机的列表，这些主机在上次扫描时在默认端口上运行前表中的软件产品之一，如下表所示。在后续扫描中，ZGrab2 确认有 21,590 个在线主机 主机在线并且可验证为开放。

为了提供 Shodan 和 Masscan 之间结果差异的具体示例，考虑 Kubernetes 的 Kubelet 部分。 Masscan 返回了正在侦听端口 10250 或 10255 的 3,128,684 台主机的列表，Shodan 报告了在这些端口上运行 Kubernetes 的 149,024 台主机。 Shodan 报告的主机中有 62% 已经属于 Masscan 的主机组，而 Shodan 特有的 56,114 个主机（尚未包含在 Masscan 集中）仅占 Masscan 主机总数的 1%。

根据所考虑的详细程度，开放可能是主观的，并且查询是唯一的，具体取决于所考虑的应用程序。 由于这些是高度可定制的开源应用程序，因此预计结果会有很大的可变性。 如果需要授权，大多数应用程序中的默认行为将返回 401 错误代码；如果不需要授权，则返回 200 状态代码以及预期内容。 为了提供 Kubelet 的另一个示例，如果对 ZGrab2 请求的 JSON 响应不是 401 并且包含 Pod 列表，特别是关键字“PodList”，则假定主机处于打开状态。

A. 扫描数据评估

初始扫描结果显示大量错误配置的 Kubernetes 主机，其中对可公开访问的只读 Kubelet 端口 10255 的查询返回了正在运行的 pod 和环境变量的列表。 前表中所示的 Shodan API 查询结果返回了同样不成比例的暴露 Kubernetes 主机数量。 尽管二次扫描（如下表所示）只能确认其中一小部分主机实际可访问，但 Kubernetes 组占暴露主机的 90.3%（总共 20,455 台主机中的 18,467 台）。

为了了解错误配置的范围和无意中暴露的数据类型，扫描了收集到的主机响应，以查找敏感的环境变量。 在公开披露的变量中看到私有加密密钥、AWS 账户令牌和财务登录信息。 条目根据重复出现的异常环境变量进行聚类，包括托管环境中托管的特定商业或开源软件的令牌。 为了自动化分析，开发了一个 Python 脚本来解析存储的 JSON，并识别敏感凭证或与所有者身份相关的信息。 此识别基于以下组内的环境变量子字符串：[PASS、KEY、PWD、USER、MAIL、ADDRESS、URI、URL、TOKEN]。 如果环境变量完全匹配（ADDRESS 而不是 SOCKET-ADDRESS），则从结果中排除字符串 ADDRESS。 需要排除列表来减少仅包含文件路径的条目数量，或者在 ADDRESS 的情况下，包含 UNIX 套接字的路径，该路径既不会在没有文件系统访问的情况下向外界公开敏感凭据，也通常不会有助于识别。

然而，“电子邮件地址”可能是一个可能包含联系人信息的字段。 对 Kubernetes API 服务器和 Kubelet API 回复的分析揭示了 52,631 个可能暴露凭据的环境变量。

通过检查 IP 地址所有者组基于 Kubernetes 的暴露情况，发现 Google Cloud Platform 代表了 3,460 个（47.36%）的主机，这些主机在扫描中发现了可公开访问的数据。 第二大群体是异质的，所有群体都远低于 1%，最好将其归类为其他提供商。 AWS 是第三大组，只有 305 个实例（4.17%），其次是 Digital Ocean（0.88%）。

0x04 蜜罐

扫描显示可以发现大量容器编排工具公开暴露在 Internet 上，而无需任何身份验证。 为了发现此类系统是否受到攻击以及如何受到攻击，构建了一个高度仪器化的环境（即高交互蜜罐），Provos 和 Holz 将其定义为一种信息系统资源，其价值在于未经授权或非法 使用该资源。 这样的系统似乎是互联网上已有的具有公开凭证和 API 端点的众多主机之一，但它位于一组透明观察点的后面，如下图所示。

公共云服务供应商宣传安全功能、可靠性和安全性。 公共云上的研究实验是在那些宣传的安全措施的范围内进行的。 其他学术和工业调查试图了解公共云中 Docker、Kubernetes和微服务架构中的漏洞现状。 扫描显示，互联网上基于容器的系统的很大一部分不是在公共云上运行，而是管理自己的服务。

为了弥补这一差距，设计并构建了一个高交互蜜罐，上面运行扫描的软件产品的实际实例，并将每个工具的控制平面暴露给互联网，从而允许记录入站和出站网络通信 来追踪攻击者的行为。 由于任何蜜罐的目标都是收集数据，因此有效的蜜罐必须：

(1) 通过与生产系统无法区分来对攻击者有吸引力；

(2)记录取证数据以供以后分析；

(3) 遏制孤立的、离散的攻击。

下表列出了在为此实验提供的分配的 C 类研究网络上运行的 25 个虚拟机，这些虚拟机完整安装了 Ubuntu Server 22.04 并具有 2022 年 2 月以来的补丁状态。

A. 威胁模型

与任何蜜罐一样，其目标是通过看似现实世界中易受攻击的系统的部署来吸引恶意方。 与此同时，必须注意不要助长或放大攻击者的潜在危害。 通过暴露端口并使用容器编排软件的简单配置，使攻击者有可能获得对主机的完全管理访问权限。 此外，还允许使用 Microsoft Threat Matrix for Kubernetes中 10 个威胁类别中的 9 个类别中的元素。 影响类别是不允许的，因为一旦攻击者获得对蜜罐的完全控制，它可能会允许基础设施被武器化以进行进一步的攻击。研究采取了多项措施来记录攻击的审计跟踪，具体包括以下几个方面：

• 所有进出虚拟机的流量均被限制为 2 Mb/s；

• 发生恶意活动时发送警报；

• 监控并记录流量 ；

• 记录容器内的击键。

B. 联网

C 类网络的所有流量的物理路由都通过单个控制点，即执行网络地址转换 (NAT) 的软件路由器。前图显示了蜜罐设计如何通过中央网关透明地路由所有传入流量。 虚拟机内部和外部的仪器促进了数据收集。 每个虚拟机上都安装了 Elasticsearch 工具，以公开中央服务器收集的数据指标。 每个 TLS 端口都配置为在内部广播数据，而无需使用 PolarProxy进行加密。

作为攻击者可直接访问的单点，网关服务器将对公共 IP 的传入请求转换为内部私有 IP，并通过专用 VLAN 进行路由。 除了地址转换功能之外，网关服务器还包含各种安全信息和事件管理 (SIEM) 工具，用于在不加密的情况下发出警报和记录攻击，包括：

• PolarProxy：中间人TLS 连接；

• TShark：数据包捕获；

• Suricata（使用 Filebeat）：SIEM 工具；

• Kibana 和 Packetbeat：网络流量的仪表板分析。

每个实例都配置为侦听默认 IP 地址和端口、解密传入的 TLS 连接、将数据存储在数据包捕获 (pcap) 文件中，以及终止或创建到内部 IP 地址或端口的新 TLS 连接。 因此，可以捕获解密的 TLS 流量并将其转发到 IDS 系统，以便在传入或传出已知攻击时发送警报。

C. 虚拟机

前表显示了此蜜罐中使用的虚拟机列表。 由于使用了PolarProxy，因此可以组合 Web 端口 80 和 443。软件产品列表中的每个端口组都有一个虚拟机，此外还为关系数据库 MariaDB 添加了一个虚拟机。 如果攻击者使用用户名和密码访问数据库，可以得出结论，他们已经从正在运行的 Pod 的 Kubernetes API 或 Kubelet 列表访问了凭据。

高交互蜜罐必然需要大量维护来维持一个持续吸引攻击者但又不允许伤害他人的操作环境。 因此，按照工作流程及时重置受感染的虚拟机。 首先，将使用感染前状态的快照恢复计算机。 其次，如果机器多次受到相同攻击的攻击，会将攻击特征添加到排除列表中，然后在不同的 IP 地址上创建一个新实例。 虚拟机 IP 的最后一个八位字节是使用随机数生成器分配的。 每个虚拟机仅公开感兴趣的特定端口，来自 Internet 的所有流量都被路由到专用内部 VLAN 上的虚拟机，以减少来自其他网络活动的噪音。

D. Docker

基于 Moby 20.10.12构建了自己的容器运行时，具有与 Docker 引擎相同的功能。做出的修改使能够通过在每次启动时发送警报并存储提取的每个容器映像的本地副本来跟踪容器启动。 每个虚拟机都安装了此 Docker 替代品，因此无论系统调用请求如何，都会记录对容器的每个请求。 镜像文件中记录的完整容器规范和相关元数据对于识别攻击非常有用。 由于研究者完全控制了容器运行时的源代码，因此可以计算一个唯一的字符串来识别容器请求到达时的每次攻击。

例如，对容器的任何请求都将附带一些上下文信息：图像、用于启动图像的任何可选参数以及入口点。 为了唯一地识别攻击签名，根据以下三项计算了 SHA-256 哈希：完整镜像规范、用于启动容器的命令行参数以及指定的入口点。 借助这种独特的标识，可以通过响应文件结束 (EOF) 错误来识别和拒绝重复攻击。 对于攻击者来说，此特定错误将显示为网络错误，而不是明确的拒绝。

E. Kubernetes

Kubernetes 类别中的虚拟机均作为单节点集群运行 K3s（版本 v1.22.7）。 这个特定版本允许将 Dockershim 配置为容器运行时接口，这使得每个 Kubernetes 安装都能够利用为实验所做的底层 Docker 替换。 为了获得正在读取的凭据信号，在虚拟机上部署了一个小型应用程序，在默认端口上公开 kubelet API：10250（加密）和 10255（未加密）。 该应用程序使用在 kubelet API 的 /pods 端点上公开可见的不同凭据频繁地连接到 MySQL 数据库。

F. Workflow工具

（1）Argo Workflow

按照网站上的快速入门指南，在虚拟机上设置 Argo Workflows，使用 K3s 作为容器编排工具，并使用修改后的 Docker 实例作为容器运行时。 手动禁用端口 2746 和 443 的 TLS，因为 PolarProxy 实例处理与外部的 TLS 通信，能够在不加密的情况下观察和记录流量。

（2）Spinnaker

使用三个虚拟机来呈现各种生产 Spinnaker 部署。 按照生产部署的在线指南完成了 Spinnaker 的完整安装，其中 K3s 作为Kubernetes 安装，底层修改后的 Docker 作为容器运行时。

（3）Airflow

设置了六个虚拟机，以在扫描中看到的各种配置来呈现不同版本的 Apache Airflow。 为 Air flow v1.10.7 的发布创建了两个虚拟机，因为它具有众所周知的 CVE (CVE-2020-11978)，其中记录了漏洞，为攻击者提供了攻击蜜罐的起点。 Airflow 的较新版本 (v1.10.15) 部署在 K3s 上，并使用修改后的 Docker 作为容器运行时。 这些虚拟机禁用了身份验证，以反映在网络扫描中看到的内容。 最后，设置了一对虚拟机来运行 v2.2.4，该虚拟机已使用推荐的 Helm 图表进行设置，默认使用 admin admin 作为凭据。

0x05 攻击观察

该蜜罐于 2022 年 3 月 21 日星期一上线，并记录了整个为期三个月的研究中的攻击情况。下表显示了针对蜜罐每个组件的攻击量细分。 总共观察到 191 次攻击，上图显示了一段时间内针对 Docker 组件的攻击量。 由于蜜罐被设计为看起来像一个运行基于容器的软件的简单配置的主机，因此攻击者无需利用 0day 漏洞与系统交互。 因此，观察到的进入策略与安全博客文章中讨论的策略一致。 此外，前所未有的攻击也会作为警报出现。 研究将网络威胁分析师、学术研究和安全博客文章的不同观察结果联系起来，形成攻击者如何通过系统进行操纵的完整画面。

A. 概述

蜜罐攻击的主要目标，特别是针对 Docker 基础设施的攻击，是非法开采门罗币，门罗币是一种流行的工作量证明加密货币，可保持用户匿名。 未经授权使用计算资源来挖掘加密货币被称为加密劫持。 XM Rig是一个流行的加密货币挖掘开源项目，也是观察到的大多数加密劫持攻击的一部分。 攻击者在互联网上找到暴露的服务时的典型攻击模式：

(1)利用暴露的服务；

(2) 对被劫持的系统建立持久化；

(3) 挖矿加密货币；

(4)检查更新或继续传播。

考虑攻击者在互联网上发现暴露端口 2375 的 Docker 守护进程的典型示例。上图显示了攻击如何从在远程主机 (honeypot-server-ip) 上启动 alpine 映像的请求开始， 将整个主机文件系统挂载为正在运行的容器内的 /mnt。 攻击脚本被设置为从远程主机下载并立即针对主机文件系统执行。 下图中显示了这样一个攻击者脚本。在此示例中，chroot 命令用于将操作上下文从容器更改为主机。 接下来，在主机系统上安装工具，并创建一个 cron 文件，以定期从攻击者的主机重新下载并执行远程脚本。

攻击的归因并不总是可能的，但有足够的证据表明 75% 的 Docker 攻击可以将活动追溯到特定的攻击组，如下所述。将攻击归因于攻击组的一些线索包括匹配以下一个或多个特征：URL 字符串、Bash 文件、IP 地址和二进制分析。 对恶意二进制文件的分析可以像将 md5sum 的输出与在线报告进行比较一样简单，也可以像将反编译的二进制文件的特征与更详细的报告进行比较一样简单。

B. Docker

Docker 组件是该蜜罐的关键元素，因为它是研究中考虑的所有容器编排产品的最低层。 由于大多数攻击都针对 Docker，因此需要排除列表才能检测到其他类型的攻击。

攻击中明显存在三个不同的攻击组，其五个特征如下表所示。从较高层面来看，TeamTN-T 脚本具有主机感染的特点，但在很大程度上无法在 Rootless Docker 上运行。

在所有三个攻击组中，攻击者的目标是未加密（非 TLS）Docker 端口 2375，而不是启用安全增强型 TLS 的端口 2376。但是，他们似乎并不喜欢 Rooted Docker 而非 Rootless Docker，因为没有办法 将它们与系统外部区分开来。 作为一个广泛的主题，针对具有 Root 权限运行 Docker 的主机的攻击很快就会被恶意软件感染，这些恶意软件会修改内核以有效地接管主机。 尽管暴露了无根 Docker 实例的主机也不能免受攻击，但这些攻击大多与容器隔离，影响较小。

大多数攻击的目标是某种形式的感染，以在主机上建立持久性。 有两种方法可以逃离容器并在主机上建立持久性：ssh 和 crontab； 这两种方法都遵循相同的模式，如下图所示，主要区别在于安装点和在主机上获得持久性的方法。

一些更恶意的活动包括在主机上构建和安装 Diamorphine rootkit，它操纵系统调用并修改内核数据结构以隐藏正在运行的进程。 某些攻击似乎可以针对无根 Docker 的开放实例，但其后果不如针对以 root 权限运行的开放 Docker 实例的攻击严重。

在利用 crontab 方法时，看到攻击者使用命令将整个主机文件系统挂载在 /mnt 下，如上图所示。容器入口点命令在容器内下载并执行 bash 脚本。 攻击者使用该脚本通过 chroot 进入主机文件系统来在主机上建立持久性。

（1）TeamTN-T

Bash 脚本助长了针对蜜罐的高度自动化的 TeamTN-T 式攻击。 自从 TeamTN-T 宣布解散并向公众发布他们的工具以来，他们的工具现在得到了广泛的使用。所说的 TeamTN-T 攻击有四种分类，每种分类都由一个唯一的字符串来引用，当需要区分时，该字符串是攻击的一部分。 由于攻击策略相似以及脚本中突出的 TeamTN-T 横幅，将它们归为一类。 TeamTN-T 攻击遵循前文描述的模式，主要区别在于其在主机上的持久性方法。 crontab攻击中常见的策略包括：

• 通过向 crontab 或 .bashrc 添加条目来自动运行；

• 安装流行的 Rootkit，例如Diamorphine；

• 禁用主机防御；

• 移除竞争矿工；

• 杀死安全守护进程（专门针对阿里云）；

• 在主机系统上安装恶意软件以维持秘密操作并传播到其他计算机；

• 通过恶意 IRC 客户端（例如 ziggystartux）建立命令和控制 (C2) 通信；

• 发起 SSH 攻击。

随着人们对恶意制作的 Docker 镜像的认识在安全社区中变得众所周知，管理员现在正在密切关注其网络上的模糊镜像。 TeamTN-T 攻击颠覆了这一常见的安全建议，记录了请求无处不在的 Alpine 映像以及各种恶意参数的攻击。从 Alpine 映像发起成功攻击的能力显示了攻击者可以多快地转向 自从 TeamTN-T 之前被认为是制作恶意 Docker 镜像以来的新策略。 下表列出了从使用 Alpine 映像针对 Docker 的 TeamTN-T 攻击中检测到的恶意软件的子字符串和 URL。

在 TeamTN-T 的 SSH 式攻击中也观察到了类似的策略。 攻击首先会请求暴露的 Docker 守护进程启动 Alpine 容器，在 /host 上安装主机文件系统，并执行上图中的文件作为 Alpine 容器中的入口点。 使用开放的 Docker 守护进程，攻击者通常会通过在禁用 SELinux 的情况下请求主机系统命名空间中的特权容器来发起 SSH 式攻击。 下图中所示的解码后的 base64 脚本显示了攻击方法在主机上的多个位置建立持久性的彻底程度。 分析表明，这些 TeamTN-T 风格的基于 Alpine 的攻击都无法感染运行 Rootless Docker 的主机。

在利用恶意图像的 TeamTN-T 攻击的子变体中，b2f628 可能是最具破坏性的。 从上表中列出的四个 URL 请求下载。分析的启动脚本 cronb.sh 执行了一长串恶意操作，包括：

• 修改内核以隐藏使用Diamorphine的操作；

• 删除竞争的加密货币劫持者；

• 安装加密货币挖掘操作；

• 收集有关攻击者服务器设置和身份的报告；

• 为 root 和新用户 hilde 提供 ssh 密钥访问权限；

• 将名为 apa.jpg 的二进制文件下载并安装到 /usr/bin/bioset，这是一个用于命令和控制 (C2) 通信的机器人；

• 启动Tmux 会话以提供反向shell 并将令牌报告给http://oracle.zzhreceive.top/ 。

尽管将此攻击与基于 TeamTN-T 的观察到的攻击归为一类，但 Unit42 报告称，这些攻击可能是由名为WatchDog 的黑客组织发起的。

（2）Kinsing

与其他攻击一样，Kinsing攻击利用暴露的 Docker 端口，与前文描述的攻击模式列表中的步骤 2 不同。 虽然大多数 Docker 攻击都试图逃离容器并在主机上站稳脚跟，但观察到的 Kinsing 攻击是通过在非特权 Ubuntu 容器上下载并执行名为 d.sh 的脚本开始的，如下图所示。 据报道，攻击通过精心设计的蠕虫功能实施秘密加密劫持操作，该功能对具有无根 Docker 的主机有效。 Falco 提醒存在恶意软件，对此进行了手动调查以确认。 正如许多安全报告所指出的，这些攻击并不总是具有相同的事件顺序，但认识到足够的战术模式，可以将其归因于 Kinsing。

（3）Cetus

Cetus攻击不需要中央服务器，因为观察到它们独特的攻击方式和蠕虫能力依赖于两个二进制文件。 攻击首先启动一个非特权的 Ubuntu 18.04 容器，然后继续：

• 在容器中安装 Masscan 和 Docker；

• 在容器中建立持久性；

• 从容器开始挖矿。

由于此攻击是从通用 Docker 容器内发起的，并且不需要对主机进行修改，因此这可能会成功对抗 Rootless Docker。 检查的二进制文件的日期为 2020 年 2 月和 2021 年 4 月，IOC 列于下表中，并且现已有详细记录。

虽然开放的 Docker 实例在对 IPv4 空间的扫描中并不突出，但这个问题确实存在，而且攻击可能会造成毁灭性的后果。 某些技术似乎可以针对无根 Docker 的开放实例，但其后果不如针对以 root 权限运行的开放 Docker 实例的攻击严重。 无根 Docker 的采用率不断变化且难以量化。

C. Kubernetes

（1）API服务器

攻击者最初浏览 API 以收集有关集群的信息，并被记录为集群管理员用户在所有 3 个 API 端口上发送 Certifi cateSigningRequests，从而为他们提供了对集群的持久管理访问权限，如 AquaSec的文章中所述。权限升级后，观察到攻击者创建了下表中列出的 Pod 和 Daemonset。 正如在 Docker 中观察到的那样，通过 Kubernetes API 服务器创建的容器具有挖掘门罗币的单一目的。 与针对 Docker 的恶意活动不同，从 Kubelet API 启动的容器并没有尝试安装 rootkit 或命令和控制脚本以传播到其他机器，相反，它们的唯一目标是开始使用 XMRig 进行挖掘。

值得注意的例外是一个尝试运行 V2-Ray（一种用于构建代理以绕过网络限制的平台）的 Daemonset 创建。 此攻击为 /etc/v2-ray 创建了一个卷来存储配置，并尝试通过端口 8388 打开连接。无法进一步描述此攻击，因为攻击者在连接被防火墙规则拒绝后几分钟内立即删除了 Daemonset。

（2）Kubernetes

对 Kubelet 的攻击不能像直接使用 Docker 或 Kubernetes API 那样简单地生成一个容器。 由于 Kublet 有助于在同一节点上的现有所有 Pod 内运行代码，因此攻击者采用了以下方法：
• 通过对 /runningpods 发出 GET 请求来列出正在运行的 Pod；

• 通过 /run/ 端点在每个正在运行的 Pod 内执行命令。

观察到针对 kubelet 的攻击类别有四种，它们由用于攻击的命名二进制文件引用：kuben2、twentysixteen、twentyseventeen 和 oracle.zzhreceive.top。 最后一次攻击显示了蠕虫功能，该蠕虫功能通过 HTTP 请求简短的 shell 脚本 kb.sh 开始，然后从 47.100.60.0 下载 xm.jpg (XMRig) 以开始加密劫持。 接下来，感染脚本尝试下载并执行脚本 scan.sh 来引导扫描活动。 利用在本研究中使用的相同工具，攻击者利用 Masscan 和 zgrab 来寻找 kubelet 端口 10250 上的其他 Kublet 实例来传播加密劫持活动。

（3）剩余Kubernetes端点

前表中列出的其余 Kubernetes 端点记录的流量包括来自 Censys 的扫描和 /healthz 端点的扫描。 没有任何流向 kubelet /pods 端点的流量记录，也没有流向 MySQL 实例的恶意流量。 鉴于在扫描中发现的泄露凭证来自 /pods 端点，这对于犯罪和非犯罪社区来说可能是一个巨大的疏忽。

D. Workflow工具

对第三类容器编排工具的攻击偏离了前文描述的模式，攻击者从利用直接进入挖掘，而没有建立持久性或传播。 尽管针对 Workflow工具的攻击明显减少，但观察到的行为可以深入了解攻击者的策略。 与完全自动化的 Docker 攻击不同，工作流工具受到人类的攻击，人们观察到他们手动收集有关环境的线索。 这些手动攻击者正在测试他们的能力，并可能构建一个攻击武器库。

（1）Apache Airflow v1

定向到 Apache Airflow v1 的大部分流量来自检查漏洞的网络扫描仪。 许多 Airflow CVE 依赖于可选启用的示例脚本中存在的漏洞。 由于尚未在所有虚拟机上安装示例脚本，因此对未安装示例脚本的虚拟机进行的攻击对攻击者行为的了解有限。 例如，攻击者并没有尝试在每个 Airflow 实例上利用相同的漏洞。

考虑上图和下图中显示的扫描。进一步检查表明，上图中的扫描来自 Nuclei，这是一个任何人都可以用来获取威胁情报的开源项目。 Nuclei 扫描正在检查 CVE-2020-11978的已知可利用 DAG。 不考虑谁可能在扫描，Nuclei 扫描和下图中所示的攻击之间的唯一区别是它们正在寻找不同的漏洞。

有四名不同的攻击者针对 Apache Airflow 实例：三名手动攻击者和一名上传的 shell 脚本。 三个手动攻击者都找到了一种使用以下策略生成反向 shell 的方法：

• 使用开源项目；

• 执行恶意 DAG 以生成 TCP 反向 shell；

• 使用 Metas ploit Metepreter 二进制文件的 example_trigger_target_dag 漏洞生成 TLS 加密的反向 shell。

第一个攻击者开始安装漏洞扫描工具和权限升级，上图提供了攻击者执行的命令的概述。 该攻击者扫描了网络，探测了网关，发现该机器正在向不易被暴力破解的 Elasticsearch 服务器报告后就离开了。 第二个攻击者检查了 CPU 功能，并使用下表中列出的钱包开始使用 XMRig 进行加密劫持操作。 第三名攻击者下载了一系列漏洞利用程序，解压后成功利用了重命名为 sshd 的 XMRig 矿工。 第四个攻击者始终来自同一 IP 范围 183.216.0.0/16，并利用上传的名为 j0u8e3b45j2jup.sh 的 shell 脚本。 该脚本会先更改主机上的 DNS 设置，然后再从每个用户的 .ssh 文件夹中攻击已知主机，然后再安装 XMRig 来挖掘门罗币。

某些攻击中使用的钱包与 PBot 活动中使用的钱包 ID 相匹配，并列于下表中。 该攻击者的多次访问表明他们的方法发生了演变，他们似乎正在开发自动更新功能：每五秒重新启动一次矿工（如果没有运行），然后重新下载（并重新运行） 每 30 分钟编写一次脚本。

（2）Apache Airflow v2

漏洞扫描程序的登录尝试失败了 Airflow v2.2.4，因为最新的已知漏洞已在此版本中修复。

（3）Spinnaker、Argo Workflow和 MySQL

Spinnaker、Argo Workflows 和 MySQL 的所有实例都被网络爬虫和漏洞扫描程序访问，但这些实例并未受到损害。 存储在 Kubelet 和 Apache Airflow 中的明文凭证未被发现并随后被利用。

0x06 结论

在本文中提出了一项实证研究，该研究测量了容器编排系统在互联网上的暴露情况，随后构建了一个高交互蜜罐来识别攻击者针对这些暴露系统的策略、技术和程序。考虑三类容器编排工具：容器构成基础层，容器编排系统构建在该层上，工作流工具密切相关：直接使用容器或在编排系统上使用容器。网络扫描显示，基于 Kubernetes 的系统占暴露主机的 85.5%（总共 21,590 个主机中的 18,467 个）。 对横幅扫描返回的数据进行分析后发现，只读 API 端点上有 52,631 个环境变量，这些变量似乎意外地显示了本应保密的数据。尽管创建并利用了一种机制来拒绝重复攻击，但仍然存在 142 起不同的 Docker 攻击、34 起 Kubernetes 攻击和 15 起针对工作流工具的攻击。 该蜜罐允许观察攻击者和易受攻击的主机系统之间的解密通信。 大多数攻击的明显意图是扩大加密劫持活动，以进行未经授权的加密货币挖掘。