~$15,9M Perdidos: Trusted Volumes, Wasabi e Mais | BlockSec Semanal

Durante as últimas duas semanas (2026/04/27 - 2026/05/10), a BlockSec identificou múltiplos incidentes de ataque em vários ecossistemas de blockchain. A tabela abaixo lista 11 incidentes notáveis com perdas totais estimadas em aproximadamente $15,9M.

Três incidentes foram selecionados para análise aprofundada com base na novidade do ataque, impacto financeiro e implicações de segurança:

• Aftermath Finance: uma exploração no mundo real em uma DEX de futuros perpétuos, onde uma sutil incompatibilidade semântica entre valores com sinal/sem sinal na validação de taxas levou à drenagem completa dos fundos do protocolo.
• Trusted Volumes: impacto financeiro significativo (~$5,87M) e uma demonstração clara de incompatibilidade de autorização na lógica de liquidação RFQ.
• Wasabi Protocol: um comprometimento de infraestrutura para controle de contratos, uma classe de ataque cada vez mais comum, porém sub-representada nos escopos de auditoria.

Destaque da Semana: Aftermath Finance

Este incidente está em destaque porque a incompatibilidade semântica entre valores com sinal/sem sinal é uma classe de vulnerabilidade sutil que vai além de qualquer protocolo individual. Qualquer protocolo DeFi que utilize uma biblioteca de ponto fixo com sinal para validar valores de taxa ou preço sem sinal é suscetível ao mesmo padrão de ataque, tornando esta exploração amplamente instrutiva tanto para desenvolvedores quanto para auditores.

Em 29 de abril de 2026, o Aftermath Perpetuals, uma exchange de futuros perpétuos on-chain na Sui, foi explorado por aproximadamente $1,14M em USDC [1]. A causa raiz foi uma incompatibilidade semântica entre valores com sinal/sem sinal na validação de taxa do construtor do protocolo: a função de comparação de taxa realizava aritmética com sinal sobre valores sem sinal, permitindo que um atacante submetesse um valor de taxa que parecia negativo sob interpretação com sinal. Durante a liquidação, a taxa negativa foi convertida em um crédito positivo de garantia, permitindo que o atacante sacasse fundos inflados do cofre do protocolo.

Contexto

O Aftermath Perpetuals é uma exchange de futuros perpétuos on-chain na Sui [2]. O protocolo permite que integradores externos ganhem taxas de negociação ao construir interfaces de front-end. Cada integrador define uma taxa (taker_fee) que é cobrada dos traders que utilizam sua interface [3]. Como salvaguarda, os traders podem aprovar integradores configurando um limite de taxa predefinido (maxTakerFee) que limita o quanto um integrador pode cobrar.

Ao executar uma ordem de mercado, o protocolo primeiro compara taker_fee com maxTakerFee para garantir que a taxa permaneça dentro do limite aprovado pelo trader, depois deduz a taxa calculada da garantia do tomador e a credita nos registros do integrador.

A aritmética do protocolo é construída sobre uma biblioteca de ponto fixo com sinal (ifixed), que representa valores como inteiros u256, mas os interpreta sob semântica de complemento de dois para operações de comparação e aritméticas.

Análise de Vulnerabilidade

Os contratos com falha incluem o módulo de interface (0x9e2080...25d136) e o módulo de câmara de compensação (0x21d001...7c5068).

A vulnerabilidade está na função calculate_taker_fees(), que usa ifixed::less_than_eq() para comparar a taker_fee do integrador com a maxTakerFee do trader:

assert!(
    ifixed::less_than_eq(
        v5.taker_fee,
        account::get_integrator_max_taker_fee(
            account::get_integrator_config(arg1, v5.integrator_address)
        )
    ),
    errors::invalid_integrator_taker_fee()
);

Tanto taker_fee quanto maxTakerFee são semanticamente taxas não negativas. No entanto, ifixed::less_than_eq() realiza uma comparação com sinal sobre u256. Quando maxTakerFee é definido como 0, um valor como 2^256 - 10^16 é interpretado sob semântica com sinal como -10^16. Como -10^16 <= 0 é verdadeiro, a verificação é aprovada.

