Глубина анализа ситуации с Safe: сможет ли Guard реконструировать контрактную Вавилонскую башню?

21 февраля 2025 года криптовалютная индустрия столкнулась с самой серьезной в своей истории кризисом управления активами. Мультиподписной кошелек на одном из торговых платформ был целенаправленно взломан, и почти 1,5 миллиарда долларов активов незаметно утекли через "законную подпись" в одной сделке. После анализа на блокчейне было показано, что злоумышленник получил мультиподписные права с помощью точного социального инжиниринга, используя функцию deleGatecall контракта Safe для внедрения вредоносной логики, в конечном итоге обойдя механизм проверки множественной подписи и переведя средства на анонимный адрес.

Этот инцидент выявил жестокую реальность: "Мультиподпись" не равняется "абсолютной безопасности". Даже такие безопасные механизмы, как мультиподписной кошелек Safe, подвержены риску взлома, если отсутствуют дополнительные меры защиты. Это не первый случай атаки на мультиподписной кошелек Safe. В прошлом году две известные биржи понесли убытки в 230 миллионов долларов и 50 миллионов долларов соответственно, подвергшись аналогичным методам атаки. Инциденты с атаками на мультиподписные кошельки Safe демонстрируют следующую техническую однородность:

• Чрезмерная зависимость от механизма подписи: передача всех обязанностей по безопасности на хранение приватного ключа.
• Отсутствие динамической защиты: нехватка сканирования рисков в реальном времени перед выполнением сделки.
• Грубый контроль доступа: не была установлена белая структура для высокорисковых операций, таких как deleGatecall.

核心问题 этой серии событий заключается не в самом контракте Safe, а в потенциальных рисках безопасности в процессе интеграции всей системы, особенно на этапе проверки на фронт-энде. Это побуждает нас задуматься: как можно усилить защитные возможности мультиподписного кошелька с помощью дополнительных механизмов безопасности Safe?

Безопасно

Safe является многоподписным ( Multi-Sig ) кошельком, предназначенным для управления безопасным хранением и перемещением высокоценных активов и цифровых валют. Как инфраструктура для децентрализованного управления активами, он обеспечивает безопасность операций с фондом через механизм совместной верификации несколькими сторонами, предотвращая использование единой точки отказа для злонамеренных действий со стороны одного администратора или хакера. Широко используется в таких сценариях, как управление DAO, доверительное управление корпоративными средствами, децентрализованные фонды и т.д. Этот контракт разработан командой Safe (ранее Gnosis Safe) и является текущим стандартом решения для управления активами на блокчейне. Контракт использует стандарт EIP-712 для реализации структурированной подписи данных, что повышает безопасность и проверяемость данных транзакций.

Основное назначение

• Управление безопасностью средств: Контракт требует, чтобы несколько заранее установленных владельцев (Owners) совместно подтвердили сделку для ее выполнения, что эффективно предотвращает ошибки в одной точке или злонамеренные действия, обеспечивая безопасность средств.
• Исполнение и управление сделками: благодаря встроенному механизму многоподписки, контракт может выполнять внешние переводы, вызывать другие контракты или обрабатывать сложную бизнес-логику при выполнении условий порога подписей, поддерживая оплату токенами и нативной валютой, а также компенсацию расходов.
• Модульное расширение: Контракт использует модульный дизайн, позволяя наследовать и комбинировать несколько управленческих модулей (таких как OwnerManager, ModuleManager, GuardManager, FallbackManager и т. д.), что делает его функциональность гибкой и легкой для расширения, предоставляя индивидуальную поддержку для различных сценариев применения.

Функция анализа

Функция execTransaction выполняет транзакцию, прошедшую многоуровневую проверку подписи:

• Вычисление уникального хеш-значения транзакции (с учетом параметров транзакции, nonce и т.д.);
• Проверка действительности всех подписей, чтобы убедиться, что каждая подпись исходит от законного владельца или предварительно одобренного адреса;
• Вызов бизнес-логики целевого адреса и запись состояния успеха или неудачи через событие после выполнения транзакции;
• Поддержка гибкой обработки газовых сборов, что обеспечивает точный расчет стоимости транзакции при оплате компенсации.

Функции checkContractSignatures и checkNSignatures проверяют данные подписей транзакций или сообщений:

• Обработка подписей EOA-аккаунтов, подписей контрактов (EIP-1271), а также предварительно одобренных хэшей;
• Убедитесь, что подписи расположены в порядке владельцев и каждая подпись поступает из действительного адреса, чтобы предотвратить атаки повторного воспроизведения и подделку подписей.

Функция getTransactionHash генерирует хэш транзакции, который используется для проверки подписи и предотвращения повторных атак:

