Profundidade da análise da situação de Safe: Guard pode reconstruir a Torre de Babel dos contratos?

No dia 21 de fevereiro de 2025, a indústria de criptomoedas enfrentou a mais grave crise de gestão de ativos da sua história. A carteira multi-assinatura em cadeia de uma certa plataforma de negociação foi direcionada e comprometida, resultando na perda silenciosa de quase 1,5 bilhões de dólares em ativos através de uma transação com uma "assinatura legítima". A análise em cadeia posterior revelou que o atacante obteve permissões de multi-assinatura por meio de um ataque de engenharia social sofisticado, implantou uma lógica maliciosa utilizando a função deleGatecall do contrato Safe e, finalmente, contornou o mecanismo de verificação de múltiplas assinaturas, transferindo os fundos para um endereço anônimo.

Este evento expôs uma cruel realidade: "multi-assinatura" não é igual a "segurança absoluta". Mesmo mecanismos de segurança como a carteira multi-assinatura Safe, se carecerem de medidas de proteção adicionais, ainda apresentam risco de serem comprometidos. Este também não é o primeiro caso de ataque à carteira multi-assinatura Safe. No ano passado, duas exchanges conhecidas perderam 230 milhões de dólares e 50 milhões de dólares, ambas enfrentando métodos de ataque semelhantes. Os eventos de ataque à carteira multi-assinatura Safe apresentam a seguinte homogeneidade técnica:

• Dependência excessiva do mecanismo de assinatura: transferir toda a responsabilidade de segurança para a custódia da chave privada.
• Falta de defesa dinâmica: falta de análise de risco em tempo real antes da execução da transação.
• Controle de permissões de forma grosseira: não foi estabelecido um mecanismo de lista branca para operações de alto risco como deleGatecall.

A questão central desta série de eventos não reside no contrato Safe em si, mas sim nas vulnerabilidades de segurança durante o processo de integração do sistema como um todo, especialmente na fase de validação no frontend. Isso nos leva a refletir: como podemos fortalecer a capacidade de proteção das carteiras multi-assinatura através de mecanismos de segurança adicionais do Safe?

Seguro

Safe é uma carteira Multi-Sig( de múltiplas assinaturas, principalmente utilizada para gerenciar o armazenamento seguro e a transferência de ativos de alto valor e criptomoedas. Como infraestrutura para gerenciamento descentralizado de ativos, garante a segurança das operações financeiras através de um mecanismo de verificação colaborativa entre várias partes, prevenindo que um único administrador ou hacker explore falhas pontuais para realizar operações maliciosas, sendo amplamente aplicada em cenários como governança DAO, custódia de fundos corporativos e pools de fundos descentralizados. O contrato foi desenvolvido pela equipe do Safe (originalmente Gnosis Safe) e é a solução de gerenciamento de ativos em cadeia padrão da indústria atual. O contrato adota o padrão EIP-712 para implementar assinaturas de dados estruturados, aumentando assim a segurança e a verificabilidade dos dados de transação.

) Uso principal

• Gestão de segurança de fundos: O contrato exige que vários proprietários pré-definidos ###Owners( confirmem conjuntamente a transação para que esta possa ser executada, prevenindo eficazmente erros de ponto único ou operações maliciosas, garantindo a segurança dos fundos.
• Execução e gestão de transações: através do mecanismo de validação de múltiplas assinaturas embutido, o contrato pode executar transferências externas, chamar outros contratos ou processar lógicas de negócios complexas, desde que as condições do limiar de assinatura sejam atendidas, suportando pagamentos e compensações de taxas em tokens e moedas nativas.
• Expansão modular: O contrato adota um design modular, permitindo a herança e a combinação de vários módulos de gestão (como OwnerManager, ModuleManager, GuardManager, FallbackManager, etc.), tornando suas funcionalidades flexíveis e fáceis de expandir, proporcionando suporte personalizado para diferentes cenários de aplicação.

) Análise de Funções

