Безопасность — это динамическое состояние, а не бумажный сертификат. Многие из проектов, взломанных в этом году, проходили аудит, а некоторые проходили его несколько раз. Это не означает, что аудиты не имеют ценности; это лишь означает, что вопросы, на которые аудиты могут ответить, гораздо уже, чем предполагает большинство людей.
Отчёт об аудите описывает определённую версию, которую определённая команда просмотрела в определённый день. Но контракты обновляются, разрешения меняются, оракулы и кросс-чейн мосты, от которых зависят проекты, меняются, и каждую неделю появляются новые техники атак. С момента выдачи отчёта начинается его срок годности. Что ещё более проблематично, так это то, что старые контракты, развёрнутые годы назад и успешно прошедшие аудит тогда, сейчас повторно сканируются партиями, и глубокие уязвимости в контракте, который работает уже много лет, можно найти всего за чуть более десяти минут.
Это третий выпуск специальной рубрики 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 заключается в проведении строгого отбора и проверки проектов в процессе листинга, а также в подписании с командами проектов деклараций о непричинении вреда и надзоре за их соблюдением. Этот уровень призван решить ту часть, которую аудиты решить не могут: отсутствие уязвимостей в коде не означает, что команда не сделает выбор, который навредит пользователям.
Для проектов, прошедших листинг, мы проводим регулярные аудиты безопасности и используем мониторинг событий в сети для отслеживания состояния контрактов. Пользователи также могут в любое время проверить текущие риск-факторы данного контракта.
Вопрос 2. Поскольку разовый аудит не равен непрерывной безопасности, как командам проектов и отрасли в целом следует скорректировать подход?
Команда безопасности Gate: Криптоиндустрия обладает структурной особенностью: значительная часть её бизнеса, особенно DeFi, функционирует в режиме, близком к модульным финансам. Различные платформы строятся из общих компонентов: контрактов, программных библиотек, кошельков, ценовых оракулов, кросс-чейн мостов, поставщиков услуг подключения, веб-интерфейсов и систем, используемых для распространения обновлений.
Поэтому помимо вопроса о том, безопасны ли ваши собственные контракты, более важный вопрос — остаётся ли надёжным каждое звено, от которого вы зависите. Если вышестоящий компонент выходит из строя, убытки распространяются вниз по цепочке. Оглядываясь на крупные атаки, проблема часто кроется в звеньях, предшествующих логике протокола: поставщиках, инструментах разработки, способе доставки программного обеспечения пользователям или процессе, посредством которого пользователи одобряют переводы.
Партнёр GoPlus Адам: Парадигма атак, при которой хакеры используют автоматизированные инструменты для эффективного поиска уязвимостей, уже сформировалась и быстро распространяется. Атаки перешли от «ручного исследования экспертами» к «конвейеру». Если мышление отрасли всё ещё застряло на «найти аудиторскую фирму, чтобы выпустить отчёт перед запуском» или «найти компанию по безопасности, чтобы исправить ситуацию после обнаружения риска», это подобно использованию лука и стрел против пулемётов. Использование столь же эффективных инструментов для противодействия атакам — единственный действенный путь.
Направление корректировки на уровне отрасли — переход от «разовых аудитов» или «поиска экспертов после возникновения проблем» к «непрерывной безопасности на протяжении всего жизненного цикла». Возьмём в качестве примера «трио безопасности контрактов» GoPlus DeepScan; это замкнутый цикл, который можно реализовать:
Перед запуском — самопроверка безопасности токена: быстрая самопроверка за минуты на предмет рисков бэкдоров, таких как ханипоты, злонамеренный выпуск, чёрные списки, аномальные налоги на транзакции и права владельца;
При запуске — ИИ-аудит контракта: глубокий анализ исходного кода, управления правами и бизнес-логики, сканирование уязвимостей на уровне синтаксиса и уровне бизнес-логики, а также предоставление структурированного отчёта об аудите;
После запуска — непрерывный мониторинг безопасности и регулярные проверки состояния: отслеживание в реальном времени новой информации об уязвимостях, инцидентов атак и рисков от внешних зависимостей (оракулов, кросс-чейн мостов, сторонних протоколов), непрерывное определение того, затронут ли проект, и предоставление регулярных оповещений. Проведение регулярных проверок безопасности и непрерывных аудитов контрактов.
Вопрос 3. Как изменились методы обнаружения уязвимостей за последние два года? Для одного и того же актива в чём разница в модели безопасности между хранением в сети и хранением на бирже?
Партнёр 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 дней с момента инцидента через раздел «Моя защита» путём обращения в службу безопасности клиентов, с материалами, включающими записи полицейского протокола и записи о переводе активов.
Вопрос 5. Что должен содержать полный отчёт об аудите? Как следует использовать оценку безопасности, ключевые выводы и рекомендации по устранению по отдельности?
Адам, партнёр GoPlus: Отчёт об аудите, который может направлять действия (а не просто быть подшитым в архив), должен содержать как минимум четыре элемента:
1) Оценка безопасности (квантифицируемый рейтинг), используется для «быстрого отсеивания», а не для «окончательных выводов». Проектные команды могут использовать оценку как количественный ориентир для внутренних оценок безопасности, сравнивая изменения после каждой итерации; биржи могут использовать её для первичного отсеивания при листинге, чтобы отсеять явно несоответствующие проекты на первом этапе; обычные пользователи могут рассматривать оценку как «точку входа» — избегать низких оценок сразу, а при высоких оценках дополнительно изучать ключевые выводы.
2) Ключевые выводы (высокорисковые проблемы и основные заключения), используются для «принятия решений». Это «резюме для руководства» отчёта: какие проблемы являются блокирующими и должны быть исправлены до запуска. Для менеджеров без технического образования и команд проверки при листинге достаточно понимания ключевых выводов.
3) Детали проблем (доказательства уязвимостей и описание воздействия), используются для «локализации проблем». Это часть для технической команды, включающая местоположение уязвимости (с точностью до контракта, функции и строки кода), тип уязвимости, уровень серьёзности, описание пути атаки и анализ первопричины. Хорошие детали проблем должны предоставлять воспроизводимый путь выполнения и условия срабатывания, а не просто список проблем.
4) Рекомендации по устранению (действенные планы исправления), используются для «замыкания цикла». Рекомендации по устранению должны быть конкретными на уровне кода, действенными, а после устранения необходимо выполнить повторное сканирование и регрессионную проверку, формируя полный цикл «оценка, ключевые выводы, детали проблем, устранение, повторное сканирование».
Команда безопасности Gate: Мы хотели бы добавить три пункта из нашей практики создания функций аудита контрактов.
Во-первых, наиболее часто упускаются именно первые два пункта: цели и ограничения аудита, а также описание области охвата. Мы определили восемь измерений для отчётов — цели и ограничения аудита, описание области охвата, матрица серьёзности, определение приоритетов, детали уязвимостей, пути рисков, модель угроз, анализ ключевых функций и рекомендации по устранению — и именно первые два пункта определяют, неправильно ли читатели поймут весь отчёт. Если ограничения не указаны чётко, читатели будут предполагать, что охвачено всё; если область охвата не указана чётко, читатели не смогут определить, был ли проверен только основной контракт или также пул ликвидности, стратегические контракты, оракулы и внешние зависимости. Многие рекламные заявления лишь говорят «прошёл аудит», не указывая, что именно было проверено — такие заявления практически не несут информации.
Во-вторых, при рассмотрении ключевых выводов риски, которые по отдельности не считаются уязвимостями, следует рассматривать в совокупности. Возьмём распространённую комбинацию в отчётах: владелец контракта может вносить адреса в чёрный список для заморозки активов, торговая пара может быть сброшена, что приведёт к невозможности перевода для обычных пользователей, требование минимального хранения не позволяет пользователям полностью продать, и единственный владелец может в любой момент изменить несколько ключевых правил. По отдельности все четыре являются нормальным дизайном; в совокупности они означают, что контроль над этим контрактом сильно сосредоточен в руках одного человека.
В-третьих, вам нужно знать, как формируется отчёт, потому что это определяет границы его надёжности. Наш аудит контрактов проходит в три этапа: сначала статический анализ для проверки базовых рисков, таких как контроль разрешений, повторный вход, манипулирование ценой, флэш-кредиты и логическая согласованность; затем моделирование бизнес-сценариев — извлечение ключевых сценариев взаимодействия контракта, проверка бизнес-путей и граничных условий, выявление проблем, которые не может охватить сканирование на основе правил; наконец, семантическая верификация — постатейная проверка ключевых бизнес-путей для подтверждения того, действительно ли риски, выявленные на первых двух этапах, имеют место. Третий этап в основном предназначен для снижения доли ложных срабатываний. Отчёт, полный ложных срабатываний, быстро исчерпает терпение пользователей, и в конечном итоге они вовсе пропустят весь этап проверки — поэтому доля ложных срабатываний напрямую определяет, будет ли этот инструмент реально использоваться.
Вопрос 6. Какие меры укрепления безопасности могут предпринять прямо сейчас обычные пользователи?
Адам, партнёр GoPlus:
1) Проверяйте безопасность токена перед торговлей. Перед покупкой новой монеты проверьте безопасность самого токена и следите за рисками бэкдоров, такими как мошенничество с honeypot, злонамеренная эмиссия, чёрные списки, аномальные налоги на транзакции и чрезмерные права Owner.
2) Регулярно очищайте одобрения контрактов. Отзывайте Approvals для DApps, которые вы больше не используете, особенно неограниченные одобрения — многие кражи происходят из-за проблем с «контрактами, которые вы когда-то одобрили».
3) Укрепляйте безопасность на уровне аккаунта. Используйте надёжные пароли и включайте 2FA; управляйте API-ключами по принципу наименьших привилегий и никогда не предоставляйте права на вывод средств недоверенным инструментам.
4) Сделайте антифишинг мышечной памятью. Проверяйте домен перед подписанием, не переходите по ссылкам в личных сообщениях и по умолчанию не доверяйте «аирдропам/службе поддержки/высокодоходному стейкингу»; фишинговый контент становится всё более убедительным, поэтому всегда сохраняйте рациональность.
5) Храните активы послойно по назначению. Держите в горячих кошельках только небольшую сумму средств, необходимых для использования; для крупных активов используйте аппаратные кошельки — не кладите все яйца в одну корзину.
6) Ориентируйтесь на «отношение к безопасности» проекта, а не на его «отчёт об аудите». Наличие непрерывного аудита и механизма мониторинга безопасности важнее, чем отчёт об аудите многолетней давности; отдавайте предпочтение проектам, которые ценят безопасность и готовы публично раскрывать механизмы построения безопасности.
Команда безопасности Gate: шесть пунктов Адама уже довольно полны. Мы хотели бы объединить их с инструментами Gate, чтобы превратить несколько из них в операции, которые вы можете выполнить прямо сейчас.
1) Проверяйте токен перед торговлей — здесь вы можете напрямую использовать функцию аудита контрактов Gate AI. Отправьте адрес контракта и получите отчёт за считанные минуты; обратите внимание на четыре пункта: права владельца, чёрный список и ограничения на торговлю, права на эмиссию и налог на перевод. Если хотя бы один из этих четырёх пунктов отмечен красным, вам следует остановиться — дальше смотреть не нужно.
2) Укрепите свой аккаунт — сначала поднимите свой рейтинг безопасности выше 80. Пароль фонда, аутентификатор, двухфакторная верификация, антифишинговый код, ключи доступа, дневной лимит на вывод, управление способами вывода — все эти элементы защиты есть в контрольном списке; просто следуйте подсказкам и выполняйте их по порядку. Главная ценность рейтинга безопасности в том, что он превращает разрозненные настройки в упорядоченный контрольный список, чтобы вам не приходилось решать, что делать в первую очередь. Достижение 80 и выше также позволяет активировать Программу защиты безопасности аккаунта, что означает дополнительный уровень подстраховки после того, как вы должным образом укрепили свой аккаунт.
3) Для антифишинга есть два готовых инструмента. Если вы получили сообщение, якобы от Gate, сначала проверьте через официальный канал верификации, принадлежит ли нам домен или электронная почта; все письма, отправленные Gate, будут содержать антифишинговый код, который вы установили сами — любое письмо без этого кода является подделкой.
4) Перед подписанием чётко проверяйте сумму одобрения. То, что сам контракт в порядке, не означает, что транзакция, которую страница просит вас подписать, в порядке. Нормальный DApp вполне может запрашивать только сумму, необходимую для этой транзакции; запрос неограниченного одобрения сразу — сам по себе повод приостановиться. Если во всплывающем окне только строка непонятных символов, отказ всегда безопаснее, чем сначала подписать, а потом задавать вопросы.
В заключение мы хотим сказать, что безопасность динамична, а не статична.
Запуск после аудита — это лишь отправная точка работы по безопасности. Для проектных команд это означает, что непрерывный мониторинг после запуска важнее самого отчёта; для торговых платформ это означает, что листинг — лишь начало проверки; а для обычных пользователей те несколько минут самопроверки перед подписанием — это шаг с наименьшими затратами и в то же время наиболее легко пропускаемый.
Безопасность никогда не была разовой сертификацией. Если все стороны сделают ещё один шаг, баланс между атакой и защитой склонится в пользу нас, «привратников».
Давайте встретимся вместе на четвёртом занятии «Курса по безопасности ворот»!
