Meerkat Finance - BSC - REKT

Если хорошо подумать, то это должно было случиться.

Впечатляющий дебют, первый крупный эксплоит на BSC, а Meerkat Finance отправляется прямиком на третью строчку на нашей доске почета.

Операция продлилась всего один день, за это время Meerkat Finance обчистили с помощью тактики рагпул на 13 миллионов BUSD и что-то около 73,000 BNB. На данный момент ущерб оценивается в $31 миллион.

Мы наблюдали за стремительным бегом Binance Smart Chain, сравнимым с летом DeFi Эфириума. Теперь, когда их коды-копии Эфириума накопили достаточно капитала, они вошли в фазу рагпулов.

За развитием событий интересно будет понаблюдать.

Свернет ли команда CZ свою корпоративную цепь, или оставит пользователей терпеть убытки?

Эта сусличья афера не оставила ворам возможности скрыться.

Куда они побегут на такой маленькой цепи? Binance перекрыла мосты, и даже bscscan.com ненадолго упал. Из-за большого ли трафика, или же это был отвлекающий маневр?

Meerkat Finance сначала заявил, что это была хакерская атака, а потом удалил свои учетные записи и предоставил пользователям BSC винить самих себя. Или, может, Binance.

Мы выражаем нашу искреннюю благодарность 0xdeadf4ce.

• Meerkat Finance Deployer апгрейдил 2 хранилища проекта.
• Адрес атакующего выполнил permissionless initialization function через прокси Vault (хранилища), в результате чего кто угодно мог стать владельцем Хранилища [2]
• Затем атакующий опустошил Хранилища с помощью функции с подписью 0x70fcb0a7, которая принимает адрес токена как инпут. Декомпиляция апгрейда смарт-контракта показала, что одного использования этой функции хватило, чтобы владелец смог вывести средства на свой счет.

Обычно, если у контракта есть функция, которая позволяет владельцу извлечь активы, которые активно используются в стратегии/хранилище, значит вы доверяете команде этого проекта.

Они могут вытащить вилку из розетки в любой момент.

Вот почему такие проекты как Yearn добавляют проверки, как на изображении внизу. Это чтобы команда могла спасти только те средства, которые не используются в активах стратегии/хранилища.

Оба пострадавших Хранилища использовали паттерн Transparent Proxy Unpgrade от OpenZeppelin. Он позволял апгрейдить логику Хранилища до новой логической имплементации с помощью функции upgradeTo (address newImplementation) на уровне прокси Хранилища.

Предыдущая имплементация Хранилища BUSD находится здесь: 0x49509a31898452529a69a64156ab66167e755dfb, Предыдущая имплементация WBNB находится здесь: 0x3586a7d9904e9f350bb7828dff05bf46a18bb271. Оба контракта проверенные и достаточно незаметные.

Meerkat Finance Deployer вызывает upgradeTo() дважды:

• в блоке 5381239, установив имплементацию Хранилища WBNB на 0x9d3a4c3acee56dce2392fb75dd274a249aee7d57
• в блоке 5381246, установив имплементацию Хранилища BUSD на 0xb2603fc47331e3500eaf053bd7a971b57e613d36

Это изменило логику Хранилища с целью ввести две важные функции, которые изначально не входили в имплементацию.

• init(address owner)
• Из декомпиляции байт-кода следует, что эта функция установила адрес на слоте памяти 0 на значение адреса функции.

Здесь нет проверки разрешения, из-за чего только что добавленная функция становится главной задней дверью всех Хранилищ.

Использование специальных паттернов Initializer на прозрачных прокси - это хорошая практика. Она была применена на первых имплементациях Хранилищ. Поэтому трудно представить, что метод unit() был добавлен с какой-то другой целью кроме спланированной кражи средств из Хранилищ.

• 0x70fcb0a7(address _param1)

