容器是一种将软件及其依赖项打包到单个工件中的机制，在过去几年中帮助推动了技术的快速进步。 然而，迁移到云和基于容器的技术的潜在安全风险并不总是清楚。本文调查了互联网上暴露的容器编排服务（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% 已经属于 Ma