趋势科技的蜜罐显示攻击者 TeamTNT 正在从至少两个攻击者控制的 DockerHub 帐户中泄露凭据，即 alpineos（超过15万次提取）和 sandeep078（200 次提取）。我们已将这些帐户通知 Docker。

 从 2021 年 9 月中旬到 2021 年 10 月上旬，我们的蜜罐帐户 alpineos 被使用了 3 次，我们跟踪了部署的 IP 地址到它们在德国的位置。攻击者登录到他们在 DockerHub 注册表上的帐户，并且可能忘记注销。除非用户未手动注销，否则标题“X-Registry-Auth”会存储凭据。

这些 DockerHub 配置文件被积极用于部署包含以下内容的恶意镜像：

· Rootkit

· 码头逃生工具包

· XMRig 门罗币矿工

· 凭据窃取者

· Kinsing 恶意软件

· Kubernetes 漏洞利用工具包

2021 年 7 月，我们发布了对 TeamTNT 恶意活动的研究，并发现了该组织通过 Docker API 渗透的证据。结果，我们发现了 26 个独特的 DockerHub 帐户，这些帐户要么遭到入侵，要么遭到恶意攻击。在我们在这里确定的两个帐户中，最有趣的研究帐户是 alpineos 帐户，该帐户托管了超过 150000 次提取的恶意容器镜像。

容器注册表和 Docker 守护进程

Docker 是一个容器服务平台，可帮助开发人员遵循一次编写，随处运行 (WORA) 的做法。它使用简单，受到开发人员的青睐，因为用户可以以极快的速度编写服务和部署应用程序。最重要的是，Docker 适用于任何平台。

容器注册表是容器镜像的存储和分发平台，类似于代码或程序托管在 GitHub 等存储库上的方式。有了正确的授权上下文，人们可以简单地“拉”一个镜像，基于它创建一个容器，然后部署应用程序。DockerHub、Amazon Elastic Container Registry (ECR) 和阿里巴巴容器注册表等许多容器注册表都托管容器镜像。

创建容器时，默认情况下，容器守护程序会从容器注册表中查找镜像。在分析中，我们以 DockerHub 为例。

Docker 守护进程 (dockerd) 从 Docker Hub 提取镜像的“Hello World”示例

如果我们不指定注册表，则默认考虑使用 DockerHub。当 Docker 守护程序（在服务器上）配置为侦听 TCP 端口（默认为端口 2375）时，Docker 为开发人员提供了一项可以在远程主机上创建容器的功能。这使得开发人员可以轻松进行远程开发和部署，因为它使用 curl、wget 和 docker-cli 等工具为各种 Docker 服务（如镜像、容器、网络和卷）提供了接口。

用于创建容器的 Docker REST API

考虑这样一个场景，在远程服务器172[.]31[.]42[.]上创建了一个带有alpine镜像库的新容器（Alpine Linux，一个基于 musl libc 库和 BusyBox 实用程序的发行版）。远程服务器通过 TCP 端口 2375 暴露了 dockerd。

基于远程主机上的 alpine 镜像创建的容器

网络服务器流量

查看服务器网络流量日志，我们可以看到，当远程服务器上请求创建一个新容器时，顺序如下：

1.客户端 ping 目标服务器（数据包 2298）以测试服务器是否可访问；

2.服务器响应状态码 200 并且它是可访问的（数据包 2300）；

3.客户端请求服务器从名为“alpine”的镜像（数据包 2302）中创建一个容器；

4.如果服务器在本地找不到“alpine”镜像，它会响应状态码 404（数据包 2304）；

5.客户端从 /info endpoint>（数据包 2306）请求服务器信息；

6.服务器使用系统范围的信息（数据包 2308）响应请求。

将 404 状态代码显示为 alpine 镜像在本地不可用

返回系统范围的信息

7. 客户端请求服务器从 alpine 镜像创建一个容器。当没有指定标签时，选择“最新”标签。

8. 服务器响应从 DockerHub 下载 alpine 镜像的进度。

从 alpine 镜像创建容器

9. 客户端请求服务器从现在下载的 alpine 镜像创建一个容器。

创建容器的请求，服务器以新创建的容器的 ID 响应

请注意上图中 X-Registry-Auth 标头中的值，其中标头带有 Base64 编码的字符串 {}。下图中的 Docker 文档列举了身份验证详细信息：