A função execTransaction executa transações que passaram pela verificação de múltiplas assinaturas:

• Calcular o hash único da transação (combinando parâmetros da transação, nonce, etc.)
• Verificar a validade de todas as assinaturas, garantindo que cada assinatura provém de um proprietário legítimo ou de um endereço previamente aprovado;
• Chamar a lógica de negócios do endereço de destino e registrar o estado de sucesso ou falha após a execução da transação através de eventos;
• Suporte para o tratamento flexível de taxas de gas, garantindo que os custos de transação sejam calculados com precisão ao pagar compensações.

As funções checkContractSignatures & checkNSignatures verificam os dados de assinatura de transações ou mensagens:

• Processar separadamente a assinatura da conta EOA, a assinatura do contrato ### EIP-1271(, e o hash pré-aprovado;
• Certifique-se de que as assinaturas estão dispostas na ordem dos proprietários e que cada assinatura vem de um endereço válido, para prevenir ataques de repetição e adulteração de assinaturas.

A função getTransactionHash gera um hash de transação, utilizado para verificação de assinatura e para prevenir ataques de repetição:

• Utilizar o padrão EIP-712 para realizar hash estruturado dos dados da transação;
• Usar montagem em linha para otimizar operações de memória e aumentar a eficiência computacional;
• Juntando o valor nonce atual, garantir a exclusividade de cada transação.

A função handlePayment processa o pagamento de compensação de gas durante o processo de execução da transação:

• Calcule o montante a pagar com base nos custos de gas efetivamente consumidos e na taxa base;
• Suporte para pagamentos em ETH e outros tokens, garantindo que a compensação de taxas seja precisa e correta.

onBeforeExecTransaction é uma função de gancho virtual interna chamada antes da execução da função execTransaction. O objetivo do design desta função é permitir que contratos filhos que herdam do contrato Safe realizem processamento lógico personalizado antes da execução da transação. O conjunto de parâmetros recebidos inclui:

• para：endereço de destino - endereço do contrato ou conta a ser chamado na transação
• valor: quantidade de éter enviada com a transação
• data: Dados de carga - contém dados de chamada com o seletor de função e parâmetros
• operação：Tipo de operação - Determine se é CALL ou DELEGateCALL
• safeTxGas: limite de gas da transação - quantidade de gas reservada para a execução da transação
• baseGas: custo de gas básico - custo de gas independente da execução da transação
• gasPrice：preço do gás - utilizado para calcular o preço de compensação das taxas de transação
• gasToken：gas token - endereço do token usado para pagar as taxas de transação
• refundReceiver: o endereço que recebe a compensação das taxas de transação
• signatures: conjunto de assinaturas - dados de assinatura do proprietário para a transação

![Profundidade análise Safe困局：Guard pode reconstruir o contrato Babel?])https://img-cdn.gateio.im/webp-social/moments-7abedb36995e926e2ebaa369f26de7d0.webp(

Apesar de os contratos de carteiras multi-sig fornecerem uma solução eficiente e segura para a gestão de ativos digitais, com um design de segurança rigoroso e uma estrutura modular flexível, garantindo o controle de segurança em todo o processo desde a inicialização da transação até a execução final, e tornando-se uma ferramenta importante para a gestão de segurança em blockchain, é igualmente importante notar que as vítimas frequentemente dependem de carteiras de hardware para assinaturas, e alguns dispositivos de hardware têm um desempenho insatisfatório na exibição de dados estruturados, o que pode levar a que os usuários não consigam identificar corretamente os dados da transação em um curto espaço de tempo, resultando em risco de "assinatura cega". Para abordar este fenômeno, além de otimizar o hardware e a exibição de dados, também se pode explorar a adição de confirmações múltiplas, dicas inteligentes e ferramentas de verificação de assinatura aprimoradas, entre outras medidas, para reduzir ainda mais os riscos de segurança associados à assinatura cega.

