A exploração que Curve encontrou desta vez pode abrir novas ideias para hackers

Por Jaleel, BlockBeats

Com a ocorrência de um incidente de exploração de vulnerabilidade, a indústria DeFi foi jogada no caos. A Curve Finance, uma gigante da indústria de DeFi, tornou-se alvo de um sério "ataque" e vários pools de stablecoin, como alETH/msETH/pETH, estão em risco. De acordo com estatísticas incompletas, o evento de exploração de vulnerabilidade causou uma perda total de 52 milhões de dólares nos pools Alchemix, JPEG'd, MetronomeDAO, deBridge, Ellipsis e CRV/ETH, e a confiança de todo o mercado foi seriamente abalada.

Os bloqueios de reentrada das versões Vyper 0.2.15, 0.2.16 e 0.3.0 são inválidos, e a interface de instalação do documento oficial Vyper recomenda uma versão errada. Outras partes do projeto que usam o compilador Vyper também correram para realizar o autoexame, tentando garantir que não se tornem a próxima vítima. À medida que a fonte do incidente de exploração de vulnerabilidade é gradualmente revelada, o mercado gradualmente percebe que essa crise não significa apenas um incidente comum de exploração de hackers, mas também revela o enorme risco potencial de toda a pilha subjacente para toda a indústria DeFi.

Em comparação com o passado, o número de incidentes de hacking no período anterior tornou-se cada vez menor, o que é inseparável da prosperidade do mercado. Durante o verão DeFi e o verão NFT, novos acordos de bilhões de dólares foram lançados todas as semanas, em comparação com o mercado atual que está encolhendo muito. Ao mesmo tempo, as oportunidades de mercado para os hackers encontrarem explorações ou criarem ataques em larga escala estão diminuindo gradualmente, o que significa que os hackers precisam de pontos de entrada mais novos e inexplorados para explorar.

Os hackers que retornam aos "primeiros princípios" encontraram um ponto de entrada perfeito no compilador de nível inferior para comer o enorme e delicioso "bolo" do mercado DeFi. O compilador de nível inferior tornou-se um hacker mais "inteligente". Escolha. A BlockBeats entrevistou o desenvolvedor de contratos inteligentes Box (@BoxMrChen) e o pesquisador BTX Derek (@begas_btxcap) sobre este incidente e os problemas relacionados que ele expôs.

Como acontece o evento Curve?

Stani (@StaniKulechov), o fundador da Aave e Lens, expressou sua opinião sobre o incidente nas redes sociais: "Este é um revés lamentável para Curve e DeFi. Embora DeFi seja um espaço aberto que pode contribuir, ele deve estar absolutamente certo é difícil e as apostas são altas. No caso da Curve, eles acertaram no nível do protocolo.

A exploração que o Curve sofreu é uma das formas mais antigas e talvez a mais comum de ataque aos contratos inteligentes da Ethereum, o ataque de reentrância. Os ataques de reentrância permitem que um invasor chame repetidamente uma função de um contrato inteligente sem esperar que a chamada anterior para essa função seja concluída. Dessa forma, eles podem continuar a usar a brecha para sacar fundos até que o contrato da vítima fique sem fundos.

Bloqueio reentrante e princípio CEI

Dê um exemplo simples para ilustrar os ataques de reentrada: um banco tem um total de 100.000 em dinheiro. Mas esse banco tem uma grande brecha, sempre que as pessoas sacam dinheiro, os funcionários do banco não atualizam o saldo da conta imediatamente, mas esperam até o final do dia para verificar e atualizar. Nesse momento, alguém descobriu essa brecha: abriu uma conta no banco, primeiro depositou 1.000 yuans, depois retirou 1.000 yuans e, em seguida, retirou 1.000 yuans após 5 minutos. Como o banco não atualiza o saldo em tempo real, o sistema pensará que sua conta ainda possui 1.000 yuans antes de verificar e atualizar. Por meio de operações repetidas, o usuário finalmente sacou todo o dinheiro de US$ 100.000 no banco. Só no final do dia é que o banco descobriu que a brecha havia sido explorada.

A complexidade do ataque de reentrância reside no fato de que ele tira proveito da chamada mútua entre contratos e das brechas lógicas do próprio contrato e obtém um comportamento fraudulento ao acionar deliberadamente exceções e funções de reversão. Os invasores podem explorar repetidamente as brechas lógicas no contrato para roubar fundos. A solução para evitar ataques de reentrada também é muito comum.Um conteúdo de código especial direcionado é definido antecipadamente para proteção e esse mecanismo de proteção é usado para garantir a segurança dos fundos.Isso é chamado de bloqueio de reentrada.

