No dia 22 de maio de 2025, a Cetus foi alvo de um ataque complexo a contratos inteligentes direcionados ao pool CLMM. Tomamos medidas imediatas para mitigar o impacto, este relatório visa divulgar de forma transparente a linha do tempo do evento, a análise da raiz do problema, a situação dos fundos e os planos subsequentes, e avançar conjuntamente nas questões futuras.
Linha do tempo do evento
UTC horário 10:30:50 – O ataque foi iniciado através de transações anormais.
UTC horário 10:40:00 – O sistema de monitoramento detectou comportamento anômalo no pool de fundos.
UTC 10:53:00 – A equipe Cetus identificou a origem do ataque e emitiu um alerta para os membros do ecossistema Sui.
UTC time 10:57:47 – The core CLMM pool has been disabled to prevent further losses.
UTC horário 11:20:00 – Todos os contratos inteligentes relevantes foram desativados globalmente.
UTC 12:50:00 – Os validadores Sui começam a votar para rejeitar transações assinadas por endereços de atacantes. Quando o stake de votos ultrapassa o limite de 33%, os validadores efetivamente "congelam" esses endereços.
UTC horário 18:04:07 – Enviar mensagem de negociação na cadeia para o atacante.
UTC tempo 18:15:28 – O contrato de vulnerabilidade foi corrigido e atualizado (ainda não reiniciado).
Análise de Ataque
O invasor explorou uma vulnerabilidade na biblioteca de código aberto 'inter_mate' no contrato CLMM e o processo de ataque é o seguinte:
a. O atacante inicia a troca relâmpago (flash_swap) para temporariamente abaixar o preço dentro do pool de liquidez.
b. Abrir posição em uma faixa de preço mais alta.
c. Utilizar a verificação de estouro errada na lógica de adicionar liquidez (add\_liquidity) para injetar um valor de liquidez artificialmente elevado com um número muito pequeno de tokens.
d. Retirar reservas de tokens através de múltiplas remoções de liquidez (remove_liquidity).
e. Utilizando cálculos não verificados (como overflowing\_sub, get\_liquidity\_from\_a), repetir o processo acima com valores de liquidez cuidadosamente construídos.
Esta vulnerabilidade não foi detectada nas auditorias de segurança anteriores.
Causa raiz
A vulnerabilidade decorre de um mal-entendido sobre a semântica da operação de deslocamento à esquerda na biblioteca de código aberto integer-mate, da qual o contrato CLMM depende. No seu método checked\_shlw, a verificação real deveria ser "se o valor de entrada ≤ 2^192", mas na versão atacada foi erroneamente verificado como "≤ 2^256", resultando na falha da verificação de estouro. Esta é a única verdadeira razão para o ataque recente.
Os atacantes exploraram a falha acima, manipulando a escala de preços (tick) do pool de liquidez e o mecanismo de liquidez, conseguindo retirar uma grande quantidade de ativos em vários ciclos de ataque.
É necessário esclarecer que, recentemente, algumas pessoas nas redes sociais erroneamente acreditaram que o ataque se originou do "erro de verificação aritmética MAX_U64" assinalado no relatório de auditoria anterior, o que levou a muitos usuários desinformados a serem induzidos em erro. Declaramos aqui: este problema não está relacionado com o ataque atual. Este problema em si é apenas uma sugestão de otimização a nível informativo, que apenas em circunstâncias extremas poderia levar ao retrocesso de transações, e já foi otimizado e corrigido nas versões anteriores.
Para proteger os interesses comuns de todo o ecossistema, com o apoio da maioria dos validadores Sui, os dois endereços de carteira Sui do atacante foram congelados urgentemente. As carteiras congeladas contêm a maior parte dos fundos roubados:
Atacante Sui carteira 1 (congelada): 0xcd8962dad278d8b50fa0f9eb0186bfa4cbdecc6d59377214c88d0286a0ac9562
Atacante Sui Wallet 2 (congelado): 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Os fundos restantes roubados foram totalmente trocados e transferidos para ETH, atualmente estão nas seguintes duas carteiras Ethereum:
Estamos a colaborar com a equipa de segurança da Sui e vários parceiros de auditoria para rever os contratos atualizados e realizar uma auditoria conjunta. Apenas após uma validação completa, iremos reativar gradualmente o pool CLMM e os serviços relacionados.
Estamos a planear iniciar uma auditoria adicional imediatamente e a publicar relatórios de auditoria regulares com base no TVL (valor total bloqueado). Ao mesmo tempo, iremos continuar a reforçar a monitorização em cadeia, otimizar a gestão de riscos e implementar limites de taxa controláveis sobre a liquidez dos ativos.
Restauro de ativos LP
Estamos a colaborar ativamente com parceiros do ecossistema central para desenhar planos de recuperação para os pools de liquidez afetados e LPs, com o objetivo de restaurar o mais rapidamente possível a funcionalidade de extração de liquidez dos pools afetados e todos os serviços.
Para alcançar o objetivo final de recuperar a totalidade das perdas dos usuários, apelamos sinceramente a todos os validadores Sui para que apoiem a votação em cadeia que lançamos recentemente. Esta votação permitirá que os usuários recuperem rapidamente a maior parte dos seus ativos. Com o seu apoio, avançaremos o mais rápido possível com a compensação das perdas dos usuários e a reconstrução da confiança da comunidade.
Trabalho Legal e de Negociação
À medida que os processos legais e de aplicação da lei avançam, também oferecemos aos atacantes uma oportunidade de hacker ético. Um aviso final será enviado aos atacantes em breve, e todos os progressos serão divulgados de forma transparente à comunidade.
Conclusão
Agradecemos sinceramente aos usuários, à Fundação Sui e aos parceiros ecológicos pela rápida resposta e forte apoio, que nos permitiram congelar rapidamente mais de 160 milhões de dólares e transmitir informações essenciais às partes afetadas. Ao mesmo tempo, sabemos que a recuperação completa ainda levará tempo e estamos tomando medidas ativas para acelerar o processo.
Desde a sua criação, a Cetus tem sido uma das equipas DeFi que mais investiu em auditorias de contratos inteligentes e proteção de sistemas na blockchain Sui. No entanto, a realidade não correspondeu às expectativas: os contratos subjacentes e as bibliotecas de código aberto dependentes passaram por várias auditorias e foram amplamente utilizados com sucesso pelos desenvolvedores do ecossistema, o que nos levou a acreditar que eram suficientemente seguros. Após uma reflexão posterior, percebemos que não mantivemos a vigilância necessária. Esta dolorosa lição ensinou-nos que devemos fazer mais.
No futuro, iremos reforçar o sistema de segurança e o controle de riscos através das seguintes medidas:
Implementar monitorização em tempo real com ferramentas como Blockaid, para detectar e responder rapidamente a ameaças e vulnerabilidades.
Otimizar a alocação de gestão de risco, aplicando limitações controláveis na taxa de fluxo de ativos
Aumentar a cobertura de testes do código-fonte de contratos inteligentes
Índice de cobertura de código público
Realizar auditoria antes do lançamento oficial, após mudanças significativas no código e ao atingir marcos críticos de TVL.
Atualização do programa de recompensas por vulnerabilidades de chapéu branco, recompensas generosas para relatórios de vulnerabilidades valiosos
As diversas medidas acima já estão em implementação e continuaremos a aprofundá-las.
Além disso, percebemos que proteger os protocolos DeFi não pode depender apenas do esforço das equipes e dos auditores, é necessário o poder de todo o ecossistema - desde desenvolvedores até contribuidores ativos de chapéu branco - para monitorar, defender e melhorar juntos. Esperamos unir todas as forças disponíveis para construir uma infraestrutura sustentável e resiliente para todo o ecossistema, que resista ao teste do tempo.
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Relatório de incidente de roubo da Cetus: divulgação da linha do tempo e detalhes do ataque
Fonte: Cetus; Compilado por: AIMan@Jinse Caijing
No dia 22 de maio de 2025, a Cetus foi alvo de um ataque complexo a contratos inteligentes direcionados ao pool CLMM. Tomamos medidas imediatas para mitigar o impacto, este relatório visa divulgar de forma transparente a linha do tempo do evento, a análise da raiz do problema, a situação dos fundos e os planos subsequentes, e avançar conjuntamente nas questões futuras.
Linha do tempo do evento
UTC horário 10:30:50 – O ataque foi iniciado através de transações anormais.
UTC horário 10:40:00 – O sistema de monitoramento detectou comportamento anômalo no pool de fundos.
UTC 10:53:00 – A equipe Cetus identificou a origem do ataque e emitiu um alerta para os membros do ecossistema Sui.
UTC time 10:57:47 – The core CLMM pool has been disabled to prevent further losses.
UTC horário 11:20:00 – Todos os contratos inteligentes relevantes foram desativados globalmente.
UTC 12:50:00 – Os validadores Sui começam a votar para rejeitar transações assinadas por endereços de atacantes. Quando o stake de votos ultrapassa o limite de 33%, os validadores efetivamente "congelam" esses endereços.
UTC horário 18:04:07 – Enviar mensagem de negociação na cadeia para o atacante.
UTC tempo 18:15:28 – O contrato de vulnerabilidade foi corrigido e atualizado (ainda não reiniciado).
Análise de Ataque
O invasor explorou uma vulnerabilidade na biblioteca de código aberto 'inter_mate' no contrato CLMM e o processo de ataque é o seguinte:
a. O atacante inicia a troca relâmpago (flash_swap) para temporariamente abaixar o preço dentro do pool de liquidez.
b. Abrir posição em uma faixa de preço mais alta.
c. Utilizar a verificação de estouro errada na lógica de
adicionar liquidez (add\_liquidity)para injetar um valor de liquidez artificialmente elevado com um número muito pequeno de tokens.d. Retirar reservas de tokens através de múltiplas remoções de liquidez (remove_liquidity).
e. Utilizando cálculos não verificados (como
overflowing\_sub,get\_liquidity\_from\_a), repetir o processo acima com valores de liquidez cuidadosamente construídos.Esta vulnerabilidade não foi detectada nas auditorias de segurança anteriores.
Causa raiz
A vulnerabilidade decorre de um mal-entendido sobre a semântica da operação de deslocamento à esquerda na biblioteca de código aberto
integer-mate, da qual o contrato CLMM depende. No seu métodochecked\_shlw, a verificação real deveria ser "se o valor de entrada ≤ 2^192", mas na versão atacada foi erroneamente verificado como "≤ 2^256", resultando na falha da verificação de estouro. Esta é a única verdadeira razão para o ataque recente.Os atacantes exploraram a falha acima, manipulando a escala de preços (tick) do pool de liquidez e o mecanismo de liquidez, conseguindo retirar uma grande quantidade de ativos em vários ciclos de ataque.
É necessário esclarecer que, recentemente, algumas pessoas nas redes sociais erroneamente acreditaram que o ataque se originou do "erro de verificação aritmética MAX_U64" assinalado no relatório de auditoria anterior, o que levou a muitos usuários desinformados a serem induzidos em erro. Declaramos aqui: este problema não está relacionado com o ataque atual. Este problema em si é apenas uma sugestão de otimização a nível informativo, que apenas em circunstâncias extremas poderia levar ao retrocesso de transações, e já foi otimizado e corrigido nas versões anteriores.
Endereço do atacante (na cadeia Sui):
0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Situação dos fundos
Para proteger os interesses comuns de todo o ecossistema, com o apoio da maioria dos validadores Sui, os dois endereços de carteira Sui do atacante foram congelados urgentemente. As carteiras congeladas contêm a maior parte dos fundos roubados:
Atacante Sui carteira 1 (congelada): 0xcd8962dad278d8b50fa0f9eb0186bfa4cbdecc6d59377214c88d0286a0ac9562
Atacante Sui Wallet 2 (congelado): 0xe28b50cef1d633ea43d3296a3f6b67ff0312a5f1a99f0af753c85b8b5de8ff06
Os fundos restantes roubados foram totalmente trocados e transferidos para ETH, atualmente estão nas seguintes duas carteiras Ethereum:
Atacante carteira Ethereum 1: 0x0251536bfcf144b88e1afa8fe60184ffdb4caf16
Atacante carteira Ethereum 2: 0x89012a55cd6b88e407c9d4ae9b3425f55924919b
Planos Futuros
Revisão de Contratos e Reforço de Segurança
Estamos a colaborar com a equipa de segurança da Sui e vários parceiros de auditoria para rever os contratos atualizados e realizar uma auditoria conjunta. Apenas após uma validação completa, iremos reativar gradualmente o pool CLMM e os serviços relacionados.
Estamos a planear iniciar uma auditoria adicional imediatamente e a publicar relatórios de auditoria regulares com base no TVL (valor total bloqueado). Ao mesmo tempo, iremos continuar a reforçar a monitorização em cadeia, otimizar a gestão de riscos e implementar limites de taxa controláveis sobre a liquidez dos ativos.
Restauro de ativos LP
Estamos a colaborar ativamente com parceiros do ecossistema central para desenhar planos de recuperação para os pools de liquidez afetados e LPs, com o objetivo de restaurar o mais rapidamente possível a funcionalidade de extração de liquidez dos pools afetados e todos os serviços.
Para alcançar o objetivo final de recuperar a totalidade das perdas dos usuários, apelamos sinceramente a todos os validadores Sui para que apoiem a votação em cadeia que lançamos recentemente. Esta votação permitirá que os usuários recuperem rapidamente a maior parte dos seus ativos. Com o seu apoio, avançaremos o mais rápido possível com a compensação das perdas dos usuários e a reconstrução da confiança da comunidade.
Trabalho Legal e de Negociação
À medida que os processos legais e de aplicação da lei avançam, também oferecemos aos atacantes uma oportunidade de hacker ético. Um aviso final será enviado aos atacantes em breve, e todos os progressos serão divulgados de forma transparente à comunidade.
Conclusão
Agradecemos sinceramente aos usuários, à Fundação Sui e aos parceiros ecológicos pela rápida resposta e forte apoio, que nos permitiram congelar rapidamente mais de 160 milhões de dólares e transmitir informações essenciais às partes afetadas. Ao mesmo tempo, sabemos que a recuperação completa ainda levará tempo e estamos tomando medidas ativas para acelerar o processo.
Desde a sua criação, a Cetus tem sido uma das equipas DeFi que mais investiu em auditorias de contratos inteligentes e proteção de sistemas na blockchain Sui. No entanto, a realidade não correspondeu às expectativas: os contratos subjacentes e as bibliotecas de código aberto dependentes passaram por várias auditorias e foram amplamente utilizados com sucesso pelos desenvolvedores do ecossistema, o que nos levou a acreditar que eram suficientemente seguros. Após uma reflexão posterior, percebemos que não mantivemos a vigilância necessária. Esta dolorosa lição ensinou-nos que devemos fazer mais.
No futuro, iremos reforçar o sistema de segurança e o controle de riscos através das seguintes medidas:
Implementar monitorização em tempo real com ferramentas como Blockaid, para detectar e responder rapidamente a ameaças e vulnerabilidades.
Otimizar a alocação de gestão de risco, aplicando limitações controláveis na taxa de fluxo de ativos
Aumentar a cobertura de testes do código-fonte de contratos inteligentes
Índice de cobertura de código público
Realizar auditoria antes do lançamento oficial, após mudanças significativas no código e ao atingir marcos críticos de TVL.
Atualização do programa de recompensas por vulnerabilidades de chapéu branco, recompensas generosas para relatórios de vulnerabilidades valiosos
As diversas medidas acima já estão em implementação e continuaremos a aprofundá-las.
Além disso, percebemos que proteger os protocolos DeFi não pode depender apenas do esforço das equipes e dos auditores, é necessário o poder de todo o ecossistema - desde desenvolvedores até contribuidores ativos de chapéu branco - para monitorar, defender e melhorar juntos. Esperamos unir todas as forças disponíveis para construir uma infraestrutura sustentável e resiliente para todo o ecossistema, que resista ao teste do tempo.