Finanças Descentralizadas comuns vulnerabilidades de segurança e medidas de prevenção

Recentemente, um especialista em segurança compartilhou uma aula sobre segurança em Finanças Descentralizadas para os membros da comunidade. Ele revisitou os principais eventos de segurança que o setor Web3 enfrentou no último ano, discutiu as razões pelas quais esses eventos ocorreram e como evitá-los, resumiu as vulnerabilidades de segurança comuns em contratos inteligentes e as medidas de prevenção, além de oferecer algumas recomendações de segurança para os desenvolvedores de projetos e usuários comuns.

Os tipos comuns de vulnerabilidades em Finanças Descentralizadas incluem empréstimos relâmpago, manipulação de preços, problemas de permissão de funções, chamadas externas arbitrárias, problemas de função fallback, vulnerabilidades de lógica de negócios, vazamento de chaves privadas, reentrância, entre outros. Abaixo, serão destacadas as três categorias de empréstimos relâmpago, manipulação de preços e ataques de reentrância.

Empréstimo Relâmpago

O empréstimo relâmpago é uma inovação nas Finanças Descentralizadas, mas quando explorado por hackers, eles podem pegar grandes quantias de dinheiro sem custo, devolvendo após a execução da arbitragem, pagando apenas uma pequena taxa de Gas para obter lucros exorbitantes.

Nos últimos dois anos, os problemas com empréstimos relâmpago têm sido frequentes. Alguns projetos parecem ter altos retornos, mas na verdade, os níveis das equipes dos projetos são variados. Mesmo que o código em si não tenha vulnerabilidades, ainda pode haver problemas lógicos. Por exemplo, alguns projetos distribuem recompensas em horários fixos com base na quantidade de tokens que os detentores possuem, mas são explorados por atacantes que utilizam empréstimos relâmpago para comprar uma grande quantidade de tokens, obtendo a maior parte das recompensas no momento da distribuição. Existem também alguns projetos que calculam preços com base em tokens, e podem ser influenciados por empréstimos relâmpago. As equipes dos projetos devem estar atentas 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, existindo principalmente dois tipos:

1. Ao calcular o preço, são utilizados dados de terceiros, mas o uso inadequado ou a falta de verificação levam a uma manipulação maliciosa do preço.

2. Usar a quantidade de tokens de certos endereços como variáveis de cálculo, e o saldo de tokens desses endereços pode ser temporariamente aumentado ou diminuído.

Ataque de Reentrada

Um dos principais perigos de chamar contratos externos é que eles podem assumir o controle do fluxo e fazer alterações nos dados chamando funções de maneira inesperada.

Existem muitas maneiras de reentrar em diferentes contratos, podendo combinar diferentes funções do contrato ou funções de vários contratos diferentes para realizar um ataque de reentrada. Portanto, ao resolver o problema de reentrada, é necessário prestar atenção a:

1. Não é apenas para prevenir o problema de reentrada de uma única função.

2. Seguir o padrão Checks-Effects-Interactions ao codificar

3. Usar um modificador de prevenção de reentrada comprovado pelo tempo

O que mais tememos é reinventar a roda, escrever tudo por conta própria. Neste meio, existem muitas melhores práticas de segurança, que podemos usar, não há necessidade de reinventar a roda. Quando você inventa uma roda, ela não foi suficientemente validada e, nesse momento, a probabilidade de problemas é, claramente, muito maior do que a probabilidade de problemas com uma solução muito madura e testada.

Sugestões de Segurança

Dicas de segurança para projetos

1. O desenvolvimento de contratos segue as melhores práticas de segurança.

2. Contratos podem ser atualizados e pausados: muitos ataques não transferem todas as moedas de uma vez, mas sim em várias transações, se houver um mecanismo de monitoramento relativamente sólido, isso pode ser detectado, e se o contrato puder ser pausado após a detecção, pode-se efetivamente reduzir as perdas.

3. Adotar um bloqueio de tempo: Se houver um bloqueio de tempo, supondo que seja necessário 48 horas para ser concluído, nesse momento, durante o período de bloqueio de tempo, muitas pessoas podem descobrir que o criador atualizou um método de mint que todos podem usar. Os que monitoram saberão que o projeto pode ter sido hackeado e poderão notificar a equipe do projeto para fazer alterações; mesmo que sejam notificados, ninguém se preocupa. Pelo menos podem retirar a sua parte do dinheiro, garantindo assim que seus lucros não sejam afetados. Portanto, se um projeto não tiver um bloqueio de tempo, teoricamente, isso aumenta a probabilidade de problemas.

