Anoymask

KindaRails2Shell (CVE-2026-66066)：透過 Active Storage 上傳的任意檔案讀取與遠端程式碼執行

1. 基本資訊

2. 一句摘要

這是一個結合 Active Storage 直接上傳與 libvips 變體處理的漏洞，攻擊者可未經身份驗證上傳特製檔案，讀取伺服器上的檔案與憑證，並視條件在 Rails 程序權限下執行程式碼。

3. 攻擊流程

  1. 攻擊者發現或猜測目標 Rails 應用程式使用 Active Storage。
  2. 攻擊者透過未驗證的直接上傳功能註冊特製檔案。
  3. 攻擊者觸發變體處理，由有漏洞的 Active Storage 與 libvips 預設建置處理。
  4. 攻擊者讀取伺服器上的任意檔案。
  5. 攻擊者取得 Rails 密鑰、雲端憑證、資料庫憑證及其他敏感資料。
  6. 攻擊者可能利用取得的密鑰或處理鏈達成遠端程式碼執行。
  7. 攻擊者可能進一步橫向移動至資料庫、儲存體、雲端環境或 CI/CD 管線（推論）。

4. 攻擊者位置與執行位置

攻擊者透過 HTTP 從外部網路上傳檔案。處理發生在 Rails 應用程式伺服器與 libvips 程序。遠端程式碼執行以 Rails 或變體處理服務的作業系統權限執行。

5. 受害者與管理員可見的現象

  • 即使沒有面向使用者的上傳畫面，只要啟用 Active Storage 即可能存在漏洞。
  • 管理員可在日誌中看到直接上傳、blob 建立、變體請求，以及 libvips 例外或檔案存取。
  • 因外觀與正常圖片處理相似，單靠 WAF 難以偵測。

6. 成功與失敗條件

成功條件

  • Active Storage 已啟用。
  • 變體處理器設為 :vips。
  • libvips 使用預設建置，例如來自發行套件。
  • 使用有漏洞的版本（早於 7.2.3.2、8.0 至 8.0.5.1，或 8.1 至 8.1.3.1）。

失敗條件

  • 已更新至修復版本。
  • 已套用 libvips/ruby-vips 條件的官方因應措施。
  • 直接上傳與變體處理已停止或網路存取受限。
  • 密鑰與檔案分離，並遵循最小權限原則。

7. 成功時的後果

伺服器上的檔案與憑證遭到外洩，導致遠端程式碼執行、資料庫遭入侵、雲端資源濫用，以及原始碼或客戶資料遭竊。JPCERT/CC 建議將所有可讀取的憑證視為已遭入侵而進行更換。

8. 可觀察的日誌

  • 電子郵件：通常沒有。
  • Proxy/SWG/DNS：應用程式伺服器後續流向未知目的地的流量，下載套件或工具。
  • Endpoint/EDR：Rails/libvips 異常檔案存取、子程序、shell，以及讀取機密檔案。
  • Identity/IdP：應用程式密鑰、雲端金鑰與資料庫憑證的異常使用。
  • SaaS/Cloud：物件儲存 blob/變體、Secrets Manager，以及雲端稽核日誌。
  • 網路：直接上傳、特製 blob、變體處理請求，以及遠端程式碼執行後的輸出流量。

9. 攻擊成功判定

  • 僅接觸：探測目標端點。
  • 使用者動作：不需要。
  • 初始執行：註冊特製 blob 與變體處理。
  • 惡意軟體或成功驗證：任意檔案讀取、使用密鑰，以及子程序執行。
  • 資料竊取 / 工作階段入侵：對密鑰、資料庫與雲端資料的異常存取。
  • 確認後續入侵：Web shell、持續性程序、新金鑰、資料庫竄改，以及外部資料外洩。

10. 調查手冊

  • 觸發條件：偵測到有漏洞的版本、PoC 風格的上傳、libvips 異常，或機密檔案存取。
  • 初始檢查：確認 Rails、activestorage、libvips 與 ruby-vips 版本、:vips 設定，以及直接上傳的可及性。
  • 端點：保留 Web、Rails 與 Active Storage 日誌、blob、變體、程序，以及檔案稽核。
  • 驗證與雲端：檢查所有密鑰的異常使用，包括 Rails 憑證、環境變數、資料庫與 S3。
  • 後續動作：追蹤新程序、cron 工作、服務、web shell、輸出流量，以及資料存取。
  • 遏制措施：更新軟體、必要時停止功能、隔離受影響主機、撤銷並輪換所有可讀取的憑證，以及從已知良好版本重建。
  • 判定類別：有漏洞 / 已探測 / 惡意上傳 / 檔案讀取 / 憑證使用 / RCE / 下游入侵。

11. 防禦與偵測構想

  • 單一事件：直接上傳後出現異常變體、libvips 存取機密檔案，或 Rails 產生 shell。
  • 時間軸關聯：Blob 建立 → 變體處理 → 機密檔案讀取 → 新驗證 → 輸出流量。
  • 威脅狩獵：跨所有面向網際網路的 Rails 應用程式，交叉比對 Active Storage 設定與過去的 blob/變體請求。
  • 日誌不足：若無物件儲存與檔案存取稽核，難以判定檔案讀取是否成功。
  • 優先因應措施：更新軟體、安全管理密鑰、套用服務最小權限，以及限制上傳。勿依賴 WAF 取代更新。

12. 事實 / 推論 / 假說

事實

  • JPCERT/CC 已確認公開 PoC，並警示大規模利用潛力。
  • 即使應用程式沒有面向使用者的上傳功能，仍可能因直接上傳缺乏驗證而遭針對。
  • JPCERT/CC 建議更換所有可讀取的憑證。

推論

  • 若 Rails 應用程式擁有高雲端權限，僅檔案讀取（尚未執行遠端程式碼）即可導致嚴重雲端入侵。

假說

  • 將 Active Storage 事件與主機檔案存取日誌結合，可比單用 WAF 更精準地判定攻擊成功。

13. MITRE ATT&CK 對應

  • 高可信度：T1190 利用公開面向應用程式、T1005 從本地系統取得資料、T1552.001 檔案中的憑證。
  • 中可信度：T1059 命令與指令碼直譯器、T1078 有效帳戶、T1105 入口工具傳輸、T1041 透過 C2 進行資料外洩。

14. 未知事項與額外調查

  • 實際利用的存在與開始時間
  • PoC 的確切檔案格式與請求順序
  • 可讀取範圍與遠端程式碼執行的完整先決條件
  • 對託管服務與衍生框架的影響

15. 對 SOC 與組織的影響

Rails 廣泛用於網路服務，即使沒有可見的上傳功能仍可能遭針對，風險相當高。組織必須對照資產清冊檢查 Gem lockfile 與執行時期設定，並假設已遭入侵而輪換憑證。

16. 依角色摘要

  • 針對 SOC：關聯上傳、變體、機密讀取與驗證使用。在 PoC 釋出後調查所有歷史日誌。
  • 針對管理員：檢查 Rails 與 libvips 相依性、更新它們，以及輪換所有可讀取的密鑰。
  • 針對使用者：不需要使用者動作。若發現服務異常，請回報管理員。