容器安全案例分析：Docker Hub 的「Imageless」攻擊

最近跟夥伴一起準備一份資安教育訓練的簡報時，有發現同事有引用了一個很好的容器安全案例分析[1]，透過這個新聞案例，來去指出容器安全開發的風險以及預防管控方式。但在預防方式裡面提到了掃描惡意映像檔。

[1]攻擊者濫用Docker Hub映像檔儲存庫出現新的手法！近3百萬儲存庫被用於推送惡意程式、架設釣魚網站
https://www.ithome.com.tw/news/162636

當然，掃描映像檔是整個容器開發週期當中重要的環節之一沒錯，但針對這個新聞案例卻是比較特別的新攻擊手法，因為它就是一種 Imageless 的攻擊，也就是它沒有映像檔。所以你也沒辦法去掃描甚麼惡意映像檔或是映像檔漏洞。

雖然沒有映像檔，但它也是透過了Docker Hub（container registry）來達成惡意攻擊，毫無疑問的也是容器安全需要留意的威脅。 也藉這此機會，來撰寫這篇文章紀錄與分享這個 Docker Hub Imageless 的攻擊到底是甚麼？

一、核心原理

首先我們先來了解這個攻擊的核心原理，去理解「為何沒有映像檔也能被濫用？」。

要理解為何沒有映像檔的頁面仍能造成實際危害，先從人性的信任談起。對許多開發者與工程師來說，看到 Docker Hub 的頁面就會下意識將其視為某種「工具說明」或「套件入口」，所以這個頁面上的東西都當成可以信任的。攻擊者便利用這個信任，把誘導連結放在儲存庫的說明（repository description）或 README 中，這些說明頁本身就像一個簡單的網頁：能放文字、連結，甚至某些情況下能包含會導致跳轉的程式碼（或透過中介頁面實現跳轉）。當搜索引擎或社群討論把這些儲存庫曝光給尋找破解軟體、電子書或遊戲外掛工具的使用者時，點擊進入的受害者便可能被導到惡意下載或釣魚頁面，從而觸發下一步的感染或資料外洩。

JFrog 的研究就發現，Docker Hub 上有大量的此類型攻擊方式，主要使用於三種主要 campaign，分別是下載器、電子書釣魚、以及網站/SEO 類別。

  • Docker Hub 的展示／文件欄（repository documentation/description）允許 HTML 或連結：Docker Hub 為了方便搜尋與說明，容許 repo owner 在儲存庫頁面放說明文字與超連結；攻擊者利用這項功能把誘導連結或 JavaScript 放在儲存庫說明裡面，作為「誘餌頁」吸引用戶點擊。
  • 目標不是拉映像並執行容器，而是利用平台可信度引流：許多開發者或使用者會在搜尋引擎或在社群討論中看到一個看似合法的 Docker Hub 頁面，點進去後被導向到惡意下載或釣魚頁面。攻擊者藉由 Docker Hub 的「域名／頁面信任度」減少受害者的警戒。
  • 大量自動化帳號與儲存庫建立：研究（JFrog）發現過去五年內出現數百萬個此類 imageless repository，並伴隨大量偽造帳號，自動化批量建立頁面以規模化誘導流量或鏈接。

看到這裡大家應該也對這個手法具有初步的概念了解。所以這個攻擊並不是透過惡意的映象檔，而是利用了大家對於 Docker Hub 平台的信任，同時也就信任了任何上面描述頁的內容。這種「平台上的文件/連結信任」就成為一個被濫用的弱點，。

二、攻擊方式與流程

