Além das chaves privadas: da carteira, L2 à cadeia de suprimentos, como proteger a fronteira de segurança da Web3?

O mês de junho que passou foi marcado por uma série de incidentes de segurança que atravessaram múltiplas camadas no mundo das criptomoedas.

O relatório mensal de segurança mais recente da PeckShield revela que, em junho, ocorreram 40 grandes ataques informáticos, com perdas totais de 75,87 milhões de dólares. Mais alarmante ainda, estes ataques não se concentraram numa única via de ataque, mas abrangeram defeitos na implementação de assinaturas em carteiras, vulnerabilidades em protocolos de L2 e ataques à cadeia de fornecimento de serviços terceiros. Várias linhas de defesa sucumbiram no mesmo mês.

Quando o risco de segurança da Web3 se expande de um ponto de entrada único para toda a cadeia de interação na blockchain, cada utilizador é obrigado a repensar uma questão: os meus ativos crypto estão realmente seguros?

I. A Importância da Implementação de Assinaturas de Baixo Nível na Carteira, Além das Chaves Privadas

O incidente de segurança ocorrido na SecondFi, uma carteira do ecossistema Cardano, em junho, é o exemplo mais direto.

A SecondFi é a sucessora da carteira Yoroi do ecossistema Cardano. Entre 21 e 23 de junho, um atacante transferiu cerca de 16 milhões de ADA de endereços de alguns utilizadores da SecondFi, envolvendo aproximadamente 374 carteiras, num valor estimado de cerca de 2,4 milhões de dólares à taxa de câmbio da época. A SecondFi afirmou posteriormente que, através de medidas de emergência, conseguiu proteger adicionalmente cerca de 129 milhões de ADA que poderiam ter sido afetados.

O aspeto mais peculiar deste incidente é que os utilizadores afetados não entregaram voluntariamente as suas frases de recuperação ao atacante. O problema residia na implementação da assinatura de baixo nível da carteira. De acordo com a análise da BlockSec, uma agência de segurança, a carteira derivava incorretamente o nonce da assinatura a partir de mensagens de transação públicas, omitindo o prefixo nonce secreto exigido pela implementação padrão.

Isto significava que, sempre que um utilizador assinava uma transação usando a versão afetada da carteira, os dados de assinatura públicos publicados na blockchain expunham informações suficientes para derivar a chave privada do endereço. Assim, o atacante não precisava de invadir o telemóvel do utilizador ou obter a frase de recuperação; bastava analisar os dados públicos da blockchain para potencialmente recuperar a chave privada de assinatura do endereço correspondente.

Do ponto de vista do utilizador, a carteira continuava a funcionar normalmente – a frase de recuperação não foi exibida, a palavra-passe não foi quebrada e as transações foram de facto iniciadas pelo próprio. No entanto, a nível criptográfico, se o endereço do utilizador tivesse gerado algumas assinaturas válidas através da versão afetada, os dados públicos da transação e da assinatura poderiam ajudar o atacante a derivar a chave privada de assinatura desse endereço.

Em suma, a segurança de uma carteira depende ainda da correta geração de chaves privadas, da execução rigorosa dos padrões criptográficos de assinatura e da capacidade de esses códigos críticos serem auditados e verificados externamente. Esta é a importância de manter os componentes principais da carteira em código aberto.

Claro, este é um defeito de implementação específico de uma versão particular de uma carteira, não um problema geral de todas as carteiras de autocustódia. Tomando como exemplo o TokenCore da imToken, o seu repositório de código principal está hospedado publicamente no GitHub, abrangendo funções de carteira de baixo nível, como gestão de chaves, derivação de endereços e assinatura de transações.

Embora o código aberto não garanta que o código esteja isento de vulnerabilidades, nem que os utilizadores possam baixar completamente a guarda, para os componentes criptográficos e de assinatura mais sensíveis de uma carteira, o código aberto fornece, pelo menos, uma premissa importante: os investigadores de segurança, programadores e a comunidade podem inspecionar o código, reproduzir problemas e testar continuamente, em vez de terem de confiar numa caixa preta não verificável.

Para o utilizador comum, estes incidentes também correspondem a alguns princípios de segurança mais práticos.

Em primeiro lugar, as carteiras devem ser sempre descarregadas a partir do site oficial ou da loja de aplicações oficial, e as versões de segurança devem ser atualizadas atempadamente.

Em segundo lugar, não é aconselhável manter todos os ativos na mesma carteira de uso diário. Ativos de longo prazo e de grande valor devem ser guardados numa carteira de hardware ou numa carteira fria independente, isolada da carteira quente usada para interagir frequentemente com DApps.

Mais importante ainda, uma vez confirmada uma vulnerabilidade ao nível da geração de chaves ou da implementação de assinaturas pela equipa oficial da carteira, simplesmente importar a frase de recuperação original para outra carteira geralmente não resolve o problema.

