Нещодавно інцидент безпеки, що стосується платформи Pump, викликав широкий інтерес. У цій статті буде проведено детальний аналіз події та обговорено уроки, які з неї можна винести.
Аналіз процесу атаки
Зловмисники в цій події не є висококваліфікованими хакерами, а, швидше за все, колишніми працівниками платформи Pump. Зловмисники володіють ключовим гаманцем, який використовується для створення торгових пар токенів на певному DEX, який ми називаємо "зламаним рахунком". Водночас ліквідні пул токенів на платформі, які ще не досягли стандартів запуску, називаються "підготовчим рахунком".
Зловмисник запозичив кошти через швидкі кредити, заповнивши всі незадовільні пулі. У нормальних умовах, коли пул відповідає стандартам, SOL з підготовчого рахунку має бути переведено на рахунок, що піддається атаці. Однак зловмисник перехопив передані SOL під час цього процесу, внаслідок чого ці токени, що мали бути запущені, не змогли вчасно з'явитися на DEX.
Аналіз жертв
Згідно з аналізом, потерпіла сторона не включає платформу, що надає швидкі позики, оскільки позика була повернена в тому ж блоці. Крім того, токени, які вже запущені на DEX, не повинні підлягати впливу, оскільки ліквідність заблокована.
Справжніми потерпілими є інвестори в усіх незаповнених басейнах перед атакою. Їхні інвестиції в SOL були викрадені під час атаки. Це також пояснює, чому оцінки збитків досягають десятків мільйонів доларів (за останніми даними, фактичні збитки становлять близько 2 мільйонів доларів).
Можливі причини отримання приватного ключа зловмисником
Головною причиною, безсумнівно, є серйозні вади внутрішнього управління платформи. По-друге, можна припустити, що заповнення токенового пулу могло бути одним із обов'язків нападника раніше. Подібно до деяких соціальних платформ, які на початку використовували автоматизованих покупців для створення ажіотажу, платформа Pump, можливо, доручила нападнику заповнити пул нововипущених токенів за рахунок проектних коштів, щоб здійснити холодний запуск і привернути увагу. Цей підхід врешті-решт став безпековою загрозою.
Уроки досвіду
Для платформ, які імітують інші проекти, не можна просто копіювати поверхневі функції, також потрібно враховувати, як надати початковий імпульс для залучення користувачів.
Платформа повинна суворо управляти внутрішніми правами, посилити заходи безпеки. Особливо для критичних операцій слід впроваджувати багатопідписні та інші розширені механізми безпеки.
На ранніх етапах проєкту, навіть якщо використовуються деякі стратегії для сприяння зростанню, потрібно ретельно оцінити потенційні ризики та розробити відповідні механізми виходу.
Інвестори повинні обережно ставитися до нових платформ, особливо до тих проектів, які ще не належно розробили систему управління ризиками. Перед участю слід повністю зрозуміти технічну архітектуру проекту та заходи безпеки.
Галузеві регуляторні органи повинні посилити перевірку криптовалютних проектів, зокрема встановити більш суворі стандарти щодо управління правами доступу та безпеки коштів.
Ця подія ще раз нагадує нам, що в швидко розвиваючійся сфері криптовалют інновації та безпека мають однакову важливість. Команди проектів повинні завжди ставити безпеку коштів користувачів на перше місце, прагнучи до зростання.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Аналіз інциденту атаки колишніх співробітників платформи Pump: уроки та висновки з втрат у 2 мільйони доларів
Аналіз інциденту з вразливістю платформи Pump
Нещодавно інцидент безпеки, що стосується платформи Pump, викликав широкий інтерес. У цій статті буде проведено детальний аналіз події та обговорено уроки, які з неї можна винести.
Аналіз процесу атаки
Зловмисники в цій події не є висококваліфікованими хакерами, а, швидше за все, колишніми працівниками платформи Pump. Зловмисники володіють ключовим гаманцем, який використовується для створення торгових пар токенів на певному DEX, який ми називаємо "зламаним рахунком". Водночас ліквідні пул токенів на платформі, які ще не досягли стандартів запуску, називаються "підготовчим рахунком".
Зловмисник запозичив кошти через швидкі кредити, заповнивши всі незадовільні пулі. У нормальних умовах, коли пул відповідає стандартам, SOL з підготовчого рахунку має бути переведено на рахунок, що піддається атаці. Однак зловмисник перехопив передані SOL під час цього процесу, внаслідок чого ці токени, що мали бути запущені, не змогли вчасно з'явитися на DEX.
Аналіз жертв
Згідно з аналізом, потерпіла сторона не включає платформу, що надає швидкі позики, оскільки позика була повернена в тому ж блоці. Крім того, токени, які вже запущені на DEX, не повинні підлягати впливу, оскільки ліквідність заблокована.
Справжніми потерпілими є інвестори в усіх незаповнених басейнах перед атакою. Їхні інвестиції в SOL були викрадені під час атаки. Це також пояснює, чому оцінки збитків досягають десятків мільйонів доларів (за останніми даними, фактичні збитки становлять близько 2 мільйонів доларів).
Можливі причини отримання приватного ключа зловмисником
Головною причиною, безсумнівно, є серйозні вади внутрішнього управління платформи. По-друге, можна припустити, що заповнення токенового пулу могло бути одним із обов'язків нападника раніше. Подібно до деяких соціальних платформ, які на початку використовували автоматизованих покупців для створення ажіотажу, платформа Pump, можливо, доручила нападнику заповнити пул нововипущених токенів за рахунок проектних коштів, щоб здійснити холодний запуск і привернути увагу. Цей підхід врешті-решт став безпековою загрозою.
Уроки досвіду
Для платформ, які імітують інші проекти, не можна просто копіювати поверхневі функції, також потрібно враховувати, як надати початковий імпульс для залучення користувачів.
Платформа повинна суворо управляти внутрішніми правами, посилити заходи безпеки. Особливо для критичних операцій слід впроваджувати багатопідписні та інші розширені механізми безпеки.
На ранніх етапах проєкту, навіть якщо використовуються деякі стратегії для сприяння зростанню, потрібно ретельно оцінити потенційні ризики та розробити відповідні механізми виходу.
Інвестори повинні обережно ставитися до нових платформ, особливо до тих проектів, які ще не належно розробили систему управління ризиками. Перед участю слід повністю зрозуміти технічну архітектуру проекту та заходи безпеки.
Галузеві регуляторні органи повинні посилити перевірку криптовалютних проектів, зокрема встановити більш суворі стандарти щодо управління правами доступу та безпеки коштів.
Ця подія ще раз нагадує нам, що в швидко розвиваючійся сфері криптовалют інновації та безпека мають однакову важливість. Команди проектів повинні завжди ставити безпеку коштів користувачів на перше місце, прагнучи до зростання.