O Solidity define um "princípio CEI" (Check Effects Interactions) para programação de contrato inteligente, que pode proteger bem as funções de ataques de reentrância. O conteúdo dos princípios do CEI inclui:

1. A ordem de invocação dos componentes da função deve ser: primeiro, inspeção, segundo, impacto nas variáveis de estado e, por último, interação com entidades externas.

2. Antes de interagir com entidades externas, todas as variáveis de estado devem ser atualizadas. Isso é chamado de "contabilidade otimista", onde os efeitos são escritos antes que a interação realmente aconteça.

3. As verificações devem ser feitas no início da função para garantir que a entidade chamadora tenha permissão para chamar a função.

4. As variáveis de estado devem ser atualizadas antes de qualquer chamada externa para evitar ataques de reentrância.

5. Mesmo entidades externas confiáveis devem seguir o padrão CEI porque podem transferir o fluxo de controle para terceiros mal-intencionados.

De acordo com a documentação, os princípios do CEI ajudam a limitar a superfície de ataque de um contrato, em particular evitando ataques de reentrância. Os princípios do CEI podem ser facilmente aplicados, principalmente na ordem dos códigos de função, sem alterar nenhuma lógica. A conhecida exploração do DAO, que levou à bifurcação do Ethereum, também ignorou o "princípio CEI", e o invasor realizou um ataque de reentrada, causando consequências devastadoras.

Mas o pool do Curve que foi atacado não seguiu esse princípio CEI porque o Curve usou o compilador Vyper. Como a vulnerabilidade do código Vyper do compilador, o bloqueio de reentrância falha, fazendo com que o ataque de reentrância do hacker seja realizado com sucesso.

A maioria das pessoas conhece o Solidity, mas o Solidity não é a única linguagem para criar contratos inteligentes. Uma alternativa popular ao Solidity é o Vyper. Embora o Vyper não seja tão poderoso e popular quanto o Solidity, ele é ideal para desenvolvedores familiarizados com o Python, porque o Vyper pode traduzir código semelhante ao Python na linguagem de programação de contrato inteligente Ethereum.

De acordo com as informações do github, o desenvolvedor que contribui pela primeira vez para a base de código do github do Vyper também é o desenvolvedor do Curve. Não é difícil explicar por que o Curve usa o Vyper em vez do Solidity.

![Hackers voltam aos "primeiros princípios", a crise do Curve não é um ataque comum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-c30cf03f91-dd1a6f-1c6801)

Por que o bloqueio de reentrância do Vyper falha?

Então, neste ataque, qual é o problema com o Vyper? Por que o bloqueio de reentrada falha? É porque não há testes? BlockBeats entrevistou o desenvolvedor de contrato inteligente Box 826.eth (@BoxMrChen), segundo ele, o bloqueio reentrante Vyper foi testado com casos de uso. Mas o motivo da falha é que o caso de teste é orientado a resultados, ou seja, o caso de teste também está errado.

Resumindo, a maior razão pela qual o bloqueio de reentrância do Vyper falha é que a pessoa que escreveu o caso de teste escreveu o caso de teste com base no resultado, sem pensar por que o slot pularia 1 inexplicavelmente.

![Hackers voltam aos "primeiros princípios", a crise do Curve não é um ataque comum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-0527942e35-dd1a6f-1c6801)

Nos parágrafos seguintes do código Vyper compartilhado pela Box, o problema pode ser visto claramente. Quando o nome do bloqueio aparecer pela segunda vez, o número de storage_slot será sobrescrito, ou seja, em ret, o slot para a primeira aquisição do bloqueio é 0, mas após uma função usar o bloqueio novamente, o slot para o bloqueio é adicionado um. Após a compilação, o slot errado é usado, fazendo com que o bloqueio reentrante não entre em vigor.

![Hackers voltam aos "primeiros princípios", a crise do Curve não é um ataque comum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-87ec9b545c-dd1a6f-1c6801)

A esquerda é o código atacado e a direita é o código reparado

"Resultados de teste errados são esperados e, claro, nenhum erro pode ser verificado. Para dar um exemplo simples, estamos fazendo um problema de cálculo agora, 1+ 1 = 2, mas a resposta padrão fornecida está errada, dizendo 1+ 1 = 3 . E isso O colega que estava fazendo a pergunta deu a resposta errada e respondeu 1+1 = 3, mas era o mesmo que a resposta padrão dada antecipadamente, então o programa naturalmente não tinha como determinar que o resultado do teste era errado." Box disse em uma entrevista com BlockBeats.

Pendurado por dois anos "Espada de Dâmocles"