• Использование стандарта EIP-712 для структурированного хэширования данных транзакций;
• Используйте встроенную ассемблерную оптимизацию операций с памятью для повышения вычислительной эффективности;
• В сочетании с текущим значением nonce, обеспечьте уникальность каждой транзакции.

Функция handlePayment обрабатывает оплату компенсации газа в процессе выполнения сделки:

• Рассчитайте сумму платежа на основе фактически израсходованных газовых сборов и базовых сборов;
• Поддержка платежей в ETH и других токенах, обеспечивающая точное возмещение затрат.

onBeforeExecTransaction является внутренней виртуальной функцией обратного вызова, которая вызывается перед выполнением функции execTransaction. Целью этой функции является предоставление возможности дочерним контрактам, наследующим Safe контракт, выполнять пользовательскую логику перед выполнением транзакции. Принятый набор параметров включает в себя:

• to：Адрес назначения - Адрес контракта или счета, который следует вызвать для сделки
• значение: количество эфира - количество эфира, отправляемого с транзакцией
• data：Данные нагрузки - содержат данные вызова с селектором функции и параметрами
• operation：Тип операции - определить, является ли это CALL или DELEGateCALL
• safeTxGas：ограничение газа для транзакции - количество газа, зарезервированного для выполнения транзакции
• baseGas：базовый gas - стоимость gas, независимая от выполнения транзакции
• gasPrice：газовая цена - используется для расчета компенсации за торговые сборы
• gasToken: газовый токен - адрес токена, используемого для оплаты транзакционных сборов
• refundReceiver: Получатель возврата - адрес, получающий компенсацию за транзакционные сборы
• signatures：Подпись набора - данные подписи владельца для транзакции

Несмотря на то, что многофункциональные кошельки с многоуровневыми контрактами предлагают эффективное и безопасное решение для управления цифровыми активами благодаря строгому дизайну безопасности и гибкой модульной структуре, обеспечивая полное управление безопасностью на всех этапах — от инициации транзакции до ее окончательного выполнения, и становятся важным инструментом для управления безопасностью в блокчейне, также следует отметить, что жертвы в большинстве своем полагаются на аппаратные кошельки для подписи, и некоторые аппаратные устройства имеют плохую отображаемость подписей структурированных данных, что может привести к тому, что пользователи не смогут точно идентифицировать данные транзакции в краткие сроки, что создает риск "слепой подписи". В ответ на это явление, помимо оптимизации аппаратного обеспечения и улучшения отображения данных, также можно рассмотреть возможность добавления многократного подтверждения, интеллектуальных подсказок и улучшенных инструментов для проверки подписи, чтобы дополнительно снизить потенциальные риски безопасности, связанные со слепой подписью.

Защита

В версии 1.3.0 контракта Safe была введена важная функция безопасности ------ механизм Safe Guard. Этот механизм предназначен для обеспечения дополнительных ограничений для стандартной схемы многоподписей n-out-of-m, что дополнительно повышает безопасность транзакций. Основная ценность Safe Guard заключается в возможности проведения проверок безопасности на различных этапах выполнения транзакции:

• Проверка перед транзакцией (checkTransaction): Механизм Guard может программно проверять все параметры транзакции перед ее выполнением, чтобы гарантировать соответствие транзакции заданным правилам безопасности.
• Проверка после сделки (checkAfterExecution): После завершения выполнения сделки Guard также проведет дополнительную проверку безопасности, чтобы убедиться, что окончательное состояние кошелька Safe соответствует ожиданиям.

Анализ архитектуры

В Safe многофункциональные транзакции обычно выполняются с помощью функции execTransaction. В случае включенного Safe Guard, когда пользователь выполняет многофункциональную транзакцию, контракт Safe вызывает функцию checkTransaction контракта Guard для проверки перед выполнением транзакции, а после завершения выполнения многофункциональной транзакции контракт Safe вызывает функцию checkAfterExecution контракта Guard для проверки результата выполнения транзакции.

Когда контракт Safe выполняет предварительную проверку многоподписных транзакций через механизм Guard, его функция checkTransaction принимает полные данные контекста транзакции, включая адрес целевого контракта, способ вызова, данные выполнения (например, deleGatecall), информацию о подписях владельца, настройки Gas и информацию о платежах. Этот механизм позволяет разработчикам реализовать многогранные стратегии управления рисками, такие как управление белым списком контрактов (ограничение взаимодействующих адресов), управление правами на уровне функций (отключение высокоопасных селекторов функций), ограничение частоты транзакций и динамические правила на основе направления потока средств и т.д. При разумной настройке стратегий Guard можно эффективно блокировать атаки злоумышленников, использующих неуровневые контракты для нападения.

