Q&A - AI's Journey Through Zero-Days And A Thousand Bugs | Bug Bounty Village, DEF CON 33
三句話摘要
介紹自動化滲透測試 AI 系統的完整架構，以及如何通過驗證、模型混合與邊界控制實現大規模漏洞發現。 自動化滲透測試的核心突破在於用驗證器根除幻覺、用模型互補提升性能、用邊界控制防止超界——技術層與安全層的結合才能規模化地找到真實漏洞。 協調員驅動的任務分配：系統以協調員為核心，負責分析優先級、決定測試策略，然後分配代理程式在指定範圍內尋找漏洞。代理完成檢測後即停止，避免進行後期開發等超範圍操作。
重點整理
重點- 1
協調員驅動的任務分配：系統以協調員為核心，負責分析優先級、決定測試策略，然後分配代理程式在指定範圍內尋找漏洞。代理完成檢測後即停止，避免進行後期開發等超範圍操作。
- 2
驗證器解決幻覺和誤報：LLM 容易產生虛假發現，系統設計了驗證器組件來確認每個漏洞的真實性。例如 XSS 檢測時，使用無頭瀏覽器和 Puppeteer 確認彈出窗口實際出現，確保結果可信。
- 3
合金模型提升性能：不固定使用單一 LLM，而是隨機選擇模型發送查詢並保存上下文。實驗證明任何模型組合都比單模型更優，模型差異越大效果越好。
- 4
邊界與策略檢查器：系統解析應用程式元素確定資產範圍，並設置策略檢查器防止執行刪除資料庫記錄等有害操作，確保滲透測試不會對目標系統造成實際傷害。
實用技巧與重點
乾貨- 支援的漏洞類型：遠端程式碼執行、檔案讀取（包含 XXE 遍歷）、SQL 注入、盲時間型 XSS、反射型 XSS、儲存型 XSS、開放重定向、服務端請求側模板注入、快取中毒、祕密洩露
- 驗證工具：無頭瀏覽器、Puppeteer、自訂驗證器組件
- 合金模型：隨機選擇模型、保存並傳遞上下文、測試結果顯示模型差異越大性能越好
- 性能優化發現：並非運行次數越多越好；暴露密鑰可能只需一次執行；RCE 等問題需多次嘗試；需平衡執行次數與資源投入
- 邊界設置：解析所有應用元素、納入範圍的資產、防止超出範圍操作
- 策略檢查器：阻止刪除資料庫記錄、防止有害系統操作
- 報告流程：AI 完成驗證 → 人工審核 → 提交 Hacker One（LLM 無直接帳戶訪問）
- 不支援的操作：後滲透測試（post-exploitation）
結論
結論“自動化滲透測試的核心突破在於用驗證器根除幻覺、用模型互補提升性能、用邊界控制防止超界——技術層與安全層的結合才能規模化地找到真實漏洞。”
完整解析
詳細團隊構建的自動化滲透測試系統以協調員組件為核心驅動力。協調員扮演滲透測試經理的角色，負責分析目標應用的優先級和偵察信息，然後智慧地分配任務給多個代理程式。系統設計的巧妙之處在於邊界控制——代理會先解析應用程式的所有元素，確定應測試的資產範圍，然後在該範圍內尋找漏洞。一旦發現漏洞，代理即停止，不會進行後期滲透或其他延伸操作。這種約束很重要，因為 LLM 通常不知道何時停止，容易越界。
系統的第二層防護是驗證器組件。LLM 在生成式任務中容易產生幻覺，聲稱找到漏洞但實際不存在。驗證器充當「第二雙眼睛」，用具體技術手段確認每個發現。以 XSS 為例，系統使用無頭瀏覽器和 Puppeteer 等工具，讓驗證器確認注入的 payload 是否真的觸發了彈出窗口，確保報告的是真實漏洞。系統支援的漏洞類型包括 RCE、SQL 注入、各類 XSS、XXE、快取中毒、服務端模板注入等，每種都有對應的驗證邏輯。
在模型策略上，團隊研發了「合金模型」概念，打破了使用單一 LLM 的傳統思路。系統隨機為每個查詢選擇不同的模型，同時保存完整的上下文和歷史信息傳遞給下一個模型。經驗證，任何兩個模型的組合都優於任何單一模型，且模型之間差異越大性能提升越明顯。例如一個模型擅長流程編寫，另一個擅長應用爬取，組合起來遠優於單一模型。但對於非常專門的目標（如只找 XSS），使用擅長該領域的單一模型更有效率。
性能優化是另一個重要發現。初期團隊以為執行次數越多越好，但積累足夠數據後發現並非如此。暴露祕密鑰匙可能一次執行就能發現整個應用，而 RCE 則需多次嘗試。團隊不斷平衡執行次數與資源投入，最終找到了各類漏洞的最優檢測策略，這大幅提升了效率和成本效益比。
系統與 HackerOne 的集成遵循嚴格的安全政策——所有 AI 發現都由人工審核後才提交，LLM 無法直接訪問帳戶。此外，系統設置了策略檢查器防止執行有害操作（如刪除資料庫記錄），確保滲透測試本身不會對目標造成實際傷害。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
