Аналіз та уроки інциденту з крадіжкою Pump

Нещодавно платформа Pump зазнала серйозної аварії безпеки, що призвело до значних фінансових втрат. У цій статті буде проведено детальний аналіз цієї події та обговорено отримані уроки.

Процес атаки

Атакуюча сторона не є висококваліфікованим хакером, а, швидше за все, колишнім співробітником Pump. Він має доступ до гаманця з правами, що дозволяє створювати торгові пари для土狗 токенів на певному DEX, який ми називаємо "цільовим рахунком". 土狗 токени, створені на Pump, перед досягненням стандартів для запуску, мають всі свої Bonding Curve LP резерви, які ми називаємо "підготовчий рахунок".

Зловмисники через миттєвий кредит взяли в борг, заповнивши всі пули, які не досягли стандарту. У нормальних умовах, в цей момент SOL з "підготовчого рахунку" має бути переведено на "цільовий рахунок" через досягнення стандарту. Однак, зловмисники скористалися моментом і витягли переведений SOL, що призвело до того, що ці мем-криптовалюти, які мали запуститися, не змогли запуститися вчасно.

Аналіз жертв

1. Платформа миттєвих кредитів не постраждала, оскільки кредит повертається в одному й тому ж блоці.
2. Токени 土狗, які вже запущені на DEX, можуть не підпадати під вплив, оскільки LP вже заблоковано.
3. Основними жертвами є користувачі, які купили токени в усіх неповних пулах на платформі Pump до початку атаки, у яких було викрадено SOL.

Обговорення причин атаки

1. На платформі існує серйозна вразливість управління правами.
2. Припускається, що нападник, можливо, відповідав за наповнення пулу токенів. Подібно до того, як на початкових етапах деякі соціальні платформи використовували ботів для скупки ключів, щоб створити ажіотаж, Pump, можливо, змусив нападника використовувати кошти проекту для заповнення пулу токенів, які він випустив (наприклад, $test, $alon тощо), щоб створити інтерес.

Уроки досвіду

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

2. Посилити управління правами доступу, підвищити обізнаність про безпеку. Розумно розподіляти та обмежувати права доступу співробітників, регулярно оновлювати ключі, встановити механізм багатопідпису - все це необхідні заходи безпеки.

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

4. Приділяйте увагу аудитам коду та програмам винагород за вразливості. Регулярно проводьте безпекові аудити, заохочуючи білих хакерів виявляти та повідомляти про вразливості.

5. Підвищення обізнаності користувачів про ризики. Платформа повинна чітко донести до користувачів потенційні ризики, заохочуючи їх вживати заходів безпеки, таких як використання апаратних гаманців тощо.

6. Створення механізму реагування на надзвичайні ситуації. Розробка детального плану дій на випадок надзвичайної ситуації, щоб у разі виникнення аварії можна було швидко зреагувати та максимально зменшити втрати.

Ця подія ще раз нагадала, що проекти Web3, розвиваючись швидко, не повинні ігнорувати основні принципи безпеки. Тільки знайдучи баланс між інноваціями та безпекою, можна дійсно сприяти здоровому розвитку галузі.