Настройка автоматического реагирования на инциденты

Аудит безопасности кросс-чейн моста

Кросс-чейн мосты — крупнейшая категория по объёму похищенных средств в истории DeFi. Ronin ($625M, март 2022), Wormhole ($320M, февраль 2022), Nomad ($190M, август 2022), Harmony Horizon ($100M, июнь 2022) — четыре взлома за один год, суммарно больше $1.2 млрд. Все атаки имели принципиально разные векторы, что говорит о системной сложности безопасности мостов.

Аудит моста — это не стандартный smart contract аудит. Он включает анализ криптографических протоколов, trust assumptions validator-сети, off-chain инфраструктуры (relayer, oracle), экономической модели и операционных процедур. Ни одна из этих областей в отдельности не покрывает полную картину рисков.

Поверхность атаки: что уникально у мостов

Cross-chain message integrity

Центральная проблема любого моста: как destination chain верифицирует, что событие на source chain действительно произошло? Разные архитектуры решают это по-разному, и каждое решение имеет специфические уязвимости.

Multisig validator модель. Threshold подпись валидаторов подтверждает события. Вектор атаки: компрометация ключей или сговор валидаторов. Ronin: 5 из 9 ключей Sky Mavis были в одном месте (infrastructure compromise + социальная инженерия через поддельное job offer).

Optimistic модель. Сообщения действительны если не оспорены. Nomad был взломан иначе: баг в инициализации позволял любому сообщению быть «доверенным» — атакующий скопировал одну уже-валидную транзакцию, заменив recipient на свой адрес, и повторил это для всех токенов.

Light client верификация. Наиболее безопасна, но дорога по газу. Аудит включает проверку корректности реализации consensus proof верификации, особенно edge cases в BFT finality.

Finality assumptions

Мост должен корректно определять finality source chain события. Преждевременная обработка (до finality) создаёт окно для double-spend через reorganization.

Аудит: проверяем что параметр requiredConfirmations в relayer соответствует реальной finality каждой поддерживаемой сети. Занижение — риск reorg атаки. Завышение — плохой UX.

Смарт-контракт анализ

Signature verification уязвимости

Это топ-1 класс уязвимостей в мостах по статистике.

Signature malleability. Стандартный ecrecover в Solidity принимает обе формы подписи (low-S и high-S). Атакующий может трансформировать подпись валидного сообщения в другую валидную подпись того же сообщения с другими v,r,s значениями. Если bridge использует hash подписи как уникальный идентификатор для replay protection — это обход защиты.

// УЯЗВИМО: прямой ecrecover
address signer = ecrecover(messageHash, v, r, s);

// БЕЗОПАСНО: OpenZeppelin ECDSA с проверкой s
address signer = ECDSA.recover(messageHash, signature);
// OZ ECDSA проверяет: require(uint256(s) <= 0x7FFFF...FFFF, "Invalid s")

Missing chain ID в domain separator. EIP-712 domain separator должен включать chainId. Без него подпись для Ethereum валидна на Polygon (одинаковый chainId если тест/prod не разделены, или если bridge задеплоен на EVM-compatible chain с тем же ID).

Отсутствие deadline в подписанном сообщении. Подпись без expiry может быть использована повторно спустя годы. Включение deadline в подписываемую структуру обязательно.

Replay protection

// Проверяем всё в одном месте до исполнения
function _validateAndMarkNonce(
    uint256 sourceChainId,
    uint256 destChainId,
    bytes32 nonce
) internal {
    require(destChainId == block.chainid, "Wrong destination chain"); // chain ID check
    require(!processedNonces[sourceChainId][nonce], "Nonce already used");
    processedNonces[sourceChainId][nonce] = true;
}

Аудит: проверяем что nonce включает source chain ID — иначе один nonce на Ethereum и Polygon независимы, и сообщение может быть реплицировано между ними.

Reentrancy в token callbacks

Некоторые токены при transfer/transferFrom вызывают callback-и (ERC-777 tokensReceived, ERC-677 transferAndCall, кастомные хуки). Если bridge вызывает transfer до обновления state (processedNonces, balances) — callback может вызвать re-entry в bridge функцию.

// УЯЗВИМО: transfer перед state update
function release(address token, address recipient, uint256 amount, bytes32 nonce) external {
    // ОШИБКА: nonce обновляется после transfer
    IERC20(token).safeTransfer(recipient, amount); // callback здесь!
    processedNonces[nonce] = true; // слишком поздно
}

