問題主要來自 Google Cloud 嘅分散式系統架構。當 API key 被刪除後,撤銷資訊需要逐步同步到各個處理身份驗證嘅伺服器。
結果就係:
Aikido 透過反覆建立並刪除 API key,再持續發送驗證請求做測試。喺 10 次實驗 入面,最短撤銷時間約 8 分鐘,最長 23 分鐘,中位數約 16 分鐘。
換句話講,控制台顯示「已刪除」並唔代表所有系統即刻停止接受該憑證。
當企業發現 API key 洩露時,通常第一步就係立即刪除憑證。但呢個延遲窗口意味住:攻擊者可能仍然可以繼續用該 key 一段時間。
如果攻擊者喺呢段時間持有 key,可能仍然做到:
研究人員指出,他們嘅測試 key 原本係用於 Gemini API,但同樣情況亦出現在其他 Google Cloud 服務,例如 BigQuery 同 Google Maps。因此問題並非某個單一產品,而係 API key 憑證機制本身嘅特性。
根據披露資料,Google 最初將呢個問題視為 分散式系統正常嘅 propagation delay(同步延遲),而唔係嚴重漏洞。有報道指相關回報曾被標記為「won’t fix」。
不過之後 Google 重新審視報告,並將事件重新開啟,內部列為 P0 等級 bug 進行調查。
由於撤銷資訊需要喺大量後端系統之間同步,因此實際失效時間會因處理請求嘅伺服器不同而有所差異。
喺 Google 完全解決問題之前,安全團隊應該假設 刪除 API key 並唔會即時阻止所有存取。
建議做法包括:
把刪除視為「延遲生效」嘅控制措施
預留大約 30 分鐘風險窗口,期間被盜 key 仍可能成功驗證。
刪除後立即監控日誌與帳單
如果喺刪除後仍見到 API 呼叫或費用異常,可能代表 key 正被利用。
為 API key 設定嚴格限制
例如限制來源 IP、HTTP referrer 或可使用嘅 API,以減低洩露後嘅濫用價值。
快速輪替憑證
不要只依賴刪除,應盡快建立新 key 並更新服務使用新憑證。
呢次事件突顯咗大型分散式系統嘅一個現實:設定變更通常唔會即時喺整個基礎設施同步。
對開發者同安全團隊嚟講,最重要嘅教訓其實好簡單:
「刪除」並唔一定代表「即刻失效」。
當涉及敏感憑證時,事故應對流程應該預留短暫嘅同步延遲時間,並持續監察系統活動,直到確定存取完全停止。
問題主要來自 Google Cloud 嘅分散式系統架構。當 API key 被刪除後,撤銷資訊需要逐步同步到各個處理身份驗證嘅伺服器。
結果就係:
Aikido 透過反覆建立並刪除 API key,再持續發送驗證請求做測試。喺 10 次實驗 入面,最短撤銷時間約 8 分鐘,最長 23 分鐘,中位數約 16 分鐘。
換句話講,控制台顯示「已刪除」並唔代表所有系統即刻停止接受該憑證。
當企業發現 API key 洩露時,通常第一步就係立即刪除憑證。但呢個延遲窗口意味住:攻擊者可能仍然可以繼續用該 key 一段時間。
如果攻擊者喺呢段時間持有 key,可能仍然做到:
研究人員指出,他們嘅測試 key 原本係用於 Gemini API,但同樣情況亦出現在其他 Google Cloud 服務,例如 BigQuery 同 Google Maps。因此問題並非某個單一產品,而係 API key 憑證機制本身嘅特性。
根據披露資料,Google 最初將呢個問題視為 分散式系統正常嘅 propagation delay(同步延遲),而唔係嚴重漏洞。有報道指相關回報曾被標記為「won’t fix」。
不過之後 Google 重新審視報告,並將事件重新開啟,內部列為 P0 等級 bug 進行調查。
由於撤銷資訊需要喺大量後端系統之間同步,因此實際失效時間會因處理請求嘅伺服器不同而有所差異。
喺 Google 完全解決問題之前,安全團隊應該假設 刪除 API key 並唔會即時阻止所有存取。
建議做法包括:
把刪除視為「延遲生效」嘅控制措施
預留大約 30 分鐘風險窗口,期間被盜 key 仍可能成功驗證。
刪除後立即監控日誌與帳單
如果喺刪除後仍見到 API 呼叫或費用異常,可能代表 key 正被利用。
為 API key 設定嚴格限制
例如限制來源 IP、HTTP referrer 或可使用嘅 API,以減低洩露後嘅濫用價值。
快速輪替憑證
不要只依賴刪除,應盡快建立新 key 並更新服務使用新憑證。
呢次事件突顯咗大型分散式系統嘅一個現實:設定變更通常唔會即時喺整個基礎設施同步。
對開發者同安全團隊嚟講,最重要嘅教訓其實好簡單:
「刪除」並唔一定代表「即刻失效」。
當涉及敏感憑證時,事故應對流程應該預留短暫嘅同步延遲時間,並持續監察系統活動,直到確定存取完全停止。