Exploit de $17M em Contrato Inteligente Fechado: Vulnerabilidade de Chamada Arbitrária no SwapNet e Aperture Finance

Em 25 de janeiro de 2026, detectamos uma série de transações suspeitas direcionadas a contratos vítimas implantados pela SwapNet e Aperture Finance no Ethereum, Arbitrum, Base e BSC, com perdas totais superiores a $17 milhões. Em linhas gerais, a causa raiz de ambos os incidentes é direta e já foi descrita em nossos alertas iniciais [1, 2]: os contratos vítimas expõem uma capacidade de chamada arbitrária devido à validação insuficiente de entradas, permitindo que atacantes abusem de aprovações de tokens existentes e invoquem transferFrom para drenar ativos.

No entanto, ambos os conjuntos de contratos vítimas são de código fechado e, uma vez descompilados, expandem-se para milhares de linhas de código com lógica de ramificação profundamente aninhada e complexa, aumentando significativamente a dificuldade de análise. Além disso, os post-mortems subsequentes divulgados pelos projetos afetados [3, 4] focaram principalmente em remediação e recuperação, com discussão limitada sobre os detalhes técnicos subjacentes. Como resultado, várias questões importantes permanecem sem resposta, incluindo como os caminhos de chamada vulneráveis foram construídos e por que as verificações existentes falharam em impedir a exploração.

Neste relatório, fornecemos uma análise técnica mais detalhada com base no bytecode descompilado e nos rastros de execução on-chain. Embora a falta de código-fonte limite a visibilidade, a análise em nível de bytecode é suficiente para reconstruir a lógica vulnerável e revela diversas observações interessantes sobre o design do contrato que não são imediatamente aparentes nos alertas de alto nível.

Começamos com uma análise aprofundada do incidente da SwapNet, seguida de uma análise detalhada do incidente da Aperture Finance.

Incidente da SwapNet

Contexto

SwapNet [5] é um agregador de DEX projetado para encontrar rotas de swap otimizadas, agregando liquidez de múltiplas fontes on-chain, incluindo AMMs e formadores de mercado privados. O protocolo também permite que os usuários especifiquem roteadores ou pools personalizados ao executar swaps, oferecendo flexibilidade adicional.

Análise da Causa Raiz

Este incidente decorre da validação insuficiente de entradas fornecidas pelo usuário, o que permite que um atacante acione chamadas transferFrom() com parâmetros arbitrários. Como resultado, ativos que haviam sido previamente aprovados para os contratos vítimas (ex.: 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e) puderam ser transferidos para o atacante.

Com base no bytecode descompilado, a função 0x87395540() aparentemente carece de validação adequada em entradas críticas. Ao substituir o endereço esperado do roteador ou pool por um endereço de token (ex.: USDC), o contrato trata incorretamente o token como um alvo de execução válido. Isso leva à execução de uma chamada de baixo nível com calldata controlado pelo atacante.

Consequentemente, o contrato vítima realiza chamadas no formato: approvedAsset.transferFrom(victim, attacker, amount), permitindo que o atacante esvazie todos os ativos aprovados.

Fluxo do Ataque

Múltiplos ataques foram observados contra a SwapNet. Aqui utilizamos a transação Base 0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57 como exemplo.

O atacante simplesmente invocou a função 0x87395540() do contrato vítima com entradas maliciosas. Essa invocação consiste em duas etapas principais.

1. Uma variável interna chave (ex.: v51) foi definida como USDC, contornando a lógica de roteamento pretendida.

2. Uma chamada de baixo nível foi executada usando calldata controlado pelo atacante, resultando na invocação de USDC.transferFrom() e no esvaziamento de todo o USDC aprovado.

Resumo de Perdas, Transações e Contratos Afetados

O incidente da SwapNet causou uma perda estimada de ~$13,41M em múltiplas redes. As tabelas abaixo resumem as principais transações de exploração e os endereços dos contratos vítimas envolvidos.

Incidente da Aperture Finance

Contexto

Aperture Finance [6] é um protocolo DeFi que gerencia posições de liquidez concentrada, como LPs do Uniswap V3, em nome dos usuários. Seus contratos de código fechado (ex.: 0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913) permitem que os usuários criem e gerenciem posições no Uniswap V3 usando tokens nativos.

Fluxo de Trabalho Pretendido para Criação de Posições UniswapV3

Ao criar posições no Uniswap V3 via função 0x67b34120(), o contrato segue um fluxo de trabalho pretendido de três etapas:

1. Converter tokens nativos em WETH (wrap)

