Finanças Descentralizadas Segurança: Vulnerabilidades Comuns e Medidas de Prevenção

Recentemente, um especialista em segurança compartilhou conteúdos relacionados à segurança das Finanças Descentralizadas, revisitando os principais eventos de segurança da indústria Web3 nos últimos mais de um ano, discutindo as razões pela qual esses eventos ocorreram e como evitá-los, resumindo as vulnerabilidades de segurança comuns em contratos inteligentes e medidas preventivas, além de oferecer algumas recomendações de segurança para os projetos e usuários.

Os tipos comuns de vulnerabilidades em Finanças Descentralizadas geralmente incluem empréstimos relâmpago, manipulação de preços, problemas de permissões de função, chamadas externas arbitrárias, problemas com funções de fallback, vulnerabilidades de lógica de negócios, vazamento de chaves privadas, reentrâncias, entre outros. Este artigo se concentra em empréstimos relâmpago, manipulação de preços e ataques de reentrada.

Empréstimo Relâmpago

O empréstimo relâmpago é uma inovação nas Finanças Descentralizadas, mas quando explorado por hackers, eles não precisam gastar nenhum custo para pegar dinheiro emprestado, devolvendo-o apenas após completar todo o processo de arbitragem, ficando com o restante como lucro da arbitragem; eles só precisam pagar uma pequena taxa de Gas para obter enormes retornos.

Ataques comuns muitas vezes vêm acompanhados de empréstimos relâmpago. Os atacantes gostam de pegar emprestado grandes quantias através de empréstimos relâmpago para manipular preços e atacar a lógica de negócios, entre outros. Os desenvolvedores precisam considerar se a funcionalidade do contrato pode falhar devido a grandes quantias de fundos ou se, através de grandes quantias, é possível interagir com várias funções do contrato em uma única transação para obter recompensas nesses cenários.

É comum ver alguns valores de quantidade de Token em contratos sendo usados para calcular recompensas, ou a quantidade de Token em pares de negociação DEX participando de vários cálculos. Como os desenvolvedores não consideraram que atacantes poderiam usar empréstimos relâmpago para manipular essas variáveis ao projetar essas funcionalidades, os fundos do contrato foram roubados.

Nos últimos dois anos, os empréstimos relâmpago enfrentaram muitos problemas. Muitos projetos de Finanças Descentralizadas parecem ter altos rendimentos, mas na verdade a qualidade das equipes por trás dos projetos varia bastante. Por exemplo, o código pode ter sido comprado, e mesmo que o código em si não tenha vulnerabilidades, ainda podem existir problemas lógicos. Por exemplo, já encontramos um projeto que distribui recompensas em horários fixos com base na quantidade de tokens que os detentores possuem, mas que foi explorado por atacantes que usaram empréstimos relâmpago para comprar uma grande quantidade de tokens, resultando na maior parte das recompensas fluindo para os atacantes no momento da distribuição. Além disso, existem alguns projetos que calculam preços com base em tokens, que podem ser influenciados por empréstimos relâmpago; como equipe do projeto, devemos estar atentos a esses problemas.

Manipulação de Preços

O problema de manipulação de preços está intimamente relacionado com os empréstimos relâmpago. Este problema deve-se principalmente ao fato de que alguns parâmetros utilizados no cálculo de preços podem ser controlados pelos usuários. Os tipos de problemas que ocorrem com frequência são de duas naturezas.

• Uma é usar dados de terceiros ao calcular preços, mas o uso incorreto ou a falta de verificação levam à manipulação maliciosa dos preços.
• Outra forma é devido ao uso de algumas quantidades de Token em determinados endereços como variáveis de cálculo, e os saldos de Token desses endereços podem ser temporariamente aumentados ou diminuídos.

Ataque de Reentrada

Um dos principais perigos de chamar contratos externos é que eles podem assumir o controle do fluxo, realizando alterações inesperadas nos seus dados ao chamar funções.

Devido ao saldo do usuário ser definido como 0 apenas no final da função, a segunda chamada ( e as chamadas seguintes ) ainda terão sucesso e poderão retirar o saldo repetidamente.

Existem muitas maneiras de reentrância para diferentes contratos, podendo combinar diferentes funções do contrato ou funções de vários contratos diferentes para realizar um ataque de reentrância. Portanto, ao resolver o problema de reentrância, precisamos prestar atenção aos seguintes pontos:

1. Não apenas prevenir problemas de reentrada de uma única função;
2. Seguir o padrão Checks-Effects-Interactions ao codificar;
3. Utilize um modificador de proteção contra reentrâncias que tenha sido testado ao longo do tempo.

Na verdade, o que mais tememos é reinventar a roda, ter que escrever tudo por conta própria. Dentro deste setor, existem muitas melhores práticas de segurança que podemos utilizar, não há necessidade de reinventar a roda. Quando você cria uma roda, ela não foi devidamente verificada, e a probabilidade de problemas nesse momento é, claramente, muito maior do que a probabilidade de problemas ao usar algo que já é maduro e testado.

