#10: Incidente ThirdWeb: Incompatibilidade Entre Módulos Confiáveis Expõe Vulnerabilidade

Em 5 de dezembro de 2023, a proeminente plataforma de desenvolvimento Web3 Thirdweb divulgou vulnerabilidades significativas de segurança em contratos inteligentes que afetavam seus contratos pré-construídos. Essa falha crítica impactou todos os tokens ERC-20, ERC-721 e ERC-1155 implantados usando esses contratos vulneráveis específicos. Nos dias seguintes à divulgação, os tokens implantados com esses contratos vulneráveis foram progressivamente explorados em uma série de ataques, ressaltando a gravidade da incompatibilidade subjacente.

Entendendo a Vulnerabilidade dos Contratos Inteligentes da ThirdWeb

A causa raiz do incidente da ThirdWeb está na interação inesperada entre dois componentes fundamentais do desenvolvimento de contratos inteligentes: ERC-2771 e a implementação de Multicall da OpenZeppelin. Para compreender totalmente a vulnerabilidade, é essencial entender cada componente individualmente e, em seguida, como a interação entre eles criou um caminho explorável.

ERC-2771: Meta-Transações e Forwarders Confiáveis

EIP-2771 define um protocolo em nível de contrato que permite que contratos Recipient aceitem meta-transações por meio de contratos Forwarder confiáveis. Esse padrão é essencial para melhorar a experiência do usuário, permitindo que terceiros (forwarders) paguem taxas de gás em nome dos usuários, abstraindo a necessidade de os usuários possuírem tokens nativos da blockchain.

Na prática, o ERC2771Context da OpenZeppelin é uma implementação amplamente adotada. Sua funcionalidade principal envolve tratar os últimos 20 bytes do calldata de um forwarder confiável como o _msgSender() efetivo. Para os desenvolvedores que usam essa biblioteca, a prática comum é substituir todos os usos diretos de msg.sender por _msgSender() para garantir compatibilidade com meta-transações. Da mesma forma, _msgData() é usado para recuperar os dados originais da transação, excluindo as informações do remetente anexadas.

function _msgSender() internal view virtual override returns (address) {
    uint256 calldataLength = msg.data.length;
    uint256 contextSuffixLength = _contextSuffixLength();
    if (isTrustedForwarder(msg.sender) && calldataLength >= contextSuffixLength) {
        return address(bytes20(msg.data[calldataLength - contextSuffixLength:]));
    } else {
        return super._msgSender();
    }
}

function _msgData() internal view virtual override returns (bytes calldata) {
    uint256 calldataLength = msg.data.length;
    uint256 contextSuffixLength = _contextSuffixLength();
    if (isTrustedForwarder(msg.sender) && calldataLength >= contextSuffixLength) {
        return msg.data[:calldataLength - contextSuffixLength];
    } else {
        return super._msgData();
    }
}

Multicall: Agrupamento de Transações para Eficiência

A funcionalidade Multicall permite que os usuários agrupem múltiplas chamadas de função em uma única transação, reduzindo significativamente os custos de gás e melhorando a eficiência das transações. O MulticallUpgradeable da OpenZeppelin é uma implementação popular para essa finalidade. Ele recebe um array de bytes de calldata e realiza um delegatecall para cada entrada, executando-os dentro do contexto do contrato chamador.

function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results) {
    results = new bytes[](data.length);
    for (uint256 i = 0; i < data.length; i++) {
        results[i] = _functionDelegateCall(address(this), data[i]);
    }
    return results;
}

(Nota: O bug discutido aqui foi corrigido em versões posteriores do Multicall da OpenZeppelin.)

A Incompatibilidade: Conflito entre ERC-2771 e Multicall

