Резюме
Platypus Finance — это AMM-протокол в блокчейне Avalanche. Он подвергался атакам три раза, а именно:
- 17 февраля 2023 года произошёл взлом из-за некорректной проверки платёжеспособности, что привело к общим потерям около $9,05 млн. Из них $2,4 млн были спасены с помощью BlockSec. Примерно 380 тыс. токенов застряли в контракте Aave, а затем были возвращены.
- 12 июля 2023 года произошёл взлом, в результате которого было потеряно около $50 тыс. из-за игнорирования разрыва цен между стейблкоинами.
- 12 октября 2023 года протокол пострадал от атак с манипуляцией ценой, потери составили около $2,2 млн. После переговоров с эксплуататором 90% украденных средств были возвращены.
Проекту повезло пережить все эти атаки. Наш анализ этих трёх эксплойтов показывает, что логических изъянов можно было избежать при проведении тщательного аудита или использовании более активных мер безопасности.
Атака первая
Чтобы понять этот инцидент безопасности, необходимо разобраться в рабочем процессе нескольких смарт-контрактов. Общий процесс выглядит так:
- Пользователь может внести токен в пул, чтобы стать LP и получить LP-токен.
- LP-токен можно застейкать в MasterPlatypus для получения вознаграждений. В процессе этого LP-токен будет переведён в контракт MasterPlatypus.
- LP-токен можно использовать в качестве залога для заимствования других активов с целью повышения эффективности использования активов.
На следующем рисунке показаны взаимодействия.

Анализ уязвимости
Уязвимость существует в функции с именем emergencyWithdraw внутри контракта MasterPlatypus. В экстренных случаях эта функция должна использоваться для вывода застейканных LP-токенов из контракта MasterPlatypus. В этой функции контракт проверяет, является ли пользователь Solvent (платёжеспособным), чтобы разрешить вывод. Логика проверяет, есть ли у пользователей какой-либо плохой долг (т. е. может ли залог покрыть долг). Если нет, пользователи могут вывести застейканные LP-токены.
Однако эта логика ошибочна. То, что пользователь является Solvent, означает лишь то, что залог пользователя может покрыть его долг. Однако это НЕ проверяет, останется ли пользователь платёжеспособным после экстренного вывода застейканных токенов. Злоумышленник может воспользоваться этим изъяном, чтобы занять активы, а затем экстренно вывести застейканные LP-токены также (без погашения долгов). См. подробный анализ в блоге Immunefi.


Анализ атаки
Мы используем транзакцию атаки в качестве примера, чтобы показать весь процесс атаки.
Шаг 1: Взять флеш-займ в 44 миллиона USDC от AAVE

Шаг 2: Внести 44 миллиона USDC в пул, чтобы получить LP-USDC

Шаг 3: Внести LP-USDC в MasterPlatypus

Шаг 4: Использовать LP-USDC в качестве залога для заимствования USP

Шаг 5: Выполнить функцию emergencyWithdraw, чтобы запустить атаку
Злоумышленник получает LP-USDC, не погасив долг по USP.

Шаг 6: Вывести LP-USDC из пула, чтобы получить USDC

Шаг 7: Продать USP ради прибыли

Однако прибыль осталась внутри контракта атаки. На самом деле злоумышленник мог настроить новый адрес получателя для свопа, чтобы получить прибыль.
Спасательная операция BlockSec
Мы обнаружили, что злоумышленник оставил прибыль внутри контракта атаки. Кроме того, внутри контракта атаки не было логики для вывода активов. Однако мы обнаружили уязвимость в контракте атаки, которую можно было использовать, чтобы "взломать в ответ" и вывести часть активов внутри контракта.
В частности, отсутствовал контроль доступа к функции обратного вызова флеш-займа, что означало, что любой мог вызвать эту функцию обратного вызова. Это также является коренной причиной многих атак на MEV-ботов.
Кроме того, внутри функции обратного вызова контракт атаки одобряет (approve) токен USDC контракту пула Platypus finance. А этот контракт пула является обновляемым (upgradable)!

Объединив два вышеуказанных фактора, мы можем спасти USDC внутри контракта атаки следующим образом:
- Обновить контракт пула Platypus finance, чтобы включить логику для вывода USDC внутри контракта
- Вызвать обратный вызов контракта атаки, чтобы одобрить USDC контракту пула
- Контракт пула может заменить любую функцию (которая будет выполнена контрактом атаки) для перевода USDC из контракта атаки (поскольку контракт атаки одобрил USDC контракту пула).
Вот транзакция для спасения 2,4 миллиона USDC.

Две другие атаки
Пожалуйста, обратитесь к следующим ссылкам для получения более подробной информации о двух других атаках.
-
Атака-II: 11 июля 2023 года. Протокол предполагает, что соотношение между USDC и USDT составляет 1:1, что отклоняется от рыночных колебаний, что приводит к ошибочной логике вывода. Ссылка на одну транзакцию атаки. Их было несколько.
-
Атака-III: 12 октября 2023 года, из-за манипуляции
cashиliability, что повлияло на цену свопа. [Первая транзакция атаки | Вторая транзакция атаки]
Резюме
Три атаки эксплуатировали различные уязвимости в протоколе. Несмотря на то, что протокол был проверен некоторыми другими поставщиками аудита, злоумышленник всё же нашёл лазейку и успешно эксплуатировал протокол. К счастью, часть активов удалось спасти, но нельзя рассчитывать на то, что удача будет сопутствовать всегда. Необходимо принять больше мер безопасности, включая мониторинг атак и автоматическое реагирование, чтобы защитить протокол и активы пользователей.
Читайте другие статьи из этой серии:
- Вступление: Топ-10 «замечательных» инцидентов безопасности в 2023 году
- №1: Сбор урожая с MEV-ботов путём эксплуатации уязвимостей в Flashbots Relay
- №2: Инцидент Euler Finance: крупнейший взлом 2023 года
- №3: Инцидент KyberSwap: мастерская эксплуатация ошибок округления с чрезвычайно тонкими вычислениями
- №4: Инцидент Curve: ошибка компилятора порождает ошибочный байт-код из безобидного исходного кода
- №6: Инцидент Hundred Finance: катализатор волны эксплойтов, связанных с точностью, в уязвимых форкнутых протоколах
- №7: Инцидент ParaSpace: гонка со временем, чтобы предотвратить самую критическую атаку в отрасли на сегодняшний день
- №8: Инцидент SushiSwap: неуклюжая попытка спасения приводит к серии атак-подражателей
- №9: MEV-бот 0xd61492: от хищника до жертвы в изощрённом эксплойте
- №10: Инцидент ThirdWeb: несовместимость между доверенными модулями раскрывает уязвимость



