Vulnerabilidades do Revest Finance: Mais do que Reentrada

Em 27 de março de 2022, o projeto DeFi de staking Revest Finance na Ethereum foi atacado devido ao mecanismo de call-back do ERC-1155, o que causou o roubo de tokens no valor de aproximadamente $2M (especificamente BLOCKS, ECO, LYXe e RENA). Analisamos o ataque em primeiro lugar e publicamos no Twitter nossa análise naquela noite (UTC+8).

Na verdade, no momento em que escrevemos o Twitter, ainda tínhamos algumas dúvidas sobre uma função no contrato TokenVault da Revest. Investigamos o contrato tentando entender sua funcionalidade. Posteriormente, descobrimos que se trata de outra vulnerabilidade crítica de dia zero, que pode ser explorada de uma forma muito mais simples e pode causar as mesmas enormes perdas (como o ataque que aconteceu).

Em seguida, contatamos imediatamente a equipe da Revest Finance, e eles responderam rapidamente e propuseram uma solução alternativa para a vulnerabilidade. Após confirmar que a vulnerabilidade não podia ser acionada, decidimos publicar este blog.

A seguir, este blog é composto por três partes: o mecanismo da Revest Finance, o ataque de re-entrância original e a nova vulnerabilidade de dia zero.

O que é o FNFT da Revest Finance

O Financial Non-Fungible Token (FNFT) da Revest Finance torna possível a transferência sem necessidade de confiança de direitos futuros sobre ativos bloqueados. O contrato de entrada (contrato Revest) fornece três interfaces diferentes para cunhar FNFTs bloqueando ativos subjacentes:

• mintTimeLock: o ativo subjacente será desbloqueado após um período de tempo.
• mintValueLock: o ativo subjacente será desbloqueado quando seu valor subir acima ou cair abaixo de um valor predeterminado.
• mintAddressLock: o ativo subjacente será desbloqueado por uma conta predeterminada.

O contrato Revest conecta os outros três contratos para bloquear e desbloquear ativos subjacentes.

• FNFTHandler: herdado do token ERC-1155. Ele cria um novo FNFT com o fnftId incremental para cada bloqueio. O bloqueio determina o fornecimento total do novo FNFT na criação. O FNFT não pode ser cunhado de nenhuma outra forma, mas pode ser queimado para desbloquear ativos subjacentes.

• LockManager: registra as condições de desbloqueio para cada bloqueio durante a criação e decide se o bloqueio pode ser desbloqueado no momento do desbloqueio.

• TokenVault: recebe e envia os ativos subjacentes e registra os metadados para cada FNFT, como o valor de um FNFT específico.

Usamos mintAddressLock como exemplo para ilustrar o processo de cunhagem de FNFTs.

As duas figuras acima descrevem como um FNFT é criado, cunhado e queimado. Especificamente, o usuário A bloqueia 100 WETH na Revest Finance, criando o FNFT correspondente com fnftId igual a 1. Por fim, ele cunha 100 1-FNFT para destinatários específicos com participações específicas.

Observe que, uma vez que o ativo subjacente é desbloqueado, cada 1-FNFT pode ser queimado para receber um (*1e18) WETH. Conforme mostrado na Figura 2, o usuário B retira 25 (* 1e18) WETH ao queimar 25 1-FNFT.

Além disso, o contrato Revest fornece outra interface, chamada depositAdditionalToFNFT, que apresenta duas vulnerabilidades que serão discutidas a seguir.

Primeiro usamos as duas figuras a seguir para descrever o uso normal dessa função.

A função depositAdditionalToFNFT bloqueia mais ativos subjacentes em um bloqueio existente (especificado por fnftId). Razoavelmente (Figura 3), ela exige que a quantidade especificada seja igual ao fornecimento total do FNFT especificado e, em seguida, distribui uniformemente os ativos adicionados a cada FNFT especificado.

Caso contrário (Figura 4), ela cria um novo bloqueio com o fnftId mais recente, queima as quantidades especificadas do FNFT antigo e cunha a quantidade especificada do novo FNFT, e então registra o depositAmount do novo bloqueio como a soma do depositAmount do bloqueio antigo e o valor especificado, conforme mostrado no código a seguir.

// Agora, transferimos para o cofre de tokens
if(fnft.asset != address(0)){
    IERC20(fnft.asset).safeTransferFrom(_msgSender(), vault, quantity * amount);
}

ITokenVault(vault).handleMultipleDeposits(fnftId, newFNFTId, fnft.depositAmount + amount);

emit FNFTAddionalDeposited(_msgSender(), newFNFTId, quantity, amount);

Como o depositAmount registrado no contrato TokenVault indica a quantidade do ativo subjacente que um FNFT específico pode retirar, essa operação transfere o valor das quantidades especificadas do FNFT antigo do bloqueio antigo para o novo bloqueio.

(A quantidade especificada maior que o fornecimento total reverterá a transação)

O que é a Vulnerabilidade de Re-entrância

Nesta parte, ilustraremos como o ataque de re-entrância funciona e discutiremos a causa raiz e o método de correção.

