Chainstack部分營運環境遭入侵，內部MCP伺服器未設驗證

Chainstack部分營運環境於10月29日遭外部攻擊者入侵。攻擊從一台仍使用預設管理員密碼的開發伺服器開始，接著經由未設驗證的內部模型上下文協定（MCP）工具伺服器進入營運環境，最後觸及存有客戶帳戶資訊的資料庫。

Chainstack於11月10日在事故報告中補充入侵技術細節。公司表示，攻擊者於10月26日進入開發環境，10月31日封鎖入侵途徑，並於11月2日完成調查。

最初的入侵點是7月安裝在開發用Kubernetes叢集中的Grafana測試伺服器。該伺服器對外網開放，預設管理員帳密也未更改，且沒有單一登入或基本驗證等額外登入防護。

攻擊者於10月26日使用預設管理員帳戶登入，並透過Grafana的資料來源代理存取內部服務。該代理沒有目的地允許清單，網路政策也未限制Grafana可連線的範圍。Chainstack表示，攻擊者連上數十個與身分驗證、資料庫、自動化及監控相關的內部服務。

同一天，攻擊者進入一台供AI代理執行Kubernetes作業的內部MCP工具伺服器。該伺服器不要求驗證，伺服器帳戶還擁有開發用叢集的管理員權限。Chainstack根據網路流量、權限設定及後續變更，判斷攻擊者曾利用這台伺服器下達命令，但未能復原個別工具呼叫紀錄。

接下來的一個半小時內，攻擊者測試內部工作流程引擎的寫入權限，並在開發用身分驗證系統中建立管理員帳戶。他們部署測試網頁，將攻擊者檔案掛載為Kubernetes ConfigMap磁碟區，並替換開發版網頁應用程式提供的JavaScript。10月27日，攻擊者以相同方式修改預備環境的網頁應用程式和開發用Grafana；Chainstack未能取回載入器所指向的第二階段指令碼。

10月29日，攻擊者直接修改自動化平台資料庫中儲存的工作流程，讓系統執行Shell命令。他們使用有效的Webhook權杖執行工作流程，之後再還原原狀。攻擊者直接修改平台資料庫，藉此繞過平台自身的變更紀錄。

在這段期間，攻擊者取得自動化Pod的環境變數、Kubernetes服務帳戶權杖，以及供基礎設施存取閘道使用的機器身分資訊。同一天，攻擊者利用遭入侵的閘道和部署自動化帳戶，列出營運用Kubernetes叢集中的機密資料，並讀取雲端及基礎設施憑證。

10月31日，攻擊者大量查詢營運環境的雲端機密資料庫。他們另建立基礎設施自動化帳戶金鑰，以及持有長期權杖的Kubernetes帳戶，試圖建立再次進入的途徑。攻擊者也使用取得的VPN金鑰連上資料庫網路。

兩個用戶端使用相同的VPN對等端身分連線，導致隧道連線端點來回切換，並造成資料庫複寫錯誤。Chainstack表示，公司因這起故障開始調查入侵事件。

攻擊者以管理員帳戶登入營運資料庫，並取走查詢結果。Chainstack表示，其中一個資料庫執行個體的PostgreSQL pg_shadow檢視表也曾遭查詢，該檢視表包含資料庫角色的密碼雜湊值。

遭存取的資料庫包含組織名稱、帳戶持有人姓名、組織成員電子郵件地址及密碼雜湊值。攻擊者也進入存放客戶節點連線資訊的系統，但Chainstack表示，沒有證據顯示這些資訊確實遭到讀取。公司基於預防措施，仍將節點連線資訊視為已暴露。

Chainstack判斷，攻擊者很可能使用開源AI攻擊框架ARTEX，依據包括攻擊者建立的檔案與帳戶命名痕跡、使用的工具及行為模式。由於多個團體都可能使用同一框架，公司未能確認攻擊者身分，也沒有發現軟體漏洞遭利用的證據。

Chainstack表示，事故期間客戶節點、控制台及API均正常運作，且未遭攻擊者修改。這是與客戶帳戶資料庫及節點憑證存放系統遭存取分開的調查結果。

MCP是一種連接規格，讓AI工具能呼叫外部系統的資料與功能。本次事件顯示的問題在於，內部工具伺服器沒有驗證機制，且該伺服器擁有範圍過大的管理員權限。本報先前曾報導Radware推出企業內部MCP伺服器與AI代理活動監控資安產品。

Chainstack要求客戶更改密碼、更新節點連線資訊並重新簽發平台API金鑰。公司表示，正加強內部MCP工具的驗證機制與最小權限控管，並分開管理開發及營運環境的帳戶與機密資料。