Pump столкнулся с внутренней атакой, убытки могут составить до 2 миллионов долларов

Недавно платформа Pump столкнулась с внутренним инцидентом атаки, который привел к потерям средств на платформе. В этой статье мы проанализируем и разберем детали этого события.

Анализ процесса атаки

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

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

Анализ жертв

В этом инциденте платформа займов под залог не понесла убытков, так как займ был возвращен в том же блоке. Кроме того, токены, уже размещенные на бирже, не должны пострадать, поскольку их ликвидность уже заблокирована.

На самом деле пострадали те пользователи, которые приобрели новые токены, еще не полностью заполнившие пул ликвидности, до того, как произошло нападение. Их вложенные SOL были похищены злоумышленниками, что вызвало огромные убытки. Хотя первоначально оценивалось, что убытки могут составить до 80 миллионов долларов, но по последним данным фактические убытки составили около 2 миллионов долларов.

Исследование причин атаки

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

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

Уроки и выводы

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

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

3. Пользователи должны быть осторожны при участии в новых проектах, особенно в отношении токенов или пулов ликвидности, которые еще не полностью установлены, и должны тщательно оценивать риски.

4. Проектная команда должна установить более完善ные механизмы безопасности и планы экстренного реагирования для борьбы с возможными атаками.

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