O caminho de exploração é ainda mais exposto porque create_integrator_info() é publicamente chamável e não impõe nenhuma permissão ou validação de limite de taxa sobre a taker_fee fornecida:

public fun create_integrator_info(arg0: address, arg1: u256): Option<IntegratorInfo> {
    let v0 = IntegratorInfo {
        integrator_address : arg0,
        taker_fee          : arg1,
    };
    option::some<IntegratorInfo>(v0)
}

A taxa negativa não é meramente aceita; ela é transformada em um crédito positivo direto de garantia durante a liquidação. No caminho de liquidação, a garantia é atualizada como collateral += pnl - taker_fee - builder_fee. Quando builder_fee é negativo, subtraí-lo equivale a uma adição:

position::add_to_collateral_usd(
    arg0,
    ifixed::sub(v6, ifixed::add(v7, v8)),
    arg2
);

Nem a validação de taxa nem a aritmética de liquidação impõem que os valores de taxa devem ser não negativos, de modo que as duas verificações ausentes se combinam: a comparação com sinal permite que o valor negativo entre, e a aritmética com sinal o converte em um crédito de garantia.

Análise do Ataque

A análise a seguir é baseada na transação 4pGQdf...wVD8.

• Passo 1: O atacante dividiu 100e6 USDC em duas contas perpétuas novas, 1227 e 1228. Isso criou contextos isolados para que o atacante pudesse atuar tanto como criador (conta 1227) quanto como tomador (conta 1228).

• Passo 2: O atacante depositou 100e6 USDC como garantia na conta 1227 e abriu uma posição de mercado, estabelecendo uma contraparte para a próxima ordem do tomador.

• Passo 3: O atacante criou um cofre de integrador e adicionou uma configuração à conta 1228 com maxTakerFee = 0. Definir o limite como zero foi essencial: fez com que a comparação com sinal taker_fee <= 0 aceitasse qualquer valor que pareça negativo sob complemento de dois.

• Passo 4: O atacante iniciou uma sessão da conta 1227 e publicou uma ordem limitada com order_size = 100e6, fornecendo a liquidez contra a qual a conta 1228 negociaria.

• Passo 5: O atacante invocou create_integrator_info() com taker_fee = 2^256 - 100e6, um valor que representa -100e6 sob semântica ifixed com sinal. Como a função é pública e não realiza nenhuma validação, a chamada foi bem-sucedida.

• Passo 6: O atacante executou uma ordem de mercado da conta 1228 usando as informações maliciosas do integrador. A comparação de taxa com sinal passou (-100e6 <= 0), e durante a liquidação a taxa negativa foi subtraída da garantia, efetivamente adicionando 100e6 em garantia gratuita à conta 1228.

• Passo 7: O atacante desalocou e retirou a garantia inflada da conta 1228, obtendo 79.610 USDC. O atacante repetiu esse padrão em várias transações para acumular aproximadamente $1,14M no total.

Conclusão

Este incidente foi causado por uma incompatibilidade semântica entre valores com sinal/sem sinal na validação de taxa do construtor do Aftermath Perpetuals. O problema central é que a função de comparação de taxa (ifixed::less_than_eq) interpreta valores de taxa sem sinal sob semântica com sinal. Quando combinado com uma função de definição de taxa publicamente chamável que não realiza validação de limite, um atacante pode injetar um valor que passa na comparação com sinal como "negativo" e é então convertido em crédito de garantia durante a liquidação.

O padrão mais amplo merece atenção: qualquer protocolo que use uma biblioteca de ponto fixo com sinal para validar valores inerentemente não negativos (taxas, preços, quantias) é vulnerável à mesma classe de ataque. As mitigações devem incluir: (1) garantir que os valores de taxa sejam não negativos antes de qualquer comparação (assert!(taker_fee >= 0)), (2) restringir create_integrator_info() a chamadores autorizados, e (3) usar funções de comparação sem sinal para valores que são semanticamente sem sinal.

Referências

• [1] Declaração Pós-Incidente da Aftermath Finance
• [2] Documentação do Aftermath Perpetuals
• [3] Códigos de Construtor / Taxa de Front-End

Mais Incidentes Neste Período

Trusted Volumes

