A Análise do Incidente de Segurança do FEGtoken: O Diabo Está nos Detalhes

Em 15 de maio de 2022, por volta das 20h20 (UTC), nosso sistema de monitoramento detectou que o contrato FEGexPRO do projeto FEGtoken foi hackeado. O atacante lançou uma série de ataques nas mainnets ETH e BSC, e o valor total envolvido acumulou cerca de $1,3 milhão (de acordo com a mensagem on-chain enviada pelo projeto).

Mais informações sobre este incidente podem ser encontradas no twitter oficial do projeto. Neste relatório, vamos nos aprofundar nos detalhes para revelar a causa raiz deste incidente.

0x1 Análise de Vulnerabilidade: À Primeira Vista

O contrato vulnerável FEGexPRO está implantado tanto na ETH quanto na BSC, e a função vulnerável do contrato é swapToSwap, como segue:

Como foi apontado nas redes sociais, o primeiro parâmetro chamado path da função swapToSwap pode ser especificado pelo chamador da função. Dessa forma, o atacante poderia explorá-lo para realizar uma aprovação arbitrária (veja a linha 682 da função swapToSwap).

Até aqui nada é novo, pois é mais um caso de parâmetro(s) não verificado(s). No entanto, o rastro do ataque sugere que este ataque não pode ser claramente ilustrado simplesmente atribuindo-o à aprovação arbitrária. De fato, existe um truque sutil, e é aqui que as coisas ficam interessantes.

0x2 Análise do Ataque

0x2.1 Análise Preliminar do Ataque

Tomamos uma transação de ataque na BSC como exemplo para ilustrar o procedimento do ataque, e o rastro do ataque correspondente, que tem como alvo o ativo fBNB, é resumido brevemente como segue:

• Passo 1: preparação de fundos e paths falsos. O atacante toma emprestado via flashloan cerca de 915 BNB do DVM e troca parte deles por 116 fBNB. O atacante então cria um conjunto de contratos que serão usados como paths falsos.
• Passo 2: depósito do fundo inicial. Ao depositar 115 fBNB no contrato FEGexPRO, o atacante aumenta seu balances2 no contrato vítima.
• Passo 3: realização da aprovação arbitrária. O atacante então invoca a função swapToSwap e passa um path falso como primeiro parâmetro, o que leva o contrato FEGexPRO a aprovar o path para gastar 114 fBNB.
• Passo 4: realizando outra aprovação ao invocar a função depositInternal e a função swapToSwap. O contrato FEGexPRO aprova outro path para gastar 114 fBNB.

O atacante lança repetidamente o Passo 4 para fazer mais aprovações. Por fim, o atacante usa os paths falsos aprovados para drenar todos os fBNB do FEGexPRO e troca parte deles por BNB para reembolsar o flashloan.

Obviamente, podemos facilmente concluir que o contrato absolutamente deveria ter verificado o parâmetro path.

PORÉM, para entender completamente este ataque, há mais uma questão a abordar: mesmo que o contrato FEGexPRO aprove o path falso, a operação approve é baseada no fato de que o balances2 do usuário seria diminuído imediatamente (linha 684 da função swapToSwap), ou seja, o fundo aprovado vem exatamente do valor depositado no Passo 3. Em outras palavras, o atacante simplesmente aprova os fundos que ele/ela próprio depositou para o path falso. Depois disso, o atacante não deveria conseguir fazer aprovações para outros paths falsos devido à diminuição do balances2.

Sendo assim, surge a questão: qual é exatamente o truque utilizado pelo atacante para fazer outras aprovações e obter lucro extra?

0x2.2 Análise Avançada do Ataque

Para responder à pergunta, devemos voltar à função swapToSwap. Após examinar cuidadosamente o código, descobrimos que o truque utilizado aqui não é apenas um path falso, mas também um swap falso, o que leva a uma inconsistência entre o valor real e o valor registrado do saldo do contrato vítima. Como resultado, a inconsistência pode ser usada para realizar aprovações repetidamente, restaurando o valor do depósito do atacante por meio da invocação da função depositInternal.

Especificamente, a função depositInternal modifica o balances2 de um usuário principalmente com base na diferença entre Main.balanceOf do contrato e _totalSupply2 (linha 651 da função depositInternal).

Como o endereço path passado para o swapToSwap é um path falso controlado pelo atacante, nada é realmente transferido para fora. Como consequência, o valor de retorno de Main.balanceOf permanece o mesmo que no Passo 3. Note que _totalSupply2 foi diminuído na função swapToSwap; assim que o atacante deposita, o balance2 aumentado será inevitavelmente maior do que o valor realmente depositado.

Portanto, no Passo 4, o atacante primeiro restaura o valor do depósito invocando a função depositInternal, e então realiza a aprovação e o swap falso invocando a função swapToSwap. Note que o valor de depósito usado pelo atacante é de quase 0 (ou seja, 1 / 1e18) fBNB, portanto a função depositInternal restauraria o balances2 do atacante para quase o mesmo valor do Passo 3, conforme explicado acima (o que também é demonstrado pelo rastro da próxima aprovação).

O atacante pode ampliar o ganho executando o Passo 4 repetidamente.

Por fim, vale notar que o ataque descrito acima é apenas um dos caminhos de ataque explorados pelo atacante. Apenas na mesma transação de ataque, o atacante também tem como alvo o ativo FEG:

0x3 A Causa Raiz

Aqui resumimos a causa raiz deste ataque:

• Primeiro, a aprovação arbitrária causada pelo parâmetro não verificado na função swapToSwap.
• Segundo, a inconsistência entre o valor real e o valor registrado do saldo do contrato vítima, devido ao swap falso na função swapToSwap. Isso é usado para realizar aprovações repetidamente, restaurando o valor do depósito do atacante.

Combinando-os, o atacante drenou com sucesso todos os fundos do contrato vítima.

0x4 Outros Ataques Relacionados

Até o momento da escrita, também observamos mais ataques relacionados lançados por outro atacante.

Novamente, contratos implantados tanto no Ethereum quanto na BSC foram atacados. Curiosamente, os rastros de ataque são diferentes do que acabamos de discutir. Embora os contratos vítimas não sejam de código aberto, suspeitamos fortemente que o atacante explorou a mesma vulnerabilidade com um método de ataque semelhante.

0x5 Lição

Tornar um projeto DeFi seguro não é uma tarefa fácil. Além da auditoria de código, acreditamos que a comunidade deve adotar um método proativo para monitorar o status do projeto e bloquear o ataque antes mesmo que ele aconteça.

Sobre a BlockSec

A BlockSec é uma empresa pioneira em segurança blockchain, fundada em 2021 por um grupo de especialistas em segurança de renome mundial. A empresa está comprometida em aprimorar a segurança e a usabilidade do emergente mundo Web3, a fim de facilitar sua adoção em massa. Para isso, a BlockSec oferece serviços de auditoria de segurança para contratos inteligentes e chains EVM, a plataforma Phalcon para desenvolvimento seguro e bloqueio proativo de ameaças, a plataforma MetaSleuth para rastreamento e investigação de fundos, e a extensão MetaDock para que desenvolvedores web3 naveguem com eficiência no mundo cripto.

Até o momento, a empresa atendeu mais de 300 clientes de prestígio, como MetaMask, Uniswap Foundation, Compound, Forta e PancakeSwap, e recebeu dezenas de milhões de dólares em duas rodadas de financiamento de investidores proeminentes, incluindo Matrix Partners, Vitalbridge Capital e Fenbushi Capital.

Site oficial: https://blocksec.com/

Conta oficial no Twitter: https://twitter.com/BlockSecTeam