Проведення пентесту криптопроекту

Проведення пентеста криптопроекту

Пентест криптопроекту — це не стандартний web application pentest плюс Slither. Це багатирівневої роботи: смарт-контракти, інфраструктура, frontend, bridges, backend API та соціальна інженерія. Ronin Bridge втратив $625M не через вразливість у контракті — через компрометацію 5 з 9 validator ключів через spear phishing. Ефективний пентест покриває всі вектори атаки.

Scope та методологія

Перше ніж починати, чітко визначити scope. Типові компоненти криптопроекту:

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

Статичний аналіз

Початок будь-якого пентесту контрактів — автоматизовані інструменти:

# Slither — static analyzer від Trail of Bits
slither . --print human-summary
slither . --detect reentrancy-eth,reentrancy-no-eth,arbitrary-send-eth

# Mythril — symbolic execution
myth analyze contracts/Vault.sol --solv 0.8.20

# Aderyn — Rust-based аналізатор, швидший за Slither на великих кодовых базах
aderyn .

# 4naly3er — спеціалізується на gas та security паттернах

Автоматичні інструменти знаходять низько висяче плід: неверний порядок операцій, неиспользовані return values, reentrancy в очевидних місцях. Критичні вразливості вони знаходять рідко.

Ручний аналіз контрактів

Фокусні області для мануального review:

Access control: хто може викликати привільовані функції? Правильно ли реалізовані onlyOwner / AccessControl? Немає ли backdoor через конструктор або initializer?

// Класична помилка: initializer можна викликати повторно
contract VulnerableProxy {
    bool private initialized;

    function initialize(address _admin) external {
        // ВРАЗЛИВІСТЬ: немає перевірки !initialized
        admin = _admin;
    }
}

// Правильно:
function initialize(address _admin) external {
    require(!initialized, "Already initialized");
    initialized = true;
    admin = _admin;
}

Price oracle manipulation: використовуються ли spot ціни замість TWAP? Можлива ли flash loan атака на oracle?

Signature validation: коректна перевірка EIP-712 підписей? Replay attack protection через nonce або chainId?

Економічні атаки

Flash loan атаки на AMM протоколи вимагають розуміння механіки пулів:

// Симуляція flash loan атаки через Foundry
// forge test --match-test testFlashLoanAttack -vvv

function testFlashLoanAttack() public {
    // 1. Беремо flash loan 1000 ETH
    uint256 flashAmount = 1000 ether;
    vm.deal(address(attacker), flashAmount);

    uint256 priceBefore = target.getPrice();

    // 2. Маніпулюємо пулом — різко купуємо токен
    attacker.manipulatePool(flashAmount);

    uint256 priceAfter = target.getPrice();
    console.log("Price manipulation:", priceBefore, "->", priceAfter);

    // 3. Експлуатуємо протокол з маніпульованою ціною
    uint256 profit = attacker.exploit();

    // 4. Повертаємо flash loan
    attacker.repayFlash(flashAmount);

    assertGt(profit, 0, "Attack should be profitable");
}

Frontend безпека

Wallet drainer injection

Найпоширеніша атака на dApp користувачів — компрометація frontend для внедрення вредоносних approve транзакцій:

Supply chain атака: зловмисник компрометує npm пакет (web3-utils, ethers fork) або CDN, з якого подгружається frontend код. Внедрений скрипт замінює адресу получателя в транзакціях або підсовує setApprovalForAll для NFT контракту.

Перевірка у пентесті:

• Наявність Subresource Integrity (SRI) хешів для зовнішніх скриптів
• Content Security Policy заголовки
• Lockfile (package-lock.json, yarn.lock) з integrity хешами
• Використовувані CDN і їх цепь довіри

Clipboard hijacking: скрипт замінює адресу у буфері обміну при копіюванні. Просте DOM injection через XSS.

Інфраструктурний аудит

RPC endpoint безпека

Багато протоколів утримують власні Ethereum ноди. Перевіряємо:

# Відкритий ли RPC публічно?
curl -X POST http://node-ip:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_accounts","id":1}'

# Якщо повертає аккаунти — критична вразливість

# Перевірка methods whitelist
curl -X POST http://node-ip:8545 \
  -d '{"method":"admin_nodeInfo","id":1}'  # має бути заблоковано

Приватні ключі та секрети

Аудит управління ключами:

• Де зберігаються deploy ключи? (HSM, AWS KMS, локальний файл?)
• Хто має доступ до multisig? Используется ли hardware wallet?
• Чи є .env файли з ключами у репозиторії (git історія)?
• Чи були ключі заротовані після звільнення сотрудників?

# Пошук секретів у git історії
git log -p --all | grep -E "(private_key|PRIVATE_KEY|mnemonic|MNEMONIC)" | head -20

# TruffleHog — спеціалізований інструмент
trufflehog git file://. --only-verified

# GitLeaks
gitleaks detect --source . -v

Bridge та cross-chain специфіка

Bridge контракти — найвисокорисковий компонент. Специфічні перевірки:

Replay attack: одна й та сама signed message може бути використана на кількох чейнах. Підпись має включати chainId та унікальний nonce.

Validator key management: скільки validator ключів потрібно компрометувати для атаки? Ronin Bridge мав 9 валідаторів, 5 контрольованих однією організацією (Axie Infinity / Sky Mavis). Ефективний threshold був 2/2, не 5/9.

Finality assumptions: bridge має дочекатися finality блоку перед мінтингом на destination chain. Для Ethereum — 12+ блоків (PoS finality). Для BSC — більше через інший консенсус.

Звіт про пентест

Структура фінального звіту:

Critical: пряма втрата коштів, можлива миттєва експлуатація
High: значний ризик за певних умов
Medium: логічні помилки, потенційні DoS вектори
Low/Informational: порушення best practice, поліпшення

Для кожної findings:

• Опис вразливості
• Proof of Concept (код або кроки воспроізведення)
• Потенційний impact
• Рекомендації по виправленню
• Статус після ремедіації

Пентест — це snapshot. Протокол міняється, новий код вимагає нового аудиту. Найкращі протоколи (Uniswap, Aave) проводять аудит кожного значного оновлення та підтримують bug bounty програми через Immunefi для постійного покриття.