№10: Инцидент с ThirdWeb: несовместимость доверенных модулей привела к обнаружению уязвимости

5 декабря 2023 года известная платформа для разработки Web3-приложений Thirdweb сообщила о критических уязвимостях в безопасности своих готовых смарт-контрактов. Этот серьезный изъян затронул все токены стандартов ERC-20, ERC-721 и ERC-1155, развернутые с использованием этих конкретных уязвимых контрактов. В дни, последовавшие за раскрытием информации, токены, развернутые с помощью данных контрактов, стали подвергаться серии атак, что подчеркнуло всю серьезность имеющейся несовместимости.

Понимание уязвимости смарт-контрактов ThirdWeb

Первопричина инцидента ThirdWeb кроется в непредвиденном взаимодействии двух фундаментальных компонентов разработки смарт-контрактов: ERC-2771 и реализации Multicall от OpenZeppelin. Чтобы полностью осознать суть уязвимости, важно сначала понять каждый компонент по отдельности, а затем проследить, как их взаимодействие создало вектор для атаки.

ERC-2771: Метатранзакции и доверенные ретрансляторы

EIP-2771 определяет протокол на уровне контракта, который позволяет контрактам-получателям (Recipient) принимать метатранзакции через доверенные контракты-ретрансляторы (Forwarder). Этот стандарт крайне важен для улучшения пользовательского опыта, поскольку он позволяет третьим сторонам (ретрансляторам) оплачивать комиссию за газ от имени пользователей, избавляя их от необходимости владеть нативными токенами блокчейна.

На практике широкое распространение получила реализация ERC2771Context от OpenZeppelin. Её основная функциональность заключается в том, что последние 20 байт calldata от доверенного ретранслятора интерпретируются как фактический _msgSender(). Для разработчиков, использующих эту библиотеку, общепринятой практикой является замена всех прямых обращений к msg.sender на _msgSender(), чтобы обеспечить совместимость с метатранзакциями. Аналогично, _msgData() используется для получения исходных данных транзакции без учета добавленной информации об отправителе.

function _msgSender() internal view virtual override returns (address) {
    uint256 calldataLength = msg.data.length;
    uint256 contextSuffixLength = _contextSuffixLength();
    if (isTrustedForwarder(msg.sender) && calldataLength >= contextSuffixLength) {
        return address(bytes20(msg.data[calldataLength - contextSuffixLength:]));
    } else {
        return super._msgSender();
    }
}

function _msgData() internal view virtual override returns (bytes calldata) {
    uint256 calldataLength = msg.data.length;
    uint256 contextSuffixLength = _contextSuffixLength();
    if (isTrustedForwarder(msg.sender) && calldataLength >= contextSuffixLength) {
        return msg.data[:calldataLength - contextSuffixLength];
    } else {
        return super._msgData();
    }
}

Multicall: Пакетная обработка транзакций для повышения эффективности

Функциональность Multicall позволяет пользователям объединять несколько вызовов функций в одну транзакцию, что значительно снижает затраты на газ и повышает эффективность транзакций. MulticallUpgradeable от OpenZeppelin — популярная реализация для этих целей. Она принимает массив байтов данных (calldata) и выполняет delegatecall для каждого элемента, запуская их в контексте вызывающего контракта.

function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results) {
    results = new bytes[](data.length);
    for (uint256 i = 0; i < data.length; i++) {
        results[i] = _functionDelegateCall(address(this), data[i]);
    }
    return results;
}

(Примечание: Описанная здесь ошибка была исправлена в более поздних версиях Multicall от OpenZeppelin.)

Несовместимость: Конфликт ERC-2771 и Multicall

Суть уязвимости смарт-контрактов в инциденте с ThirdWeb проистекает из критического несоответствия в том, как данные вызовов (calldata) обрабатываются стандартами ERC-2771 и Multicall. ERC-2771 ожидает, что доверенный ретранслятор упакует данные сообщения и информацию об отправителе вместе. Затем контракт-получатель использует _msgData() и _msgSender(), чтобы правильно распаковать эту информацию.

Однако функция Multicall в своей уязвимой версии не была рассчитана на совместимость с тем, как ERC-2771 упаковывает данные для метатранзакций. В частности, когда Multicall обрабатывает пакет вызовов, он должен был корректно извлечь _msgSender() из первоначальной метатранзакции, а затем добавлять эту информацию об отправителе к данным каждого отдельного вызова перед их исполнением. Этот важный шаг отсутствовал.

Поскольку информация об отправителе не добавлялась должным образом к данным каждого подвызова, обрабатываемого Multicall, контекст ERC-2771 в целевом контракте пытался распаковать информацию об отправителе из последних 20 байт _msgData() самого подвызова. Важно отметить, что злоумышленник мог контролировать эти последние 20 байт. Это позволяло атакующему создать специфические данные вызовов, которые при обработке функцией Multicall и последующей интерпретации контрактом с поддержкой ERC-2771 выполняли произвольную логику с подделанным значением _msgSender() (например, адрес, контролируемый злоумышленником, или даже адрес пула самого протокола). Это фактически обходило предназначенные проверки безопасности и нарушало ожидания, установленные обеими спецификациями, что приводило к несанкционированным действиям.

Инцидент с ThirdWeb: Анализ атаки и эксплуатации

Давайте рассмотрим пример из реальной жизни, связанный с использованием данной уязвимости в смарт-контрактах ThirdWeb, с помощью транзакции атаки, проанализированной платформой Phalcon от BlockSec.

Стратегия злоумышленника заключалась в манипуляции _msgSender() для выдачи себя за пул Uniswap, что позволило истощить его баланс токенов.

• Шаг 1: Первичное получение токенов. Атакующий начал с обмена 5 WETH на 3 455 399 346 токенов TIME на децентрализованной бирже. Это дало необходимые токены для последующей манипуляции.

• Шаг 2: Исполнение вредоносного Multicall. Это суть эксплойта. Злоумышленник обратился к доверенному ретранслятору со специально подготовленными байтами данных, предназначенными для использования несовместимости ERC-2771 и Multicall. Когда эти данные были обработаны функцией Multicall, была вызвана функция burn контракта токена TIME. Важно отметить, что из-за уязвимости _msgSender() был неверно интерпретирован как адрес пула Uniswap. Это позволило злоумышленнику фактически сжечь значительную часть токенов TIME, хранившихся в пуле Uniswap, без реального разрешения. Платформа BlockSec Phalcon предоставляет детальное отслеживание транзакций для визуализации этого процесса.

  

  На изображении выше показано, как обрабатывается вызов Forwarder.execute от злоумышленника. Функция multicall получает массив байтов, что затем приводит к вызову функции burn с подделанным _msgSender().

  

  Этот детальный вид из Phalcon показывает bytes[] длиной 1, используемый в качестве данных для вызова контракта, что приводит к выполнению функции burn под ложным _msgSender().

• Шаг 3: Манипуляция ценой. Сжигая большое количество токенов TIME из пула Uniswap, злоумышленник радикально снизил ликвидность пула для TIME. Это искусственное сокращение предложения привело к резкому росту цены TIME по отношению к WETH внутри пула.

• Шаг 4: Прибыльный арбитраж. При искусственно завышенной цене TIME злоумышленник обменял свои оставшиеся 3 455 399 346 токенов TIME обратно на 94 WETH, получив существенную прибыль на манипуляции ценой.

Эта последовательность событий демонстрирует изощренную атаку, использующую тонкую уязвимость смарт-контракта, возникшую из-за несовместимости модулей.