Децентралізовані фінанси безпеки: загальні вразливості безпеки та запобіжні заходи

Нещодавно один експерт з безпеки поділився інформацією щодо безпеки Децентралізованих фінансів, підсумувавши значні інциденти безпеки в індустрії Web3 за останній рік, обговоривши причини їх виникнення та способи уникнення, підсумувавши поширені вразливості смарт-контрактів та заходи запобігання, а також надавши деякі рекомендації з безпеки для проектів та користувачів.

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

Швидкий кредит

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

Звичайні атаки часто супроводжуються闪电贷, зловмисники люблять брати в借ги великі суми через闪电贷, маніпулювати цінами, атакувати бізнес-логіку тощо. Розробники повинні враховувати, чи не призведе велика кількість коштів до аномалій у функціонуванні контракту, або ж до отримання винагород через взаємодію з кількома функціями контракту в одній транзакції.

Часто можна побачити, що значення кількості Token в контракті використовується для розрахунку винагород, або ж кількість Token в торгових парах DEX використовується для участі в різних розрахунках. Оскільки розробники не врахували можливість того, що зловмисники можуть використати флеш-кредит для маніпулювання цими змінними, це призвело до крадіжки коштів з контракту.

За останні два роки в闪电贷 виникло багато проблем. Багато проектів DeFi виглядають дуже прибутковими, але насправді рівень команди проекту варіюється. Наприклад, код може бути купленим, і навіть якщо сам код не має вразливостей, логічно можуть виникнути проблеми. Наприклад, був проект, який на фіксований час виплачував винагороди залежно від кількості токенів, що належать тримачам, але зловмисники скористалися闪电贷 для покупки великої кількості токенів, і в момент виплати винагород більшість винагород потрапила до зловмисників. Крім того, є проекти, що розраховують ціну за допомогою Token, які можуть впливати на ціну через闪电贷, тому команди проектів повинні бути обережні щодо цих проблем.

Маніпуляція цінами

Проблема маніпуляції цінами тісно пов'язана з闪电贷, ця проблема в основному виникає через те, що деякі параметри під час обчислення цін можуть контролюватися користувачем, часто виникають два типи проблем.

• Один із способів полягає в використанні даних третьої сторони при розрахунку ціни, але неправильне використання або відсутність перевірок призводить до того, що ціну можна маніпулювати зловмисно.
• Інший варіант полягає в тому, що деякі адреси використовують кількість токенів як змінну для обчислень, і залишки токенів на цих адресах можуть тимчасово збільшуватися або зменшуватися.

Атака повторного входу

Однією з основних небезпек виклику зовнішніх контрактів є те, що вони можуть захопити контрольний потік і внести непередбачувані зміни у ваші дані.

Оскільки баланс користувача встановлюється в 0 лише в кінці функції, другий виклик ( та подальші виклики ) все ще будуть успішними і баланс буде знову і знову зніматися.

Щодо різних контрактів, існує багато способів повторного входу, які можна поєднати з різними функціями контракту або функціями кількох різних контрактів, щоб здійснити атаку повторного входу, тому при вирішенні проблеми повторного входу нам слід звернути увагу на такі моменти:

1. Не лише запобігання проблемі повторного входу для єдиної функції;
2. Дотримуйтесь моделі Checks-Effects-Interactions під час кодування ;
3. Використовуйте перевірений часом модифікатор для запобігання повторному виклику.

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

Історія вразливості Omni Protocol --- Боротьба між чотирма хакерами

Мемпул Ethereum постійно контролюється великою кількістю хакерів, які постійно аналізують угоди та намагаються випередити вигідні угоди, щоб отримати прибуток. Атакувальна угода, подана виявником вразливості Omni Protocol, була захоплена двома хакерами, які використали бот для випередження в flashbot, щоб заволодіти 1200 ETH з протоколу Omni Protocol, тоді як атакуючий, що виявив уразливість, отримав лише 480 ETH. Протягом цього часу ще один хакер виявив атакувальну угоду, подану хакерами-випереджувачами в flashbot, і, використовуючи особливість, що атакувальна угода потребує покупки токенів Doodle ERC20, здійснив сандвіч-атаку, отримавши прибуток у 151 ETH.

