Налаштування автоматичного реагування на інциденти

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

Кросс-чейн мости — крупнейша категорія за обсягом викрадених коштів у історії 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), економічної моделі та операційних процедур. Жодна з цих областей окремо не охоплює повної картини рисків.

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

Цілісність кросс-чейн повідомлень

Центральна проблема будь-якого моста: як 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

Мост має коректно визначати finality подій source chain. Передчасна обробка (до finality) створює окно для double-spend через реорганізацію.

Аудит: перевіряємо що параметр requiredConfirmations у relayer відповідає реальній finality кожної підтримуваної мережі. Занижання — ризик reorg атаки. Завищення — поганий UX.

Аналіз смарт-контрактів

Вразливості верифікації підписів

Топ-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")

Відсутність chain ID у domain separator. EIP-712 domain separator має включати chainId. Без нього підпись для Ethereum валідна на Polygon (однаковий chainId якщо test/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

Деякі токени викликають callback-и при transfer/transferFrom (ERC-777 tokensReceived, ERC-677 transferAndCall, кастомні хуки). Якщо bridge викликає transfer до оновлення state (processedNonces, balances) — callback може вхідити в 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

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 — недостатньо для моста з TVL $100M+. Рекомендований мінімум: 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 також не має намагатися)
• Мониторинг та alerting: реагує ли relayer на аномалії (різкий рост об'єму, необичні адреси)
• Failover: що станеться при downtime relayer? Є ли fallback механізм для користувачів?

Економічний аналіз

Мости вразливі не тільки до технічних атак, але й до економічних.

Атаки через liquidity imbalance. Якщо мост використовує liquidity pool модель, атакуючий може дренувати pool на одній стороні, створюючи стан де bridge приймає deposits але не може виконати withdrawals.

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

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

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

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

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

За результатами: детальний звіт з класифікацією findings (Critical/High/Medium/Low/Informational), PoC експлойтів для Critical/High, рекомендації по виправленню та re-verification після виправлень.

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

Термін аудиту: 2–4 тижні залежно від складності та обсягу контрактів. Вартість обговорюється після надання codebase та архітектурної документації.