No primeiro ataque de reentrância registrado na história, os atacantes do WETH Attack são exatamente os hackers brancos que intencionalmente criam ataques a fim de fazer com que os desenvolvedores prestem atenção aos ataques de reentrância, com o objetivo de tornar mais projetos imunes à possibilidade de ataques de reentrância. No contexto de contratos inteligentes, os desenvolvedores devem usar diferentes mecanismos de gatilho, como chamar uma função de mudança de estado para obter proteção. Isso exige que os desenvolvedores considerem totalmente possíveis cenários de ataque ao projetar contratos e tomem as precauções apropriadas.

A fim de obter uma compreensão aprofundada do editor Vyper, BlockBeats entrevistou o pesquisador BTX Derek (@begas_btxcap), ele disse que para desenvolvedores familiarizados com Python, Vyper é uma escolha mais ideal do que Solidity, com uma interface de interface do usuário mais confortável e aprendizado mais rápido. Mas, aparentemente, algumas versões do código do editor Vyper não foram auditadas por terceiros confiáveis. Até mesmo algum trabalho de auditoria pode ser feito pelos próprios desenvolvedores. "Esse tipo de coisa não acontecerá na indústria de TI tradicional, porque depois que uma nova linguagem for lançada, haverá inúmeras empresas de auditoria procurando por suas brechas."

Sem mencionar, permitir que um bug exista abertamente por dois anos.

O colaborador do Vyper, fubuloubu, também disse: O compilador não é tão revisado ou auditado quanto todos pensam. A maioria dos compiladores tem mudanças significativas e frequentes, o que torna a auditoria uma desvantagem. Mesmo com uma auditoria completa da base de código, ela ficará desatualizada conforme mais versões forem adicionadas depois disso. Auditar o compilador não é uma boa ideia, porque faz mais sentido auditar o produto final (ou seja, código EVM bruto) produzido pelo usuário final usando a ferramenta.

Tudo isso aponta para um problema final: a motivação. Dito isso, ninguém tem incentivo para encontrar bugs críticos em compiladores, especialmente versões mais antigas. fubuloubu fez anteriormente uma proposta que ajudaria a melhorar o Vyper adicionando um programa de recompensas co-patrocinado pelos usuários, mas não foi adiante.

Os hackers estão voltando aos "Primeiros Princípios"

Este é outro exemplo vivo de práticas de desenvolvimento seguras contratuais para desenvolvedores de protocolos e projetos. Mas o mais importante, o incidente do Curve deu a todos nós um aviso de que a segurança do compilador subjacente foi seriamente ignorada, e os hackers que retornaram aos "primeiros princípios" encontraram um perfeito no compilador inferior. corte a entrada.

Posteriormente, Stani (@StaniKulechov), o fundador da Aave e Lens, também postou um longo artigo nas mídias sociais para expressar seus sentimentos: O ataque à Curve significa que o risco de DeFi sempre envolveu toda a pilha subjacente, linguagem de programação, EVM , etc Isso nos alerta para sermos mais cautelosos e sensíveis, especialmente ao usar EVMs personalizados e cadeias de aplicativos no futuro.

![Hackers voltam aos "primeiros princípios", a crise do Curve não é um ataque comum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-3324fcfbcd-dd1a6f-1c6801)

Ataques de um nível inferior

Para vulnerabilidades do compilador, é difícil descobrir apenas auditando a lógica do código-fonte do contrato. Apenas pesquisar as diferenças entre versões e versões também é um grande projeto. É necessário combinar versões específicas do compilador com padrões de código específicos para determinar se os contratos inteligentes são afetados pelas vulnerabilidades do compilador.

"Atualmente apenas dois compiladores são os melhores, a base de código do Vyper é menor, mais fácil de ler e tem menos alterações para analisar seu histórico, provavelmente é por isso que os hackers começam aqui, a base de código do Solidity é um pouco maior ”fubuloubu até suspeita que estado- hackers apoiados podem estar envolvidos neste ataque do Curve: “Levará semanas a meses para encontrar a vulnerabilidade e, considerando os recursos investidos, pode ser realizado por um pequeno grupo ou equipe”.

Como a linguagem de compilação mais usada na indústria de criptografia, a segurança do Solidity é ainda mais preocupante pelos usuários. Afinal, se o compilador Solidity tiver o problema de falha de bloqueio de reentrada desta vez, então a história de toda a indústria DeFi pode ter para ser reescrito.

De acordo com alertas de segurança emitidos regularmente pela equipe de desenvolvimento do Solidity, existem vulnerabilidades de segurança em muitas versões diferentes do compilador Solidity.

O bug do compilador mais recente registrado foi em 26 de junho, ao investigar um relatório de segurança relacionado ao uso de abi. O antigo gerador de código não avaliava expressões complexas como atribuições, chamadas de funções ou condições cujo .selector estava sendo acessado. Isso causa efeitos colaterais de tais expressões não serem executadas, portanto, os contratos compilados com o pipeline antigo podem se comportar incorretamente.

