O padrão ERC20 é um dos padrões de token mais amplamente usados na blockchain. Ao implantar projetos de token ERC20, além das vulnerabilidades no código do contrato, há também um risco maior de ataques devido à falta de conhecimento do time do projeto sobre os pares de tokens ou os vários recursos envolvidos.
Esses riscos de ataque podem ser agrupados em duas categorias: manipulação de preços e falhas de recompensa.
A manipulação de preços refere-se a situações em que os invasores podem manipular o preço de um par de tokens para roubar ativos em um determinado período ou prazo, devido a considerações de segurança insuficientes no código ou na implantação.
As falhas no mecanismo de recompensa referem-se a situações em que os invasores podem obter recompensas além das esperadas pelo time do projeto devido à falta de conhecimento sobre os aplicativos de blockchain ou a falhas lógicas na implementação do mecanismo de recompensa, permitindo que eles roubem ativos dentro do projeto.
No conteúdo a seguir, daremos exemplos de incidentes de segurança e forneceremos boas práticas de segurança relevantes para contratos de token ERC20.
Manipulação de Preços
Os ataques relacionados à manipulação de preços ocorrem principalmente nas seguintes situações:
Manipulação de preços causada por diferenças de implementação entre diferentes pares de tokens do mesmo token.
Manipulação de preço causada por mecanismos de migração não razoáveis durante a migração de liquidez.
Manipulação de preço causada por controle malicioso de oráculos de preço de pares de tokens.
Incidentes de ataque causados por diferenças de implementação entre diferentes pares de tokens do mesmo token
Em alguns casos, os times de projeto podem implantar diferentes pares de tokens de seu token de projeto e outros tokens em várias exchanges em função de diferentes requisitos. No entanto, as diferenças nas taxas e em outros aspectos entre diferentes exchanges ou pools de tokens podem ser exploradas por invasores para manipular os preços.
Incidente de ataque do BabyDoge
Nos pares de tokens relacionados ao BabyDoge, o contrato FarmZAP permite a compra e venda de tokens BabyDoge com taxa zero. Ao mesmo tempo, o BabyDoge também tem pares de tokens na PancakeSwap. Quando os usuários realizam transações durante um determinado período de tempo, as taxas deduzidas são recompensadas e adicionadas aos pares de tokens da PancakeSwap.
Nesse cenário, o invasor explorou o recurso de taxa zero do FarmZAP na negociação de tokens BabyDoge. Ele adquiriu uma grande quantidade de tokens BabyDoge usando BNB e, em seguida, trocou os tokens BabyDoge adquiridos por BNB por meio do FarmZAP em pares de tokens PancakeSwap.
É importante observar que, devido à presença de uma grande quantidade de tokens BabyDoge na PancakeSwap, o preço dos tokens BabyDoge nesse par era extremamente baixo. Por outro lado, no par de tokens BabyDoge, o preço dos tokens BabyDoge era excepcionalmente alto devido à abundância de BNB.
Além disso, o invasor acionou o mecanismo de distribuição de taxas do BabyDoge, convertendo mais tokens BabyDoge em BNB por meio da PancakeSwap e aumentando a liquidez. Isso reduziu ainda mais o preço do BabyDoge no par PancakeSwap BabySwap.
Usando o recurso de taxa zero do FarmZAP mais uma vez, o invasor usou o BNB obtido para adquirir tokens BabyDoge da PancakeSwap e depois os vendeu para obter lucro.
O principal aspecto desse incidente de ataque é o aumento da diferença entre os tokens BabyDoge nos dois pares de tokens por meio do recurso de taxa zero do FarmZAP e do mecanismo de distribuição de taxas. Essa diferença foi explorada para roubar ativos do contrato.
Boas Práticas de Segurança:
Em qualquer situação, garanta taxas de transação consistentes (não limitadas a isso) para o mesmo token em diferentes pares de tokens para evitar a perda de ativos devido a diferenças entre pares de tokens. Recomenda-se usar DEXs (como UniSwap, PancakeSwap, SushiSwap) com base no mesmo código durante o processo de criação do par de tokens, pois a semelhança do código subjacente facilita a garantia da consistência do comportamento do par de tokens em diferentes DEXs.
Ataques relacionados à Migração do Pool de Liquidez
À medida que as DEXs ou os projetos evoluem, os times de projeto podem querer criar novos pools de tokens para aliviar problemas como taxas de negociação ou utilização de capital entre pares de tokens. Para garantir que os ativos dos usuários não sejam perdidos e permitir a migração conveniente de ativos ou liquidez entre diferentes versões de pares de tokens, algumas exchanges permitem que os usuários migrem ativos diretamente do pool antigo sem precisar retirá-los primeiro.
Incidente de ataque ao CellFrame
O CellFrame tem contratos de pool de tokens antigos e novos e oferece suporte à migração direta de tokens de liquidez do pool de tokens antigo para o novo. No entanto, os invasores exploraram uma vulnerabilidade na lógica de transferência do contrato de migração de liquidez.
O invasor primeiro adicionou liquidez ao antigo pool de tokens para obter tokens de liquidez. Em seguida, ele tomou emprestada uma grande quantidade de BNB no pool antigo e a substituiu por tokens CELL. Durante a retirada de liquidez do antigo pool de tokens, o grave desequilíbrio entre BNB e CELL permitiu que o invasor obtivesse uma quantidade significativa de BNB.
Em seguida, o invasor pegou emprestado uma grande quantidade de tokens CELL e converteu todos eles em BNB no novo pool. Posteriormente, ele transferiu os tokens de liquidez do pool antigo para o novo. Devido ao desequilíbrio entre BNB e CELL no novo pool, combinado com o fato de que o contrato de transferência de liquidez calculou a transferência de liquidez com base na proporção de BNB e CELL no novo pool, a diferença entre os dois tokens, bem como a presença de tokens CELL no contrato de transferência de liquidez, possibilitou a realização do ataque.
A principal causa desse incidente de ataque está na vulnerabilidade do processo de transferência de liquidez. Embora a exploração adicional tenha sido facilitada pela presença de tokens CELL no pool de transferência de tokens, o foco principal deve ser a falha no processo de migração de liquidez.
Boas Práticas de Segurança:
Ao realizar a migração de liquidez, é importante considerar o impacto da diferença de proporção entre os dois pares de tokens nos pools de liquidez antigo e novo. Para atenuar os riscos de segurança causados pela disparidade entre os pools antigo e novo durante a migração, recomenda-se garantir que a diferença da proporção de tokens permaneça em um intervalo pequeno durante o processo de migração de liquidez.
Ataques Resultantes de Oráculos Manipulados
Em algumas implementações de tokens, o preço de um par de tokens é determinado por grandes exchanges ou oráculos descentralizados que atuam como referências de preço. Os ataques podem ocorrer quando esses oráculos são manipulados.
Evento de ataque do SELLC
O SELLC tem dois contratos de pool de liquidez: USDT/SELLC e USDT/WBNB, bem como um contrato de minerador. No contrato de minerador, a quantidade de tokens SELLC que um usuário deve receber é calculada com base no preço no pool SELLC/WBNB ou no pool USDT/SELLC.
No entanto, devido à baixa liquidez no pool do USDT, um invasor se aproveitou disso e manipulou o preço dos tokens SELLC no pool do USDT/SELLC. Como resultado, o invasor conseguiu reduzir o preço dos tokens SELLC, adquirir mais tokens SELLC por meio do contrato de mineração e, em seguida, restaurar o preço do token SELLC/USDT ou trocar tokens SELLC por WBNB no pool SELLC/WBNB para obter lucro.
O principal motivo desse ataque (conforme documentado neste evento de ataque) foi a baixa liquidez do par de tokens SELLC/USDT, que foi usado como oráculo de preço no contrato do minerador.
Boas Práticas de Segurança:
Ao usar outros pares de tokens ou contratos como oráculos, devem ser realizadas auditorias de segurança completas, e a comunicação transparente e periódica com usuários e desenvolvedores é essencial. Avalie e monitore regularmente a segurança dos contratos e resolva prontamente quaisquer vulnerabilidades ou riscos. Além disso, reduza o risco de pontos únicos de falha, diversificando entre vários pares de tokens ou oráculos.
Reentrância Read-Only (Somente Leitura)
Para ataques de vulnerabilidade causados por reentrância somente leitura, consulte nosso artigo, que fornece informações detalhadas sobre eventos de ataque e princípios de ataque relacionados.
Falhas nos Mecanismos de Recompensa
Falha por não considerar ataques de Empréstimos Relâmpagos em recompensas baseadas em volume**
Em alguns pares de tokens, os usuários podem ser recompensados com tokens com base no volume de fundos com os quais contribuem. No entanto, o time do projeto não considerou as características dos ataques de empréstimos relâmpagos ou as falhas no mecanismo de recompensa de token. Isso pode permitir que os invasores simulem transações com grandes fundos por meio de empréstimos relâmpagos e obtenham recompensas de tokens além das expectativas do time do projeto.
Evento de Ataque do SLOT
No SLOT, os usuários são recompensados com tokens SLOT com base na quantidade de fluxo que fornecem para o token SLOT e esse par de tokens foi adicionado ao pool de liquidez da PancakeSwap.
A intenção do time do projeto era incentivar mais usuários a comprar tokens SLOT por meio desse mecanismo. No entanto, devido a falhas de projeto no mecanismo de recompensa e à falta de consideração de que os invasores poderiam obter grandes quantidades de BNB por meio de empréstimos rápidos e trocá-los por SLOT, recompensas substanciais foram concedidas, resultando no roubo de ativos BNB do pool de tokens SLOT.
Neste evento de ataque, o principal motivo foi a consideração inadequada de usuários mal-intencionados que simulam transações por meio de empréstimos rápidos ao projetar o mecanismo de recompensa para o token SLOT.
Boas Práticas de Segurança:
Ao projetar mecanismos de recompensa, é fundamental considerar a possibilidade de usuários mal-intencionados tomarem emprestadas grandes quantidades de ativos para simular transações. Recomenda-se definir um limite máximo para o mecanismo de recompensa ou implementar espaços de tempo (não permitindo o cálculo e a distribuição de recompensas em uma única transação) para evitar ataques causados por empréstimos rápidos e métodos semelhantes.
Sobre nós
Na Eocene Research, fornecemos os insights de intenções e segurança por trás de tudo o que você sabe ou não sabe sobre blockchain e capacitamos cada indivíduo e organização a responder a perguntas complexas com as quais nem sequer sonhávamos naquela época.
Aprenda mais: [Website] | [Medium] | [Twitter]
Esse artigo foi escrito por Eocene | Security e traduzido por Fátima Lima. O original pode ser lido aqui.
Top comments (0)