Люди, які знаходять вразливості, не отримують найбільше прибутку, а більше заробляють інші мисливці в темному лісі. У цій екосистемі повно мисливців, між якими можуть бути жертви, навіть якщо нападник новачок, він може не забрати більшість грошей з цього проекту, якщо не візьме все одразу. Багато людей також використовують вищу плату за Gas, щоб швидше виконати транзакції, під час яких, якщо залучені торги токенами на DEX, може виникнути атака «сендвіч», що створює велику плутанину.

Рекомендації з безпеки

Останні поради з безпеки для проєктів та звичайних учасників.

Поради з безпеки для проекту

Один. Розробка контрактів дотримується найкращих практик безпеки.

Два. Контракт може бути оновлений, призупинений: Багато атак не є одноразовими, коли всі монети переводяться, а виконуються у кількох транзакціях. Якщо є відносно надійний механізм моніторингу, це можна виявити. Після виявлення контракт, припустимо, може бути призупинений, що може ефективно знизити втрати.

Три. Використання тимчасового замка: Як у деяких випадках, якщо є тимчасовий замок, припустимо, що його можна завершити протягом 48 годин, у цей час багато людей з тимчасовим замком можуть виявити, що цей творець оновив метод mint, і ним може скористатися будь-хто. Ті, хто стежить, зрозуміють, що проект, ймовірно, був зламаний, і вони можуть сповістити команду проекту про необхідність змін. Навіть якщо припустити, що сповістили, і ніхто не реагує, принаймні, можна спочатку забрати свою частину грошей, щоб забезпечити свої доходи від втрат. Отже, якщо проект не має тимчасового замка, теоретично це збільшує ймовірність виникнення проблем.

Чотири, збільшити інвестиції в безпеку, створити повну систему безпеки: Безпека - це не точка і не лінія, безпека - це система. Не думайте, що як проектна сторона, якщо контракт пройшов аудит кількома компаніями, то з цим все в порядку, в результаті хакер викрав приватний ключ, навіть якщо це мультипідпис, викрав усі кілька приватних ключів. Або, наприклад, якщо є проблеми з економічною моделлю, проблеми з бізнес-моделлю... Існує тисячі і тисячі способів, які можуть призвести до втрати грошей, важливо, чи зможемо ми уникнути всіх ризиків безпеки заздалегідь. Слід намагатися проводити моделювання ризиків, а потім поступово уникати більшості ризиків, залишковий ризик також є прийнятним ризиком, у межах допустимого. Безпека та ефективність неможливо поєднати, потрібно робити певні компроміси. Але якщо зовсім не звертати увагу на безпеку, якщо не інвестувати в безпеку, то бути атакованим — це цілком нормально.

П'ять. Підвищення обізнаності всіх співробітників про безпеку: Підвищення обізнаності про безпеку не потребує багато технологій. На Twitter ми часто можемо бачити, як багато людей втрачають NFT через фішинг, насправді способи фішингу використовують людські слабкості. Якщо трохи більше звертати увагу, можна уникнути пасток. У великому середовищі Web3, якщо трохи більше запитувати чому, трохи більше думати, можна уникнути багатьох проблем.

Шість. Профілактика внутрішніх зловживань, підвищуючи ефективність, одночасно посилюючи контроль ризиків: Знову візьмемо кілька прикладів. По-перше, власник контракту є одностороннім, а не багатостороннім, втрата приватного ключа призведе до контролю всього проєкту; по-друге, не використовувалися часові замки, деякі ключові операції оновлювалися миттєво, ніхто не знав про це, що є дуже несправедливим для всіх учасників протоколу; і ще, внутрішні зловживання, внутрішній механізм безпеки не виконав жодної функції.

Як протоколи в блокчейні можуть забезпечити підвищення безпеки, зберігаючи при цьому ефективність? Існують деякі інструменти безпеки, які можуть призначити певну особу для виконання певної дії, наприклад, для п'яти з трьох підписів; можна призначити певну адресу для виконання певної дії, наприклад, можна довірити дуже надійному вузлу моніторинг ризиків безпеки. Припустимо, що протокол зазнає нападу, і кошти поступово переходять на адресу хакера, якщо цей контракт має функцію призупинення, то ми можемо надати цю функцію певній особі, і вона зможе виконати цю дію.