A história por trás da vulnerabilidade do Omni Protocol --- O confronto entre quatro hackers

O mempool do Ethereum tem sido monitorizado por um grande número de hackers, que estão constantemente a analisar transações e a correr à frente de transações lucrativas para obter lucros. As transações de ataque submetidas pelo descobridor da vulnerabilidade do Omni Protocol foram capturadas por dois hackers, que utilizaram robôs de corrida para roubar 1200 ETH do protocolo Omni em transações de corrida publicadas no flashbot, enquanto o atacante que descobriu a vulnerabilidade apenas obteve 480 ETH. Durante esse período, outro hacker descobriu as transações de ataque submetidas pelos hackers de corrida no flashbot e, aproveitando a necessidade de comprar o token Doodle ERC20 nas transações de ataque, executou um ataque de sanduíche, lucrando 151 ETH.

Os que descobrem vulnerabilidades não são os que mais lucram; quem lucra mais são os outros caçadores na floresta escura. Neste ecossistema, há caçadores em toda parte, e os caçadores podem ser presas uns dos outros. Mesmo o iniciador do ataque, se for um novato, pode não conseguir levar a maior parte do dinheiro do projeto, a menos que consiga pegar tudo de uma vez. Além disso, muitas pessoas usam taxas de Gas mais altas para executar transações primeiro. Se a corrida envolver a compra e venda de tokens em DEX, pode haver ataques de sanduíche, o que é muito confuso.

Sugestões de Segurança

Por fim, aqui estão algumas recomendações de segurança para as partes do projeto e para os usuários comuns.

Dicas de segurança para o projeto

Um, o desenvolvimento de contratos deve seguir as melhores práticas de segurança.

Dois, Contratos podem ser atualizados e pausados: Muitos ataques não são feitos de uma só vez, transferindo todas as moedas, mas sim executados em várias transações. Se houver um mecanismo de monitoramento relativamente sólido, isso pode ser detectado. Após a descoberta, supondo que o contrato possa ser pausado, isso pode efetivamente reduzir as perdas.

Três, uso de bloqueio temporal: Em certos casos, se houver um bloqueio temporal, supondo que seja necessário completar dentro de 48 horas, nesse momento muitas pessoas podem perceber que o criador atualizou um método de mintagem que qualquer um pode usar. Aqueles que monitoram saberão que o projeto provavelmente foi hackeado e poderão notificar a equipe do projeto para fazer alterações. Mesmo que supostamente tenham sido notificados, se ninguém agir, pelo menos podem retirar a sua parte do dinheiro, garantindo que os seus lucros não sejam afetados. Portanto, se um projeto não tiver um bloqueio temporal, teoricamente aumenta a probabilidade de problemas.

Quatro, aumentar o investimento em segurança, estabelecer um sistema de segurança completo: A segurança não é um ponto, nem uma linha, a segurança é um sistema. Não pense que, como parte do projeto, o contrato não terá problemas apenas porque foi auditado por várias empresas, o resultado é que um hacker roubou a chave privada, mesmo que seja uma multi-assinatura, roubou todas as chaves privadas. Ou pode ser que o modelo econômico tenha problemas, o modelo de negócios tenha problemas... existem milhares e milhares de maneiras que podem levar a perder dinheiro, depende de conseguir evitar todos os riscos de segurança antecipadamente. É necessário fazer modelagem de risco o máximo possível e, em seguida, gradualmente evitar a maior parte dos riscos, os riscos remanescentes também são riscos aceitáveis, dentro de um intervalo suportável. Segurança e eficiência não podem coexistir, é necessário fazer certas concessões. Mas se não se preocupar com a segurança, se não houver investimento em segurança, ser atacado é muito normal.

Cinco, aumentar a consciência de segurança de todos os funcionários: Aumentar a consciência de segurança não requer muita tecnologia. No Twitter, vemos frequentemente muitas pessoas perdendo NFTs devido a phishing, na verdade, o phishing usa as fraquezas da natureza humana; talvez prestando um pouco mais de atenção, as pessoas não seriam enganadas. No grande ambiente do Web3, só é preciso fazer um pouco mais de perguntas sobre o porquê, e pensar um pouco mais para evitar muitos problemas.

Seis, prevenir a má conduta interna, aumentando a eficiência enquanto se reforça o controle de risco: Vamos usar alguns casos como exemplo. Primeiro, o Owner do contrato é uma única assinatura em vez de múltiplas assinaturas, se a chave privada for perdida, todo o projeto fica sob controle; segundo, não foi utilizado um bloqueio de tempo, algumas operações de atualização críticas são atualizadas imediatamente, sem que ninguém saiba, o que é muito injusto para todos os participantes do protocolo; e por último, a má conduta interna, os mecanismos de segurança internos não tiveram qualquer efeito.