В условиях недавних инцидентов с безопасностью все большее внимание уделяется безопасности многофункциональных кошельков с многоподпиской. Поставщики аппаратных кошельков призывают усилить возможности анализа и защиты Safe-контрактов, чтобы предотвратить повторение подобных рисков. После инцидента на одной из торговых платформ многие проектные команды начали сосредотачиваться на Safe-контрактах и исследовать обновления и расширения на основе механизма Guard. Среди них есть инновационные приложения на основе механизма Guard, которые создают промежуточное решение по безопасности, основанное на многофункциональном кошельке Safe, обеспечивая дополнительную безопасность между базовыми активами и активами пользователей. Его основная функция заключается в том, чтобы передавать в функцию checkTransaction целевые контракты, способы вызова, данные выполнения, информацию о подписи владельца, информацию о платеже и информацию о газе, связанные с многофункциональными транзакциями Safe, для реализации детальной проверки транзакций, включая контроль доступа к вызовам контрактов из белого списка, операциям функций из белого списка, целям перевода из белого списка, частоте транзакций и другим контролям.

Стоит отметить, что сам Safe предоставляет только функции управления Guard и обратного вызова, а фактическая логика проверки многоподписей реализуется пользователями самостоятельно, и её безопасность зависит от качества реализации Guard. Например, одно из решений по безопасности расширило эту идею, назначив специального Guardian для каждого Vault, чтобы указать разрешенные целевые адреса и права доступа, реализовав три основных элемента контроля доступа: указание разрешенных контрактов, определение разрешенных функций и требования верификации ACL. При этом используется разделенный механизм управления, где Vault Guardian отвечает за выполнение, а Governor контролирует права управления, что обеспечивает возможность своевременного принятия мер по защите активов пользователей, даже если возникнут проблемы с Guardian. Похожая концепция дизайна также применяется в другом модуле безопасности, который перехватывает ключевые операции с помощью функции preExecute и осуществляет тонкий контроль над высокорисковыми операциями, такими как установка модуля, настройка хуков и управление верификаторами, с помощью механизма белого списка, тем самым гарантируя, что только проверенные контракты могут быть добавлены в систему, обеспечивая долговременную безопасность для кошелька.

В цепочке атак на платформе обмена, если контракт Safe развернут с разумно настроенным механизмом Guard, вредоносный deleGatecall, инициированный злоумышленником через execTransaction, будет перехвачен на этапе предварительной проверки несколькими стратегиями: функция checkTransaction механизма Guard сначала распознает тип операции deleGatecall и активирует правила отключения (например, принудительно ограничивает операцию только обычными вызовами), затем анализирует поле data и обнаруживает аномальный адрес контракта и высокорисковый селектор функции, с помощью предустановленных стратегий белого списка контрактов и черного списка функций транзакция будет отменена, в конечном итоге формируя защитную систему «перехват стратегии → логическое блокирование», полностью блокируя пути изменения данных и перевода средств.

В целом, Safe предоставляет функцию Guard только после версии 1.3.0. Хотя Guard может обеспечить очень тонкую проверку многоподписных транзакций, пользователи сталкиваются с высокими барьерами при использовании функции Guard. Им необходимо самостоятельно реализовать логику проверки Guard, и грубая или дефектная реализация Guard может не помочь пользователям повысить безопасность их кошельков Safe, поэтому важно провести аудит безопасности реализации Guard. Безусловно, безопасная и правильная реализация Guard может значительно повысить безопасность кошелька Safe.

Заключение и перспектива

Инцидент с атакой на одну из торговых платформ подчеркивает важность своевременного обновления безопасности инфраструктуры. Эта платформа использовала версию v1.1.1(\u003c1.3.0) контракта Safe, что означает, что они не могли воспользоваться ключевой функцией безопасности Guard. Если бы эта платформа обновила контракт Safe до версии 1.3.0 или выше и реализовала соответствующий механизм Guard, например, указав уникальный адрес в белом списке для получения средств и проведя строгую верификацию ACL функций контракта, возможно, она могла бы избежать этих потерь. Хотя это всего лишь гипотеза, она предоставляет важные идеи для управления безопасностью активов в будущем.

Механизм Safe Guard похож на интеллектуальную систему безопасности, установленную в сейф для цифровых активов, и его эффективность зависит от строгости дизайна правил и качества их реализации. Столкнувшись с все более сложными методами атак, нам нужно:

• Автоматизированная проверка: создание автоматизированного механизма проверки сделок
• Динамическая настройка стратегии: реальная настройка безопасности на основе разведывательной информации о угрозах
• Многоуровневая защита: создание системы глубинной защиты с использованием различных механизмов безопасности
• Постоянный аудит: реализация Guard