Docker 注册中心认证文档

在上述场景中，在服务器上发起创建基于 alpine 的容器的客户端没有登录到 DockerHub 注册中心。因此，X-Registry-Auth 标头的值是用Base64编码的{}。使用“docker login”，可以对容器注册中心进行身份验证，并安全地处理它们的存储库。

如果授权用户重复该过程，其中配置文件为“satoshiav0cad0”的合法用户使用“docker login”登录并查看相同的标头值，标头 X-Registry-Auth 现在将包含以 Base64 编码的凭据。

Base64 编码的凭据

从Base64解码凭据

这些是用户“satoshiav0cad0”的 DockerHub 凭据。经分析，凭据可以在上述标头 X-Registry-Auth 中看到，这只是因为在目标服务器上发起创建容器请求的客户机已经向DockerHub容器注册中心对其进行了身份验证。

作为一个合法的示例，用户可能希望对其 DockerHub 存储库进行身份验证，以根据其私有存储库中的镜像创建容器。但是，如果用户忘记使用“docker logout”从 DockerHub 注销，并在通过 TCP 暴露 dockerd 的不受信任的主机上创建容器，用户就会面临风险，因为他们的用户名和密码是硬编码且未加密的，更不用说只在Base64中编码了。

凭据泄漏场景

在第一种情况下，受害者登录到他们的 DockerHub 注册表。攻击者获得对受害者虚拟机 (VM) 的访问权限，并尝试在远程服务器上创建一个容器，并通过 TCP 暴露 dockerd。如果容器尝试创建的镜像不存在，则从 DockerHub 中提取该镜像，并使用 Base64 编码的凭据填充标头 X-Registry-Auth。

从DockerHub提取的镜像包含base64编码的凭据

一旦被滥用，这些被攻击的帐户可用于查看以下信息，甚至可以通过以下方式进行预览：

1.关联的电子邮件和重复使用的凭据。攻击者可以检查在不同平台上重复使用的密码并检查密码是否泄露；

2.私有存储库和镜像，这些可能包含 API 密钥等凭据，并使用后门修改私有镜像；

3.访问令牌，这些可以用来保持对帐户的持久访问；

4.开发人员的工具。相关功能可用于污染基于Docker的构建管道，并导致供应链攻击。

从不同的角度来看，另一种攻击场景可能涉及攻击者的帐户本身，其中攻击者登录到他们自己的 DockerHub 注册表并且他们的帐户泄露了凭据。虽然合法用户可能不担心窃取攻击者的凭据，但我们分析创建新容器的过程也适用于捕获可能已将各自帐户保持登录状态的攻击者。然后，他们可能尝试在蜜罐中使用TCP上暴露的dockerd创建一个容器。由于趋势科技的蜜罐运行 tcpdump 并将网络流量捕获为数据包捕获 (PCAP)，因此研究人员可以获取以 Base64 编码的攻击者的凭据。

攻击者的凭据泄露

总结

开发人员使用容器来帮助他们进行开发和部署，优化他们的工作流程，并提高他们的工作效率。众所周知，诸如组件错误配置之类的小漏洞会被攻击者滥用。攻击者可以从这些漏洞中执行破坏性活动，例如破坏主机以进行未经授权的加密货币挖掘、泄露密钥和凭据等敏感信息，或者，在最坏的情况下，控制受害者服务器以扩大僵尸网络恶意软件的使用，以及其他非法活动。事实上，只要存在可被滥用的组件和帐户，TeamTNT 等网络犯罪组织就一直存在。

根据研究人员的观察，之所以能够识别 TeamTNT 的账户，是因为：

攻击者使用 alpineos 的凭据登录到他们的 DockerHub 帐户；

攻击者的计算机是自我感染的，并且没有使用凭据助手；

攻击者在攻击暴露的 Docker REST API 服务器时没有从他们的 DockerHub 帐户中注销。

我们发现总共有 30 个此类帐户遭到入侵，其凭据被泄露。这些注册表是 DockerHub 和阿里云容器注册表。虽然我们已经获得了这些信息并可以访问上述可能被 TeamTNT 滥用的凭据，但并未在未经授权的情况下访问这些凭据。

参考及来源：https://www.trendmicro.com/en_us/research/22/i/security-breaks-teamtnts-dockerhub-credentials-leak.html