Наприклад, якщо ми говоримо про маркет-мейкерів для DEX, якщо не обмежити права Owner, то Owner може перевести гроші на іншу адресу, може обмежити адреси для переказу токенів, обмежити, з якими парами токенів можна працювати, встановити, що гроші можна вивести лише на певну адресу. Це підвищує ефективність, забезпечуючи при цьому певний рівень безпеки.

Сім. Безпека залучення третіх сторін: Як частина екосистеми, у проєктів завжди є свої постачальники і споживачі. Існує принцип, згідно з яким "за замовчуванням всі постачальники і споживачі є небезпечними". Незалежно від того, чи це постачальники, чи споживачі, потрібно проводити перевірку. Щодо третіх сторін ми дуже важко можемо контролювати, фактично ризик безпеки є особливо великим, тому потрібно бути дуже обережними при залученні третіх сторін. Контракт є відкритим, його можна залучати та викликати; якщо контракт закритий, його абсолютно не можна використовувати. Тому що ми не знаємо, яка логіка всередині, або залучений контракт сам по собі може бути контрактом, що підлягає оновленню, зазвичай його використання може не викликати проблем, але ми не можемо передбачити, чи не станеться так, що одного дня він буде оновлений до злочинного контракту, це неможливо контролювати.

Як користувачам/LP визначити, чи є смарт-контракт безпечним?

Для звичайних користувачів ми оцінюємо безпеку проекту, зокрема, за шістьма основними пунктами:

Одне. Чи є контракт з відкритим вихідним кодом: Усі проекти, контракти яких не є відкритими, категорично не слід торкатися, оскільки ми не можемо знати, що написано в контракті.

Два. Чи використовує власник мультипідпис, чи є мультипідпис децентралізованим: Якщо не використовувати мультипідпис, ми не можемо оцінити бізнес-логіку та зміст проекту. Якщо виникне інцидент безпеки, неможливо буде визначити, чи це влаштував хакер. Навіть якщо використовується мультипідпис, потрібно перевірити, чи є мультипідпис децентралізованим.

Три. Існуюча торгівля контрактом: Особливо на ринку є багато проектів, які займаються фішингом, які можуть створити досить схожий контракт. У цьому випадку нам потрібно звернути увагу на час розгортання контракту, кількість взаємодій тощо, це все є критеріями для оцінки безпеки контракту.

Четверте, чи є контракт агентським контрактом, чи можна його оновити, чи є таймлок: Якщо контракт абсолютно не підлягає оновленню, він занадто жорсткий, тому я все ж рекомендую, щоб контракт проєкту можна було оновити. Але оновлення повинно проводитися з урахуванням методів; коли оновлення має зміст оновлення або важливі зміни параметрів, має бути таймлок, щоб дати людям вікно часу для оцінки, чи є справжнє оновлення шкідливим чи корисним для користувачів, це також є способом публічної прозорості.

П’яте, чи проходив контракт аудит у кількох організацій ( не слід сліпо довіряти аудиторським компаніям ), чи не є надмірними права власника: По-перше, не слід довіряти лише одній аудиторській компанії, оскільки різні аудиторські компанії та різні аудитори можуть мати різні погляди на проблеми. Якщо проект має результати аудиту від кількох організацій, які виявили різні проблеми, і команда проекту їх виправила, то це буде безпечніше, ніж якщо аудит провела лише одна компанія. Відповідальна команда проекту шукатиме кілька аудиторських організацій для виконання перехресного аудиту.

По-друге, потрібно звернути увагу на те, чи не є повноваження Owner занадто великими. Наприклад, в деяких проектах з північними звірами Owner може повністю контролювати кошти користувачів; якщо токенів купується небагато, можна нормально купувати і продавати, але якщо обсяг покупки токенів величезний, Owner відразу може контролювати і заблокувати їх, і торгівля стає неможливою. Також деякі проекти NFT працюють аналогічно. У нормальному проекті повноваження Owner обов'язково повинні бути контрольованими, щоб не було надто багато небезпечних операцій, а дії виконувалися б із використанням таймлоків, щоб користувачі знали, що саме відбувається. Особливо в погані часи на ринку, існує безліч схем шахрайства, тому всім слід звертати увагу на повноваження Owner.

Шість, зверніть увагу на оракули: Якщо проект використовує ринкові провідні оракули, в основному не буде великих проблем, але якщо використовуються самостійно створені оракули або якщо якісь випадкові токени можуть бути закладені туди.