Isto porque, depois de importar o mesmo conjunto de frases de recuperação para outra carteira, os endereços e chaves privadas já expostos não se alteram. Os ativos afetados precisam de ser transferidos para um novo endereço que nunca tenha assinado através da versão vulnerável. Para o utilizador comum, a abordagem mais segura é geralmente seguir o processo de emergência oficial para criar um novo conjunto de carteira e frases de recuperação, e depois completar a migração dos ativos, em vez de importar ou operar repetidamente os endereços originais.

II. L2 não é apenas "Ethereum mais barato", mas também uma cadeia de confiança complexa

Para além das carteiras, os múltiplos incidentes de junho apontaram também riscos para os sistemas L2, cada vez mais complexos.

A 14 e 18 de junho, duas antigas implementações Rollup relacionadas com o Aztec foram atacadas, resultando em perdas totais de cerca de 4,35 milhões de dólares.

É importante notar que as implementações atacadas eram versões antigas, como o Aztec Connect, já em estado legado, e não representam um ataque à própria rede principal atual do Aztec Network. No entanto, os problemas expostos por estes dois incidentes servem de alerta para todo o campo dos ZK Rollups.

Num dos incidentes, o atacante explorou uma inconsistência entre o número de transações e os dados efetivamente processados, fazendo com que o sistema registasse um depósito internamente na prova, mas contornando o processo de dedução de saldo correspondente na L1.

O outro incidente resultou da falta de uma restrição no circuito de conhecimento zero. O sistema verificou uma prova formalmente válida, mas não garantiu que a árvore de estado privado usada nessa prova fosse completamente consistente com a raiz do estado público real na Ethereum para liquidação. O atacante pôde, assim, gerar uma prova em torno de uma árvore de estado falsa e retirar ativos do contrato L1.

Este tipo de problema é difícil de resumir com a tradicional "linha de código vulnerável no contrato". O conhecimento zero pode provar que um determinado processo de cálculo segue as regras estabelecidas, mas apenas se as próprias regras estiverem corretas e completas. Se o programador se esquecer de restringir uma variável crítica, a prova pode ser matematicamente válida, mas prova um resultado que não corresponde ao estado de liquidação real.

O incidente de segurança subsequente no Taiko expôs outro risco na cadeia de confiança da L2.

A 22 de junho, o processo de verificação de provas baseado em SGX do Taiko foi explorado, resultando em perdas de cerca de 1,7 milhões de dólares. De acordo com a análise da BlockSec, o atacante usou uma chave privada de assinatura de enclave SGX que tinha sido anteriormente submetida a um repositório público no GitHub, ao mesmo tempo que explorava a falha do contrato de verificação na chain que não rejeitava enclaves em modo DEBUG, registando um provador malicioso como instância legítima.

O atacante subsequentemente falsificou uma prova de estado L2, fazendo com que o contrato na Ethereum aceitasse um estado L2 inexistente, acabando por retirar ativos dos fundos da bridge. Em última análise, o problema deveu-se ao facto de a chave usada para assinar o ambiente de execução fidedigno (TEE) ter sido tornada pública e as regras de atestação remota não terem verificado completamente os atributos do ambiente de execução, fazendo com que uma prova "certificada" perdesse o seu significado de confiança pretendido.

Entretanto, a Base experimentou uma paragem na produção de blocos da rede principal a 25 e 26 de junho. Na sua análise posterior, a Base afirmou que ambas as interrupções resultaram do mesmo defeito na lógica de construção de blocos: uma transação que falhou na execução não limpou corretamente o estado previamente registado, levando a que as transações seguintes fossem incorretamente calculadas em termos de Gas, gerando um bloco que continha uma transição de estado inválida. Como outros nós não conseguiram aceitar esse bloco, a rede acabou por parar de avançar. A Base afirmou que a integridade da chain não foi comprometida durante o incidente e que os fundos dos utilizadores estiveram sempre seguros.

Este não foi um roubo de ativos ou um ataque externo, mas sim uma falha técnica que afetou a disponibilidade e a capacidade de recuperação da rede. No entanto, de uma perspetiva de segurança mais ampla, a própria disponibilidade é parte do modelo de segurança da L2.

Para o utilizador, a segurança de uma chain não depende apenas de os hackers poderem ou não falsificar ativos, mas também de os blocos poderem ser produzidos continuamente, de as pontes (bridges) funcionarem corretamente, de os nós poderem recuperar rapidamente e de, quando o sistema falha, o utilizador ainda ter uma via de saída viável.

Assim, ao utilizar L2s, os utilizadores não devem comparar apenas taxas e expectativas de airdrops. Para L2s mais pequenas, recém-lançadas ou com mecanismos de segurança em rápida mudança, evite manter grandes quantidades de ativos por longos períodos que excedam as necessidades reais de uso; antes de fazer uma bridge, confirme que está a usar a bridge oficial e familiarize-se com os prazos de retirada, mecanismos de pausa e modos de saída de emergência; se a rede parar de produzir blocos, houver anomalias na bridge ou a equipa emitir alertas de segurança, não reenvie transações repetidamente ou continue a fazer bridge de ativos.

A abordagem mais segura é gerir ativos de diferentes finalidades e níveis de risco de forma dispersa, em vez de concentrar toda a liquidez na mesma L2, na mesma bridge ou no mesmo mecanismo de saída.

