Безпека — це динамічний стан, а не папірцева сертифікація. Багато проєктів, які були зламані цього року, проходили аудит, а деякі проходили його кілька разів. Це не означає, що аудити не мають цінності; це лише означає, що питання, на які можуть відповісти аудити, значно вужчі, ніж припускає більшість людей.
Звіт про аудит описує певну версію, яку певна команда переглянула в певний день. Але контракти оновлюються, дозволи змінюються, оракули та крос-чейн мости, від яких залежать проєкти, змінюються, і щотижня з'являються нові техніки атак. У момент доставки звіт починає втрачати чинність. Що ще більш проблематично, старі контракти, розгорнуті роки тому, які тоді успішно проходили аудит, зараз повторно скануються партіями, і глибокі вразливості в контракті, який працює вже роки, можна знайти лише за трохи більше ніж десять хвилин.
Це третій випуск спеціального проєкту Gate «Курс безпеки Gate». Ми запросили постачальника послуг безпеки Web3 GoPlus Security та команду безпеки Gate, щоб обговорити аудити та перевірку вразливостей з точки зору постачальника послуг безпеки та торгової платформи: чому проєкти, що пройшли аудит, все ще потрапляють у халепу, як читати звіт, які перевірки виконує платформа до та після лістингу, і як звичайні користувачі можуть зробити коло самоперевірки перед підписанням.
Профілі гостей
Партнер GoPlus Адам: Адам є партнером GoPlus і керівником його інституту досліджень безпеки.
GoPlus Security створює перший децентралізований рівень безпеки для Web3 та ШІ. Використовуючи блокчейн та передові рішення безпеки на основі ШІ, він надає користувачам інтелектуальні, ефективні та децентралізовані продукти й послуги безпеки. З 2022 року GoPlus досяг експоненційного зростання, досягнувши 30 мільйонів щоденних викликів API та запобігши потенційним збиткам користувачів майже на 100 мільярдів доларів.
Команда безпеки Gate: Департамент безпеки Gate відповідає за побудову систем безпеки акаунтів, торгівлі та активів платформи, а також протягом тривалого часу займається апеляціями користувачів і запитами про допомогу щодо ненормальних акаунтів.
Заснована у 2013 році, Gate є першою в галузі торговою платформою, яка запустила 100% доказ резервів, і наразі обслуговує понад 60 мільйонів користувачів по всьому світу. Безпека є передумовою життєздатності цього бізнесу, і через «Курс безпеки Gate» ми сподіваємося чітко пояснити спільні механізми, що стоять за цими реальними ризиками.
Питання 1. Чому багато проєктів після проходження аудитів все ще зламують і вони все ще страждають від зловживання дозволами?
Партнер GoPlus Адам: «Одноразовий аудит» не дорівнює «завжди безпечно». Традиційні послуги аудиту контрактів зараз страждають від чотирьох структурних недоліків:
1) Перевірка у стилі знімка. Аудит по суті є напіворучною перевіркою інженерами з аудиту в певний момент часу, і його ефективність залежить від якості інструментів, індивідуальних навичок і робочого стану. Але код контракту оновлюється, адміністративні дозволи змінюються, а конфігурації параметрів коригуються. З моменту доставки звіту одноразового аудиту він «втрачає чинність».
2) Неможливість передбачити майбутнє. Постійно з'являються нові типи вразливостей і нові техніки атак, і історичні аудити не можуть охопити майбутні ризики.
3) Неконтрольовані зовнішні залежності. Проєкти зазвичай залежать від оракулів, крос-чейн мостів і сторонніх протоколів, а зміни ризиків у цих залежностях виходять за межі традиційних аудитів.
4) Концентровані вибухи старих контрактів. Контракти, розгорнуті роки тому, які тоді «проходили аудит», зараз партіями повторно виявляються автоматизованими інструментами, наприклад, глибокі вразливості в Balancer, Yearn та подібних проєктах, які залишалися невиявленими роками після запуску.
Що стосується зловживання дозволами, то воно частіше виникає на операційному етапі, ніж у самому коді контракту. Причини включають: надмірні дозволи Owner (можливість довільно карбувати, вносити до чорного списку або призупиняти торгівлю), витік приватних ключів адміністратора, неналежне управління мультипідписами, зловмисні пропозиції та атаки на управління... Усе це проблеми безпеки, які легко виникають на операційному етапі. Навіть якщо звіт про аудит позначає ризики дозволів, хто буде стежити за цим згодом? Чи є операції безпечними та обґрунтованими, відповісти неможливо.
Вихід у живу мережу після аудиту контракту — це лише відправна точка роботи з безпеки, а не її кінець. Проєктам потрібна безперервна безпека, що охоплює весь життєвий цикл контракту, а не одноразовий звіт про аудит.
Команда безпеки Gate: Аудити можуть сказати користувачам, що код може робити, але вони не можуть сказати користувачам, що команда проєкту має намір зробити.
Це те, що ми відчули найглибше за роки проведення перевірок перед лістингом. Першопричина багатьох інцидентів криється в намірах команди проєкту. Контракт може бути технічно повністю відповідним, а дизайн дозволів власника може бути в межах норми, але команда проєкту все одно може вибрати момент, щоб скористатися цими дозволами: змінити правила торгівлі, увімкнути чорні списки або додатково викарбувати токени. Ці дії є цілком законними на рівні коду, і звіти про аудит не позначать їх як уразливості, оскільки вони спочатку є частиною дизайну.
Тому поза межами технічних аудитів має бути ще один рівень обмежень. Підхід Gate полягає в проведенні суворої перевірки та відбору проєктів під час процесу лістингу, а також у підписанні з командами проєктів декларацій про непричинення шкоди та нагляді за їх дотриманням. Цей рівень покликаний вирішити ту частину, яку аудити вирішити не можуть: відсутність уразливостей у коді не означає, що команда не робитиме вибору, який завдає шкоди користувачам.
Для проєктів, що пройшли лістинг, ми проводимо регулярні аудити безпеки та використовуємо моніторинг подій ончейн для відстеження стану контракту. Користувачі також можуть у будь-який момент перевірити поточні ризикові пункти даного контракту.
Q2. Оскільки одноразовий аудит не дорівнює безперервній безпеці, як мають адаптуватися команди проєктів і галузь загалом?
Команда безпеки Gate: Криптоіндустрія має структурну особливість: значна частина її бізнесу, особливо DeFi, працює в режимі, близькому до модульних фінансів. Різні платформи будуються зі спільних компонентів: контрактів, програмних бібліотек, гаманців, цінових оракулів, кросс-чейн мостів, постачальників послуг підключення, веб-інтерфейсів і систем, що використовуються для розповсюдження оновлень.
Тому поза питанням, чи є ваші власні контракти безпечними, важливішим питанням є те, чи залишається надійною кожна ланка, від якої ви залежите. Якщо компонент вище за течією виходить з ладу, збитки поширюються вниз по ланцюгу. Озираючись на великі атаки, проблема часто криється в ланках, що передують логіці протоколу: постачальники, інструменти розробки, спосіб, яким програмне забезпечення досягає користувачів, або процес, за допомогою якого користувачі схвалюють перекази.
Партнер GoPlus Адам: Парадигма атак, у якій хакери використовують автоматизовані інструменти для ефективного пошуку уразливостей, вже набула форми і швидко поширюється. Атаки перейшли від «експертного ручного дослідження» до «конвеєра». Якщо мислення галузі досі застрягає на «знайти аудиторську фірму, щоб випустити звіт перед запуском» або «знайти компанію з безпеки, щоб виправити ситуацію після виявлення ризику», це схоже на використання луків і стріл проти кулеметів. Використання однаково ефективних інструментів для протидії атакам — це єдиний ефективний шлях.
Напрямок адаптації на рівні галузі — перехід від «одноразових аудитів» або «пошуку експертів після виникнення проблем» до «безперервної безпеки протягом усього життєвого циклу». Візьмімо як приклад «тріо безпеки контрактів» GoPlus DeepScan; це замкнений цикл, який можна впровадити:
Перед запуском, самоперевірка безпеки токена: швидка самоперевірка за хвилини щодо ризиків бекдорів, таких як ханипоти, зловмисне карбування, чорні списки, аномальні податки на транзакції та дозволи власника;
Під час запуску, AI-аудит контракту: глибокий аналіз вихідного коду, управління дозволами та бізнес-логіки, сканування уразливостей на рівні синтаксису та рівні бізнес-логіки, а також надання структурованого звіту про аудит;
Після запуску, безперервний моніторинг безпеки та регулярні перевірки стану: відстеження нових даних про уразливості, інцидентів атак і ризиків від зовнішніх залежностей (оракули, кросс-чейн мости, сторонні протоколи) в реальному часі, безперервне визначення того, чи впливає це на проєкт, і надання рутинних оповіщень. Проведення регулярних перевірок стану безпеки та безперервних аудитів контрактів.
Q3. Як змінилися методи виявлення уразливостей за останні два роки? Для одного й того самого активу, яка різниця в моделі безпеки між зберіганням ончейн і зберіганням на біржі?
Партнер GoPlus Адам: Відверто кажучи, в короткостроковій перспективі методи пошуку уразливостей атакуючими стали більш різноманітними. Є три причини:
1) Автоматизовані інструменти значно знизили поріг для пошуку уразливостей. Роботу, яка колись вимагала від провідних дослідників безпеки тижнів, тепер можна виконати через конвеєр атак за хвилини;
2) Величезна кількість старих контрактів, які «тоді були перевірені аудитом», накопичилася ончейн, що робить їх «золотою жилою» з величезними запасами для атакуючих;
3) Атаки — це одностороння монетизація: достатньо знайти «одну» вразливість, тоді як захисники повинні захищатися від «усіх» вразливостей.
Хакерам потрібно лише кілька хвилин, щоб витягти ці гроші, і насправді захисникам також потрібно лише кілька хвилин, щоб знайти ту саму вразливість. Єдина різниця полягає в тому, чи правильно команда проєкту використала інструменти до того, як це зробили хакери.
Що важливіше, захисники мають три структурні переваги, яких не мають атакуючі:
1) Перевага першопрохідця: захисники можуть перевіряти необмежену кількість разів до запуску та під час роботи, тоді як атакуючі можуть лише сподіватися, що захисники не провели перевірку;
2) Перевага у витратах: аудит ШІ оплачується за використання або щорічно, витрати достатньо низькі, щоб бути рутинними та повномасштабними;
3) Накопичення знань: база знань з безпеки продовжує розвиватися з кожним новим інцидентом атаки, і система захисту стає сильнішою чим більше її використовують.
У двох моделях, ончейн та офчейн, «хто захищає ваші активи» та «типи ризиків, з якими ви стикаєтеся» є абсолютно різними.
Ончейн самостійне зберігання: Безпека = безпека приватного ключа + безпека контракту. Ви є єдиною стороною, відповідальною за безпеку—якщо ваш приватний ключ втрачено або викрадено, немає «служби підтримки», до якої можна звернутися; кожна взаємодія несе ончейн-ризик (вразливості схвалення, фішингові підписи, шахрайство з ханипотами); перевага полягає в тому, що ваші активи не залежать від кредитоспроможності будь-якої платформи.
Кастодіальне зберігання на біржі: Безпека = безпека платформи + безпека облікового запису. Приватні ключі керуються платформою (розділення гарячих/холодних гаманців, мультипідпис, контроль ризиків), що еквівалентно передачі «технічної безпеки» на аутсорсинг біржі; але вам також потрібно належним чином захищати безпеку вашого власного облікового запису на біржі (пароль, 2FA, фішинг, API Key тощо), і водночас обов'язково обирати біржу з надійною кредитоспроможністю платформи.
Загалом, ончейн — це «захист приватного ключа + ризик самостійної роботи», тоді як біржі — це «кредитоспроможність платформи + ризик інфраструктури безпеки». Перше перевіряє вашу обізнаність з безпеки Web3, тоді як друге перевіряє інфраструктуру біржової платформи та ваші звички щодо безпеки облікового запису.
Q4. Як торгова платформа, які покращення безпеки зробила Gate?
Команда безпеки Gate: По-перше, ми проводимо регулярні аудити безпеки лістингових проєктів, водночас безперервно відстежуючи стан контрактів через ончейн-моніторинг подій. Чи було оновлено контракт, чи змінилися дозволи, чи відбулися аномальні великовартісні операції—все це потребує безперервного моніторингу, оскільки висновок перевірки на момент лістингу, як і звіти аудиту, згадані Адамом, також має термін придатності. Користувачі також можуть будь-коли перевірити поточні ризикові пункти даного контракту.
Тепер щодо самої платформи. Програма винагород за вразливості безпеки Gate завжди відкрита, і дослідники безпеки з усього світу можуть надсилати нам знайдені проблеми через три канали: [email protected], тікети підтримки та платформу HackenProof. Ми вимагаємо, щоб команди проєктів проходили перевірку, і ми самі повинні проходити перевірку—це не повинно бути односторонньою вимогою.
Розглянувши монети та платформу, тепер поговоримо про облікові записи.
Наша порада—не шукати те «найбезпечніше місце», а розподілити свої гроші за частотою використання, що є більш практичним: тримайте кошти, якими ви часто торгуєте, на своєму спотовому рахунку для доступу в будь-який час; кошти, яких ви не торкатиметеся від шести місяців до року, покладіть у Gate Vault.
Vault використовує MPC плюс підписи 2-з-3. Приватний ключ розділено на три фрагменти, які зберігаються відповідно на пристрої користувача, у Gate та в незалежної третьої сторони. Повний приватний ключ ніколи не збирається в жодний момент, і ні Gate, ні ця третя сторона не можуть ініціювати транзакцію самостійно. Усі виведення коштів також вимагають 48-годинного періоду очікування перед надходженням коштів—ці 48 годин слугують буфером безпеки для користувачів, протягом яких виведення можна будь-коли заморозити. У більшості випадків крадіжок користувачі помічають щось не те пізніше, ніж атакуючий, і після того, як ончейн-переказ відправлено, його не можна скасувати—але протягом цих 48 годин у Gate Vault користувачі можуть будь-коли його заморозити. Навіть якщо щось піде не так, 48-годинна затримка дає вам час виявити та заморозити це.
Тепер другий момент: Програма захисту безпеки облікового запису Gate.
Програма захисту безпеки облікового запису Gate базується на оцінці безпеки. Налаштування безпеки облікового запису спочатку були розкидані по різних сторінках — перевірка під час входу, автентифікатор, двофакторна перевірка, ключі доступу, ліміти торгівлі, ліміти виведення — і користувачам було важко точно визначити, які кроки вони вже виконали. Оцінка безпеки перетворює ці пункти на бал від 0 до 100, тож ви одразу бачите, які з них увімкнено, а яких ще бракує; коли оцінка змінюється, система також нагадує користувачам завершити їх.
Щойно оцінка безпеки досягає 80, а обліковий запис перебуває у звичайному статусі, ви можете активувати програму захисту. Після активації це означає, що після того, як користувачі належним чином подбали про власний захист, існує додатковий рівень підстраховки: протягом періоду захисту, якщо активи на обліковому записі були переказані без авторизації, користувачі можуть подати заявку на компенсацію, якщо дотримано правил, причому поточна максимальна сума на один інцидент становить 200 000 доларів США. Цей ліміт згодом буде збільшено, з градацією за рівнем VIP до максимуму 1 мільйон доларів США. Заявки необхідно подавати протягом 45 днів з моменту інциденту через «Мій захист», звертаючись до служби безпеки клієнтів, з матеріалами, що включають записи поліцейського звіту та записи про переказ активів.
Q5. Що має містити повний звіт про аудит? Як слід використовувати оцінку безпеки, ключові висновки та рекомендації щодо виправлення кожен окремо?
Адам, партнер GoPlus: Звіт про аудит, який може скеровувати дії (а не просто бути підшитим у теку), має містити щонайменше чотири елементи:
1) Оцінка безпеки (кількісний рейтинг), що використовується для «швидкого відсіювання», а не для «остаточних висновків». Команди проєктів можуть використовувати оцінку як кількісний орієнтир для внутрішніх оцінок безпеки, порівнюючи зміни після кожної ітерації; біржі можуть використовувати її для початкового відсіювання під час лістингу, щоб відсіяти явно невідповідні проєкти на першому етапі; звичайні користувачі можуть сприймати оцінку як «точку входу» — одразу уникати низьких оцінок, а для високих оцінок далі дивитися ключові висновки.
2) Ключові висновки (високоризикові проблеми та основні висновки), що використовуються для «ухвалення рішень». Це «резюме для керівництва» звіту: які проблеми є блокуючими і мають бути виправлені до запуску. Для менеджерів без технічного досвіду та команд перевірки лістингу достатньо зрозуміти ключові висновки.
3) Деталі проблем (докази вразливостей та опис впливу), що використовуються для «локалізації проблем». Це частина для технічної команди, що включає місцезнаходження вразливості (з точністю до контракту, функції та рядка коду), тип вразливості, рівень серйозності, опис шляху атаки та аналіз першопричини. Хороші деталі проблем мають надавати відтворюваний шлях виконання та умови спрацювання, а не просто перелік проблем.
4) Рекомендації щодо виправлення (практичні плани виправлення), що використовуються для «замикання циклу». Рекомендації щодо виправлення мають бути конкретними на рівні коду, практичними, а після виправлення необхідно виконати повторне сканування та регресійну перевірку, утворюючи повний цикл «оцінка, ключові висновки, деталі проблем, виправлення, повторне сканування».
Команда безпеки Gate: Ми хотіли б додати три пункти з нашої практики створення функцій аудиту контрактів.
По-перше, найлегше саме перші два пункти: цілі та обмеження аудиту, а також опис обсягу. Ми визначили вісім вимірів для звітів — цілі та обмеження аудиту, опис обсягу, матриця серйозності, визначення пріоритетів, деталі вразливостей, шляхи ризику, модель загроз, аналіз ключових функцій та рекомендації щодо виправлення — і саме перші два пункти визначають, чи неправильно витлумачать читачі весь звіт. Якщо обмеження не вказані чітко, читачі вважатимуть, що він охоплює все; якщо обсяг не вказано чітко, читачі не можуть визначити, чи аудит охоплював лише основний контракт, чи також пул ліквідності, стратегічні контракти, оракули та зовнішні залежності. Багато рекламних тверджень лише кажуть «перевірено аудитом», не вказуючи, що саме було перевірено — такі твердження фактично не несуть жодної інформації.
По-друге, розглядаючи ключові висновки, ризики, які окремо не вважаються вразливостями, слід розглядати разом. Візьміть поширену комбінацію у звітах: власник контракту може вносити адреси до чорного списку для заморожування активів, торгову пару можна скинути, через що звичайні користувачі не зможуть переказувати, вимога мінімального утримання перешкоджає користувачам повністю продати, а єдиний власник може будь-коли змінити кілька ключових правил. Розглянуті окремо, усі чотири є нормальним дизайном; взяті разом, вони означають, що контроль над цим контрактом сильно зосереджений в руках однієї особи.
По-третє, вам потрібно знати, як формується звіт, оскільки це визначає межі його надійності. Наш аудит контрактів складається з трьох етапів: спочатку статичний аналіз для перевірки базових ризиків, таких як контроль дозволів, повторний вхід, маніпулювання ціною, флеш-позики та логічна узгодженість; потім моделювання бізнес-сценаріїв, вилучення основних сценаріїв взаємодії контракту, перевірка бізнес-шляхів і граничних умов, пошук проблем, які не може охопити сканування на основі правил; нарешті, семантична верифікація, поелементна перевірка ключових бізнес-шляхів для підтвердження того, чи справді підтверджуються ризики, виявлені на перших двох етапах. Третій етап переважно покликаний зменшити частку хибнопозитивних спрацювань. Звіт, переповнений хибнопозитивними спрацюваннями, швидко втратить терпіння користувачів, і зрештою вони взагалі пропустять етап перевірки — тому частка хибнопозитивних спрацювань безпосередньо визначає, чи справді використовуватиметься цей інструмент.
Q6. Що можуть зробити звичайні користувачі вже зараз для посилення захисту?
Адам, партнер GoPlus:
1) Перевіряйте безпеку токена перед торгівлею. Перш ніж купувати нову монету, перевірте безпеку самого токена та звертайте увагу на ризики бекдорів, такі як шахрайство з ханипотами, зловмисний майнінг, чорні списки, аномальні податки на транзакції та надмірні права власника.
2) Регулярно очищайте дозволи контрактів. Відкликайте дозволи (Approvals) для DApps, якими ви більше не користуєтеся, особливо необмежені дозволи — багато крадіжок походять від проблем із «контрактами, які ви колись схвалили».
3) Посилюйте захист на рівні облікового запису. Використовуйте надійні паролі та вмикайте 2FA; керуйте API-ключами за принципом найменших привілеїв і ніколи не надавайте дозволи на виведення коштів ненадійним інструментам.
4) Зробіть антифішинг звичкою. Перевіряйте домен перед підписанням, не переходьте за посиланнями в особистих повідомленнях і за замовчуванням не довіряйте «ейрдропам/службі підтримки/високодохідному стейкінгу»; фішинговий контент стає дедалі переконливішим, тому завжди зберігайте раціональність.
5) Зберігайте активи розподілено за призначенням. Тримайте в гарячих гаманцях лише невелику суму коштів, потрібних для використання; для великих активів використовуйте апаратні гаманці — не кладіть усі яйця в один кошик.
6) Звертайте увагу на «ставлення до безпеки» проєкту, а не на його «аудиторський звіт». Наявність безперервного аудиту та механізму моніторингу безпеки важливіша за аудиторський звіт дворічної давності; віддавайте перевагу проєктам, які цінують безпеку та готові публічно розкривати свої механізми побудови безпеки.
Команда безпеки Gate: Шість пунктів Адама вже досить повні. Ми хотіли б поєднати їх з інструментами Gate, щоб перетворити кілька з них на операції, які ви можете зробити одразу.
1) Перевіряйте токен перед торгівлею — тут ви можете безпосередньо скористатися функцією аудиту контрактів Gate AI. Надішліть адресу контракту та отримайте звіт за кілька хвилин; зверніть увагу на чотири пункти: права власника, чорний список і обмеження торгівлі, права на майнінг та податок на переказ. Якщо хоча б один із цих чотирьох пунктів позначено червоним, вам слід зупинитися — далі дивитися не потрібно.
2) Посильте захист облікового запису — спершу підніміть свій показник безпеки вище 80. Пароль фонду, автентифікатор, двофакторна перевірка, антифішинговий код, ключі доступу (passkeys), денний ліміт на виведення, керування способами виведення — усі ці елементи захисту є в контрольному списку; просто дотримуйтеся підказок і виконуйте їх один за одним. Найбільша цінність показника безпеки полягає в тому, що він перетворює налаштування, розкидані всюди, на впорядкований контрольний список, тож вам не доведеться вирішувати, що робити першим. Досягнення 80 або вище також дозволяє активувати Програму захисту безпеки облікового запису, що означає додатковий рівень страховки після того, як ви належно посилили захист власного облікового запису.
3) Для антифішингу є два готові інструменти. Якщо ви отримали повідомлення, яке нібито надійшло від Gate, спершу перевірте офіційний канал верифікації, чи належить домен або електронна адреса нам; усі електронні листи, надіслані Gate, міститимуть антифішинговий код, який ви встановили самостійно — будь-який без цього коду є підробкою.
4) Перед підписанням чітко перевіряйте суму дозволу. Те, що сам контракт у порядку, не означає, що транзакція, яку сторінка просить вас підписати, також у порядку. Нормальний DApp цілком може запитувати лише суму, потрібну для цієї транзакції; запит одразу на необмежений дозвіл сам по собі вартий паузи. Якщо у спливаючому вікні лише рядок незрозумілих символів, відмова завжди безпечніша, ніж спочатку підписати, а потім ставити запитання.
Насамкінець хочемо сказати, що безпека є динамічною, а не статичною.
Запуск після аудиту — це лише відправна точка роботи з безпеки. Для команд проєктів це означає, що безперервний моніторинг після запуску важливіший за сам звіт; для торгових платформ це означає, що лістинг — лише початок перевірки; а для звичайних користувачів ті кілька хвилин самоперевірки перед підписанням є кроком з найнижчою вартістю і водночас тим, який найлегше пропустити.
Безпека ніколи не була одноразовою сертифікацією. Якщо всі сторони зроблять ще один крок, баланс між атакою та захистом схилиться на користь нас, «охоронців брами».
Зустрічаємося на четвертому занятті «Курсу безпеки воріт» разом!