Em 7 de maio de 2026, um contrato proxy RFQ (Request-For-Quote) personalizado na Ethereum foi explorado, drenando aproximadamente $5,87M do formador de mercado TrustedVolumes. A causa raiz foi uma incompatibilidade de autorização na função de preenchimento de ordens do contrato de implementação RFQ: a pesquisa de permissão do assinante e a operação de transferência de tokens referenciavam campos diferentes da ordem, de modo que a verificação de autorização passou para um endereço enquanto os fundos foram debitados de outro. O atacante drenou aproximadamente 1.291 WETH, 206K USDT, 16,94 WBTC e 1,27M USDC.

Contexto

A TrustedVolumes atua como formadora de mercado no protocolo RFQ implantado na Ethereum. Os formadores de mercado geram continuamente cotações de preço assinadas fora da cadeia; os tomadores (tipicamente traders ou roteadores agregadores) submetem uma cotação escolhida on-chain, e o contrato do protocolo verifica a assinatura e liquida atomicamente a negociação movendo tokens entre o criador e o tomador através de transferFrom. O protocolo segue um design sem cofre: nunca custodia fundos. Cada criador pré-concede ao contrato do protocolo uma permissão ERC-20 para cada token que pretende cotar, e o protocolo puxa os tokens diretamente da carteira do criador no momento do preenchimento.

Para permitir que os criadores deleguem a operação de assinatura a uma carteira quente, o contrato do protocolo mantém um registro de assinantes por criador. Um criador pode chamar registerAllowedOrderSigner(signer, allowed) para incluir uma chave quente na lista de permissões, e qualquer ordem subsequente assinada por essa chave é honrada como se tivesse sido assinada pelo criador.

Análise de Vulnerabilidade

O contrato proxy RFQ está implantado em 0xeEeEEe...051756, e o contrato de implementação está em 0x88eb28...2760d8.

A função de preenchimento de ordens 0x4112e1c2() no contrato de implementação RFQ recupera o assinante via ecrecover() e verifica o mapeamento allowedOrderSigner para decidir se aceita a assinatura. A chave de pesquisa para essa verificação é varg4, o endereço do lado do tomador da ordem. No entanto, o transferFrom subsequente que debita os fundos usa varg5, o campo do criador da ordem. Como varg4 e varg5 são campos independentes da estrutura da ordem, a verificação de autorização e a operação de fluxo de fundos referenciam entidades diferentes. Nenhuma verificação impõe que o domínio do assinante autorizado corresponda ao endereço do qual os tokens são efetivamente retirados.

A função registerAllowedOrderSigner escreve a lista de permissões usando msg.sender como chave externa, enquanto o caminho de preenchimento lê usando varg4 como chave externa. Contanto que o chamador em varg4 tenha previamente se registrado via registerAllowedOrderSigner, a verificação de autorização é aprovada independentemente do endereço do criador de terceiros que aparece em varg5.

Análise do Ataque

A análise a seguir é baseada na transação 0xc5c61b...990513.

• Passo 1: O atacante implantou um contrato de ataque e chamou registerAllowedOrderSigner através dele, registrando o EOA do atacante na lista de permissões de assinantes. Isso garantiu que as ordens assinadas pelo atacante passassem na verificação de autorização de assinante do protocolo.

• Passo 2: O contrato de ataque retirou 4 wei de USDC do EOA do atacante e aprovou 4 wei para o protocolo RFQ, equipando o contrato de ataque com a consideração mínima necessária para atuar como tomador.

• Passo 3: O atacante forjou quatro ordens, cada uma assinada pelo EOA do atacante e nomeando a TrustedVolumes como criadora. Como a verificação do assinante consultou varg4 (o contrato do atacante) enquanto transferFrom debitou varg5 (TrustedVolumes), cada ordem drenou fundos da TrustedVolumes. As quatro ordens trocaram 1 wei de USDC por 1.291 WETH, 206.282 USDT, 16,939 WBTC e 1.268.771 USDC respectivamente, totalizando um lucro de aproximadamente $5,87M.

Conclusão