III. Contratos não foram comprometidos, mas serviços terceiros podem trazer o ataque ao utilizador

Se os problemas nas carteiras e L2s ainda ocorrem em componentes tecnológicos de baixo nível, o incidente na Polymarket demonstra que o frontend da web, mais próximo do utilizador, também pode tornar-se uma porta de entrada para fundos.

A 25 de junho, a Polymarket afirmou que um dos seus fornecedores terceiros tinha sido invadido, permitindo ao atacante injetar scripts maliciosos no frontend da Polymarket a que alguns utilizadores acediam.

De acordo com estatísticas de agências de segurança e analistas on-chain, o incidente causou perdas de cerca de 3 milhões de dólares em ativos de utilizadores, envolvendo cerca de 11 carteiras. Os fundos roubados foram posteriormente transferidos via bridge da Polygon para a Ethereum e convertidos em cerca de 1893 ETH. No entanto, a Polymarket afirmou posteriormente que já removeu a dependência afetada e irá reembolsar integralmente os utilizadores afetados.

O ponto crítico deste incidente é que os utilizadores podem ainda ter acedido ao domínio correto da Polymarket, e as divulgações atuais não apontam para uma vulnerabilidade no contrato inteligente principal da Polymarket. O problema residia principalmente nas dependências de frontend de terceiros carregadas pela página web.

Isto serve de espelho. Hoje em dia, a maioria das aplicações Web3 não funciona inteiramente on-chain. As páginas web que os utilizadores veem, como interfaces de negociação, ainda dependem fortemente da infraestrutura tradicional da Internet e de pacotes de software de terceiros. Se qualquer uma destas dependências for atacada, um site legítimo pode exibir informações erradas, substituir endereços de recebimento ou induzir a carteira a assinar transações maliciosas.

Portanto, "o URL é verdadeiro" não equivale necessariamente a "todo o código carregado neste momento é seguro", e "o contrato passou por uma auditoria" não significa que todo o caminho de interação entre o utilizador e o contrato esteja isento de riscos. Face a este tipo de ataques ao frontend e à cadeia de fornecimento, é difícil para o utilizador comum inspecionar independentemente cada linha de código carregada na página. No entanto, ainda é possível limitar perdas potenciais reduzindo as permissões de cada interação:

• Use uma carteira separada para interagir com DApps: Tente não ligar a carteira de poupança de longo prazo diretamente a vários sites DeFi, NFT, mercados de previsão e airdrops. A carteira de uso diário deve conter apenas fundos que planeia usar a curto prazo. Mesmo que o frontend ou as autorizações sejam comprometidos, o impacto é relativamente limitado.
• Preste atenção à operação real antes de assinar, não apenas aos botões na página: O facto de a página web dizer "Iniciar sessão", "Reivindicar" ou "Confirmar encomenda" não significa que a assinatura que aparece na carteira seja a mesma coisa.
• Quando a página apresentar anomalias, não confie na inércia para continuar a operar: Se a página subitamente lhe pedir para importar novamente a frase de recuperação, descarregar plugins adicionais, ou se o conteúdo da transação exibido não corresponder à descrição na página, pare a interação, confirme a situação através de vários canais oficiais do projeto e verifique ou revogue autorizações históricas não utilizadas.
• Do ponto de vista do produto carteira, isto também significa que o papel da carteira está a mudar.

Ela não deve ser apenas uma ferramenta para guardar chaves privadas e mostrar janelas de assinatura. Precisa também de ajudar o utilizador a compreender a intenção da transação, identificar autorizações anómalas, mostrar alterações nos ativos e fornecer avisos suficientemente claros antes de ocorrerem interações de alto risco.

No entanto, a carteira também não pode eliminar todos os riscos para o utilizador. Um modelo de segurança mais realista é que a carteira, o protocolo, a L2, os prestadores de serviços terceiros e o utilizador trabalhem em conjunto para reduzir a superfície de ataque, em vez de empurrar toda a responsabilidade para qualquer uma das partes.

Considerações Finais

No passado, costumava dizer-se: "Quem controla a chave privada, controla os ativos on-chain."

Esta afirmação ainda é verdadeira, mas não cobre todo o processo desde "gerar a intenção de transação" até "concluir a liquidação on-chain". A segurança da Web3 hoje já não se resume a proteger um conjunto de frases de recuperação, mas sim a proteger todo o caminho, desde a geração de chaves pela carteira, exibição da transação, execução da assinatura, até à verificação pela rede e liquidação final.

Claro, isto não significa que os utilizadores devam evitar todas as interações on-chain. Para o utilizador, hábitos de segurança verdadeiramente eficazes significam gerir separadamente a finalidade dos ativos, o nível de risco e o cenário de interação: ativos de longo prazo com forte isolamento, interações diárias com pequenos montantes, DApps desconhecidos com baixas autorizações, operações de alto risco com múltiplas verificações.

Afinal, quando o risco de segurança se expande de um ponto para uma cadeia, a defesa do utilizador também deve evoluir de proteger bem a chave privada para um conjunto completo de hábitos.

Que possamos todos aprender com isto.