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

No mês passado, junho, o mundo cripto passou por uma série de incidentes de segurança em várias frentes.

O mais recente relatório mensal de segurança da PeckShield mostra que, em junho, ocorreram 40 grandes ataques hackers, com perdas totais de US$ 75,87 milhões. Mais preocupante ainda, esses ataques não se concentraram em um único vetor de ataque, mas abrangeram falhas de implementação de assinatura em carteiras, vulnerabilidades em protocolos L2 e ataques à cadeia de suprimentos de serviços terceirizados — várias linhas de defesa caíram sucessivamente no mesmo mês.

Quando o risco de segurança Web3 se expande de um ponto de entrada único para todo o caminho de interação on-chain, cada usuário é forçado a repensar uma questão: meus ativos cripto ainda estão seguros?

I. Além da chave privada: a importância da implementação de assinatura de baixo nível da carteira

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

A SecondFi é sucessora da Yoroi, carteira do ecossistema Cardano. Entre 21 e 23 de junho, um atacante transferiu cerca de 16 milhões de ADA de alguns endereços de usuários da SecondFi, envolvendo aproximadamente 374 carteiras, totalizando cerca de US$ 2,4 milhões com base no preço do evento. Posteriormente, a SecondFi informou que, por meio de medidas emergenciais, protegeu outros cerca de 129 milhões de ADA que poderiam ser afetados.

O mais peculiar desse incidente é que os usuários afetados não entregaram ativamente suas frases-semente ao atacante. O problema estava na implementação da assinatura de baixo nível da carteira. Segundo análise da BlockSec, a carteira derivava incorretamente o nonce da assinatura a partir de mensagens de transação públicas, omitindo o prefixo secreto do nonce exigido pela implementação padrão.

Isso fez com que, sempre que um usuário assinasse uma transação usando a versão afetada da carteira, os dados de assinatura públicos publicados na chain expusessem informações suficientes para derivar a chave privada do endereço. Assim, o atacante não precisava invadir o celular do usuário nem obter a frase-semente; bastava analisar dados on-chain públicos para possivelmente recuperar a chave privada de assinatura do endereço correspondente.

Do ponto de vista do usuário, a carteira parecia funcionar normalmente — afinal, a frase-semente não foi exibida em pop-ups, a senha não foi quebrada e a transação foi realmente iniciada pelo próprio usuário. Mas, do ponto de vista criptográfico, se o endereço do usuário tivesse gerado algumas assinaturas válidas com a versão afetada, os dados públicos de transação e assinatura poderiam ajudar o atacante a derivar a chave privada de assinatura daquele endereço.

Em suma, a segurança de uma carteira depende de como a chave privada é gerada corretamente, se a assinatura segue rigorosamente os padrões criptográficos e se esses códigos críticos podem ser auditados e verificados externamente. Essa é a importância de manter os componentes principais da carteira como código aberto.

Claro, isso é uma falha de implementação de uma versão específica de uma carteira específica, não um problema generalizado de todas as carteiras autocustodiantes. Tomando como exemplo o TokenCore da imToken, seu repositório de código principal está hospedado publicamente no GitHub, cobrindo funções de baixo nível como gerenciamento de chaves, derivação de endereços e assinatura de transações.

Embora código aberto não signifique que o código esteja livre de vulnerabilidades, e muito menos que os usuários possam baixar a guarda, para os componentes criptográficos e de assinatura mais sensíveis de uma carteira, o código aberto pelo menos fornece uma premissa importante: pesquisadores de segurança, desenvolvedores e a comunidade podem inspecionar o código, reproduzir problemas e testar continuamente, em vez de confiar em uma caixa preta não verificável.

Para usuários comuns, esse tipo de incidente também corresponde a alguns princípios de segurança práticos.

Primeiro, as carteiras devem sempre ser baixadas pelo site oficial ou lojas oficiais de aplicativos, e as versões de segurança devem ser atualizadas em tempo hábil.

Em segundo lugar, não é aconselhável manter todos os ativos na mesma carteira de uso diário. Ativos grandes e de longo prazo devem ser armazenados em carteiras frias ou hardware wallets, isolados da carteira quente que frequentemente se conecta a DApps.

Mais importante ainda, uma vez que a carteira confirma oficialmente uma vulnerabilidade no nível de geração de chave ou implementação de assinatura, simplesmente importar a mesma frase-semente para outra carteira geralmente não resolve o problema;

