容器鏡像倉庫泄露風險分析
責編：gltian ｜2023-11-07 15:18:27一. 概述
Docker提供了一種快速、靈活和可移植的方式來構建和交付應用程序，Docker鏡像倉庫使得用戶能夠更加方便地存儲和共享Docker鏡像。然而，鏡像泄露敏感信息事件屢有發生，因此，在使用Docker鏡像倉庫過程中，我們應該始終關注其安全性，并且采取必要的措施以保護敏感信息和數據的安全。
Docker鏡像倉庫分為公共鏡像倉庫和私有鏡像倉庫，公共鏡像倉庫主要是由一些官方機構提供給用戶免費使用的存儲和共享Docker鏡像的平臺，常見的公共鏡像倉庫有Docker Hub，阿里云鏡像倉庫、Google鏡像倉庫等，都包含了廣泛的公共鏡像供用戶使用。私有鏡像倉庫是用戶自己搭建用于存儲和共享Docker鏡像的平臺。用戶可以在私有鏡像倉庫中存儲自己的鏡像，并控制訪問權限，使其只能被特定的用戶或組織使用。常見的私有鏡像倉庫有Harbor和Docker Registry，其中Harbor提供了企業級的鏡像倉庫管理功能，包括鏡像復制、安全掃描等功能。
本文主要對公共鏡像倉庫Docker Hub、私有鏡像倉庫Harbor、Docker Registry的數據泄露風險進行了分析。
文中涉及到的技術僅供教學、研究使用，禁止用于非法用途，文中所涉及漏洞驗證，均使用本地服務器。
二. Docker Hub鏡像泄露分析
2.1Docker Hub鏡像密鑰泄露情況
今年7月，德國亞琛工業大學(RWTH-Aachen University)的研究人員在Docker Hub上發現了數萬個暴露了敏感數據、源代碼的鏡像[1]。他們在分析了337171個鏡像，包含了1647300層的復雜數據集后，最終在28621個鏡像（占比8.5%）中發現了52107個有效的私鑰和3158個API密鑰。
圖1 研究人員最終獲取的敏感信息匯總
從圖1中可以看出，私鑰的泄露可能會導致中間人攻擊、身份偽造等后果，主要私鑰類型有PEM Private Key、PEM Private Key Block等。API敏感信息主要包括公有云服務憑證、金融支付憑證、社交媒體憑證和物聯網憑證，其中泄露的公有云服務憑證類型的包括了阿里云、亞馬遜云、Azure等多個大型公有云服務，金融支付憑證則包含了亞馬遜MWS、Bitfinex、Coinbase等大型國外交易網站或加密貨幣的交易憑證，社交媒體的憑證主要包含了Facebook和Twitter，物聯網設備的憑證數量相對較少，但也可能會導致物聯網設備數據被竊取的嚴重后果，例如汽車位置信息的跟蹤定位。
2.2 暴露敏感信息分析
另外，德國亞琛工業大學的研究人員還對暴露的敏感信息進行了分析，確定其實際用途進而了解所暴露的攻擊面的大小。結果根據泄露的密鑰發現了22082個證書，其中還包括7546個私有簽名證書和1060個公共CA簽名證書，研究者對這些CA證書進行了深入分析后，發現仍有141份證書有效。
圖2 Docker Hub泄露信息類型匯總
研究人員進一步通過Censys數據庫[2]對密鑰進行分析，發現了存在275269個主機使用了這些泄露的密鑰。如圖2所示，其中包括了可能傳輸物聯網敏感數據的MQTT資產以及AMQP資產，存儲重要敏感數據的FTP資產、PostgreSQL資產和MYSQL資產，還包括上萬臺用于SMTP、POP3、IMAP等郵件系統服務器。
對于SSH服務器和Kubernetes服務器，泄露的密鑰可能會帶來遠程惡意shell訪問、僵尸網絡擴張等威脅。
（備注：基于白帽原則研究人員并未對暴露的服務驗證其密鑰）
Docker Hub免費版只支持公開鏡像的托管，因此只能使用其公共鏡像倉庫的功能。如果用戶缺乏安全意識，將帶有敏感信息的鏡像上傳至公共鏡像倉庫，將導致鏡像和敏感信息泄露的風險。因此，建議避免將存儲敏感信息的鏡像上傳至Docker Hub公共鏡像倉庫，而是選擇自建Harbor或Docker Registry私有鏡像倉庫。同時，使用自建私有鏡像倉庫時也需要注意安全性。接下來的內容將分析私有鏡像倉庫的安全性。
三. Harbor鏡像泄露分析
3.1 Harbor組件公網暴露情況
截至2023年11月，在Shodan上可以檢測到12379個暴露的Harbor資產，如圖3所示，其中檢測到國內3377個Harbor資產，國外9002個資產，值得一提的是，在2022年4月，國內的Harbor資產暴露數量僅為2557[4]，在近一年半的時間內增長了820個，增長率為32%。這些資產都是暴露在公網上，且大量資產都處于存活狀態。
圖3 Harbor資產在Shodan上掃描的結果
3.2 鏡像泄露風險分析
既然Harbor在公網上暴露了這么多資產，且暴露資產的數量增長如此迅猛，公網上的Harbor資產是否也存在鏡像泄露風險呢？本文將逐步進行分析。
3.2.1 CVE-2022-46463導致鏡像泄露過程驗證
提到Harbor鏡像泄露風險，不得不說其近年來頻頻爆出漏洞，如CVE-2022-46463，NVD對該漏洞的描述如圖4所示[5]，我們可以得出攻擊者可在無認證情況下，訪問公開和私有的鏡像倉庫。
圖4 NVD對CVE-2022-46463的描述
雖然圖4的公告中明確指出了該漏洞所影響的范圍是2.5.3以下的版本，但經過實際安裝測試，筆者發現截至2023年11月，Harbor最新Release版本2.9.1，以及之前發布的2.8.4及更老的版本，依然還存在該鏡像泄露風險。利用該Harbor特性獲取鏡像信息的驗證過程如下：
首先在服務器上安裝harbor目前的最新release版本2.9.1，如圖5所示。
圖5 測試環境的Harbor版本為2.9.1
之后任意上傳測試鏡像至Harbor，并將其設置為公開，如圖6、圖7所示。
圖6 將測試鏡像打標簽，并上傳到Harbor
圖7 Harbor上可以查詢到該鏡像
最后，在另外一臺服務器上，依然可以現通過Harbor的API接口獲取服務器上存儲的鏡像信息，再進一步獲取某個鏡像的digest等具體信息后，可以組裝出該鏡像的拉取命令，并對該鏡像進行拉取，結果成功拉取了該測試鏡像。具體過程如圖8到圖10所示。
圖8 通過CVE-2022-46463發現了上傳的鏡像倉庫名稱
圖9 通過Harbor的API接口進一步獲取該鏡像的digest
圖10 通過鏡像的digest組裝出鏡像拉取命令，并成功拉取該鏡像
上述過程是在沒有任何認證前提下，從目前最新Release版本（2.9.1）Harbor項目中獲取鏡像信息的過程，可以看出我們能夠獲取Harbor私有倉庫中被設置為“公開”的鏡像倉庫的信息，甚至能夠進行拉取。
行文至此，想必讀者一定會好奇，為何如此嚴重的漏洞，官方遲遲不修復呢？
3.2.2 “假漏洞”烏龍事件
細心一點的讀者可以發現，NVD對該漏洞的描述（如圖4）中最后的NOTE對該漏洞做出了補充說明：即官方認為這個“漏洞”是Harbor的一個特性。
官方具體的回應如圖11所示。
圖11 Harbor官方對此漏洞的回復
官方回應明確指出，他們不認為公開的CVE-2022-46463是Harbor的一個漏洞，而是Harbor官方文檔中所明確定義的特性之一，即用戶可以設置一些鏡像為公開，該特性導致Harbor上的所有被設置為公開的項目都通過相應的API接口被列舉，獲取詳細信息，甚至被拉取。
筆者在測試過程中，確實發現在新建項目時可以對項目的訪問級別進行勾選，如圖12所示。
圖12 新建項目界面
而且，在訪問級別后面的說明也對項目公開做出了詳細且明確的描述，當項目設置為公開時，任何人都有該項目下的讀權限，且命令行用戶不需要“docker login”就可拉取該項目下的鏡像。
測試過程中，如果用戶不對項目訪問級別勾選“公開”項，則只有項目設置所屬賬戶和admin賬戶可以看到此類項目，因而所有未認證的用戶均無法通過API或前端查詢到任何信息，如圖13所示。
圖13 未認證用戶無法通過API獲取到該項目的任何信息
盡管該項目對“公開”的描述已經很詳實，但由于Harbor的前端界面需要登錄認證，針對使用Harbor不熟悉的用戶在操作時仍有可能會誤用該功能，從而使包含敏感信息的鏡像倉庫對所有人開放，而用戶的初衷可能只是對認證用戶開放。
通過上述實驗可以看出，幾乎所有版本的Harbor都存在通過特定方式獲取鏡像的風險，這可能導致敏感信息泄露。因此，在使用Harbor進行鏡像管理時，特別是在部署在公網上的情況下，建議用戶先熟悉Harbor的使用方式和特性，并嚴格控制鏡像倉庫的公開范圍。同時，重視對鏡像倉庫中的敏感信息和相關配置信息的管理，以避免因公開包含敏感信息的鏡像而導致敏感信息泄露的風險。
四. Docker Registry鏡像泄露分析
4.1 Docker Registry組件公網暴露情況
截至2023年11月，在Shodan上可以檢測到12920個暴露的Docker Registry資產，如圖14所示，其中檢測到國內2902個Harbor資產，國外10018個。
圖14 Docker Registry資產在Shodan上掃描的結果
4.2 鏡像泄露風險分析
由于Docker Registry私有倉庫的認證機制在默認情況下并不會開啟，因而攻擊者可以直接調用官方提供的API接口[6]獲取私有鏡像倉庫的列表和版本信息，進而可獲取鏡像的詳細信息，最終導致鏡像泄露的風險。以上筆者進行了驗證，過程如下：
當使用命令docker run -p 5000:5000 –restart=always –name registry -v /var/lib/registry:/var/lib/registry -d registry進行Docker Registry私有倉庫的構建時，默認不會開啟認證服務。若該鏡像倉庫服務暴露在公網時，任意用戶可以通過官方API對鏡像列表進行獲取，如圖15所示。
圖15 通過API對資產的鏡像倉庫列表進行讀取
在獲取到鏡像倉庫列表后，進一步通過官方API獲取tag信息，如圖16所示。
圖16 通過API獲取鏡像倉庫的tag列表
通過獲取倉庫名稱和tag，我們不僅可以獲取鏡像構建的詳細信息，還能夠根據名稱和tag信息組合出鏡像拉取命令并進行拉取，如圖17所示。
圖17 組合出來的鏡像倉庫拉取代碼
若要開啟認證服務，則需要先創建Docker Registry認證文件目錄和認證文件，并使用Apache的htpasswd來創建加密文件，容器的啟動方式如圖18所示。
圖18 開啟認證服務時的Docker Registry啟動方式（示例）
當給Docker Registry添加了認證機制后，再通過其API接口獲取鏡像列表時將返回未認證的提示，如圖19所示，因此添加認證機制的Docker Registry將可以對私有鏡像倉庫進行保護。
圖19 具有認證機制的Docker Registry將可以對私有鏡像倉庫進行保護
由此得出，雖然Docker Registry的安裝部署和使用起來非常方便，但是直接使用Docker Registry身份認證服務的默認配置并不安全。而且由于Docker Registry沒有前端界面，缺少Harbor中直觀的用戶認證與配置方式，導致用戶在使用Docker Registry時，不安全配置的可能性較大。
筆者建議在使用Docker Registry進行私人鏡像管理時，應首先開啟其認證機制后再進行鏡像的傳輸，從而避免鏡像信息的泄露。
五. 總結
本篇文章主要介紹和分析了公共鏡像倉庫Docker Hub中鏡像和敏感信息泄露情況，以及Harbor、Docker Registry兩個私有鏡像倉庫中鏡像和敏感信息的泄露風險。
近年來云上數據泄露事件屢見不鮮，公有鏡像倉庫泄露大量密鑰已是事實，私有鏡像倉庫的安全風險依然存在，因此，建議大家在使用鏡像倉庫過程中密切關注其安全性，并且采取必要的措施以保護敏感信息和數據的安全，在構建鏡像時，避免直接將密鑰設置在環境變量中，避免在鏡像中直接添加包含源代碼、敏感配置信息等。
參考文獻
[1] Thousands of images on Docker Hub leak auth secrets, private keys (bleepingcomputer.com)https://www.bleepingcomputer.com/news/security/thousands-of-images-on-docker-hub-leak-auth-secrets-private-keys/
[2] https://search.censys.io/
[3] https://www.docker.com/pricing/
[4] 云原生服務風險測繪分析（二）：Harbor – 綠盟科技技術博客 (nsfocus.net)
[5] https://nvd.nist.gov/vuln/detail/CVE-2022-46463
[6] https://docs.docker.com/registry/
來源：綠盟科技研究通訊