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如若轉載，請註明原文地址