O núcleo da vulnerabilidade dos contratos inteligentes do incidente da ThirdWeb emergiu de uma inconsistência crítica na forma como o calldata é processado pelo ERC-2771 e pelo Multicall. O ERC-2771 espera que o forwarder confiável empacote os dados da mensagem e as informações do remetente juntos. O contrato destinatário então usa _msgData() e _msgSender() para desempacotar corretamente essas informações.

No entanto, a função Multicall, em sua implementação vulnerável, não foi projetada para ser compatível com a forma como o ERC-2771 empacota dados para meta-transações. Especificamente, quando o Multicall processa um lote de chamadas, ele deveria ter extraído corretamente o _msgSender() da meta-transação inicial e então anexado essas informações do remetente ao calldata de cada chamada individual antes de executá-las. Essa etapa crucial estava ausente.

Sem as informações do remetente sendo corretamente anexadas ao calldata dentro de cada sub-chamada processada pelo Multicall, o contexto ERC-2771 dentro do contrato alvo tentaria desempacotar as informações do remetente a partir dos últimos 20 bytes do _msgData() da sub-chamada. Crucialmente, um atacante poderia controlar esses últimos 20 bytes. Isso permitiu que um agente malicioso criasse calldata específico que, quando processado pelo Multicall e então interpretado por um contrato habilitado para ERC-2771, executaria lógica arbitrária com um valor _msgSender() manipulado (por exemplo, um endereço controlado pelo atacante ou até mesmo o endereço do pool de um protocolo). Isso efetivamente contornou as verificações de segurança pretendidas e violou as expectativas estabelecidas por ambas as especificações, levando a ações não autorizadas.

Incidente ThirdWeb: Análise e Exploração do Ataque

Vamos examinar um exemplo real da exploração da vulnerabilidade dos contratos inteligentes do incidente da ThirdWeb, usando uma transação de ataque analisada pela plataforma Phalcon da BlockSec.

A estratégia do atacante envolveu manipular o _msgSender() para se passar por um pool Uniswap, drenando assim seu saldo de tokens.

• Passo 1: Aquisição Inicial de Tokens. O atacante começou trocando 5 WETH por 3.455.399.346 tokens TIME em uma exchange descentralizada. Isso forneceu os tokens necessários para a manipulação subsequente.

• Passo 2: Execução Maliciosa do Multicall. Este é o núcleo da exploração. O atacante invocou um forwarder confiável com calldata cuidadosamente elaborado para explorar a incompatibilidade ERC-2771/Multicall. Quando esse calldata foi analisado pela função Multicall, resultou na chamada da função burn do contrato de token TIME. Crucialmente, devido à vulnerabilidade, o _msgSender() foi incorretamente interpretado como o endereço do Pool Uniswap. Isso permitiu ao atacante efetivamente queimar uma parcela significativa dos tokens TIME mantidos pelo pool Uniswap, sem autorização real. A plataforma Phalcon da BlockSec fornece rastreamento detalhado de transações para visualizar esse fluxo.

  

  A imagem acima ilustra como a chamada Forwarder.execute do atacante é processada. A função multicall recebe um array de bytes, que então leva à chamada da função burn com o _msgSender() manipulado.

  

  Esta visão detalhada do Phalcon mostra o bytes[] de comprimento 1 sendo usado como dados para chamar o contrato, levando à execução da função burn sob o falso _msgSender().

• Passo 3: Manipulação de Preço. Ao queimar uma grande quantidade de tokens TIME do pool Uniswap, o atacante reduziu drasticamente a liquidez do pool para TIME. Essa escassez artificial fez com que o preço de TIME em relação ao WETH disparasse dentro do pool.

• Passo 4: Arbitragem Lucrativa. Com o preço de TIME artificialmente inflacionado, o atacante então trocou seus 3.455.399.346 tokens TIME restantes de volta por 94 WETH, obtendo um lucro substancial com o preço manipulado.

Essa sequência de eventos demonstra um ataque sofisticado que aproveita uma sutil vulnerabilidade de contrato inteligente decorrente de incompatibilidade entre módulos.