DotSwap V1 遭利用攻擊，約 8.5 BTC 被竊，損失估計達 68.5 萬美元
DotSwap V1 遭利用攻擊，約 8.5 BTC 被竊，損失估計達 68.5 萬美元
10 月 25 日，DotSwap 交易平台的舊版 DotSwap V1 遭到攻擊，約有 8.5 BTC 被竊，事發當時價值約 68.5 萬美元。
這起事件凸顯出比特幣應用程式正面臨日益嚴峻的安全挑戰：即使使用者操作的是去中心化資產，後端授權系統、託管式流動性基礎設施，以及自動簽署服務，仍可能形成集中式的單點故障。
根據 On Nexus 發布的事件更新，受影響的平台目前已下線，團隊正調查攻擊、追蹤被竊資金，並與交易所及區塊鏈情報合作夥伴展開合作。
DotSwap V1 發生了什麼事？
DotSwap V1 採用伺服器端簽署模式管理流動性池。其流動性基礎設施透過託管式多重簽名架構運作，這意味著使用者存入的 BTC 是由平台的簽署流程控制，而不是由各個流動性提供者直接掌握。
據報導，攻擊者利用了 V1 後端中仍在運作的舊版簽署機制。在大約四個小時內，自動化腳本透過平台現有介面進行操作，逐步將資金從 V1 流動性池與使用者帳戶中轉出。
這次攻擊並非僅針對單一代幣或端點。據報導，相關腳本測試了平台的各個介面，並鎖定與 99 種 Runes 代幣相關的資產，使攻擊者得以在更廣泛的應用環境中找出並利用弱點。
估計總損失約為：
- 8.5 BTC 遭竊
- 約 68.5 萬美元資金受到影響
- DotSwap V1 的流動性提供者存款受到影響
- 平台外、由使用者自行控制的錢包未受影響
DotSwap V1 隨後已關閉。On Nexus 表示，目前正努力恢復相關服務，並將發布更完整的事件分析報告，以及針對受影響使用者的後續方案。
為什麼流動性提供者成為主要受害者？
這起事件中最重要的區別，在於平台管理的資金與使用者自行掌握的資產之間存在差異。
將 BTC 存入 DotSwap V1 的流動性提供者，必須承擔平台託管與簽署架構所帶來的風險。雖然系統採用了多重簽名控制，但簽署流程仍與後端服務相連，而這些服務可以透過應用程式介面被查詢並觸發。
這表示，單靠多重簽名保護並不足以消除營運風險。如果授權邏輯、API 權限、簽署政策或伺服器端控制設計不當，攻擊者仍可能找到方法，產生有效交易。
相較之下，將資產保存在自託管錢包中、且未存入 V1 流動性池的使用者，則未受到這起事件影響。他們的私鑰始終位於遭入侵的平台環境之外。
這項區別是理解流動性池風險的關鍵：
一個協議即使使用區塊鏈進行結算，仍可能在託管、簽署、定價、路由或存取控制等環節依賴中心化基礎設施。
因此，使用者不應只判斷某個應用程式是否「在鏈上」，還應了解簽署權限位於何處、誰掌握提款權限，以及後端系統是否能凍結或重新導向存入的資金。
一起可能由 AI 輔助的自動化攻擊案例
On Nexus 將這起事件描述為近期 AI 驅動或高度自動化攻擊趨勢的一部分。
自動化技術能大幅提升漏洞利用的速度與範圍。攻擊者不必一次手動測試一項功能，而可以透過程式自動：
- 找出暴露在外的 API 端點
- 發送大量請求
- 比較不同資產的回應
- 偵測不一致的授權行為
- 找出異常的簽署或提款路徑
- 在短時間內連續執行交易
在支援數十種代幣合約與交易路由的環境中，自動化更容易找出細微的實作差異，而這些差異在日常人工測試中可能難以察覺。
更廣泛的教訓是，安全團隊如今必須防範將傳統腳本與日益強大的 AI 代理結合起來的攻擊。API 探勘、漏洞分類、交易建構與監控等工作，都能透過自動化工具加速完成。
這一趨勢也讓速率限制、端點隔離、異常偵測、簽署政策執行，以及即時交易監控，對數位資產平台而言變得更加重要。
這起事件揭示了 Runes 基礎設施的哪些問題？
Runes 生態系擴大了可在比特幣上發行與交易的同質化資產種類。然而，支援這些資產的基礎設施仍在發展階段，許多應用程式依賴索引器、鏈下服務、託管式資金池，以及專門的交易邏輯共同運作。
這也帶來幾個主要風險：
- 對索引器的依賴： 錢包餘額與代幣狀態可能依賴第三方索引服務。
- 後端授權： 平台可能透過中心化 API 判斷某筆交易是否可以簽署。
- 託管式流動性： 使用者可能將 BTC 存入由應用程式管理的共同錢包。
- 合約與資產複雜性： 支援大量 Runes 資產會增加需要測試的路由、介面與特殊情況。
- 營運集中化： 一個遭入侵的簽署服務，可能同時影響多個資金池。
有意參與 Runes 交易或提供流動性的使用者，在存入資金前，應先檢視專案的託管模式。平台的使用者介面看似去中心化，但重要的控制功能仍可能集中在單一實體手中。
如需了解比特幣資產生態的背景，使用者可以參考 比特幣開發者文件 以及 Bitcoin Optech 電子報。這些資源會定期介紹比特幣協議、錢包與基礎設施的最新發展。
給加密貨幣使用者的實用安全教訓
1. 確認資金是否始終由你掌控
在提供流動性或存入資產前，應先確認平台是否能在沒有由你的錢包直接簽署交易的情況下移動資金。
以下問題值得事先了解：
- 存入的資金會進入由使用者控制的地址，還是平台控制的地址？
- 私鑰由誰持有？
- 簽署是在本機、硬體裝置上，還是伺服器端完成？
- 管理員能否暫停提款或更改簽署規則？
- 提款限額與監控控制是否有公開說明？
這些問題的答案，可能會實質改變該服務的風險程度。
2. 將舊版產品視為潛在攻擊面
DotSwap V1 事件說明了為什麼平台的舊版本不應繼續與現行服務連結。即使新版本採用了更強的控制措施，過時的 API、簽署路徑與帳戶權限仍可能遭到利用。
專案應透過以下措施，徹底淘汰已停止使用的產品：
- 撤銷 API 憑證
- 移除舊有簽署權限
- 停用未使用的端點
- 輪替服務金鑰
- 將舊版資料庫與正式環境系統分離
- 監控歷史基礎設施是否出現異常活動
3. 避免將資產集中在單一應用程式中
流動性提供者應考慮在不同錢包、協議與託管模式之間分散資產。將大量 BTC 集中在單一應用程式中，可能放大單次漏洞利用或營運故障所造成的影響。
這麼做無法消除協議風險，但能降低單一事件波及整個資產配置的可能性。
4. 監控錢包活動與授權狀態
使用者應定期檢查錢包餘額、已連結的應用程式、帳戶工作階段與交易紀錄。意外出現的簽署請求、不熟悉的提款地址，或來自新裝置的登入，都應視為潛在警訊。
對於高價值交易，使用者應自行確認：
- 收款地址
- 資產種類與數量
- 網路
- 交易手續費
- 應用程式網域
- 錢包顯示的最終交易詳情
5. 了解多重簽名不等於完全去中心化
多重簽名架構可以提升系統的韌性，但實際效果取決於簽署者如何分配，以及授權機制如何執行。
如果所有簽署者都由同一個組織控制、連接至同一個後端，或受同一套有缺陷的政策引擎管理，系統仍可能存在實質的中心化故障點。
安全性取決於完整的簽署架構，而不只是是否存在多個簽名。
受影響使用者應注意什麼？
與 DotSwap V1 有關聯的使用者，應提防聲稱可以提供退款、補償或緊急提款工具的釣魚訊息。攻擊者經常利用公開事件冒充專案團隊，將受害者引導至偽造網站。
受影響使用者應：
- 只透過經過驗證的專案官方管道取得資訊
- 避免在網站輸入助記詞或私鑰
- 對未經邀請的退款表格保持警惕
- 保存交易 ID 與存款紀錄
- 自行查驗區塊鏈上的交易
- 監控相關錢包地址是否出現資金移動
- 在任何簽署操作前，等待官方公布恢復或申領流程
合法的支援團隊絕不會要求使用者提供錢包助記詞，以驗證所有權或處理退款。
如需一般性的數位資產保護建議，CISA 網路安全指南提供了有關釣魚攻擊、帳戶安全與惡意活動的實用資訊。
對 DeFi 與比特幣應用程式的更廣泛影響
DotSwap V1 遭利用的事件，不只是某個存在漏洞的平台所發生的事故，也反映了加密貨幣產業中更廣泛的矛盾：應用程式可能以去中心化介面呈現給使用者，但在幕後仍依賴中心化元件。
隨著比特幣金融應用程式逐漸成熟，安全審查不能只涵蓋智慧合約程式碼。稽核也應檢查：
- API 驗證與授權
- 伺服器端簽署服務
- 金鑰管理與簽署者隔離
- 資料庫權限
- 資產索引系統
- 升級與關閉程序
- 監控與事件回應
- 緊急提款機制
到了 2025 年，自動化代理與 AI 輔助開發日益普及，使這項審查工作更加重要。如果安全控制未能同步演進，更快速的軟體開發與自動化互動可能擴大攻擊面。
對使用者而言，最可靠的保護仍然是清楚了解資產的託管狀態。直接存放在自託管錢包中的資產，與存入平台控制的資金池中的資產，面臨的是不同類型的風險。兩種模式都不是完全沒有風險，但風險來源存在實質差異。
硬體錢包如何融入更安全的自託管策略？
硬體錢包能將私鑰與連接網際網路的應用程式隔離，有助於降低伺服器端遭入侵所帶來的風險。使用者與去中心化應用程式互動時，可以透過專用簽署裝置檢查並核准交易詳情，而不是完全依賴瀏覽器介面。
OneKey 硬體錢包是為自託管流程而設計，包括離線金鑰保護與裝置上的交易確認功能。它們無法消除智慧合約風險、釣魚攻擊、惡意介面或市場波動，但能協助使用者掌控那些未被主動存入託管平台或流動性池的資產。
核心原則很簡單：在提供流動性或授權交易前，使用者應了解資金由誰控制、自己正在簽署什麼，以及平台是否能在未經直接批准的情況下移動資產。
DotSwap V1 約 8.5 BTC 的損失，再次凸顯託管架構、簽署權限與營運安全的重要性，絲毫不亞於代幣用途或交易量。在自動化程度日益提高的加密貨幣環境中，充分理解自託管機制並仔細驗證交易，仍是使用者最重要的防線。
