Протокол Superfluid - REKT

$8.7M слито из протокола Superfluid.

Протокол управления криптовалютными потоками подвергся хакерской атаке в 06:17 +UTC 08/02/22.

Другие проекты, использовавшие сервис для выплат вкладчикам или заключения договоров условного депонирования для инвесторов, пострадали от негативного влияния на цену, вызванного тем, что злоумышленники сбросили их нативные токены.

В списке пострадавших протоколов находятся: Mai Finance (QI), Stacker Ventures (STACK), Stake DAO (SDT), и Museum of Crypto Art (MOCA).

Больше всех пострадал токен QI, сразу после дампа он упал почти на 80%, но с того момента уже восстановился до ~62% от своей цены до взлома.

@francescorenzia из Superfluid сообщил rekt.news, что атака была направлена только на кошельки, содержавшие самые большие объемы средств на платформе. Прошло некоторое время, прежде чем уязвимость была устранена, но хакер оставил нетронутыми множество ETH, USDC и DAI. Предположительно потому, что ему "хватило".

Как это произошло?

Адрес атакующего: 0x1574f7f4c9d3aca2ebce918e5d19d18ae853c090

Транзакция эксплоита: 0xdee86cae2e1bab16496a49…

Украденные активы:

19.4M QI (общая стоимость до хака - $24M) проданы за четыре транзакции за 2.3k WETH (~$6.2M)

24.4 WETH - (~$76k)

563k USDC проданы за 173 WETH

45k SDT - проданы за ~17 WETH - (~$54k)

24k STACK - проданы за ~6.2 WETH - (~$19k)

39k sdam3CRV - произведен обмен на am3CRV, затем на ~44k amDAI

1.5M MOCA - 1M из 1.5M продано за 173 WETH (~$500K)

11k MATIC - Еще не проданы.

Итого - ~$8.7M

~6 часов спустя после атаки Superfluid устранили баг с помощью Mudit Gupta.

Патч можно найти здесь.

Следующий ниже текст взят из пост-мортема самих Superfluid.

Объяснение уязвимости

Superfluid.sol, известный как хост-контракт, является контрактом, который позволяет Superfluid заключать составные соглашения (ConstantFlowAgreement, InstantDistributionAgreement) в одной транзакции, а составленные системы часто называют Super Apps.

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

В "ctx" содержится весь контекст, который необходимо знать функции согласования, в частности, кто является "msg.sender" первоначального вызова.

Именно здесь была обнаружена злосчастная уязвимость.

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

Этот механизм использовался для того, чтобы создавать индексы IDA "от имени" других счетов и выводить таким образом их токены.

Контракт эксплоитера:

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

В транзакции данного эксплоита злоумышленник использовал контракт IDA, чтобы слить фонды из других аккаунтов, используя ту же технику:

Цепочка вызовов функций

deleteAnyFlowBad

Для вызова callAgreement принято использовать заменитель ctx, чтобы последующий код соглашения solidity мог прочитать его непосредственно как аргумент "ctx".

Чтобы узнать больше об этом понятии, прочитайте About-Placeholder-Ctx).

Именно здесь злоумышленнику удалось внедрить поддельный "ctx", в котором можно было установить произвольного отправителя.

Superfluid.callAgreement

В обычном случае Superfluid.callAgreement создает ctx и ставит на него штамп (сохраняет его хэш в переменном состоянии), чтобы его можно было проверить с помощью Superfluid.isCtxValid..

ConstantFlowAgreementV1.createFlow

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

AgreementLibrary.authorizeTokenAccess

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

Но Ctx фальшивый!

Проблема заключалась в том, что, как и в эксплуатирующей функции deleteAnyFlowBad, можно внедрить поддельный ctx.

После объединения в один объект байтов с помощью Superfluid.replacePlaceholderCtx (хост не делает никаких предположений о конкретных данных соглашения), результирующий dataWithCtx теперь содержит 2 варианта ctx, легитимный и инжектированный.

Когда договор соглашения декодирует эти данные, декодер abi принимает первый (инжектированный) вариант и игнорирует оставшиеся данные, которые содержат легитимный ctx.

Чтобы решить эту проблему, Superfluid добавил шаг проверки в договор соглашения:

ISuperfluid.isCtxValid. Это проверяет декодированный ctx, сравнивая его штамп (хэш), хранящийся в хост-контракте.

Эта проверка уже была предусмотрена для обработки данных ctx, предоставляемых обратными вызовами SuperApp, но не была предусмотрена для данных, передаваемых доверенным хост-контрактом.

Superfluid связалась со злоумышленником ончейн и, согласно пост-мортему, предложение о баунти размером в $1M в обмен на возврат фондов остается в силе.

Команда также заявляет, что большинство пострадавших аккаунтов уже получили назад свои деньги, а более значительные потери QI и МОСА будут компенсироваться более поступательно.

Несмотря на то, что этот эксплоит не был самым значительным (номер 42 в нашем рейтинге), и не были потеряны средства пользователей, он примечателен тем, как он повлиял на другие протоколы.

Растущая доля инфраструктур ДАО представляет больше целей для анонимных хакеров, которые так распространены в DeFi.

Украденные деньги все еще лежат в кошельке злоумышленника.

Возьмет ли он баунти, или же оставит Superfluid ни с чем?

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

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

Дисклеймер:

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