GMX зазнав хакерської атаки, що призвела до втрат понад 40 мільйонів доларів. Зловмисники скористалися вразливістю повторного входу та створили шорт позиції за умов, що контракт активує функцію кредитного плеча.
Суть проблеми полягає в неправильному використанні функції executeDecreaseOrder. Першим параметром цієї функції повинен бути зовнішній рахунок (EOA), але зловмисник передав адресу смарт-контракту. Це дозволило зловмиснику повторно увійти в систему під час викупу, маніпулювати внутрішнім станом, в результаті чого викуплені активи значно перевищували фактичну вартість GLP, якою він володів.
У GMX GLP є токеном постачальника ліквідності, що представляє частку в активі сховища (наприклад, USDC, ETH, WBTC). У нормальних умовах, коли користувач викуповує GLP, система розраховує кількість активів, що підлягають поверненню, виходячи з частки GLP, яку має користувач, та поточної загальної вартості управлінських активів (AUM). Обчислення AUM включає загальну вартість усіх пулів токенів, глобальний шорт позиції, вже зарезервовані суми та попередньо задані утримання та інші фактори.
Проте, коли була увімкнена функція кредитного плеча, у системі виникла вразливість. Зловмисник відкрив великі шорт позиції по WBTC перед викупом GLP. Оскільки шорт позиція відразу ж збільшила глобальний обсяг шортів, і ціна не змінилася, система за замовчуванням вважала, що ця шорт позиція є збитковою. Ця частина нереалізованих збитків була помилково зарахована до "активів" трезора, що призвело до штучного збільшення AUM. Хоча трезор насправді не отримав додаткової вартості, розрахунок викупу базувався на цьому завищеному AUM, що дозволило зловмиснику отримати активи, які значно перевищували те, що він повинен був отримати.
Ця атака виявила серйозні недоліки GMX у механізмі важелів та дизайні захисту від повторного виклику. Основна проблема полягає в тому, що логіка викупу активів покладається на AUM занадто сильно, не проводячи достатньо обережної перевірки безпеки щодо його складових (наприклад, нереалізованих збитків). Водночас, ключова функція не має обов'язкової перевірки припущення про особу виконавця (EOA проти контракту).
Ця подія ще раз нагадує розробникам, що при виконанні фінансових операцій, чутливих до коштів, необхідно забезпечити неможливість маніпуляцій з системним станом. Особливо при впровадженні складної фінансової логіки (такої як важелі, деривативи) потрібно особливо уважно ставитися до ризиків, пов'язаних з повторними входами та забрудненням стану. Розробницька команда повинна переглянути дизайн своїх контрактів, посилити заходи безпеки та розглянути можливість впровадження більш суворих механізмів аутентифікації та перевірки стану, щоб запобігти повторенню подібних атак.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
GMX遭Хакер атаки 可重入漏洞致损4000万美元
GMX зазнав хакерської атаки, що призвела до втрат понад 40 мільйонів доларів. Зловмисники скористалися вразливістю повторного входу та створили шорт позиції за умов, що контракт активує функцію кредитного плеча.
Суть проблеми полягає в неправильному використанні функції executeDecreaseOrder. Першим параметром цієї функції повинен бути зовнішній рахунок (EOA), але зловмисник передав адресу смарт-контракту. Це дозволило зловмиснику повторно увійти в систему під час викупу, маніпулювати внутрішнім станом, в результаті чого викуплені активи значно перевищували фактичну вартість GLP, якою він володів.
У GMX GLP є токеном постачальника ліквідності, що представляє частку в активі сховища (наприклад, USDC, ETH, WBTC). У нормальних умовах, коли користувач викуповує GLP, система розраховує кількість активів, що підлягають поверненню, виходячи з частки GLP, яку має користувач, та поточної загальної вартості управлінських активів (AUM). Обчислення AUM включає загальну вартість усіх пулів токенів, глобальний шорт позиції, вже зарезервовані суми та попередньо задані утримання та інші фактори.
Проте, коли була увімкнена функція кредитного плеча, у системі виникла вразливість. Зловмисник відкрив великі шорт позиції по WBTC перед викупом GLP. Оскільки шорт позиція відразу ж збільшила глобальний обсяг шортів, і ціна не змінилася, система за замовчуванням вважала, що ця шорт позиція є збитковою. Ця частина нереалізованих збитків була помилково зарахована до "активів" трезора, що призвело до штучного збільшення AUM. Хоча трезор насправді не отримав додаткової вартості, розрахунок викупу базувався на цьому завищеному AUM, що дозволило зловмиснику отримати активи, які значно перевищували те, що він повинен був отримати.
Ця атака виявила серйозні недоліки GMX у механізмі важелів та дизайні захисту від повторного виклику. Основна проблема полягає в тому, що логіка викупу активів покладається на AUM занадто сильно, не проводячи достатньо обережної перевірки безпеки щодо його складових (наприклад, нереалізованих збитків). Водночас, ключова функція не має обов'язкової перевірки припущення про особу виконавця (EOA проти контракту).
Ця подія ще раз нагадує розробникам, що при виконанні фінансових операцій, чутливих до коштів, необхідно забезпечити неможливість маніпуляцій з системним станом. Особливо при впровадженні складної фінансової логіки (такої як важелі, деривативи) потрібно особливо уважно ставитися до ризиків, пов'язаних з повторними входами та забрудненням стану. Розробницька команда повинна переглянути дизайн своїх контрактів, посилити заходи безпеки та розглянути можливість впровадження більш суворих механізмів аутентифікації та перевірки стану, щоб запобігти повторенню подібних атак.