Глубина анализа ситуации с Safe: сможет ли Guard реконструировать Бабельскую башню контракта?
21 февраля 2025 года криптовалютная индустрия столкнулась с самой серьезной кризисом управления активами в своей истории. Мультиподписной кошелек на одном из торговых платформ был целенаправленно атакован, и почти 1,5 миллиарда долларов активов исчезли через "легитимную подпись" транзакции. После анализа на блокчейне выяснилось, что злоумышленник с помощью тщательной социальной инженерии получил права мультиподписей, использовал функцию deleGatecall контракта Safe для внедрения вредоносной логики и в конечном итоге обошел механизм проверки нескольких подписей, переведя средства на анонимный адрес.
Этот инцидент выявил жестокую реальность: "мультиподпись" не равна "абсолютной безопасности"; даже такие механизмы безопасности, как мультиподписной кошелек Safe, все еще подвержены риску взлома при отсутствии дополнительных мер защиты. Это не первый случай атаки на мультиподписной кошелек Safe. В прошлом году две платформы понесли убытки в 230 миллионов и 50 миллионов долларов соответственно, столкнувшись с аналогичными методами атаки. Атаки на мультиподписной кошелек Safe демонстрируют следующую технологическую однородность:
Избыточная зависимость от механизма подписи: передача всех обязательств по безопасности на хранение закрытого ключа.
Отсутствие динамической защиты: нехватка сканирования рисков в реальном времени перед выполнением сделок.
Контроль доступа с грубой гранулярностью: не установлена белая список для высокорисковых операций, таких как deleGatecall.
Основная проблема этой серии событий заключается не в самом контракте Safe, а в потенциальных угрозах безопасности в процессе интеграции всей системы, особенно на этапе верификации на фронтенде. Это побуждает нас задуматься: как можно усилить защитные способности мультиподписного кошелька с помощью дополнительных механизмов безопасности Safe?
Безопасно
Safe является мультиподписным кошельком (Multi-Sig), предназначенным для управления безопасным хранением и передачей высокоценного актива и цифровых валют. В качестве инфраструктуры для децентрализованного управления активами он обеспечивает безопасность операций с финансами через механизм совместной проверки несколькими сторонами, предотвращая злоупотребления со стороны единственного администратора или хакера, использующего единую точку отказа, и широко применяется в таких сценариях, как управление DAO, доверительное управление корпоративными фондами, децентрализованные фонды и т.д. Этот контракт разработан командой 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：Данные нагрузки - содержат данные вызова с селектором функции и параметрами
операция：Тип операции - определить, является ли это CALL или DELEGateCALL
safeTxGas: ограничение газа для транзакций - количество газа, зарезервированного для выполнения транзакции
baseGas: базовый gas - стоимость gas, независимая от выполнения сделки
gasPrice：gas цена - используется для расчета компенсации транзакционных расходов
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 предоставляет только функции управления Guard и обратных вызовов, фактическая логика проверки многоподписей реализуется пользователем самостоятельно, а его безопасность зависит от качества реализации Guard. Некоторые решения расширили эту идею, назначив специального Guardian для каждой конфигурации Vault, чтобы указать допустимые целевые адреса и права на операции, реализуя три основных элемента контроля доступа: указание разрешенных контрактов, определение разрешенных функций и требования к валидации ACL. При этом используется раздельный механизм управления, за выполнение отвечает Vault Guardian, а Governor контролирует полномочия управления, что гарантирует, что даже если у Guardian возникнут проблемы, можно будет своевременно принять меры для защиты активов пользователей. Подобные дизайнерские идеи также применяются в других проектах в модулях безопасности, путем перехвата ключевых операций и с помощью механизма белого списка для тонкой настройки управления высокорисковыми операциями, такими как установка модулей, настройка хуков и управление валидаторами, что гарантирует, что только доверенные контракты могут быть добавлены в систему, обеспечивая долговременную безопасность кошелька.
В случае цепочки атак на платформе обмена, если контракт Safe задействует разумно настроенный механизм Guard, то вредоносный deleGatecall, инициируемый злоумышленником через execTransaction, будет перехвачен множеством стратегий на этапе предварительной проверки: функция checkTransaction механизма Guard сначала распознает тип операции deleGatecall и активирует правила отключения (например, принудительное ограничение операции только обычными вызовами), затем анализирует поле data и обнаруживает нестандартный адрес контракта и опасный селектор функции, после чего через предустановленный белый список контрактов и черный список функций транзакция будет отменена, в конечном итоге формируя защитную систему «перехват стратегии → логическая блокировка», полностью блокируя пути к изменению данных и перемещению средств.
В целом, функция Guard в Safe доступна только начиная с версии 1.3.0. Хотя Guard может обеспечить крайне детальную проверку многофакторных транзакций, пользователи сталкиваются с высокими барьерами при использовании этой функции. Им необходимо самостоятельно реализовать логику проверки Guard, и грубая или дефектная реализация Guard может не помочь пользователям повысить безопасность их кошелька Safe, поэтому проведение аудита безопасности реализации Guard является необходимым. Безусловно, безопасная и правильная реализация Guard может значительно повысить безопасность кошелька Safe.
Заключение и перспективы
Инцидент с атакой на одну торговую платформу подчеркивает важность своевременного обновления инфраструктуры безопасности. Эта платформа использует версию Safe контракта v1.1.1 (<1.3.0), что означает, что они не могут использовать механизм Guard, эту ключевую функцию безопасности. Если бы платформа обновила свой Safe контракт до версии 1.3.0 или выше и реализовала соответствующий механизм Guard, например, указала единственный адрес в белом списке для получения средств и провела строгую проверку ACL функций контракта, возможно, она смогла бы избежать этих потерь. Хотя это всего лишь гипотеза, она предоставляет важные идеи для управления безопасностью активов в будущем.
Механизм Safe Guard похож на умную систему безопасности, установленную в сейф для цифровых активов, и его эффективность зависит от строгости проектирования правил и качества выполнения. В условиях всё более сложных методов атак нам нужно:
Автоматизированная проверка: создание автоматизированного механизма проверки сделок
Динамическая корректировка стратегии: актуализация безопасности в реальном времени на основе угроз.
Многоуровневая защита: создание системы глубины защиты на основе различных механизмов безопасности
Постоянный аудит: регулярный аудит безопасности реализации Guard
Будущее управления цифровыми активами будет умным.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
8 Лайков
Награда
8
4
Поделиться
комментарий
0/400
MetaverseLandlord
· 07-09 09:40
Безопасность снова была нарушена? Я не могу понять.
Посмотреть ОригиналОтветить0
MEVictim
· 07-09 09:39
Эх, этот safe — просто шутка.
Посмотреть ОригиналОтветить0
MechanicalMartel
· 07-09 09:39
Еще один смарт-контракт с уязвимостью🤔
Посмотреть ОригиналОтветить0
SchrodingerWallet
· 07-09 09:26
разыгрывайте людей как лохов несколько лет, а все еще занимаются ерундой
Механизм Safe Guard: новое направление в реконструкции архитектуры безопасности Кошелька с несколькими подписями
Глубина анализа ситуации с Safe: сможет ли Guard реконструировать Бабельскую башню контракта?
21 февраля 2025 года криптовалютная индустрия столкнулась с самой серьезной кризисом управления активами в своей истории. Мультиподписной кошелек на одном из торговых платформ был целенаправленно атакован, и почти 1,5 миллиарда долларов активов исчезли через "легитимную подпись" транзакции. После анализа на блокчейне выяснилось, что злоумышленник с помощью тщательной социальной инженерии получил права мультиподписей, использовал функцию deleGatecall контракта Safe для внедрения вредоносной логики и в конечном итоге обошел механизм проверки нескольких подписей, переведя средства на анонимный адрес.
Этот инцидент выявил жестокую реальность: "мультиподпись" не равна "абсолютной безопасности"; даже такие механизмы безопасности, как мультиподписной кошелек Safe, все еще подвержены риску взлома при отсутствии дополнительных мер защиты. Это не первый случай атаки на мультиподписной кошелек Safe. В прошлом году две платформы понесли убытки в 230 миллионов и 50 миллионов долларов соответственно, столкнувшись с аналогичными методами атаки. Атаки на мультиподписной кошелек Safe демонстрируют следующую технологическую однородность:
Основная проблема этой серии событий заключается не в самом контракте Safe, а в потенциальных угрозах безопасности в процессе интеграции всей системы, особенно на этапе верификации на фронтенде. Это побуждает нас задуматься: как можно усилить защитные способности мультиподписного кошелька с помощью дополнительных механизмов безопасности Safe?
Безопасно
Safe является мультиподписным кошельком (Multi-Sig), предназначенным для управления безопасным хранением и передачей высокоценного актива и цифровых валют. В качестве инфраструктуры для децентрализованного управления активами он обеспечивает безопасность операций с финансами через механизм совместной проверки несколькими сторонами, предотвращая злоупотребления со стороны единственного администратора или хакера, использующего единую точку отказа, и широко применяется в таких сценариях, как управление DAO, доверительное управление корпоративными фондами, децентрализованные фонды и т.д. Этот контракт разработан командой Safe и является текущим стандартным решением для управления активами на блокчейне. Контракт использует стандарт EIP-712 для реализации структурированной подписи данных, что повышает безопасность и возможность проверки данных транзакций.
Основное назначение
Функция анализа
функция execTransaction выполняет транзакцию, прошедшую многоуровневую проверку подписи:
Функции checkContractSignatures и checkNSignatures проверяют данные подписи транзакции или сообщения:
Функция getTransactionHash генерирует хэш транзакции, который используется для проверки подписи и предотвращения атак повторного воспроизведения:
Функция handlePayment обрабатывает оплату компенсации газа во время выполнения процесса транзакции:
onBeforeExecTransaction является внутренней виртуальной хуковой функцией, вызываемой перед выполнением функции execTransaction. Дизайн этой функции предназначен для того, чтобы позволить дочерним контрактам, наследующим Safe контракт, выполнять пользовательскую логику перед выполнением транзакции. Принимаемый набор параметров включает:
Несмотря на то, что многофункциональные кошельки на основе контрактов благодаря своей строгой безопасности и гибкой модульной структуре предоставляют эффективное и безопасное решение для управления цифровыми активами, обеспечивая полный контроль безопасности на всех этапах, от инициации транзакции до окончательного выполнения, и становятся важным инструментом для безопасности в блокчейне, также необходимо отметить, что жертвы в основном полагаются на аппаратные кошельки для подписи, и некоторые аппаратные устройства имеют плохую визуализацию структурированных данных, что может привести к тому, что пользователи не смогут точно распознать данные транзакции в короткий срок, что создает риск "слепой подписи". В ответ на это явление, помимо оптимизации аппаратного обеспечения и улучшения визуализации данных, также можно рассмотреть возможность увеличения многоуровневых подтверждений, интеллектуальных подсказок и улучшения инструментов проверки подписи, чтобы дополнительно снизить риски безопасности, связанные со слепой подписью.
Защита
Важная функция безопасности, введенная в версии 1.3.0 Safe контракта - механизм Safe Guard. Этот механизм предназначен для предоставления дополнительных ограничений стандартной многоподписной схемы n-out-of-m, что еще больше увеличивает безопасность транзакций. Основная ценность Safe Guard заключается в возможности проведения проверок безопасности на различных этапах выполнения транзакции:
Анализ архитектуры
В Safe многосторонние сделки обычно выполняются с помощью функции execTransaction. В случае включенного Safe Guard, когда пользователь выполняет многостороннюю сделку, контракт Safe вызывает функцию checkTransaction контракта Guard для проверки перед выполнением сделки, а после завершения выполнения многосторонней сделки, контракт Safe вызывает функцию checkAfterExecution контракта Guard для проверки результата выполнения сделки.
Когда контракт Safe выполняет предварительную проверку многофакторной транзакции через механизм Guard, его функция checkTransaction будет принимать полный контекст данных транзакции, включая адрес целевого контракта, способ вызова, данные выполнения (например, deleGatecall), информацию о подписи владельца, настройки Gas и информацию о платеже. Этот механизм позволяет разработчикам реализовать многослойные стратегии управления рисками, такие как управление белым списком контрактов (ограничение взаимодействующих адресов), управление правами на уровне функций (деактивация высокоопасных селекторов функций), ограничения по частоте транзакций и динамические правила на основе движения средств и т.д. При разумной конфигурации стратегии Guard можно эффективно блокировать атаки злоумышленников с использованием неуровневых атак.
На фоне недавних инцидентов с безопасностью возрастает внимание к безопасности многоподписных кошельков со стороны всех участников. Поставщики аппаратных кошельков призывают усилить анализ и защиту Safe-контрактов, чтобы предотвратить подобные риски в будущем. После инцидента на одной из торговых платформ многие проекты начали сосредотачиваться на Safe-контрактах и исследовать возможности обновления и расширения на основе механизма Guard. Среди них есть инновационные приложения, основанные на механизме Guard, которые создают промежуточное решение по безопасности на основе многоподписного кошелька Safe, обеспечивая дополнительную защиту между основными активами и активами пользователей. Его основная функция заключается в том, что через функцию checkTransaction передаются целевые контракты, способы вызова, данные выполнения, информация о подписи владельца, информация о платеже и информация о газе, что позволяет провести очень детальную проверку транзакции, включая контроль разрешений на вызов контрактов из белого списка, операции функций из белого списка, целевые переводы из белого списка, частоту транзакций и т.д.
Стоит отметить, что сам Safe предоставляет только функции управления Guard и обратных вызовов, фактическая логика проверки многоподписей реализуется пользователем самостоятельно, а его безопасность зависит от качества реализации Guard. Некоторые решения расширили эту идею, назначив специального Guardian для каждой конфигурации Vault, чтобы указать допустимые целевые адреса и права на операции, реализуя три основных элемента контроля доступа: указание разрешенных контрактов, определение разрешенных функций и требования к валидации ACL. При этом используется раздельный механизм управления, за выполнение отвечает Vault Guardian, а Governor контролирует полномочия управления, что гарантирует, что даже если у Guardian возникнут проблемы, можно будет своевременно принять меры для защиты активов пользователей. Подобные дизайнерские идеи также применяются в других проектах в модулях безопасности, путем перехвата ключевых операций и с помощью механизма белого списка для тонкой настройки управления высокорисковыми операциями, такими как установка модулей, настройка хуков и управление валидаторами, что гарантирует, что только доверенные контракты могут быть добавлены в систему, обеспечивая долговременную безопасность кошелька.
В случае цепочки атак на платформе обмена, если контракт Safe задействует разумно настроенный механизм Guard, то вредоносный deleGatecall, инициируемый злоумышленником через execTransaction, будет перехвачен множеством стратегий на этапе предварительной проверки: функция checkTransaction механизма Guard сначала распознает тип операции deleGatecall и активирует правила отключения (например, принудительное ограничение операции только обычными вызовами), затем анализирует поле data и обнаруживает нестандартный адрес контракта и опасный селектор функции, после чего через предустановленный белый список контрактов и черный список функций транзакция будет отменена, в конечном итоге формируя защитную систему «перехват стратегии → логическая блокировка», полностью блокируя пути к изменению данных и перемещению средств.
В целом, функция Guard в Safe доступна только начиная с версии 1.3.0. Хотя Guard может обеспечить крайне детальную проверку многофакторных транзакций, пользователи сталкиваются с высокими барьерами при использовании этой функции. Им необходимо самостоятельно реализовать логику проверки Guard, и грубая или дефектная реализация Guard может не помочь пользователям повысить безопасность их кошелька Safe, поэтому проведение аудита безопасности реализации Guard является необходимым. Безусловно, безопасная и правильная реализация Guard может значительно повысить безопасность кошелька Safe.
Заключение и перспективы
Инцидент с атакой на одну торговую платформу подчеркивает важность своевременного обновления инфраструктуры безопасности. Эта платформа использует версию Safe контракта v1.1.1 (<1.3.0), что означает, что они не могут использовать механизм Guard, эту ключевую функцию безопасности. Если бы платформа обновила свой Safe контракт до версии 1.3.0 или выше и реализовала соответствующий механизм Guard, например, указала единственный адрес в белом списке для получения средств и провела строгую проверку ACL функций контракта, возможно, она смогла бы избежать этих потерь. Хотя это всего лишь гипотеза, она предоставляет важные идеи для управления безопасностью активов в будущем.
Механизм Safe Guard похож на умную систему безопасности, установленную в сейф для цифровых активов, и его эффективность зависит от строгости проектирования правил и качества выполнения. В условиях всё более сложных методов атак нам нужно:
Будущее управления цифровыми активами будет умным.