// БЕЗОПАСНО: Checks-Effects-Interactions
function release(...) external {
    require(!processedNonces[nonce], "Used");
    processedNonces[nonce] = true; // сначала state
    IERC20(token).safeTransfer(recipient, amount); // потом transfer
}

Wrapped token контракт

Мост минтит wrapped токены на destination chain. Аудит wrapped token контракта:

• Кто имеет MINTER_ROLE? Только bridge контракт или также deployer?
• Есть ли cap на mint? Без cap — компрометация minter роли даёт infinite mint
• Совместимость с DeFi протоколами: нет ли fee-on-transfer или rebase логики, которая сломает bridge математику

Upgrade mechanism

Upgradeable мосты — стандарт (нужна возможность исправлять баги), но upgrade сам по себе — вектор атаки.

Вопросы для аудита:

• Есть ли timelock на upgrade? Без timelock owner может мгновенно upgrade к malicious implementation
• Кто имеет право upgrade? Только multisig? Есть ли governance?
• Storage layout: новая версия контракта может сломать существующий storage если не соблюдать правила upgrades (EIP-1967 proxy storage slots)
• Инициализация: initialize() вместо constructor() в upgradeable контрактах. Кто-нибудь может вызвать initialize() повторно если нет initializer модификатора?

Validator инфраструктура аудит

Ключевое управление

Для multisig-based мостов это наиболее критичная область. Аудит включает:

Threshold адекватность. 3 из 5 — недостаточно для моста с $100M+ TVL. Рекомендуемый минимум: 5 из 9 или 7 из 13. Wormhole имел 19 guardians с порогом 13 — компрометация 13 была технически необходима, но не произошла.

Географическое и организационное разнообразие. Все validator ключи в одной инфраструктуре (один cloud provider, одна команда) — single point of failure. Ronin: Sky Mavis управляла 5 из 9 ключей сама.

HSM usage. Ключи валидаторов должны быть в Hardware Security Module (AWS CloudHSM, Azure Dedicated HSM, физические Ledger) — не в hot environment.

Key rotation. Есть ли процедура ротации ключей? Скомпрометированный ключ без возможности ротации остаётся угрозой навсегда.

Relayer безопасность

Relayer — привилегированный off-chain компонент. Его компрометация не должна приводить к краже средств (этим должна заниматься signature verification), но может блокировать операции (DoS) или манипулировать порядком сообщений.

Аудит relayer:

• Replay protection: relayer не должен дважды отправлять одно сообщение (bridge контракт должен это отклонять, но relayer тоже не должен пытаться)
• Monitoring и alerting: реагирует ли relayer на аномалии (резкий рост объёма, необычные адреса)
• Failover: что происходит при downtime relayer? Есть ли fallback механизм для пользователей?

Экономический анализ

Мосты уязвимы не только к техническим атакам, но и к экономическим.

Liquidity imbalance атаки. Если мост использует liquidity pool модель, атакующий может дренировать pool на одной стороне, создавая состояние где bridge принимает deposits но не может исполнить withdrawals.

Price oracle manipulation. Мосты с fee в процентах от объёма используют price oracles для расчёта. Манипуляция oracle (flash loan через Uniswap TWAP с коротким периодом) может создать ситуацию с неправильными fee расчётами.

Wrapped token depeg. Wrapped токен должен всегда быть 1:1 с оригиналом. При взломе (mint без lock) wrapped токен депегируется. Есть ли circuit breaker который приостанавливает bridge при обнаружении депега?

Процесс аудита и deliverables

Аудит bridge контракта включает:

1. Manual code review (4–8 дней): каждая строка Solidity контрактов, особое внимание к signature verification, replay protection, access control, upgrade механизму
2. Automated analysis (1–2 дня): Slither, Mythril, Semgrep для систематического поиска известных паттернов
3. Integration testing (2–3 дня): Foundry fork тесты сценариев атак на mainnet-state
4. Validator infrastructure review (2–3 дня): архитектура key management, operational security
5. Economic model analysis (1–2 дня): liquidity mechanics, oracle dependencies, circuit breakers

По итогам: детальный отчёт с классификацией находок (Critical/High/Medium/Low/Informational), PoC эксплойтов для Critical/High, рекомендации по исправлению и re-verification после исправлений.

Обязательное условие деплоя: мост без прохождения аудита специализированной команды (не generic smart contract аудиторов, а именно с опытом bridge-проектов) не должен принимать TVL больше тестовых сумм. История показывает это слишком убедительно.

Сроки аудита: 2–4 недели в зависимости от сложности и объёма контрактов. Стоимость обсуждается после предоставления codebase и архитектурной документации.