AWS 誘餌藏「情境炸彈」截停 AI 入侵,但中招之後仲要有人執手尾
Tech News

AWS 誘餌藏「情境炸彈」截停 AI 入侵,但中招之後仲要有人執手尾

圖片:via iThome — https://www.ithome.com.tw/news/177359
TechLab 編輯部(譯)·

Tracebit 用模型安全限制拖慢攻擊,實際成效要睇點部署

俾 AI agent 自己踩停掣

AI agent 一旦攞到雲端 access key,可以逐項列出 IAM、Secrets Manager、S3 同其他資源,再按搵到嘅線索提升權限。Tracebit 今次諗法幾直接:喺一個扮成重要憑證嘅 canary secret 入面,收埋會觸發模型安全限制嘅文字。Agent 見到個名夠吸引,讀取內容之後又將文字塞入自己嘅 context,模型供應商嗰層安全機制就可能拒絕繼續,防守方同時收到誘餌俾人開過嘅警報。

情境炸彈點樣收埋喺 AWS

可以想像入侵者先列出 Secrets Manager 入面所有項目,見到一個似「root recovery codes」嘅 secret,於是照讀內容。人手攻擊者睇到一堆奇怪文字,最多懷疑係假資料;AI agent 就可能將成段內容交返畀模型分析。情境炸彈正正利用呢一步,混入敏感題材、緊急字眼或者常見 prompt injection 格式,令模型判斷後續對話踩過安全界線,成個自動攻擊程序停低。

呢招有趣嘅地方,係 canary 原本主要負責報警,而家仲可以干擾對方。傳統誘餌憑證只要俾人使用,保安團隊就知道有人四圍摷;加入情境炸彈之後,警報發出嗰刻,惡意 agent 亦有機會即場卡住。對速度以分鐘計嘅自動攻擊,呢段額外時間幾有用,尤其係 agent 已經識得自行換角色、讀 secret、改 Lambda 或濫用 CodeBuild 嗰類環境。

152 次測試數字好睇,但範圍要講清楚

Tracebit 用一個約有 300 項資源、預先留低十條攻擊路徑嘅模擬 AWS 帳戶,測試 Opus 4.8、Gemini 3.1 Pro、GLM 5.2、DeepSeek 4 Pro 同 Kimi K2.6,合共評核咗 152 次攻擊測試。按 Tracebit 公布嘅結果,放入一個情境炸彈後,五款模型取得完整 admin 權限嘅平均比率由 57% 跌至 5%,至於取得 admin 權限兼建立持久據點嘅完整攻陷,比率就由 36% 跌至 1%。

同一套 Tracebit 測試入面,Opus 4.8 喺乾淨環境有 93% 機會升到 admin,加入情境炸彈後就跌到 0%。任何攻擊路徑成功嘅比率亦由 91% 跌至 15%,而成功行完攻擊路徑嘅測試全部都有觸發 canary 警報。iThome 報道亦引述呢批結果,不過數字只代表 Tracebit 指定嘅模型、agent 工具、prompt、供應商安全政策同 AWS 場景,未可以推論到所有 AI 入侵都會有相同效果。

攻擊者改流程,個炸彈就可能失靈

情境炸彈靠模型願意讀取誘餌、把內容放入 context,同保留足夠嚴格嘅安全限制。攻擊者可以先用程式篩走可疑內容,只提取 metadata;亦可以叫另一個模型做分類、改用限制較少嘅模型,或者見到 agent 停低後由人手接管。炸彈針對嘅題材亦要跟模型調整,Tracebit 測試發現唔同模型對生物安全或政治敏感內容反應各異,模型或者供應商更新政策後,今日有效嘅字串亦可能好快過期。

仲有一點要攤開講:呢份係 Tracebit 自己發表嘅 working paper,暫時未見正式同行評審,而公司本身有賣 canary 保安服務,亦已經將情境炸彈加入產品選項,商業利益相當直接。研究方法有交代 baseline、攻擊路徑同剔除無關失敗嘅做法,但公開結果仍由供應商自行設計同評分。之後最好有獨立團隊用其他 agent harness、模型同真實雲端配置重做一次。

警報響起,真正應變先開始

公司可以將呢類誘餌放近高價值資源,當成偵測同拖延多一層,但唔應該因為 agent 有機會拒絕就當事故完結。Access key 已經外洩嘅話,仍然要即刻停用同輪替憑證、檢查 CloudTrail、收回異常 session、修補 IAM trust policy,再追查對方有冇建立新帳戶、角色或持久據點。平日收緊最小權限、限制 coding agent 可用工具同設定人工批核,先可以減低一個 prompt 或一條 key 直接變成全帳戶事故嘅機會。


參考來源

本文根據原文及公開資料整理;資料有出入時,以原文及官方資料為準。

分享:WhatsAppThreadsTelegramFacebook