2. Fazer swap de tokens nativos via função interna 0x1d33()

3. Criar posições no UniswapV3

O problema surge na Etapa 2: 0x1d33() realiza um swap personalizado por meio de uma chamada de baixo nível, onde parâmetros críticos (ex.: o alvo da chamada e o calldata) parecem ser controlados pelo usuário e insuficientemente validados, permitindo chamadas externas não intencionais. Mais detalhes são fornecidos nas seções seguintes.

Análise da Causa Raiz

Semelhante ao caso da SwapNet, o incidente da Aperture Finance é causado pela validação insuficiente de entradas em chamadas de baixo nível. Quando 0x67b34120() é invocado, a função interna 0x1d33() executa uma chamada de baixo nível usando calldata fornecido pelo usuário, sem aplicar restrições rigorosas ao alvo da chamada ou ao seletor de função.

Conforme mostrado na figura abaixo, o calldata utilizado para acionar a chamada de baixo nível é baseado inteiramente nas entradas do atacante.

Isso permite que os atacantes construam calldata malicioso que resulta em: approvedToken.transferFrom(victim, attacker, amount) executado no contexto do contrato vítima. Como resultado, não apenas tokens ERC20, mas também NFTs de posição do Uniswap V3 aprovados podem ser drenados.

Fluxo do Ataque

Múltiplos ataques foram observados contra a Aperture Finance. Nesta seção, utilizamos a transação Ethereum 0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a como exemplo representativo.

1. O atacante criou um contrato de ataque 0x5c92884dFE0795db5ee095E68414d6aaBf398130.

2. O contrato de ataque invocou a função 0x67b34120() com entradas maliciosas e 100 wei de ETH (ou seja, msg.value == 100).

• a) Os ETHs nativos foram convertidos em WETHs via a função WETH.deposit().

• b) A função interna 0x1d33() foi invocada para realizar uma chamada de baixo nível. Nesta etapa, uma chamada de WBTC.transferFrom(victim, attacker, amount) é invocada no contexto do contrato vítima, permitindo que o atacante esvazie os tokens aprovados. Vale notar que uma verificação de saldo foi aprovada ao final da função 0x1d33(). Especificamente, a função 0x1d33() comparou as variações de saldo com um valor de saída de swap (ou seja, varg2.word2) também especificado pelo atacante. Como resultado, foram executadas com sucesso sem receber nada.

3. Por fim, a função NonfungiblePositionManager.mint() foi invocada para criar uma posição para o atacante usando 100 wei de WETH.

Descobertas Interessantes

Ao comparar transações de criação normais e anômalas, observamos que ambas aprovaram tokens para o mesmo gastador (ex.: OKX DEX: TokenApprove), mas especificaram endereços de roteador diferentes (ou seja, DexRouter e WBTC). Isso sugere que o contrato pode aplicar validação no gastador de aprovação, mas falhar em validar o alvo de execução real, deixando uma lacuna crítica explorável via chamadas arbitrárias.

Transação normal: https://app.blocksec.com/phalcon/explorer/tx/eth/0xc823b703c716fa9078e1d71714b734557bd540ddd1e41590dd73da7c5aba0200

Transação anômala: https://app.blocksec.com/phalcon/explorer/tx/eth/0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a

Resumo de Perdas, Transações e Contratos Afetados

O incidente da Aperture Finance resultou em uma perda total estimada de ~$3,67M em múltiplas redes. As tabelas abaixo resumem as principais transações de exploração e os endereços dos contratos vítimas associados.

Conclusão

Embora os incidentes da SwapNet e da Aperture Finance tenham afetado protocolos e redes diferentes, o problema subjacente em ambos os casos não é complexo: chamadas de baixo nível controladas pelo usuário combinadas com validação insuficiente de entradas em contratos que detêm aprovações de tokens. Esses incidentes servem como um lembrete de que a flexibilidade no design de contratos deve ser cuidadosamente equilibrada com restrições rígidas de chamada, especialmente em sistemas de código fechado onde a revisão externa é limitada.

Referências

[1] https://x.com/Phalcon_xyz/status/2015614087443697738

[2] https://x.com/Phalcon_xyz/status/2015624519898234997

[3] https://meta.matcha.xyz/SwapNet-Incident-Post-Mortem

[4] https://x.com/ApertureFinance/status/2015938720453820752

[5] https://x.com/0xswapnet

[6] https://x.com/ApertureFinance

Sobre a BlockSec

A BlockSec é uma provedora completa de segurança em blockchain e conformidade para criptoativos. 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 sobre 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