HTTP Terminator 自主搵漏洞:AI 識開新路,但研究員仍要守尾門
Tech News

HTTP Terminator 自主搵漏洞:AI 識開新路,但研究員仍要守尾門

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

PortSwigger 將多年 HTTP 研究經驗拆成可反覆驗證嘅自主系統

PortSwigger 研究總監 James Kettle 公開 HTTP Terminator,嘗試將自己多年研究 HTTP request desync 嘅方法交畀 AI 執行。iThome 報道提到,系統識得提出攻擊假設、自動驗證,再將已證實嘅異常變成下一輪線索。呢件事值得睇,因為 AI 資安工具平時多數沿住已知漏洞類型掃描,今次就開始摸到自行提出新研究方向呢一步。

將研究員直覺拆成四段

HTTP Terminator 將研究拆成構思、驗證、確認影響同延伸發現四段。Kettle 先將 138 份 HTTP 同 SMTP RFC 拆成約 1.5 萬段短資料,減少模型俾大量舊知識帶住走;AI 再據此產生約 3 萬個去重測試向量。PortSwigger 話,系統只會喺 bug bounty 或漏洞披露計劃授權嘅網站測試,亦限制每個網域每秒少過一次請求。

呢個設計有個幾實際嘅 insight:成套系統最實際嘅作用,係反覆淘汰模型產生嘅垃圾答案,唔使指望模型一次就答中。 Kettle 初期見到模型不停重複舊手法,仲會將正常 HTTP 行為當成漏洞。靠 prompt 勸模型小心都唔可靠,最後要用獨立程式判定結果、分隔每個步驟嘅上下文,再保存完整證據,先可以壓低誤報。

HTTP Terminator 由提出假設、驗證到延伸發現嘅研究架構圖

圖片:PortSwigger

AI 已經識開新路,能力仍有明顯斷層

據 PortSwigger 公布,系統去到研究實際影響嗰一段時,已累積約 700 個有異常嘅目標,亦提出多種新 desync 觸發方式、一種新模式同一種改善利用可靠度嘅方法。研究亦涵蓋銀行、政府網上基建、機場系統同 BeyondTrust 產品部署,不過實際機構大多冇公開名稱,TechLab 冇獨立驗證受影響名單,所以唔應將呢啲案例擴寫成整個行業已普遍失守。

最有意思嘅 Shared-Parser Confusion 概念,源於 AI 留意到部分 server 可能共用程式碼處理 HTTP request 同 response,令本來只屬於 response 嘅規則意外喺 request 生效。不過 Kettle 講得好清楚:AI 提供咗線索,最後由佢親自確認同整理成完整攻擊概念。系統亦提出過幾條只有理論可能、未證明到實際影響嘅路線,反映新奇輸出同有效研究成果之間仍隔住專家判斷

PortSwigger 比較 AI、確定性程式同研究員各自負責範圍嘅示意圖

圖片:PortSwigger

CVE 有編號,公開紀錄仍未齊

另一條發現鏈指向 Apache Traffic Server。PortSwigger 話相關零時差漏洞已修補,編號係 CVE-2026-63078;不過截至 2026 年 8 月 11 日,CVE 官方 API 仍回覆紀錄不存在,Apache 公開資料亦未見受影響版本、修補版本或 CVSS 評分。換句話講,暫時只可以確認研究方公布嘅修補說法,實際版本範圍同嚴重程度仍係 [待確認],營運團隊唔好單靠個 CVE 編號判斷自己有冇受影響。

公開原始碼,唔代表下載完就全自動運作

PortSwigger 已經將 HTTP Terminator 程式碼放上 GitHub,採用 AGPL-3.0 授權。repository 列出四個主要部分,其中產生同整理測試資料嗰兩段可獨立運行;驗證部分要配合商業版 Burp Suite,後段調查亦依賴外部 MCP 組件、Burp Organizer 同獲授權目標。研究期間用過嘅資料庫冇包喺 repository,所以準確啲講,公開嘅只係核心設計同部分可執行工具,未足以一鍵重現完整研究環境。

呢點亦解釋咗點解 HTTP Terminator 暫時唔適合直接塞入企業產品。佢可以長時間大量試錯,仲會因應異常改變方向;若果授權清單、速率限制、確定性驗證同人工覆核做得鬆,誤報、服務中斷以至越界測試都可能出現。PortSwigger repository 本身亦警告,只可以對自家或明確授權系統使用,公開研究碼冇取消使用者守規矩嘅責任。

AppSec 團隊要改嘅係驗證方法

對開發者同 AppSec 團隊,最貼地嘅影響係測試範圍會擴闊。傳統 scanner 擅長重播已知 pattern,呢類 agent 就可以由協議文件、異常回應同上一輪發現再生測試方向。金融、航空、電商等依賴反向代理、快取同多層 HTTP 基建嘅機構尤其要重新檢查前後端 request 邊界處理,但個別香港機構有冇用受影響版本仍要自行核對。

防守方面,Kettle 建議前端去後端避免再用 HTTP/1.1,改行 HTTP/2 或以上;若果舊架構暫時改唔到,就要喺前後兩邊限制可接受嘅 HTTP method,同埋邊啲 method 可以帶 request body。至於導入自主研究 agent,較穩陣嘅次序係先做好獲授權資產清單、速率限制、可重複驗證同人工批准,之後先逐步放大自主範圍。


參考來源

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

分享:WhatsAppThreadsTelegramFacebook