Finanças Descentralizadas comuns vulnerabilidades de segurança e medidas de prevenção
Recentemente, um especialista em segurança compartilhou uma aula de segurança em Finanças Descentralizadas para os membros da comunidade. O especialista revisitou os principais eventos de segurança que afetaram a indústria Web3 no último ano e meio, discutiu as razões por trás desses eventos de segurança e como evitá-los, resumiu as vulnerabilidades de segurança comuns em contratos inteligentes e medidas preventivas, além de oferecer algumas recomendações de segurança para as equipes de projeto e usuários comuns.
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ções, chamadas externas arbitrárias, problemas com funções de fallback, vulnerabilidades de lógica de negócios, vazamento de chaves privadas, reentrância, entre outros. Abaixo, focaremos em empréstimos relâmpago, manipulação de preços e ataques de reentrância.
Empréstimo Relâmpago
Os empréstimos relâmpago são uma inovação nas Finanças Descentralizadas, mas quando são explorados por hackers, eles podem pegar grandes quantidades de fundos sem necessidade de qualquer custo, executar todo o processo de arbitragem e devolver o montante, pagando apenas uma pequena taxa de Gas para obter lucros enormes.
Nos últimos dois anos, os empréstimos relâmpago enfrentaram muitos problemas. Alguns projetos de Finanças Descentralizadas parecem ter altos rendimentos, mas na verdade, o nível das equipes por trás dos projetos varia muito. Alguns códigos de projetos podem ser comprados, e mesmo que o código em si não tenha falhas, ainda podem existir problemas lógicos. Por exemplo, houve um projeto que distribuía recompensas com base na quantidade de tokens que os detentores possuíam em horários fixos, mas foi explorado por atacantes que usaram empréstimos relâmpago para comprar uma grande quantidade de tokens, fazendo com que a maior parte das recompensas fosse para os atacantes no momento da distribuição. Além disso, há projetos que calculam preços através de Tokens, que podem ser afetados por empréstimos relâmpago. As equipes por trás 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. Este problema deve-se principalmente ao fato de que alguns parâmetros podem ser controlados pelos usuários durante o cálculo do preço. Os tipos de problemas que ocorrem com frequência são dois:
Ao calcular o preço, utiliza-se dados de terceiros, mas o uso incorreto ou a falta de verificação leva a manipulação maliciosa do preço.
Usou a quantidade de Token de alguns endereços como variável de cálculo, e o saldo de Token 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 inesperadas nos seus dados ao chamar funções.
Devido ao fato de que o saldo do usuário é definido como 0 apenas no final da função, a segunda chamada de ( e as subsequentes ) ainda serão bem-sucedidas, e o saldo será retirado repetidamente.
Existem muitas formas de reentrância para diferentes contratos, que podem ser combinadas com 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, devemos prestar atenção aos seguintes pontos:
Não apenas prevenir o problema de reentrada de uma única função;
Seguir o padrão Checks-Effects-Interactions ao codificar;
Utilize um modificador de proteção contra reentrância que tenha sido comprovado ao longo do tempo.
Na verdade, o que mais tememos é reinventar a roda, escrevendo tudo por conta própria. Dentro deste setor, existem muitas melhores práticas de segurança que podemos usar, não há necessidade de reinventar a roda. Quando você cria uma roda, ela não foi suficientemente validada, e a probabilidade de problemas nesse momento é claramente muito maior do que a probabilidade de problemas com algo muito maduro e testado.
Sugestões de Segurança
Dicas de segurança do projeto
O desenvolvimento de contratos deve seguir as melhores práticas de segurança.
Contratos podem ser atualizáveis e pausáveis: muitos ataques não são uma única transação que retira 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 detecção, assumindo que o contrato pode ser pausado, é possível reduzir efetivamente as perdas.
Adotar um bloqueio de tempo: se houver um bloqueio de tempo, supondo que é necessário completar dentro de 48 horas, nesse momento muitas pessoas podem perceber que o criador atualizou um método de mint novamente, e qualquer um pode usá-lo. Aqueles que monitoram saberão que o projeto provavelmente foi hackeado e poderão notificar a equipe do projeto para que faça alterações; mesmo que supondo que a notificação tenha sido feita e ninguém se importe, pelo menos poderão retirar a sua parte do dinheiro, garantindo assim que os seus lucros não sejam afetados. Portanto, se um projeto não tiver um bloqueio de tempo, teoricamente, aumenta a probabilidade de problemas.
Aumentar o investimento em segurança, estabelecendo 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 está livre de problemas apenas porque foi auditado por várias empresas. Deve-se tentar fazer modelagem de riscos e, em seguida, gradualmente evitar a maior parte dos riscos, o risco restante é um risco aceitável, dentro de um alcance suportável. Segurança e eficiência não podem coexistir, é necessário fazer certas concessões. Mas se não cuidar da segurança e não houver investimento em segurança, ser atacado é bastante normal.
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.
Prevenir atos maliciosos internos, aumentando a eficiência ao mesmo tempo que se reforça o controle de riscos.
Segurança na introdução de terceiros: Como parte do ecossistema, os projetos têm seus próprios upstream e downstream. Há um princípio de que "por padrão, tanto o upstream quanto o downstream são inseguros". É necessário realizar verificações tanto para o upstream quanto para o downstream. É muito difícil controlar terceiros, e 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 ser introduzido e chamado; se o contrato não for de código aberto, não deve ser referenciado.
Como os usuários/LP podem determinar se um contrato inteligente é seguro?
Para utilizadores comuns, avaliamos a segurança de um projeto com base nos seguintes seis pontos:
O contrato é de código aberto? Projetos cujos contratos não são de código aberto devem ser rejeitados, pois não temos como saber o que está escrito no contrato.
O proprietário utiliza múltiplas assinaturas? As múltiplas assinaturas são descentralizadas? Se não utilizarmos múltiplas assinaturas, não conseguimos 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 um hacker. Mesmo que sejam utilizadas múltiplas assinaturas, é necessário avaliar se estas são realmente descentralizadas.
Situação das transações do contrato: especialmente porque há muitos projetos de phishing no mercado, que podem criar um contrato bastante semelhante, neste caso, devemos observar o tempo de implantação do contrato, o número de interações, etc., esses são todos critérios de avaliação para determinar se o contrato é seguro.
O contrato é um contrato de agência, pode ser atualizado, tem bloqueio temporal: se o contrato não puder ser atualizado de forma alguma, será muito rígido, ainda recomendo que o contrato do projeto possa ser atualizado. No entanto, a atualização deve ser feita de forma cuidadosa. Quando houver conteúdo de atualização e alterações nos parâmetros importantes, deve haver um bloqueio temporal, proporcionando uma janela de tempo para que todos possam avaliar se a verdadeira atualização é prejudicial ou benéfica para os usuários, o que também é uma forma de ser transparente e aberto.
O contrato já 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, porque diferentes empresas de auditoria e diferentes auditores têm perspectivas diferentes sobre os problemas. Em segundo lugar, deve-se verificar se as permissões do Owner são excessivas. As permissões de um Owner de um projeto normal devem ser controláveis, para que não haja muitas operações de alto risco, e as operações também devem ser feitas de forma a permitir que os usuários saibam o que está sendo operado.
Atenção aos oráculos: se o projeto usar oráculos líderes disponíveis no mercado, basicamente não haverá grandes problemas, mas se usar oráculos construídos internamente, ou oráculos onde se pode simplesmente fornecer preços com algumas garantias de tokens, é preciso ter cuidado. Quando se descobre que o oráculo pode ter alguns problemas, ou que existe a possibilidade de manipulação, mesmo que o retorno do projeto seja elevado, não se deve participar.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
16 Curtidas
Recompensa
16
4
Compartilhar
Comentário
0/400
MetaverseHobo
· 13h atrás
Deve ser cauteloso faça a sua própria investigação (DYOR)
Finanças Descentralizadas segurança: Análise de vulnerabilidades comuns e medidas de prevenção
Finanças Descentralizadas comuns vulnerabilidades de segurança e medidas de prevenção
Recentemente, um especialista em segurança compartilhou uma aula de segurança em Finanças Descentralizadas para os membros da comunidade. O especialista revisitou os principais eventos de segurança que afetaram a indústria Web3 no último ano e meio, discutiu as razões por trás desses eventos de segurança e como evitá-los, resumiu as vulnerabilidades de segurança comuns em contratos inteligentes e medidas preventivas, além de oferecer algumas recomendações de segurança para as equipes de projeto e usuários comuns.
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ções, chamadas externas arbitrárias, problemas com funções de fallback, vulnerabilidades de lógica de negócios, vazamento de chaves privadas, reentrância, entre outros. Abaixo, focaremos em empréstimos relâmpago, manipulação de preços e ataques de reentrância.
Empréstimo Relâmpago
Os empréstimos relâmpago são uma inovação nas Finanças Descentralizadas, mas quando são explorados por hackers, eles podem pegar grandes quantidades de fundos sem necessidade de qualquer custo, executar todo o processo de arbitragem e devolver o montante, pagando apenas uma pequena taxa de Gas para obter lucros enormes.
Nos últimos dois anos, os empréstimos relâmpago enfrentaram muitos problemas. Alguns projetos de Finanças Descentralizadas parecem ter altos rendimentos, mas na verdade, o nível das equipes por trás dos projetos varia muito. Alguns códigos de projetos podem ser comprados, e mesmo que o código em si não tenha falhas, ainda podem existir problemas lógicos. Por exemplo, houve um projeto que distribuía recompensas com base na quantidade de tokens que os detentores possuíam em horários fixos, mas foi explorado por atacantes que usaram empréstimos relâmpago para comprar uma grande quantidade de tokens, fazendo com que a maior parte das recompensas fosse para os atacantes no momento da distribuição. Além disso, há projetos que calculam preços através de Tokens, que podem ser afetados por empréstimos relâmpago. As equipes por trás 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. Este problema deve-se principalmente ao fato de que alguns parâmetros podem ser controlados pelos usuários durante o cálculo do preço. Os tipos de problemas que ocorrem com frequência são dois:
Ao calcular o preço, utiliza-se dados de terceiros, mas o uso incorreto ou a falta de verificação leva a manipulação maliciosa do preço.
Usou a quantidade de Token de alguns endereços como variável de cálculo, e o saldo de Token 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 inesperadas nos seus dados ao chamar funções.
Devido ao fato de que o saldo do usuário é definido como 0 apenas no final da função, a segunda chamada de ( e as subsequentes ) ainda serão bem-sucedidas, e o saldo será retirado repetidamente.
Existem muitas formas de reentrância para diferentes contratos, que podem ser combinadas com 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, devemos prestar atenção aos seguintes pontos:
Não apenas prevenir o problema de reentrada de uma única função;
Seguir o padrão Checks-Effects-Interactions ao codificar;
Utilize um modificador de proteção contra reentrância que tenha sido comprovado ao longo do tempo.
Na verdade, o que mais tememos é reinventar a roda, escrevendo tudo por conta própria. Dentro deste setor, existem muitas melhores práticas de segurança que podemos usar, não há necessidade de reinventar a roda. Quando você cria uma roda, ela não foi suficientemente validada, e a probabilidade de problemas nesse momento é claramente muito maior do que a probabilidade de problemas com algo muito maduro e testado.
Sugestões de Segurança
Dicas de segurança do projeto
O desenvolvimento de contratos deve seguir as melhores práticas de segurança.
Contratos podem ser atualizáveis e pausáveis: muitos ataques não são uma única transação que retira 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 detecção, assumindo que o contrato pode ser pausado, é possível reduzir efetivamente as perdas.
Adotar um bloqueio de tempo: se houver um bloqueio de tempo, supondo que é necessário completar dentro de 48 horas, nesse momento muitas pessoas podem perceber que o criador atualizou um método de mint novamente, e qualquer um pode usá-lo. Aqueles que monitoram saberão que o projeto provavelmente foi hackeado e poderão notificar a equipe do projeto para que faça alterações; mesmo que supondo que a notificação tenha sido feita e ninguém se importe, pelo menos poderão retirar a sua parte do dinheiro, garantindo assim que os seus lucros não sejam afetados. Portanto, se um projeto não tiver um bloqueio de tempo, teoricamente, aumenta a probabilidade de problemas.
Aumentar o investimento em segurança, estabelecendo 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 está livre de problemas apenas porque foi auditado por várias empresas. Deve-se tentar fazer modelagem de riscos e, em seguida, gradualmente evitar a maior parte dos riscos, o risco restante é um risco aceitável, dentro de um alcance suportável. Segurança e eficiência não podem coexistir, é necessário fazer certas concessões. Mas se não cuidar da segurança e não houver investimento em segurança, ser atacado é bastante normal.
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.
Prevenir atos maliciosos internos, aumentando a eficiência ao mesmo tempo que se reforça o controle de riscos.
Segurança na introdução de terceiros: Como parte do ecossistema, os projetos têm seus próprios upstream e downstream. Há um princípio de que "por padrão, tanto o upstream quanto o downstream são inseguros". É necessário realizar verificações tanto para o upstream quanto para o downstream. É muito difícil controlar terceiros, e 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 ser introduzido e chamado; se o contrato não for de código aberto, não deve ser referenciado.
Como os usuários/LP podem determinar se um contrato inteligente é seguro?
Para utilizadores comuns, avaliamos a segurança de um projeto com base nos seguintes seis pontos:
O contrato é de código aberto? Projetos cujos contratos não são de código aberto devem ser rejeitados, pois não temos como saber o que está escrito no contrato.
O proprietário utiliza múltiplas assinaturas? As múltiplas assinaturas são descentralizadas? Se não utilizarmos múltiplas assinaturas, não conseguimos 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 um hacker. Mesmo que sejam utilizadas múltiplas assinaturas, é necessário avaliar se estas são realmente descentralizadas.
Situação das transações do contrato: especialmente porque há muitos projetos de phishing no mercado, que podem criar um contrato bastante semelhante, neste caso, devemos observar o tempo de implantação do contrato, o número de interações, etc., esses são todos critérios de avaliação para determinar se o contrato é seguro.
O contrato é um contrato de agência, pode ser atualizado, tem bloqueio temporal: se o contrato não puder ser atualizado de forma alguma, será muito rígido, ainda recomendo que o contrato do projeto possa ser atualizado. No entanto, a atualização deve ser feita de forma cuidadosa. Quando houver conteúdo de atualização e alterações nos parâmetros importantes, deve haver um bloqueio temporal, proporcionando uma janela de tempo para que todos possam avaliar se a verdadeira atualização é prejudicial ou benéfica para os usuários, o que também é uma forma de ser transparente e aberto.
O contrato já 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, porque diferentes empresas de auditoria e diferentes auditores têm perspectivas diferentes sobre os problemas. Em segundo lugar, deve-se verificar se as permissões do Owner são excessivas. As permissões de um Owner de um projeto normal devem ser controláveis, para que não haja muitas operações de alto risco, e as operações também devem ser feitas de forma a permitir que os usuários saibam o que está sendo operado.
Atenção aos oráculos: se o projeto usar oráculos líderes disponíveis no mercado, basicamente não haverá grandes problemas, mas se usar oráculos construídos internamente, ou oráculos onde se pode simplesmente fornecer preços com algumas garantias de tokens, é preciso ter cuidado. Quando se descobre que o oráculo pode ter alguns problemas, ou que existe a possibilidade de manipulação, mesmo que o retorno do projeto seja elevado, não se deve participar.