這類攻擊的流程概念上不複雜，但往往結合自動化、大量註冊與社工程，形成規模化濫用。攻擊的常見步驟與技術細節可能如下：

  1. 建立假帳號（或被盜帳號）：攻擊者以自動化腳本註冊大量 Docker Hub 帳號或利用已被入侵的帳號。
  2. 建立 imageless 儲存庫並編輯說明頁：儲存庫無映像，只在說明欄放置 HTML／外部連結或 JS 轉址碼（例如：先連到合法域名，再由該頁面轉址到惡意載點）。
  3. 搜尋引擎或社群誘導流量：攻擊者可能同時在論壇、社群、或 SEO 技巧下將這些儲存庫曝光，或利用關鍵字優化讓目標用戶在找破解/電子書/免費資源時誤點。
  4. 導流到惡意站點／下載器：受害者被導到釣魚頁或下載含惡意 payload 的「下載器」，若下載並執行會進一步感染（例如聯絡 C2、下載廣告軟體或遠端存取工具）。

三、典型場景

誰會被影響？怎麼會被騙呢？這類攻擊最常命中的族群是會在網路上搜尋“範例映像”、“工具”或“免費資源”的人，但實際上任何點開惡意連結的人都可能受害。

  • 開發者或 DevOps 人員搜尋範例映像或工具時：在找某個工具、套件或破解資源時，看到 Docker Hub 上的 repo 說明頁就點進去下載或按連結。
  • 安全研究者或運維人員快速參考 README／說明頁：查找範例或文件時，若信任該頁面來源可能會誤跟惡意外部連結。
  • 一般使用者尋找免費電子書或破解工具：攻擊者特別針對想找免費資源的人群（如電子書、遊戲外掛程式）做誘餌。

一個場景範例：

一位開發者在搜尋某個 CLI 工具的範例映像與使用方式，搜尋結果中出現一個看似完整、包含使用說明的 Docker Hub 儲存庫。雖然沒有映像檔，但該儲存庫具有說明頁，開發者進入閱讀說明頁，，當中的「下載」或「獲取安裝包」連結把他導到一個惡意下載器頁面，誤以為是官方釋出而執行，結果主機被植入後門。

再一個場景範例：

想像你是一名開發者，為了快速部署一個範例環境，你在 Google 搜尋某個工具的 Docker 映像。結果第一個搜尋結果就是一個看起來非常完整的 Docker Hub 頁面：沒有映像檔，但是有指令、有範例、有下載連結。於是你順手點開那個連結、下載安裝，沒想到那其實是一個惡意執行檔。這就是 imageless 攻擊典型的受害情境。

四、實務防護建議

在容器安全中，「掃描映像檔」幾乎是所有課程與流程的標配。但這起事件正好是無法透過此方式來防禦的。
Imageless 攻擊沒有映像檔，因此沒有任何 CVE、沒有 SBOM，也沒有可供掃描的物件。即使企業部署了最嚴謹的映像掃描工具，這類攻擊依然能輕鬆繞過偵測。

更根本的問題在於：這類攻擊針對的是「使用者信任」，而不是技術漏洞。它並非從映像層侵入，而是從內容層與使用者互動層下手。這提醒我們，容器安全不能只看技術面的漏洞掃描，還必須把平台治理與內容信任機制納入防護範圍。

這類型的防護其實可以分成不同面向來看，分別為「註冊/託管端（Registry 平台層面）」、「企業使用者（使用/拉映像者）」與「執行時/運行時偵測」。

A. Registry / 平台供應商可以採取（廠商／平台層面）

  1. 強化內容審查與自動化偵測：對儲存庫描述中的外部連結、script、或可疑 HTML 進行自動化掃描（例如偵測跳轉、可疑域名、短網址或嵌入 JS）。（這也是 JFrog 與 Docker 合作後所建議的方向）。
  2. 限制說明欄的可用語法：移除或限制 HTML/JS，僅允許純文字或受限的 Markdown，減少可被濫用的攻擊面。
  3. 異常行為監控（大量帳號/大量儲存庫建立）：偵測在短時間內大量建立儲存庫或相似說明內容之帳號，並啟用自動暫停與人工審核流程。
  4. 改善帳號驗證與攔截假帳號：加強註冊驗證、IP/行為分析，減少自動化註冊成功率。

（註：Docker 官方已回應並移除 JFrog 回報的惡意 repo，顯示平台合作與負責任通報是可行解法之一。）Docker