Também podemos ver um arquivo no repositório Github do Solidity que lista alguns bugs conhecidos relacionados à segurança no compilador Solidity. A lista remonta à versão 0.3.0, bugs que existiam apenas antes desta versão não estão listados. Aqui, há outro arquivo bugs_by_version.json. Este arquivo pode ser usado para consultar quais bugs uma versão específica do compilador é afetada.

Felizmente, é justamente pela ampla aplicação da linguagem Solidity e o auxílio da Ethereum Foundation que muitos problemas existentes têm sido apontados por projetos e protocolos durante o processo de implantação. Portanto, o Solidity concluiu a modificação e melhoria alguns passos mais rápido do que o Vyper. Sob essa perspectiva, esta é uma das razões pelas quais o Solidity é mais padronizado e seguro.

Para ajudar os desenvolvedores do Solidity a testar melhor e evitar que o mesmo aconteça. O co-fundador da UnitasProtocol, SunSec (@ 1 nf 0 s 3 cpt), lançou um guia de teste de segurança DeFiVulnLabs Solidity após o ataque Curve, suportando 47 tipos de vulnerabilidades, incluindo descrições de vulnerabilidade, cenários, defesas, códigos de vulnerabilidade e medidas de mitigação e como testar .

Como evitar ataques de baixo nível tanto quanto possível?

Nesse incidente da Curve, a Box acredita que o esclarecimento para todos os desenvolvedores é: não tente seguir a tendência tecnológica e escolha soluções imaturas; não aprove seu próprio código sem escrever casos de teste (várias versões do Vyper que apresentam problemas até o casos de teste estão errados); nunca aprove seu próprio código; algumas fortunas podem levar anos para serem descobertas; a não atualização é arrogância para si mesmo e desprezo pelos outros.

Normalmente, os desenvolvedores não pensam em armadilhas aqui e escolhem uma versão para compilar à vontade, o que pode ignorar os riscos trazidos pelas diferenças entre as versões. Até mesmo atualizações de versão menores podem introduzir alterações importantes, o que é especialmente importante ao desenvolver aplicativos descentralizados.

Os avisos aos desenvolvedores deste evento Curve são: use uma versão mais recente da linguagem do compilador. É importante manter sua base de código, aplicativos e sistema operacional atualizados e criar suas próprias defesas de segurança em todos os aspectos. Geralmente, há menos problemas de segurança conhecidos do que as versões mais antigas, embora as versões mais recentes possam apresentar novos problemas de segurança. Obviamente, também devemos prestar atenção aos anúncios de atualização da versão oficial e da comunidade a tempo. Entenda as alterações trazidas por cada versão e atualize sua própria base de código e ambiente operacional conforme necessário. Seguir essas etapas pode reduzir bastante os incidentes de segurança causados por bugs do compilador.

Além disso, casos de teste de unidade para completar o código. A maioria dos erros no nível do compilador levará a resultados de execução de código inconsistentes, que são difíceis de encontrar apenas por meio de revisão de código, mas podem ser expostos em testes. Melhorar a cobertura do código pode ajudar a evitar tais problemas. E tente evitar o uso de recursos de linguagem complexos, como montagem em linha e codificação e decodificação de matriz multidimensional, a menos que haja uma necessidade clara. Historicamente, a maioria das vulnerabilidades da linguagem Solidity tem sido relacionada a esses recursos avançados. Os desenvolvedores devem evitar o uso de recursos de linguagem experimental para se exibir sem uma necessidade específica.

Para a camada de protocolo e pessoal de segurança, os possíveis riscos da versão do compilador não podem ser ignorados ao realizar auditorias de código. É previsível que os hackers tenham aberto novas ideias e, no futuro, haverá cada vez mais incidentes de exploração de vulnerabilidades de nível inferior. Ao mesmo tempo, como a infraestrutura subjacente, a pilha subjacente, a linguagem de programação, o EVM, etc. precisam ser auditados. No futuro, o mercado de empresas de auditoria se tornará cada vez maior, e o mercado de bônus para convidados brancos também se tornará cada vez maior. A equipe Vyper também planeja começar a revisar o programa de recompensas de bugs depois que o assunto for oficialmente resolvido.

Claro, não precisamos entrar em pânico com os riscos da infraestrutura subjacente. No momento, a maioria dos bugs do compilador são acionados apenas em padrões de código específicos, e o impacto real precisa ser avaliado de acordo com a situação do projeto. A atualização regular da versão do compilador e o teste de unidade adequado podem ajudar a prevenir riscos.