Bug bounty horror stories | Joran Honig (Consensys)
三句話摘要
Bug Bounty 漏洞賞金計畫的黑暗面：來自真實場景的七個失敗案例與教訓。 賞金計畫的成敗關鍵在於事前規則設計與雙方溝通品質，而非漏洞本身的技術難度——沒有清晰框架的賞金，只會讓雙方都輸。 通報方式決定結果：FA 錢包案顯示，在主網執行破壞性 PoC 再用 GitHub issue 回報，是最糟糕的漏洞披露方式，可能導致資金永久鎖定，且完全無法主張白帽保護。
重點整理
重點- 1
通報方式決定結果：FA 錢包案顯示，在主網執行破壞性 PoC 再用 GitHub issue 回報，是最糟糕的漏洞披露方式，可能導致資金永久鎖定，且完全無法主張白帽保護。
- 2
白帽行動必須先協調：白帽搶救資金失敗的案例說明，未與協議團隊同步直接上鏈操作，風險極高。最佳實踐是由團隊自行執行搶救，白帽只提供技術支援。
- 3
DAO 論壇不適合賞金談判：當漏洞超出既定賞金範圍，被迫移到公開論壇討論時，外部參與者對漏洞背景一無所知，討論快速劣化為情緒攻擊，反而損害已談妥的條款。
- 4
LLM 假報告正在破壞生態信任：AI 生成的高品質但虛假漏洞報告大量消耗協議方審核資源，導致對真實研究員採取防禦性溝通態度，進一步惡化雙方關係。
實用技巧與重點
乾貨- Kraken 案：安全公司竊取超過 300 萬美元進行「實證測試」，數週後才通報
- Skyers Swap：2024 年 11 月遭駭，損失 5,500 萬美元，黑客提出要求包含整間公司所有權
- DAO 論壇談判風險：外部社群成員對漏洞細節零了解，且有權投票降低已協商的賞金金額
- 平台工具：Immunefi 可對惡意幽靈行為（ghosting）的協議方執行「踢出平台」處罰
- 白帽安全港（Safe Harbor）協議：明確界定受保護的白帽操作場景，是避免法律風險的關鍵框架
- 反面案例：某賞金平台將漏洞報告標題上鏈，直接洩露關鍵漏洞資訊
- 常見惡意行為：「最佳實踐未遵循」類垃圾報告、LLM 生成假漏洞報告
結論
結論“賞金計畫的成敗關鍵在於事前規則設計與雙方溝通品質，而非漏洞本身的技術難度——沒有清晰框架的賞金，只會讓雙方都輸。”
完整解析
詳細Bug Bounty 賞金計畫的理論很美好，但現實中充斥各種讓雙方都頭痛的失敗場景。講者彙整了多個真實案例，試圖還原那些推特上從未被提起的另一面。
最早的案例是 FA 錢包事件：某研究員直接在主網上接管合約所有權、執行自毀函數，造成不明數量資金鎖定，事後才透過 GitHub issue 通報。這個案例的問題不在於研究員發現漏洞，而在於他選擇用「真實破壞」來證明漏洞存在，這種做法在法律上幾乎不可能主張善意。Kraken 案則更進一步：一家安全公司找到漏洞後，實際竊取超過 300 萬美元作為「測試」，並等了數週才通報。從交易所角度看，這段時間根本無法判斷是真駭客還是白帽行動，製造了巨大的運營恐慌。
協商層面的混亂同樣觸目驚心。Skyers Swap 在 2024 年 11 月被駭走 5,500 萬美元後，黑客的第一個回應竟是「我累了，明天再說要求」，隔天提出的條件則是要求取得整間公司所有權——談判就此破裂。另一個案例是某大型協議的漏洞超出了賞金計畫的既定範圍，協議方為了彌補，提議在 DAO 論壇上追加賞金。結果可想而知：論壇參與者對漏洞技術細節毫無了解，討論迅速演變成對研究員的道德指控，甚至出現要求縮水已談妥金額的聲浪。講者的結論是：賞金計畫必須在案件發生前就設計完整，一旦需要依賴公開論壇動員共識，談判空間就已蕩然無存。
對研究員而言，問題同樣存在。白帽救援失敗案例顯示，未與協議團隊事先溝通就自行上鏈搶救，不僅可能觸法，操作失誤還會直接虧損。協議方的常見惡意行為則包括：無故拖延支付、完全不回應（ghosting）、以「安全預算凍結」為由拒付。更新的問題是 LLM 的普及：AI 現在能生成措辭完整、格式正確但內容虛假的漏洞報告，大量消耗協議方的審核精力，進而讓他們對所有回報都抱持防禦甚至對抗的姿態，最終連累真正的研究員。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