B. 企業使用者（DevOps / 開發 /安全團隊）應有的檢查與流程

  1. 不要信任來自 registry 的「說明頁面」當作可信來源：教育團隊若要下載工具或第三方資源，以官方資源為準，而非僅依 Docker Hub repo 說明頁。
  2. 在 CI/CD 中加入映像來源白名單（allowlist）與簽署驗證：只允許從你信任的 registry、具簽章（image signature）或來自內部鏡像倉儲的映像拉取。採用 Sigstore / cosign 等影像簽章技術可確保映像來源與完整性。
  3. 封鎖或監控 registry 說明內的外部連結：若你的開發人員在內部 wiki 或自動化腳本中引用外部 Docker Hub 頁面，先對連結執行安全檢查（例如用網域分類或安全網關進行掃描）。
  4. 培訓（Security Awareness）：說明 imageless 濫用的手法，提醒團隊不要因「看到 Docker Hub」就降低警戒。

C. 執行時偵測與網路防護（Runtime / Infra）

這邊的Runtime與Infra的防護建議，實際上保護範圍也不僅僅是容器安全，更是整個開發與企業安全的強化安全做法。

  1. Egress 過濾與 URL 類別封鎖：控制叢集或工作站對外連線，只允許必要的外部域名；對可疑下載／未知域名啟用流量攔截或沙箱分析。
  2. 運行時行為監控（Falco、eBPF、EDR）：即使攻擊以下載器形式落地，運行時偵測可捕捉異常行為（非授權的網路連線、外部 process spawn、可疑 binary 執行）。
  3. Admission Controller / ImagePullPolicy 及 Pod Security：限制可自動拉取並執行的鏡像來源（例如只允許 internal registry 或簽署過的鏡像），降低直接從 public registry 執行未審核映像的風險。
  4. 沙箱化檢驗下載內容：若業務上必須允許下載第三方二進位或工具，先在隔離沙箱中自動執行行為分析，再決定是否允許到生產環境。

五、檢核清單

✅ 只允許白名單 registry 的映像進入 CI/CD。

✅ 導入 Sigstore / cosign 等映像簽章驗證。

✅ 對 registry metadata（說明欄、連結）啟用自動掃描或封鎖策略。

✅ 平台啟用異常註冊偵測與內容審核。

✅ 對開發團隊進行「imageless 攻擊」教育與模擬演練。

✅ 部署 Egress 控制、URL 分類與下載沙箱化。

✅ 導入運行時異常偵測（Falco、EDR 等）。

✅ 定期審查 registry 活動與拉取紀錄。

六、結語

在我們熟悉的容器安全防禦中，大家最常提到的關鍵字就是「映像檔（Image）」：掃描漏洞、比對簽章、追蹤來源。但這起事件特別之處就在於——攻擊者根本沒有上傳任何映像檔，卻仍然能濫用 Docker Hub 這個平台進行惡意行為。

也透過這次的案例分析，讓大家了解 Docker Hub 不只是儲存映像檔的地方，它同時也是一個「內容平台」。每個儲存庫（repository）都有 README、說明文字、外部連結與標籤。攻擊者正是看準這一點，利用這些非映像內容（metadata）作為誘餌，將使用者導向外部惡意網站或釣魚頁面。是一種「社交工程式」的濫用手法——不是複雜的技術漏洞，而是信任機制被操弄的結果。

這也讓我們明白，容器安全的範圍其實早已超出映像檔本身，而延伸到了整個供應鏈與生態系信任模型。

參考資料

  1. iThome 報導：「攻擊者濫用Docker Hub映像檔儲存庫出現新的手法！近3百萬儲存庫被用於推送惡意程式、架設釣魚網站」。iThome
  2. The Hacker News / JFrog 報導：「Millions of Malicious ‘Imageless’ Containers Planted on Docker Hub Over 5 Years」。The Hacker News
  3. Docker 官方聲明：Docker 與 JFrog 合作移除大量 imageless repo。Docker

Tags: , ,

發佈留言