iT邦幫忙

2026 iThome 鐵人賽

DAY 17
0

同一個 Zero-day 能力,既能修補也能攻擊

[[我也希望安全第一]]|第 17/30 天

找到 zero-day 之後,模型站在哪一邊

OpenAI 表示 Astra 已能在無人引導下尋找並利用未知漏洞,成為公司第一個跨過 critical cybersecurity threshold 的模型。對維護大型軟體的人來說,這正是夢寐以求的能力:在攻擊者之前找到洞、產生 patch、跑 regression test。

換個帳號、目標和工具,同一套能力也能主動利用漏洞。

這不是在模型裡找一個「攻擊模式」再把它刪掉就能處理。漏洞研究本來就需要理解如何利用;惡意軟體分析有時也需要解包、執行與修改。攻防共用大量知識和工具,真正不同的是授權、目標、執行環境與後續效果。

能力相同,部署條件不同

OpenAI 把 Daybreak 分成 Blue 與 Red:Blue 面向較廣的防禦工作,例如事件回應、惡意軟體分析與 patch 驗證;Red 提供更廣也更危險的能力,只給經審核夥伴。Anthropic 的 Mythos 也採類似的合作夥伴限制。

這種分層沒有消除雙重用途,只是把風險放到存取與執行控制:

工作 合理防禦用途 同一能力的濫用 適合的控制
漏洞發現 掃描自家版本、提出修補 掃描公開目標找入口 proof of control、target allowlist
Exploit 驗證 確認 patch 有效 建立可武器化 exploit 私有靶場、輸出限制、人工覆核
Credential 分析 找出外洩 secret 收集與測試可用憑證 synthetic secret、禁止真實登入
Malware 分析 解讀樣本與 IOC 改寫成較難偵測版本 隔離執行、artifact quarantine
自動修補 產生 patch、跑測試 植入後門或破壞功能 signed diff、獨立測試、review

只看 prompt 裡寫「我是安全研究員」沒有用。系統要驗證登入者是否控制目標、工作是否在約定時間窗、流量是否只能到靶場,以及產出的 exploit 能否離開環境。

三個人用同一種能力,真的攻進了 OpenAI

Hacktron 的三人團隊後來提供了一個很直接的對照。他們參加 OpenAI 的 bug-bounty 計畫,使用 Claude Opus 5 從社群論壇的圖片上傳開始,沿著 Discourse、ImageMagick 與 libheif 的處理鏈找到入口,再串接另一個帳號漏洞,取得數個 ChatGPT/Codex 帳戶的控制權。其中一名 OpenAI 員工的 Codex 還連著公司的 GitHub organization。

這次確實「用 AI 攻進了 OpenAI」,但它不是 Agent 自己挑了一家公司動手。目標範圍、授權、通報窗口和停止點都由人類研究者控制;團隊在找到路徑後通知 OpenAI 與 Discourse,漏洞獲得修補,OpenAI 支付 6,500 美元獎勵。和第 11 篇的 Hugging Face 事件相比,技術動作可能很像,治理性質卻完全不同。

另一個值得注意的細節是,Hacktron 表示特供資安研究者的 Opus 4.8 在幾個工作階段裡都做不出可用 exploit,Opus 5 發布後數小時內便成功。這只是單一團隊的案例,不是完整 benchmark;它仍然說明 access review 不能只在第一次開通時做。模型版本一換,同一個帳號與同一組工具能做到的事情可能已經不同。

這起事件也沒有讓傳統供應鏈問題消失。libheif 的錯誤早在數月前修掉,卻沒有被正式標成 CVE,下游因此可能沒有把升級視為安全更新。AI 縮短的是找到並武器化漏洞的時間,不會替團隊完成版本盤點、patch propagation 與帳號連結隔離。

防禦者真的得到什麼

AI 對網安的幫助不必等到全自動 SOC。比較實際的幾項是:把大量 log 串成事件時間線、把 crash 轉成最小重現、比較 patch 前後行為、替已知 IOC 找相似模式,以及幫忙檢查大量程式碼。

Hugging Face 重建 17,000 個動作時,甚至碰到一個荒謬場面:部分前沿模型的 guardrail 分不清防禦調查與攻擊,拒絕協助,團隊改用中國開源模型 GLM。防護若只靠關鍵字拒絕,可能先擋住最需要處理事故的人。

較成熟的設計不是全面放行,而是讓高風險能力在具備證據的工作區內可用:ticket、資產所有權、靶場、時間窗、輸出目的地與審核者都綁在同一個 engagement。

「只有 AI 能防 AI」是一句太方便的行銷

OpenAI、Anthropic、Google、Microsoft 與資安公司等逾百家組織曾共同警告,AI 網攻將變得更普遍、更精密。這個預測值得準備;簽署者也有明顯利益:前沿實驗室一面提高網攻能力,一面把防禦包成 Daybreak、Mythos 等產品。

傳統防線沒有因此作廢。TeamPCP 的人類駭客透過軟體供應鏈竊取大量憑證,和 Agent 事件最後都會碰到相似的控制:最小權限、套件完整性、網段隔離、快速輪換與異常警示。差別是 AI 把攻擊迭代的速度和可取得性往前推。

對採購團隊來說,真正要問的不是「這是不是 AI 防禦」,而是:它縮短了哪一段時間、誤報多少、需要讀哪些資料、能執行哪些動作,以及模型供應商出問題時還剩下哪些傳統控制。

接下來探討技術邊界

從一次測試越界開始,接著把偵測、隔離、停止與復原分開處理。走到攻防雙重用途,工程團隊能做的事已經很具體:縮小目標、限制出口、保留 trace、撤銷能力,也替無法倒帶的效果準備補償流程。完整的累積鎖地圖留在系列首頁,方便之後繼續更新。

技術可以限制破壞半徑,也能留下調查材料。當第三方真的受損,下一個問題已不只是怎麼停:誰應該負責、誰要賠、平台在知道風險後又有什麼義務?第 18 篇從這裡開始。

本篇的鎖

  • 鎖是什麼:依工作與風險分級的模型存取、目標所有權證明、私有靶場、輸出隔離與獨立 patch 驗證。
  • 想攔什麼:把漏洞發現、exploit 驗證和 malware 分析能力從合法防禦轉用到未授權目標。
  • 破口在哪:攻防共享技術,文字聲明可偽造;過度拒絕又會讓事件回應者失去工具。
  • 怎麼補:把權限綁到可驗證的 engagement 與執行環境,衡量實際縮短的防禦時間,並保留不依賴單一模型的傳統控制。

參考與來源


上一篇
第 16 篇|出錯之後為什麼救不回來——rollback、補償操作與不可逆行動
下一篇
第 18 篇|誰為失控負責——開發者、部署者、使用者與模型供應商
系列文
我也希望安全第一——然後我們看看這些鎖是怎麼一個個被撬開的18
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言