TeamTNT 的 DockerHub 憑據泄露漏洞

趨勢科技的蜜罐顯示攻擊者 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 濫用的憑據，但並未在未經授權的情況下訪問這些憑據。

本文翻譯自：http://www.trendmicro.com/en_us/research/22/i/security-breaks-teamtnts-dockerhub-credentials-leak.html如若轉載，請註明原文地址