Safe Guard

A funcionalidade de segurança importante introduzida na versão 1.3.0 do Safe contrato ------ mecanismo Safe Guard. Este mecanismo destina-se a fornecer condições de restrição adicionais para o esquema padrão de múltiplas assinaturas n-out-of-m, aumentando ainda mais a segurança das transações. O valor central do Safe Guard reside na capacidade de realizar verificações de segurança em diferentes fases da execução da transação:

• Verifique antes da transação )checkTransaction(: O mecanismo Guard pode realizar uma verificação programática de todos os parâmetros da transação antes da execução, garantindo que a transação esteja em conformidade com as regras de segurança predefinidas.
• Verifique )checkAfterExecution( após a transação: Após a conclusão da execução da transação, o Guard realizará uma verificação de segurança adicional para verificar se o estado final da carteira Safe após a execução da transação está de acordo com o esperado.

) Análise de Arquitetura

No Safe, as transações multi-assinatura são geralmente executadas através da função execTransaction. Com o Guard ativo, quando um usuário executa uma transação multi-assinatura, o contrato Safe chamará a função checkTransaction do contrato Guard para realizar a verificação antes da transação, e após a conclusão da transação multi-assinatura, o contrato Safe chamará a função checkAfterExecution do contrato Guard para verificar o resultado da execução da transação.

Quando o contrato Safe executa a pré-verificação de transações multi-assinatura através do mecanismo Guard, sua função checkTransaction receberá todos os dados contextuais da transação, incluindo o endereço do contrato de destino, o método de chamada, os dados de execução (como deleGatecall), informações de assinatura do owner, configuração de Gas e informações de pagamento. Este mecanismo permite que os desenvolvedores implementem estratégias de risco multifacetadas, como controle de lista branca de contratos (limitar endereços interativos), gestão de permissões a nível de função (desativar seletores de funções de alto risco), restrições de frequência de transações e regras dinâmicas baseadas em fluxo de fundos, entre outras. Com uma configuração adequada da estratégia Guard, é possível bloquear efetivamente ataques que utilizem camadas não contratuais.

Num contexto de recentes incidentes de segurança, as partes estão cada vez mais preocupadas com a segurança dos contratos de carteira multi-assinatura. Os fornecedores de carteiras de hardware estão pedindo um aumento na capacidade de análise e proteção dos contratos Safe, para prevenir a ocorrência de riscos semelhantes no futuro. Após o incidente em uma plataforma de negociação, muitos projetos começaram a se concentrar nos contratos Safe e a explorar soluções de atualização e expansão baseadas no mecanismo Guard. Entre eles, existem inovações baseadas no mecanismo Guard, que constroem uma solução de segurança de camada intermediária baseada em carteiras multi-assinatura Safe, proporcionando uma proteção adicional entre os ativos subjacentes e os ativos dos usuários. Seu papel central é, através da transmissão do contrato alvo, método de chamada, dados de execução, informações de assinatura do owner, informações de pagamento e informações de gas envolvidos na transação multi-assinatura Safe para a função checkTransaction, implementar uma verificação de transação de granularidade extremamente fina, incluindo controle de permissões como chamadas de contratos em lista branca, operações de funções em lista branca, destinatários de transferência em lista branca, frequência de transações, entre outros.

![Profundidade解析Safe困局：Guard 能否重构契约巴别塔？]###https://img-cdn.gateio.im/webp-social/moments-e4f0b0daf2f48ba716dc7fdddcfdabec.webp(

