Em 22 de maio de 2025, o Cetus Protocol, a maior DEX de liquidez concentrada na Sui, sofreu um exploit catastrófico que drenou a liquidez de múltiplos pools, resultando em perdas estimadas de ~$223 milhões. Esse incidente se destaca como o maior hack de DeFi de 2025, evidenciando vulnerabilidades críticas na segurança de contratos inteligentes, especialmente relacionadas à aritmética de ponto fixo.
O exploit teve origem em uma falha em uma função customizada de prevenção de overflow, checked_shlw(). Devido a uma constante incorreta e a uma comparação equivocada, essa função falhou em detectar condições inseguras antes de realizar um deslocamento à esquerda utilizado na matemática de ponto fixo u256. Essa negligência permitiu uma truncagem silenciosa dos bits mais significativos durante cálculos de delta cruciais, como a determinação da quantidade de tokens de entrada necessária para uma dada liquidez. Ao manipular cuidadosamente parâmetros como o tamanho da liquidez e as configurações de tick/faixa de preço, o atacante conseguiu enganar o protocolo para calcular um depósito necessário de essencialmente 1 unidade de token, ao mesmo tempo em que creditava sua posição com uma enorme quantidade de liquidez. Com essa posição inflada registrada na blockchain, o atacante então removeu a liquidez e retirou as reservas reais, efetivamente drenando os pools.
Entendendo a Liquidez Concentrada e a Matemática de Ponto Fixo
O Cetus Protocol utiliza um design de market maker de liquidez concentrada (CLMM), uma abordagem sofisticada em que os provedores de liquidez (LPs) fornecem ativos apenas dentro de uma faixa de preço escolhida (um intervalo de ticks). Ao contrário dos AMMs tradicionais que distribuem a liquidez de forma uniforme, os CLMMs permitem que os LPs concentrem capital entre limites inferiores e superiores específicos. Esse design melhora significativamente a eficiência de capital, mas introduz uma forte dependência de matemática de ponto fixo precisa para conversão entre:
- A quantidade de liquidez creditada a uma posição.
- As quantidades reais de tokens que devem ser depositadas ou podem ser retiradas.
Quando um usuário adiciona liquidez, o protocolo calcula os deltas de tokens (quanto de tokens subjacentes é necessário) com base no preço atual e na faixa selecionada. Por outro lado, quando a liquidez é removida, o cálculo inverso determina a quantidade de ativos que a posição tem direito de retirar.
A vulnerabilidade central no Incidente Cetus explorou essa relação intrincada: se o cálculo de "quanto você deve depositar" pudesse ser manipulado para ser muito pequeno, enquanto a posição ainda era creditada com grande liquidez, um atacante poderia posteriormente remover essa liquidez creditada para retirar reservas reais do pool. Isso evidencia um vetor de ataque comum em protocolos DeFi que envolvem operações matemáticas complexas.
A Vulnerabilidade Crítica de Deslocamento u256
A causa raiz desse enorme hack de DeFi foi um bug dentro de uma função auxiliar projetada para realizar com segurança um deslocamento à esquerda, uma operação comum na aritmética de ponto fixo u256 (tipicamente << 64 para aplicar um fator de escala 2^64). Em sistemas baseados em Move como o Sui, as verificações de overflow não são aplicadas de forma uniforme em todas as operações, tornando as salvaguardas manuais para deslocamento de bits cruciais.
O Cetus implementou um auxiliar de prevenção de overflow, checked_shlw(), para verificar se o deslocamento de um valor u256 64 bits à esquerda excederia o limite de 256 bits. No entanto, devido a uma constante incorreta e a uma comparação equivocada, essa verificação crítica podia ser contornada para determinadas entradas grandes que deveriam ter sido rejeitadas.
Especificamente, a função get_delta_a, responsável por calcular a quantidade de tokens subjacentes (Token A) necessária para a provisão de liquidez entre dois preços (sqrt_price_0 e sqrt_price_1), chama checked_shlw(). O propósito de checked_shlw() aqui é garantir que o numerador no cálculo do Token A não sofra overflow quando deslocado.
A falha estava na verificação de overflow de checked_shlw(), que utilizava uma máscara de 0xffffffffffffffff << 192 (equivalente a 2^256 - 2^192). Essa máscara é significativamente maior do que o limiar correto. Consequentemente, um valor de entrada maior que 2^192 mas menor que essa máscara errônea poderia passar pela verificação, mesmo que deslocá-lo à esquerda de fato excedesse o intervalo u256. O deslocamento à esquerda subsequente resultava então em uma truncagem silenciosa, produzindo um valor incorreto e significativamente menor.
A figura abaixo ilustra a diferença entre a implementação vulnerável e a versão corrigida. O limite correto deveria ter sido 1 << 192, e não o muito maior 0xffffffffffffffff << 192. O atacante explorou engenhosamente essa verificação falha para cunhar uma quantidade incomumente grande de tokens LP enquanto depositava uma quantia mínima, como 1 wei do Token A.
Anatomia do Hack DeFi do Cetus
Embora o atacante tenha aplicado a mesma técnica em múltiplos pools, o fluxo do ataque subjacente permaneceu consistente. Vamos analisar uma transação específica para entender as etapas envolvidas nessa sofisticada violação de segurança blockchain.
1. Manipular o Preço do Pool com um Flashloan
O ataque começou com o atacante utilizando um flashloan para adquirir rapidamente 10.024.321,28 haSUI. Em seguida, trocou 5.765.124,79 SUI, reduzindo intencionalmente o preço do pool de 18.956.530.795.606.879.104 para 18.425.720.184.762.886. Esse movimento estratégico de preço foi crucial, pois permitiu ao atacante abrir uma posição CLMM que exigia apenas uma quantidade mínima de um token, aproveitando o comportamento de liquidez "unilateral / quase de token único" inerente aos designs de liquidez concentrada.
2. Adicionar Liquidez com um Depósito "Quase Gratuito"
Em seguida, o atacante selecionou uma faixa de tick muito estreita (ex.: 300000–300200) e ajustou com precisão a liquidez alvo. Em sistemas CLMM, os cálculos de delta de tokens são altamente dependentes dos preços de raiz quadrada nos limites da faixa, e faixas estreitas podem tornar certos valores intermediários extremamente sensíveis a pequenas variações.
Ao ajustar cuidadosamente esses parâmetros, o atacante fez com que uma multiplicação interna produzisse um valor intermediário u256. Esse valor deveria ter sofrido overflow ao ser deslocado à esquerda, mas passou com sucesso pela guarda falha de checked_shlw(). Como consequência direta da truncagem induzida pelo deslocamento inseguro, o protocolo calculou a quantidade necessária do Token A como efetivamente 1 unidade, ao mesmo tempo em que cunhava e registrava a posição com uma quantidade massiva de liquidez (ou seja, 10.365.647.984.364.446.732.462.244.378.333.008).
3. Remover Liquidez para Extrair Reservas Reais
Com uma posição on-chain que aparentava falsamente deter liquidez inflada, o atacante prosseguiu para remover a liquidez e retirar ativos como se a posição tivesse sido devidamente financiada. Essa etapa crítica é onde as reservas reais do pool foram sistematicamente drenadas, levando à substancial perda de $223 milhões.
4. Repetir em Múltiplos Pools
Após validar com sucesso o primitivo do exploit, o atacante replicou o mesmo fluxo de trabalho em múltiplos pools, multiplicando rapidamente as perdas totais e executando um dos maiores hacks de DeFi até hoje.
Best Security Auditor for Web3
Validate design, code, and business logic before launch
Principais Conclusões e Lições de Segurança Blockchain
O Incidente Cetus serve como um lembrete contundente dos desafios intrincados na segurança blockchain, especialmente dentro de protocolos DeFi complexos. A causa raiz foi uma verificação de overflow defeituosa em torno de um deslocamento à esquerda u256 no caminho de matemática de ponto fixo. Isso permitiu que um deslocamento com overflow truncasse silenciosamente os bits altos, fazendo com que o depósito necessário parecesse próximo de zero, enquanto ainda creditava uma posição LP com liquidez massiva, permitindo por fim a extração das reservas.
Lições Aprendidas para Segurança de Contratos Inteligentes:
- Rigor na Aritmética: Seja excepcionalmente rigoroso ao lidar com deslocamentos, fatores de escala, arredondamento e condições de limite na aritmética de ponto fixo. Essas são fontes comuns de vulnerabilidades críticas.
- Primitivos Comprovados: Priorize o uso de primitivos de matemática segura comprovados ou invariantes formalizados em vez de desenvolver funções auxiliares ad-hoc. Se auxiliares customizados forem necessários, valide suas constantes e limiares com extremo cuidado.
- Testes Abrangentes: Implemente extensos testes de casos extremos e baseados em propriedades para cobrir valores máximos, ticks de limite e combinações adversariais de parâmetros. Essa abordagem proativa pode descobrir falhas sutis antes da implantação.
- Monitoramento Contínuo: Mesmo com auditorias robustas, soluções de monitoramento em tempo real são cruciais. Ferramentas como o Phalcon Security da BlockSec podem detectar atividades suspeitas on-chain e possíveis exploits em andamento, oferecendo uma última linha de defesa vital.
O Incidente Cetus ressalta a importância de uma abordagem multicamadas para a segurança blockchain, combinando revisão de código meticulosa, metodologias avançadas de testes e monitoramento contínuo on-chain para proteger contra sofisticados hacks de DeFi.
Referências
Sobre a BlockSec
A BlockSec é uma provedora completa de segurança blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam nossos clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchains 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 blockchain em conferências de prestígio, reportou vários ataques de dia zero 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