pois, ao importar a mesma frase-semente para outra carteira, os endereços e chaves privadas já expostos não mudam. Os ativos afetados precisam ser transferidos para um novo endereço que nunca tenha sido assinado pela versão vulnerável. Para usuários comuns, a abordagem mais segura geralmente é seguir o processo de emergência oficial para criar um novo conjunto completo de carteira e frase-semente e, em seguida, realizar a migração de ativos, em vez de importar repetidamente ou manipular o endereço original.

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

Além das carteiras, vários incidentes em junho também apontaram riscos para sistemas L2 cada vez mais complexos.

Em 14 e 18 de junho, duas implantações antigas de Rollup relacionadas à Aztec foram atacadas, resultando em perdas totais de aproximadamente US$ 4,35 milhões.

É importante notar que os ataques foram contra implantações antigas em estado legado, como a Aztec Connect, e não equivalem a um ataque à rede principal atual da Aztec Network. No entanto, os problemas expostos por esses dois incidentes servem como um alerta significativo para todo o campo de ZK Rollups.

Em um dos incidentes, o atacante explorou uma inconsistência entre o número de transações e os dados reais processados, fazendo com que o sistema registrasse um depósito dentro da prova, mas contornasse o processo de dedução de saldo correspondente na L1.

O outro incidente originou-se de uma falta de restrição no circuito de prova de conhecimento zero. O sistema validou uma prova formalmente válida, mas não garantiu que a árvore de estado privado usada na prova fosse idêntica à raiz de estado público na Ethereum realmente usada para liquidação. Assim, o atacante poderia gerar uma prova em torno de uma árvore de estado falsa e sacar ativos do contrato L1.

Esse tipo de problema é difícil de resumir como "existe uma linha de código vulnerável no contrato". Afinal, uma prova de conhecimento zero pode demonstrar que um determinado processo computacional segue regras estabelecidas, mas apenas se as próprias regras estiverem corretas e completas. Se o desenvolvedor esquecer de restringir uma variável crítica, a prova ainda 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 na Taiko expôs outro tipo de risco na cadeia de confiança da L2.

Em 22 de junho, o processo de verificação de prova baseado em SGX da Taiko foi explorado, causando perdas de aproximadamente US$ 1,7 milhão. De acordo com a BlockSec, o atacante usou uma chave privada de assinatura de enclave SGX que havia sido enviada anteriormente a um repositório público no GitHub, e também explorou o fato de que o contrato de verificação on-chain não rejeitava enclaves no modo DEBUG. O atacante registrou um provador malicioso como uma instância legítima.

Em seguida, o atacante falsificou provas de estado L2, fazendo com que o contrato na Ethereum aceitasse um estado L2 inexistente e, finalmente, sacasse ativos dos fundos da ponte. Em essência, a chave usada para assinar o ambiente de execução confiável foi exposta, e as regras de atestação remota não verificaram completamente as propriedades do ambiente de execução, fazendo com que uma prova "atestada" perdesse seu significado de confiança pretendido.

Enquanto isso, a Base sofreu paralisações na produção de blocos da mainnet entre 25 e 26 de junho. Em sua análise pós-evento, a Base afirmou que as duas 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 registrado anteriormente, fazendo com que as transações subsequentes tivessem o gás calculado incorretamente e gerassem um bloco contendo uma transição de estado inválida. Como outros nós não puderam aceitar esse bloco, a rede acabou parando. A Base afirmou que a integridade da chain não foi comprometida durante o incidente e os fundos dos usuários permaneceram seguros.

Não se trata de roubo de ativos ou ataque externo, mas de uma falha técnica que afetou a disponibilidade e capacidade de recuperação da rede. No entanto, de uma perspectiva mais ampla de segurança, a disponibilidade em si é parte do modelo de segurança da L2.

Porque, para o usuário, se uma chain é segura não depende apenas de se um hacker pode falsificar ativos, mas também se os blocos podem ser produzidos continuamente, se as pontes funcionam, se os nós podem se recuperar rapidamente e se o usuário possui um caminho de saída viável quando o sistema falha.

Portanto, ao usar L2, os usuários não devem comparar apenas taxas e expectativas de airdrop. Para L2s de menor escala, 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 além das necessidades reais de uso; antes de fazer cross-chain, confirme se está usando a ponte oficial e entenda os tempos de retirada, mecanismos de pausa e modos de saída de emergência; quando a rede parar de produzir blocos, a cross-chain estiver anormal ou houver alertas de segurança oficiais, não fique reenviando transações ou transferindo mais ativos.

