GMX зазнав значного безпекового витоку, збитки склали до 40 мільйонів доларів
Нещодавно значна подія безпеки, що стосується децентралізованої торгової платформи, привернула широку увагу в галузі. Зловмисники скористалися повторювальною вразливістю в системі, відкрили короткі позиції за умов, коли функція важелів була увімкнена, і успішно здійснили атаку, що призвела до збитків платформи більше ніж 40 мільйонів доларів.
Основна проблема події полягає у використанні функції executeDecreaseOrder. Перший параметр цієї функції повинен був бути адресою зовнішнього рахунку, але зловмисник хитро передав адресу смарт-контракту. Це дозволило зловмиснику повторно входити в систему під час процесу викупу активів, маніпулюючи внутрішнім станом, в результаті чого викуплені активи мали вартість, що значно перевищує фактичну вартість GLP токенів, які він має.
У нормальних умовах GLP як токен постачальника ліквідності представляє частку активів платформи, що належать користувачу. Коли користувач викуповує GLP, система розраховує кількість активів, що підлягають поверненню, на основі пропорції GLP, що належить користувачу, до загального обсягу постачання та поточної суми активів управління (AUM). Розрахунок AUM враховує кілька факторів, включаючи загальну вартість усіх токенних пулів, нереалізовані прибутки та збитки глобальних коротких позицій тощо.
Однак, коли платформа активувала функцію важелів, зловмисники знайшли можливість використати системні вразливості. Перед викупом GLP зловмисники відкрили великі короткі позиції на WBTC. Через недоліки в дизайні системи нові короткі позиції штучно збільшують AUM, хоча насправді не приносять додаткової вартості до скарбниці. Це призвело до того, що сума викупу, розрахована на основі завищеного AUM, значно перевищує частку, на яку має право зловмисник.
Ця подія виявила серйозні недоліки платформи в дизайні механізму важелів та захисту від повторних викликів. Основна проблема полягає в тому, що логіка викупу активів надмірно довіряє значенню AUM, не проводячи достатньої перевірки безпеки його складових частин (таких як нереалізовані збитки). Одночасно, припущення про особу виклику в ключових функціях також не має обов'язкових перевірок.
Ця подія знову попереджає розробників блокчейн-проектів, що при обробці операцій з великими сумами коштів необхідно забезпечити, щоб стан системи не був зловмисно маніпульований. Особливо під час впровадження складної фінансової логіки, такої як маржинальна торгівля, похідні та інші функції, необхідно ретельно захищатися від ризиків, пов'язаних з атаками повторного входу та забрудненням стану.
Для користувачів ця подія також нагадує нам про необхідність бути обережними при участі в проектах децентралізованих фінансів, ретельно оцінюючи безпеку платформи та здатність контролювати ризики. Для команди проекту стане особливо важливим посилення безпекового аудиту, впровадження багатофакторної аутентифікації, реалізація більш жорсткого управління правами доступу та інших заходів.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
GMX зазнав атаки на 40 мільйонів доларів: вразливість повторного входу виявила ризики DEX
GMX зазнав значного безпекового витоку, збитки склали до 40 мільйонів доларів
Нещодавно значна подія безпеки, що стосується децентралізованої торгової платформи, привернула широку увагу в галузі. Зловмисники скористалися повторювальною вразливістю в системі, відкрили короткі позиції за умов, коли функція важелів була увімкнена, і успішно здійснили атаку, що призвела до збитків платформи більше ніж 40 мільйонів доларів.
Основна проблема події полягає у використанні функції executeDecreaseOrder. Перший параметр цієї функції повинен був бути адресою зовнішнього рахунку, але зловмисник хитро передав адресу смарт-контракту. Це дозволило зловмиснику повторно входити в систему під час процесу викупу активів, маніпулюючи внутрішнім станом, в результаті чого викуплені активи мали вартість, що значно перевищує фактичну вартість GLP токенів, які він має.
У нормальних умовах GLP як токен постачальника ліквідності представляє частку активів платформи, що належать користувачу. Коли користувач викуповує GLP, система розраховує кількість активів, що підлягають поверненню, на основі пропорції GLP, що належить користувачу, до загального обсягу постачання та поточної суми активів управління (AUM). Розрахунок AUM враховує кілька факторів, включаючи загальну вартість усіх токенних пулів, нереалізовані прибутки та збитки глобальних коротких позицій тощо.
Однак, коли платформа активувала функцію важелів, зловмисники знайшли можливість використати системні вразливості. Перед викупом GLP зловмисники відкрили великі короткі позиції на WBTC. Через недоліки в дизайні системи нові короткі позиції штучно збільшують AUM, хоча насправді не приносять додаткової вартості до скарбниці. Це призвело до того, що сума викупу, розрахована на основі завищеного AUM, значно перевищує частку, на яку має право зловмисник.
Ця подія виявила серйозні недоліки платформи в дизайні механізму важелів та захисту від повторних викликів. Основна проблема полягає в тому, що логіка викупу активів надмірно довіряє значенню AUM, не проводячи достатньої перевірки безпеки його складових частин (таких як нереалізовані збитки). Одночасно, припущення про особу виклику в ключових функціях також не має обов'язкових перевірок.
Ця подія знову попереджає розробників блокчейн-проектів, що при обробці операцій з великими сумами коштів необхідно забезпечити, щоб стан системи не був зловмисно маніпульований. Особливо під час впровадження складної фінансової логіки, такої як маржинальна торгівля, похідні та інші функції, необхідно ретельно захищатися від ризиків, пов'язаних з атаками повторного входу та забрудненням стану.
Для користувачів ця подія також нагадує нам про необхідність бути обережними при участі в проектах децентралізованих фінансів, ретельно оцінюючи безпеку платформи та здатність контролювати ризики. Для команди проекту стане особливо важливим посилення безпекового аудиту, впровадження багатофакторної аутентифікації, реалізація більш жорсткого управління правами доступу та інших заходів.