É importante notar que o Safe em si só oferece gerenciamento Guard e funcionalidades de callback, a lógica de verificação de transações multi-assinatura é implementada pelos próprios usuários, e sua segurança depende da qualidade da implementação do Guard. Por exemplo: uma solução de segurança expandiu essa ideia, configurando um Guardian específico para cada Vault para designar endereços e permissões de operação permitidos, implementando três elementos principais de controle de permissões: contratos permitidos, funções permitidas e requisitos de validação ACL. Ao mesmo tempo, adota um mecanismo de governança separado, onde o Vault Guardian é responsável pela execução, enquanto o Governor controla os direitos de governança, garantindo que mesmo que ocorra um problema com o Guardian, medidas corretivas possam ser tomadas rapidamente para proteger os ativos dos usuários. Uma filosofia de design semelhante também foi aplicada em outro módulo de segurança, que intercepta operações críticas através da função preExecute, e utiliza um mecanismo de lista branca para controlar com precisão operações de alto risco, como instalação de módulos, configuração de hooks e gerenciamento de validadores, garantindo que apenas contratos confiáveis possam ser adicionados ao sistema, proporcionando uma segurança duradoura para a carteira.

Em uma cadeia de ataque de eventos em uma determinada plataforma de negociação, se o contrato Safe implementar um mecanismo Guard com configurações razoáveis, o deleGatecall malicioso iniciado pelo atacante através do execTransaction será interceptado por múltiplas estratégias na fase de verificação: a função checkTransaction do Guard primeiro identifica o tipo de operação deleGatecall e aciona regras de desativação (como a limitação forçada da operação apenas para chamadas normais), em seguida, analisa o campo data para detectar endereços de contratos não convencionais e seletores de funções de alto risco, revertendo diretamente a transação através das estratégias predefinidas de lista branca de contratos e lista negra de funções, formando assim um sistema de defesa de "interceptação de estratégia → bloqueio lógico", bloqueando completamente a manipulação de armazenamento e o caminho de transferência de fundos.

![Profundidade解析Safe困局：Guard 能否重构契约巴别塔？])https://img-cdn.gateio.im/webp-social/moments-4947f64f2aa4163ee644b6f8e911c6f8.webp(

De um modo geral, o Safe só oferece a funcionalidade de Guard após a versão 1.3.0. Embora o Guard possa fornecer uma verificação de transações multi-assinatura extremamente granular, os usuários têm um grande obstáculo ao usar a funcionalidade de Guard. Eles precisam implementar a lógica de verificação do Guard por conta própria, e uma implementação de Guard rudimentar ou defeituosa pode não ajudar os usuários a aumentar a segurança de suas carteiras Safe. Portanto, é necessário realizar uma auditoria de segurança na implementação do Guard. Não há dúvida de que uma implementação de Guard segura e adequada pode aumentar significativamente a segurança da carteira Safe.

Conclusão e Perspetivas

Um incidente de ataque a uma plataforma de negociação destacou a importância de atualizar prontamente a infraestrutura de segurança. A plataforma utilizava a versão v1.1.1)<1.3.0( do contrato Safe, o que significa que não conseguiram utilizar o mecanismo Guard, uma característica de segurança crucial. Se a plataforma tivesse atualizado para o contrato Safe na versão 1.3.0 ou superior e implementado um mecanismo Guard adequado, como designar um endereço de lista branca único para receber fundos e realizar uma rigorosa validação de ACL nas funções do contrato, poderia ter evitado esta perda. Embora isso seja apenas uma suposição, oferece uma importante reflexão para a gestão de segurança de ativos no futuro.

O mecanismo Safe Guard é como um sistema de segurança inteligente instalado em um cofre de ativos digitais, cuja eficácia depende da rigorosidade do design das regras e da qualidade da implementação. Diante de métodos de ataque cada vez mais sofisticados, precisamos:

• Validação automatizada: estabelecer um mecanismo de validação de transações automatizado
• Ajuste dinâmico de estratégia: ajuste em tempo real da estratégia de segurança com base em inteligência de ameaças
• Múltiplas camadas de defesa: combinar vários mecanismos de segurança para construir um sistema de defesa em profundidade
• Auditoria contínua: implementação de Guard