Aurora устраняет две уязвимости

10 и 16 июня 2022 г. команда Aurora Labs получила два важных отчета об ошибках

Blog post cover

10 и 16 июня 2022 г. команда Aurora Labs через программу вознаграждения за обнаружение ошибок (на платформе Immunefi) получила два отчета о критических ошибках.

За ценный вклад в обеспечение безопасности для пользователей сети Aurora оба хакера получили максимальное предусмотренное программой вознаграждение — сумму в $1 млн в токенах Aurora, которые будут разблокироваться постепенно в течение одного года.

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

Часть 1. Вывод средств из EthCustodian без сжигания

Описание уязвимости

Злоумышленник может вывести активы из пула Rainbow Bridge на Ethereum, не сжигая соответствующие активы на стороне NEAR/Aurora. Это может помешать законному выводу средств пользователями в будущем (когда в пуле останется недостаточно средств).

Проблема

Уязвимость была вызвана тем, что мост использует возвращаемые движком значения для сжигания на Aurora, которые затем указывают пулу на освобождение средств на стороне Ethereum. Однако, поскольку контракт движка содержит EVM, Тьюринг-полную виртуальную машину, это означает, что злоумышленник может заставить движок создать выходные данные, которые выглядят как событие сжигания на Aurora, хотя на самом деле это событие не произошло. Поддельные выходные данные затем используются для вывода средств из пула на Ethereum.

Решение

В качестве временного решения мы реализовали проверку в движке, запрещающую выходные данные, которые могли быть синтаксически проанализированы как событие вывода из пула моста (конечно, за исключением фактической функции вывода). Это закрывает уязвимость, но слегка «по-хакерски». Долгосрочное решение (которым сейчас занимается команда моста) состоит в том, чтобы мост работал с доказательствами состояния NEAR (т.е. фактическими балансами токенов) вместо доказательств выходных данных транзакций.

В качестве примечания: причина, по которой использование выходных данных транзакций в качестве доказательства событий в мосте не является безопасным, заключается в том, что Тьюринг-полная виртуальная машина совмещена с логикой обслуживания моста. В этом отчете об ошибке говорилось о том, что ETH находится под угрозой, и этого можно было бы полностью избежать, если бы события генерировались из отдельного контракта из движка (это отделение логики ETH NEP-141 от остальной части движка уже обсуждалось на форуме Aurora).

Это изменение предотвратило бы обнаруженную ошибку, но тот же принцип применим и к краже токенов ERC-20 при работе с мостом. Следовательно, аналогичным образом события моста должны были приходить от отдельных учетных записей, содержащих логику NEP-141 (например, dac17f958d2ee523a2206206994597c13d831ec7.factory.bridge.near), а не от самого движка. Ключевым моментом является то, что всегда опасно совмещать конфиденциальную бизнес-логику с Тьюринг-полной виртуальной машиной, принимающей произвольные пользовательские входные данные. Это надо иметь в виду в будущем.

Часть 2. Ft_on_transfer

Описание уязвимости

Поток для передачи через мост токенов NEP-141 из NEAR в Aurora в качестве токенов ERC-20 может быть использован злоумышленником для кражи ETH с любого адреса на Aurora. Примечание: этот же поток используется для передачи через мост токенов ERC-20 между Ethereum и Aurora, поскольку это делается путем передачи через мост токена ERC-20 из Ethereum в NEAR как NEP-141, а затем токен из NEAR передается в Aurora. Злоумышленник должен нацеливаться на адреса индивидуально, и при каждой попытке атаки может быть украдено не более 18,4 ETH (даже если баланс целевого адреса выше).

Проблема

Проблемной частью передачи NEP-141 через мост является возможность взимать комиссию (выраженную в ETH) с получателя. От получателя никогда не требуется одобрять эту плату, и из-за свободно доступного характера моста любой пользователь может перевести через мост любой токен. Таким образом, злоумышленник может создать бесполезный токен NEP-141 на NEAR, перевести его в Aurora, а затем начать отправлять его на целевые адреса в Aurora, взимая комиссию. Поскольку токен NEP-141 ничего не стоит, а транзакции на NEAR дешевы, это означает, что злоумышленник может получить ETH с адресов Aurora практически бесплатно.

Основная причина проблемы

Основной причиной действительно является ошибка проектирования. В проекте ни при каких условиях не должны возникать ситуации, когда с получателя взимается плата, на которую он не давал согласие. Цель этой платы состояла в том, чтобы позволить внешнему интерфейсу моста покрыть стоимость NEAR по переводу токенов ERC-20 из Ethereum в Aurora (у типичного пользователя нет учетной записи NEAR, только адрес Aurora, и эта операция по переводу принципиально происходит на NEAR, а не на EVM Aurora). Однако эта плата так и не была включена, потому что работа моста субсидируется через валидатора Aurora на NEAR.

Решение

Поскольку плата никогда не использовалась на законных основаниях внешним интерфейсом моста, мы просто удалили логику, которая устанавливает ненулевую плату. Чтобы избежать подобных проблем в будущем, мы позаботимся о том, чтобы пользователь, который платит комиссию, был обязан явным образом согласиться с ней (например, подписав транзакцию).

О сети Aurora и ее программе вознаграждения

Сеть Aurora сосредоточена на смарт-контрактах и веб-приложениях, и ее программа вознаграждения за обнаружение ошибок приветствует всех белых хакеров, желающих внести свой вклад в глобальную безопасность web3 и получить за это вознаграждение.

Эта программа направлена на профилактику:

  • потери активов, хранящихся на Rainbow Bridge;
  • потери любых пользовательских средств, будь то в состоянии покоя или в движении;
  • постоянной заморозки средств;
  • потери средств системы управления;
  • невозможности вызова смарт-контракта;
  • хищения и заморозки невостребованного дохода в любом размере.

Это уже не первый случай, когда программа доказывает свою полезность — первое сообщение о критической ошибке было получено 26 апреля 2022 года. Мы также опубликовали тогда подробную статью об этой проблеме, которую можно прочитать здесь.

Хотите узнать больше о самой программе вознаграждения за обнаружение ошибок? Переходите на Immunefi.

Автор: Майкл Бирч (Michael Birch) Github / LinkedIn

This site uses cookies.
Read more