Vulnerabilidade de replay de assinatura ERC-1271

Em 27 de outubro de 2023, a Alchemy descobriu uma vulnerabilidade de replay de assinatura de contrato ERC1271 que afetou um grande número de contas de contrato inteligente (SCA), e levou a riscos ao interagir com diversas aplicações. As SCAs afetadas incluíam nossa LightAccount e a SmartAccount da OKX, e as interações com aplicações que identificamos como estando em risco incluíram Permit2 e Cowswap. Rapidamente levamos essa questão às várias SCAs e aplicações afetadas e descobrimos que curiousapple, um pesquisador de segurança independente, havia encontrado a mesma vulnerabilidade um mês antes. Colaboramos com curiousapple, Frangio (autor do ERC1271), o time do ERC4337, e outros especialistas técnicos em SCA em uma correção. Neste momento, nenhum fundo está em risco e o impacto às aplicações é bastante limitado. Todas as SCAs envolvidas já reconheceram o risco ou lançaram uma correção.

Detalhes técnicos

Assinaturas de contrato ERC-1271

No Ethereum e em todas as chains baseadas na Ethereum Virtual Machine (EVM), existem dois tipos diferentes de contas - Externally Owned Accounts (EOA) e Smart Contracts. EOAs conseguem autenticar mensagens assinando com a chave privada do seu par de chaves ECDSA associado. No entanto, como os smart contracts recebem um endereço predeterminado durante a criação do contrato, eles não têm acesso fácil a uma chave privada para assinar mensagens.

Para resolver esse problema, o padrão de assinaturas de contrato ERC-1271 foi proposto em 2018. Com esse padrão, smart contracts podem implementar restrições/verificações para o que constitui uma assinatura válida, e aplicações podem chamar contract.isValidSignature para verificar se alguma ação foi autorizada pelo smart contract.

No contexto de contas de contrato inteligente (SCAs), o ERC-1271 é bastante útil, pois permite que usuários de SCAs usem aplicações baseadas em assinatura exatamente como as EOAs fazem. Essas aplicações incluem OpenSea, e a maior parte do DeFi (que dependem do fluxo de aprovação de token → chamada).

Vulnerabilidade de replay de assinatura ERC1271

A maioria das SCAs implementa o ERC-1271 usando sua implementação de referência mostrada acima. Do ponto de vista de engenharia, é uma implementação leve, e torna as integrações de clientes muito mais fáceis, já que poderíamos reutilizar métodos como signTypedData, signMessage, eth\_signTypedData\_v e personal\_sign da mesma forma que são usados para EOAs.

No entanto, no caso em que o mesmo endereço possui múltiplas SCAs, e a aplicação não inclui o endereço de origem da interação, a mesma assinatura seria válida em ambas as contas para aquela aplicação.

Como essa vulnerabilidade só é possível com uma combinação de SCA e aplicação, o quão grave essa vulnerabilidade seria depende de quais aplicações essa interação funcionaria. A primeira aplicação que investigamos foi a Permit2, que é infraestrutura pública construída pela Uniswap que melhora a segurança e a UX dos fluxos de aprovação de tokens ERC20 em toda a indústria, e por isso é amplamente usada hoje.

O bloco de código abaixo mostra as structs que a assinatura do Permit2 cobre. Notavelmente, address owner, o endereço de onde os tokens são retirados, não é coberto pela assinatura e é passado como argumento nas chamadas ao Permit2.

Como um atacante tiraria proveito dessa vulnerabilidade de replay de assinatura é algo como:

1. Bob solicita um pagamento de X tokens de Alice, que possui n SCAs, e solicita que isso seja feito via Permit2
2. Depois que Alice assina o primeiro permit, Bob pode fazer replay desse permit em todas as SCAs de Alice para receber um total de n X tokens.

Durante esse processo, criamos uma prova de conceito para confirmar essa vulnerabilidade. Ela pode ser encontrada aqui: replay-sig-poc​

Impacto

Como parte de nossa investigação, descobrimos que:

1. Múltiplas SCAs estavam em risco.

2. Além da nossa LightAccount, outras SCAs incluíam a Kernel da Zerodev, Biconomy, Soul Wallet, o EIP4337Fallback da eth-infinitism para Gnosis Safes, AmbireAccount, a SmartAccount da OKX, a BaseWallet da Argent, e a Fuse Wallet.

3. Múltiplas aplicações estavam em risco:

4. Permit2 - Transferências baseadas em assinatura são replicáveis via replay. No entanto, a maior parte do uso do Permit2 é com o Universal Router, e qualquer forma de tirar proveito disso exigiria uma vulnerabilidade crítica independente no Universal Router.

5. Cowswap - Trades usando o caminho ERC-1271 são replicáveis via replay. A assinatura cobre address recipient, então o risco aqui seria, no máximo, preços desatualizados e/ou algumas perdas para MEV.

6. Gnosis Safe não era vulnerável a esse vetor de ataque.

Nesse momento, divulgamos isso às SCAs e aplicações via um grupo no telegram e descobrimos que curiousapple também havia descoberto o mesmo problema um mês antes e estava colaborando com Frangio e outros especialistas técnicos em SCA em uma correção. No geral, a lista completa de combinações afetadas de SCAs e aplicações até o momento é mostrada abaixo:

Nota: No caso da Argent, como é um aplicativo móvel e gera o signer por dispositivo, é impossível que 2 SCAs sejam possuídas pela mesma EOA, portanto o ataque de replay de assinatura não funciona contra a Argent. No entanto, projetos que fazem fork dos contratos da Argent sem fazer fork de toda a sua arquitetura podem estar em risco e devem adotar a arquitetura de wallet da Argent, ou lançar uma correção.

Correção

Foram propostas duas correções para as SCAs. Os construtores de SCA devem notar que devem implementar uma dessas duas soluções para prevenir o ataque de replay acima:

Ambas as soluções previnem o ataque de replay de assinatura ERC-1271. A segunda solução é mais leve, mas significaria que os clientes de wallet teriam que exibir um hash opaco para os usuários assinarem. A primeira correção é um caminho mais fácil para garantir que as assinaturas não sejam opacas para o usuário, e é por isso que optamos pela primeira correção para a LightAccount. A maioria das outras SCAs também optou pela mesma correção.

Agradecimentos

Muito obrigado à OKX por pagar uma recompensa por bug a Howy por esse problema!

Parabéns a curiousapple por receber recompensas por bug da Ambire, Instadapp, Biconomy e Cowswap!

Além disso, um grande agradecimento a:

1. Dror Tirosh por fazer o brainstorming da abordagem de correção com struct EIP-712 que a maioria das SCAs adotou
2. Frangio por compartilhar mais contexto sobre o ERC-1271 e pelo grande esforço em atualizar a implementação de referência do ERC-1271 via o comitê do EIP
3. Ivo (Ambire) por seu mergulho profundo nas diferenças de implementação técnica entre as duas soluções propostas
4. Vectorized por disponibilizar e financiar uma recompensa de 0,5 ETH para uma implementação cliente da solução EIP-712 aninhada
5. Juno (ChainLight) por aceitar o desafio acima, lançando uma implementação cliente da solução EIP712 aninhada e reivindicando a recompensa da Vectorized
6. David Eiber por sua ajuda no brainstorming de vulnerabilidades relacionadas, na indexação de SCAs e protocolos afetados, e na criação de PoCs
7. Yoav Weiss por sua ajuda durante todo o processo, incluindo nos conectar com pesquisadores de segurança e outras SCAs e aplicações afetadas