Como os protocolos na blockchain podem garantir eficiência ao mesmo tempo que melhoram a segurança? Algumas ferramentas de segurança podem designar uma pessoa específica para executar uma operação, como uma assinatura múltipla de três em cinco; pode-se designar um endereço específico para realizar uma operação, como monitorar riscos de segurança em um nó muito confiável. Supondo que se descubra que o protocolo está sendo atacado e que os fundos estão gradualmente sendo transferidos para o endereço do hacker, se esse contrato tiver uma função de pausa, podemos conceder a função de pausa a uma pessoa, e ela poderá realizar essa operação.

Por exemplo, para os formadores de mercado que operam em DEX, se não houver restrições nas permissões do Owner, o Owner pode transferir fundos para outros endereços, pode restringir os endereços para transferências de moeda, limitar quais pares de moedas podem ser operados, e definir que o dinheiro só pode ser retirado para um determinado endereço. Isso garante uma certa segurança enquanto melhora a eficiência.

Sete, Segurança da Introdução de Terceiros: Como parte do ecossistema, os projetos têm seus próprios upstream e downstream. Existe um princípio de que "por padrão, todos os upstream e downstream são inseguros". É necessário realizar verificações tanto para upstream quanto para downstream. Para terceiros, é muito difícil controlar, e a exposição ao risco de segurança é, na verdade, bastante grande, por isso devemos ter muito cuidado com a introdução de terceiros. O contrato é de código aberto, podendo ser introduzido e chamado; se o contrato não for de código aberto, definitivamente não pode ser referenciado. Porque não sabemos qual é a lógica interna, ou se a introdução desse contrato é, por si só, um contrato atualizável; o uso normal pode não ter problemas, mas não podemos prever se, de repente, em um dia, ele será atualizado para se tornar um contrato malicioso, o que é incontrolável.

Como os usuários/LP podem determinar se um contrato inteligente é seguro?

Para usuários comuns, avaliamos se um projeto é seguro principalmente com base nos seguintes seis pontos:

I. O contrato é de código aberto?: Qualquer projeto cujo contrato não seja aberto, devemos evitar completamente, pois não temos como saber o que está escrito no contrato.

Dois, o Owner utiliza múltiplas assinaturas, e as múltiplas assinaturas são descentralizadas: Se não houver múltiplas assinaturas, não podemos avaliar a lógica e o conteúdo do negócio do projeto. Uma vez que ocorra um evento de segurança, não será possível determinar se foi causado por hackers. Mesmo que sejam utilizadas múltiplas assinaturas, é necessário verificar se essas múltiplas assinaturas são realmente descentralizadas.

Três, Situação das Transações do Contrato: Especialmente porque há muitos projetos de phishing no mercado, é possível que um contrato semelhante seja criado. Nesse momento, devemos observar o tempo de implantação do contrato, o número de interações, etc. Esses são critérios de avaliação para determinar se o contrato é seguro.

Quatro, o contrato é um contrato de representação, pode ser atualizado, existe um bloqueio de tempo: Se o contrato não puder ser atualizado de forma alguma, será muito rígido; ainda assim, recomendo que o contrato do projeto possa ser atualizado. No entanto, a atualização deve ser feita com cuidado; quando houver conteúdo de atualização e alterações em parâmetros importantes, deve haver um bloqueio de tempo, oferecendo um período para que todos possam avaliar se a atualização real é prejudicial ou benéfica para os usuários, o que também é uma maneira de garantir a transparência.

Cinco, o contrato foi auditado por várias instituições ( não confie cegamente nas empresas de auditoria ), o Owner tem permissões excessivas: Primeiramente, não confie apenas em uma empresa de auditoria, pois diferentes empresas de auditoria e diferentes auditores têm perspectivas diferentes sobre os problemas. Se um projeto teve resultados de auditoria de várias instituições e foram encontrados problemas diferentes, e a equipe do projeto fez as devidas correções, isso é mais seguro em comparação com a auditoria realizada apenas por uma única empresa de auditoria. Uma equipe de projeto responsável procurará várias instituições de auditoria para realizar auditorias cruzadas.

Em segundo lugar, é importante observar se os direitos do Owner são excessivos. Por exemplo, em alguns projetos de 貔恘盘, o Owner pode controlar completamente os fundos dos usuários; se a quantidade de tokens comprados for baixa, as compras e vendas podem ocorrer normalmente, mas se a quantidade de tokens comprados for enorme, o Owner pode imediatamente bloquear e impedir transações. Alguns projetos de NFT funcionam da mesma forma. Em um projeto normal, os direitos do Owner devem ser controláveis, para que não haja muitas operações de alto risco, e as operações devem ser feitas de forma programada, permitindo que os usuários saibam o que está sendo realizado. Especialmente em tempos de mercado ruim, existem vários tipos de projetos fraudulentos, por isso todos devem dar atenção aos direitos do Owner.

Seis, Atenção aos Oráculos: Se o projeto usar oráculos de liderança do mercado, basicamente não haverá grandes problemas, mas se usar oráculos próprios, ou se for possível colocar qualquer token como colateral, isso pode ser um risco.