O defeito central é uma incompatibilidade de autorização na função de preenchimento de ordens: o endereço usado para a verificação de permissão do assinante difere do endereço que efetivamente paga. Especificamente, registerAllowedOrderSigner escreve a lista de permissões sob msg.sender, o caminho de preenchimento lê sob o campo do tomador (varg4), e transferFrom debita do campo do criador (varg5). Como essas três operações referenciam entidades diferentes, qualquer atacante que registre seu próprio assinante pode forjar ordens que drenam um criador terceiro. As verificações de autorização que controlam a movimentação de ativos devem ser vinculadas ao endereço que efetivamente pagará, e os caminhos de escrita e leitura devem usar a mesma chave.

Wasabi Protocol

Em 30 de abril de 2026, o Wasabi Protocol, um protocolo de opções e futuros perpétuos implantado em múltiplas cadeias EVM, sofreu um incidente de segurança resultando em aproximadamente $5,7M em perdas ($4,8M em fundos de usuários, $900K do tesouro Wasabi) [1][2]. O ataque originou-se de um comprometimento de infraestrutura: um endpoint de análise exposto em um servidor público vazou credenciais que eventualmente levaram ao roubo de chaves privadas que controlavam os contratos inteligentes EVM do protocolo. Usando essas chaves, o atacante executou saques não autorizados de múltiplos cofres Wasabi na Ethereum, Base, Blast e Berachain.

Contexto

O Wasabi Protocol opera implantações em cadeias EVM (Ethereum, Base, Blast, Berachain) e Solana. Este incidente foi limitado ao lado EVM do protocolo; as implantações na Solana e o Prop AMM não foram afetados.

Os contratos EVM da Wasabi (WasabiLongPool, WasabiShortPool, WasabiVault) são administrados via chaves privilegiadas. O protocolo também executa infraestrutura off-chain incluindo serviços de análise e monitoramento construídos no Spring Boot.

Análise do Ataque

O incidente seguiu uma cadeia de comprometimento de infraestrutura para controle de contrato:

• Passo 1: O atacante descobriu que o Spring Boot Actuator estava instalado em um servidor Wasabi voltado ao público. Os dumps de heap do Actuator normalmente são protegidos por senha, mas este servidor usava uma variante diferente do framework Spring que era incompatível com o mecanismo padrão de proteção por senha, deixando o endpoint de dump de heap exposto.

• Passo 2: O atacante recuperou o dump de heap, que continha credenciais para um servidor interno separado.

• Passo 3: Usando as credenciais vazadas, o atacante pivotou para o servidor interno e obteve chaves privadas que controlavam os contratos inteligentes EVM da Wasabi.

• Passo 4: Com as chaves privilegiadas em mãos, o atacante executou fluxos de saque não autorizados contra os contratos WasabiLongPool, WasabiShortPool e WasabiVault na Ethereum, Base, Blast e Berachain, drenando aproximadamente $5,7M no total.

Conclusão

Este incidente demonstra que a segurança de contratos inteligentes não termina no nível do código. O exploit não exigiu nenhuma vulnerabilidade on-chain; o atacante obteve controle puramente por meio de exposição de infraestrutura. As principais lições são: (1) superfícies de depuração e análise (dumps de heap, endpoints de perfil, exportadores de log) nunca devem ser acessíveis em infraestrutura pública, (2) credenciais para sistemas de produção devem ser estritamente segregadas dos ambientes de análise e monitoramento, e (3) chaves de administração de contratos inteligentes devem ser protegidas com controles de defesa em profundidade incluindo custódia multisig, assinatura com suporte de hardware, separação de funções, monitoramento em tempo real e procedimentos de pausa de emergência.

Referências

• [1] Alerta BlockSec Phalcon
• [2] Declaração Pós-Incidente do Wasabi Protocol

Sobre a BlockSec

A BlockSec é uma provedora completa de segurança em blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam nossos clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e cumprir obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou múltiplos artigos de segurança em blockchain em conferências de prestígio, reportou vários ataques zero-day em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares e protegeu bilhões em criptomoedas.

• Site oficial: https://blocksec.com/

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

• 🔗 Serviço de Auditoria BlockSec : Enviar uma solicitação

• 🔗 Phalcon Security APP: Agendar uma demonstração

• 🔗 Phalcon Compliance