As três figuras acima descrevem basicamente todo o processo do ataque de re-entrância. Especificamente, o atacante primeiro bloqueia zero tokens RENA para cunhar 2 1-FNFT que não têm valor. Em seguida, o atacante bloqueia zero tokens RENA novamente, mas cunha 360.000 2-FNFT que também não têm valor (por enquanto). Durante a última etapa, o atacante re-entra na função depositAdditionalToFNFT do contrato Revest por meio do mecanismo de call-back do FNFTHandler herdado do padrão de token ERC-1155, o que sobrescreve o depositAmount do bloqueio com fnftId igual a 2 antes da atualização do fnftId. Como resultado, o atacante obtém 360.001 2-FNFT com depositAmount igual a 1e18, o que significa que ele pode retirar 360.001 * 1e18 RENA do contrato TokenVault. Além disso, o único custo é 1e18 RENA.

Método de Correção

Os códigos da Revest Finance estão completamente alinhados com o padrão clássico de re-entrância: usar fnftId -> chamada externa com mecanismo de callback -> atualizar fnftId. Portanto, a maneira mais direta de corrigir os problemas é quebrar esse padrão. O código corrigido é mostrado abaixo:

function mint(
    address account, 
    uint id, 
    uint amount, 
    bytes memory data
) external override onlyRevestController {
    require(amount > 0, "Invalid amount");
    require(supply[id] == 0, "Repeated mint for the same FNFT");
    supply[id] += amount;
    fnftsCreated += 1;
    _mint(account, id, amount, data);
}

Primeiro, ele move a operação de atualização para antes da chamada externa (_mint), o que pode evitar o ataque. Segundo, como o sistema não permite cunhar zero FNFT nem cunhar repetidamente o mesmo FNFT, ele adiciona duas verificações para garantir que o sistema funcione conforme esperado, o que pode melhorar a segurança do sistema.

A Nova Vulnerabilidade de Dia Zero

Ao analisar o código da Revest Finance, a função handleMultipleDeposits no contrato TokenVault sempre nos confundiu, cujo código é mostrado abaixo.

function handleMultipleDeposits(
    uint fnftId,
    uint newFNFTId,
    uint amount
) external override onlyRevestController {
    require(amount >= fnfts[fnftId].depositAmount, 'E003');
    IRevest.FNFTConfig storage config = fnfts[fnftId];
    config.depositAmount = amount;
    mapFNFTToToken(fnftId, config);
    if(newFNFTId != 0) {
        mapFNFTToToken(newFNFTId, config);
    }
}

Durante a chamada à função depositAdditionalToFNFT, a função handleMultipleDeposits altera o depositAmount do bloqueio antigo ou registra o do novo. Quando o newFNFTId é zero, ela não registra o depositAmount do novo bloqueio, pois esta é uma operação para adicionar ativos extras ao bloqueio existente.

De acordo com o senso comum, quando o newFNFTId não é zero, ela apenas registra o depositAmount do novo bloqueio, mas não altera o depositAmount do antigo. No entanto, o código nos mostra que ele não só registra o depositAmount do novo bloqueio, mas também altera o depositAmount do antigo.

Acreditamos que essa é uma séria vulnerabilidade lógica de dia zero e então escrevemos um PoC para verificá-la. As três figuras a seguir descrevem como o PoC funciona.

Especificamente, o atacante primeiro bloqueia zero RENA para cunhar 360.000 1-FNFT. Depois disso, o atacante invoca diretamente a função depositAdditionalToFNFT para criar um novo bloqueio. Devido ao bug lógico, o contrato TokenVault altera incorretamente o depositAmount do bloqueio antigo de zero para 1e18. Como resultado, o atacante obtém 359.999 1-FNFT no valor de 359.999 RENA. Obviamente, o PoC é muito mais simples do que o ataque de re-entrância real.

A Solução Alternativa para Corrigir a Vulnerabilidade

Este é um bug lógico, e recomendamos usar o seguinte código para corrigi-lo.

function handleMultipleDeposits(
    uint fnftId,
    uint newFNFTId,
    uint amount
) external override onlyRevestController {
    require(amount >= fnfts[fnftId].depositAmount, 'E003');
    IRevest.FNFTConfig memory config = fnfts[fnftId];
    config.depositAmount = amount;
    if(newFNFTId != 0) {
        mapFNFTToToken(newFNFTId, config);
    } else {
        mapFNFTToToken(fnftId, config);
    }
}

Como os dois contratos vulneráveis: TokenVault e FNFTHandler armazenam muitos estados críticos, o projeto não pode reimplantar o contrato TokenVault e o contrato FNFTHandler sem migrar os estados. Para evitar ataques futuros a essa vulnerabilidade, o projeto reimplantou uma versão simplificada do contrato Revest, que desativa funções mais complexas para reduzir as superfícies disponíveis a qualquer potencial atacante. Após verificar a solução alternativa, acreditamos que o contrato Revest simplificado pode mitigar os possíveis ataques mencionados neste blog.

Conclusã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 ocorra.

Sobre a BlockSec

A BlockSec é uma empresa pioneira em segurança blockchain estabelecida 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 para o emergente mundo Web3, a fim de facilitar sua adoção em massa. Para tanto, a BlockSec fornece serviços de auditoria de segurança de contratos inteligentes e cadeias EVM, a plataforma Phalcon para desenvolvimento de segurança e bloqueio proativo de ameaças, a plataforma MetaSleuth para rastreamento e investigação de fundos, e a extensão MetaDock para construtores web3 navegarem com eficiência no mundo cripto.

Até o momento, a empresa atendeu mais de 300 clientes ilustres, como MetaMask, Uniswap Foundation, Compound, Forta e PancakeSwap, e recebeu dezenas de milhões de dólares americanos 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