4. 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 aprovado por várias empresas de auditoria está tudo bem, deve-se considerar vários riscos que podem levar à perda de fundos. Deve-se tentar fazer uma modelagem de risco e, em seguida, gradualmente evitar a maior parte dos riscos, os riscos remanescentes também são riscos aceitáveis, dentro de um limite suportável. Segurança e eficiência não podem ser obtidas juntas, é necessário fazer certas concessões. Mas se não se preocupar com a segurança, e não houver investimento em segurança, ser atacado é muito normal.

5. Aumentar a consciência de segurança de todos os funcionários: Aumentar a consciência de segurança não requer muita tecnologia. Neste grande ambiente, basta fazer um pouco mais de perguntas sobre o porquê e pensar um pouco mais para evitar muitos problemas.

6. Prevenir a má conduta interna, ao mesmo tempo que se melhora a eficiência e se aumenta o controle de riscos: por exemplo, se o Proprietário do contrato é uma assinatura única ou múltipla, se utiliza um bloqueio de tempo, etc., tudo isso precisa ser considerado.

7. 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 "por padrão, todos os upstream e downstream são inseguros". Tanto para upstream quanto para downstream, é necessário realizar validações. É muito difícil controlar terceiros, a exposição ao risco de segurança é, na verdade, bastante grande, portanto, é preciso ter muito cuidado com a introdução de terceiros. O contrato é de código aberto, pode-se introduzir e chamá-lo; se o contrato não for de código aberto, definitivamente não pode ser referenciado.

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

Para usuários comuns, a avaliação da segurança de um projeto deve se basear nos seguintes seis pontos:

1. O contrato é de código aberto: Projetos cujos contratos não são de código aberto não devem ser tocados, porque não temos como saber o que está escrito no contrato.

2. O proprietário usa múltiplas assinaturas? As múltiplas assinaturas são descentralizadas? Se não usarmos múltiplas assinaturas, não conseguiremos avaliar a lógica de negócios e o conteúdo do projeto. Em caso de um evento de segurança, não conseguiremos determinar se foi causado por um hacker. Mesmo se forem usadas múltiplas assinaturas, é necessário verificar se estas são descentralizadas.

3. Situação das transações do contrato existente: especialmente porque existem muitos projetos de phishing no mercado, que podem criar um contrato bastante semelhante, neste momento devemos observar o tempo de implantação do contrato, o número de interações, etc., que são todos critérios para avaliar se o contrato é seguro.

4. O contrato é um contrato de agência, pode ser atualizado, tem um bloqueio de tempo: se o contrato não puder ser atualizado de forma alguma, será muito rígido, ainda recomendo que os contratos dos projetos possam ser atualizados. No entanto, a atualização deve ser feita com critério; quando houver conteúdo de atualização e alterações em parâmetros importantes, deve haver um bloqueio de tempo, proporcionando uma janela de tempo para que todos possam avaliar se a atualização é prejudicial ou benéfica para os usuários, o que também é uma forma de ser público e transparente.

5. O contrato foi auditado por várias instituições ( não confie cegamente nas empresas de auditoria ), as permissões do Owner são excessivas: primeiro, não confie apenas em uma empresa de auditoria, pois diferentes empresas de auditoria e diferentes auditores têm perspectivas diferentes sobre o problema. Em segundo lugar, verifique se as permissões do Owner são excessivas. As permissões de um Owner de um projeto normal devem ser controláveis, assim não haverá muitas operações de alto risco, e as operações também devem ser feitas de forma a usar um bloqueio de tempo, para que os usuários saibam o que está sendo operado.

6. Atenção aos oráculos: se o projeto usar oráculos líderes de mercado, basicamente não haverá grandes problemas, mas se usar oráculos próprios, ou oráculos que permitem alimentar preços apenas com algumas garantias de tokens, é preciso ter cuidado. Quando se descobre que o oráculo pode ter alguns problemas, ou que pode ser manipulado, mesmo que os retornos do projeto sejam altos, não se deve participar.