Исходный код недоступен. В декомпилированном источнике поставлено ограничение, можно только проверить, что caller равен слоту памяти 0, установленному по unit() method и пересылать balanceOf() на контракт токена, поставляемого param1 и использующего адрес Хранилища как цель запроса. Обе функции не входили в предыдущие имплементации Хранилищ.

Сравнивая размер байт-кода старой и новой имплементаций, можно заметить, что новая имплементация занимает лишь 1/4 размера предыдущей логики.

Потому как Meerkat Finance Deployer делал все апгрейды, самой вероятной версией, учитывая все аспекты данных в цепи, был намеренный «rug pull», но все же теорию, что приватный ключ был скомпрометирован, не стоит сбрасывать со счетов.

В момент написания статьи средства частично распределили между разными адресами и отправили, видимо, в сторону Binance Bridge, который принадлежит обменнику Binance.

Мост Binance.org приостановлен, видимо, чтобы помешать перевести деньги на другие цепи.

Хронология событий (04.03.2021)

04-мар-2021 08:53:10 +UTC Meerkat Finance Deployer проводит апгрейд Хранилища WBNB в контракт 0x9d3a4c3acee56dce2392fb75dd274a249aee7d57

04-мар-2021 08:53:31 +UTC Meerkat Finance Deployer проводит апгрейд Хранилища BUSD в контракт 0xb2603fc47331e3500eaf053bd7a971b57e613d36

04-мар-2021 08:54:31 +UTC Атакующий вызывает method 0x70fcb0a7 в Хранилище BUSD, чтобы вывести 13,968,039 BUSD

04-мар-2021 08:54:55 +UTC Атакующий вызывает method 0x70fcb0a7 в Хранилище WBNB чтобы вывести 73,635 WBNB

Та же партия разыгрывается на других цепях, но баланс сил не равный. Грабителям негде спрятаться, потому что CZ следит за ними и мосты горят.

Даже в группе Meerkat_Rugpull в Телеграм, участники чата не могли договориться о том, как бы они хотели, чтобы Binance разобрался в этой ситуации.

Мог ли Binance отмотать цепь и возместить ущерб пользователям?

Ответ не так очевиден - 21 таинственный валидатор теоретически могли бы организовать возврат, но это маловероятно. Это бы только подлило масла в огонь проблем CeDeFi и добавило работы юристам BSC (которые уже и так на нервах).

Binance скорее всего предусмотрела план действий при таком развитии событий. То, как они разберутся в этой ситуации, создаст прецедент.

Это не первый многомиллионный рагпул на BSC, но это первый случай после появления PancakeSwap и пришедшего с ним большого количества пользователей.

Забудьте о том, что кто-то из Binance придет, найдет раздающего merkle и вернет средства. Деньги исчезли.

Так мы узнали, что протоколы на BSC не безопаснее, чем на Эфириуме.

CZ не спасет вас. Транзакции у них дешевле, но зато нет оригинальных разработок.

Что станет с этой корпоративной цепью, когда запустят Eth L2?

REKT представляет собой общественную площадку для анонимных авторов. Мы не несём ответственность за выражаемые точки зрения или контент на этом веб-сайте.

Пожертвование (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C

Дисклеймер:

REKT не несет никакой ответственности за любое содержание, размещенное на нашем Веб-сайте или имеющее какое-либо отношение к оказываемым нами Услугам, независимо от того, было ли оно опубликовано или создано Анонимным Автором нашего Веб-сайта или REKT. Не смотря на то, что мы устанавливаем правила поведения и нормы публикаций для Анонимных Авторов, мы не контролируем и не несем ответственность за содержание публикаций Анонимных Авторов, а также за то, чем делятся и что передают Авторы с помощью нашего Сайта и наших Сервисов, и не несем ответственность за любое оскорбительное, неуместное, непристойное, незаконное или спорное содержание, с которым вы можете столкнуться на нашем Веб-сайте и на наших Сервисах. REKT не несет ответственность за поведение, будь то онлайн или офлайн, любого пользователя нашего Веб-сайта или наших Сервисов.