Uma abordagem mais segura é gerenciar ativos de diferentes propósitos e níveis de risco de forma dispersa, em vez de colocar toda a liquidez na mesma L2, na mesma ponte ou no mesmo mecanismo de saída.

III. Contratos não foram invadidos, mas serviços terceirizados podem trazer ataques aos usuários

Se os problemas de carteiras e L2 ainda ocorrem em componentes técnicos mais básicos, o incidente da Polymarket mostra que o frontend web, o mais próximo do usuário, também pode se tornar uma porta de entrada para perda de fundos.

Em 25 de junho, a Polymarket informou que um de seus fornecedores terceirizados foi invadido, e o atacante injetou scripts maliciosos no frontend da Polymarket acessado por alguns usuários.

De acordo com agências de segurança e analistas on-chain, o incidente causou perdas de aproximadamente US$ 3 milhões em ativos de usuários, envolvendo cerca de 11 carteiras. Os fundos roubados foram posteriormente transferidos da Polygon para a Ethereum e trocados por aproximadamente 1.893 ETH. No entanto, a Polymarket informou posteriormente que removeu a dependência afetada e reembolsará integralmente os usuários afetados.

O ponto-chave desse incidente é que os usuários provavelmente ainda estavam acessando o domínio correto da Polymarket, e as divulgações atuais não apontam para vulnerabilidades no contrato inteligente principal da Polymarket. O problema estava principalmente nas dependências de frontend de terceiros carregadas pela página.

Isso serve como um espelho: hoje, a maioria dos aplicativos Web3 não opera totalmente on-chain. As páginas web que os usuários veem, como interfaces de negociação, ainda dependem fortemente da infraestrutura tradicional da internet e pacotes de software de terceiros. Se qualquer uma dessas dependências for atacada, um site legítimo pode exibir informações incorretas, 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 foi auditado" não significa que todo o caminho de interação entre o usuário e o contrato esteja livre de riscos. Diante desses ataques de frontend e cadeia de suprimentos, é difícil para usuários comuns verificar 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 interações com DApps: carteiras de poupança de longo prazo não devem se conectar diretamente a sites de DeFi, NFT, mercados de previsão ou airdrops. A carteira de uso diário deve conter apenas fundos para uso recente, limitando o impacto mesmo se o frontend ou as autorizações forem comprometidas.
• Preste atenção à ação real ao assinar, não apenas ao botão na página: o site pode dizer "Login", "Receber" ou "Confirmar pedido", mas isso não significa que a assinatura exibida na carteira seja a mesma coisa.
• Se a página apresentar comportamento anômalo, não continue por inércia: se a página de repente pedir para reimportar a frase-semente, baixar um plugin extra ou exibir conteúdo de transação diferente do descrito, 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 de carteira, isso também significa que o papel da carteira está mudando.

Ela não deve ser apenas uma ferramenta para armazenar chaves privadas e exibir janelas de assinatura, mas também precisa ajudar o usuário a entender a intenção da transação, identificar autorizações anormais, mostrar mudanças de ativos e fornecer avisos claros antes de interações de alto risco.

Mas a carteira também não pode eliminar todos os riscos pelo usuário. Um modelo de segurança mais realista é que carteiras, protocolos, L2s, provedores de serviços terceirizados e usuários trabalhem juntos para reduzir a superfície de ataque, em vez de empurrar toda a responsabilidade para um lado.

Considerações finais

No passado, dizia-se: quem controla a chave privada, controla os ativos on-chain.

Essa afirmação ainda é válida, mas não cobre todo o processo desde "gerar a intenção de transação" até "concluir a liquidação on-chain". Hoje, a segurança Web3 não é mais apenas proteger uma frase-semente, mas proteger todo o caminho, desde a geração de chaves pela carteira, exibição da transação, execução da assinatura, até a verificação da rede e liquidação final.

Claro, isso não significa que os usuários devam evitar todas as interações on-chain. Para os usuários, hábitos de segurança eficazes significam gerenciar separadamente o propósito dos ativos, o nível de risco e o cenário de interação: ativos de longo prazo com alto isolamento, interações diárias com valores pequenos, 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 usuário também deve evoluir de proteger a chave privada para um conjunto completo de hábitos.

Que possamos aprender juntos.