DxSale perde US$7,3 milhões em hack a provedores de liquidez na BNB Chain

DxSale, uma plataforma de lançamentos de tokens e bloqueio de liquidez de longa data amplamente usada durante o primeiro boom de memecoins da BNB Chain, sofreu um exploit grave que drenou um valor estimado em US$7,3 milhões dos fundos de provedores de liquidez (LP).

O incidente afetou mais de 1.400 pools de liquidez, segundo rastreamento on-chain compartilhado após o ocorrido.

Os pools estavam distribuídos por vários projetos de tokens mais antigos, muitos dos quais não registravam desenvolvimento ativo ou atividade de negociação há anos, mas ainda mantinham liquidez bloqueada dentro dos contratos da DxSale.

Notavelmente, o exploit não parece ter mirado um único token ou projeto. Em vez disso, impactou uma camada de infraestrutura compartilhada usada por centenas de deployments, ampliando a escala das perdas.

Como aconteceu o ataque aos LPs na BNB Chain

Análise on-chain e detalhamento de investigadores da Tahax sugerem que o exploit não foi repentino.

Em vez disso, desenrolou-se por meio de uma série de alterações administrativas controladas que ocorreram meses antes do esvaziamento efetivo.

Cerca de 269 dias antes do incidente, o deployer da DxSale teria transferido a propriedade de um contrato chave de locker para uma nova carteira. A transição não foi anunciada publicamente e não foi emitido nenhum aviso de migração aos usuários ou equipes de tokens que dependiam do sistema.

Ao longo do tempo, o controle de propriedade não permaneceu estático. Os direitos administrativos teriam sido movimentados por aproximadamente 80 transferências entre carteiras, cada uma projetada para obscurecer a trilha das mudanças de custódia.

Esses movimentos reduziram a visibilidade sobre quem, em última instância, controlava o sistema de lockers, enquanto mantinham privilégios administrativos intactos.

Dois dias antes do início do exploit, a propriedade foi consolidada em uma única carteira:

0xC4574DDEF299e7E563971e200433e592EeaaFA69

A carteira foi recém-criada e, segundo relatos, financiada via Bybit, com atividade de roteamento ligada a infraestrutura de pontes cross-chain frequentemente usada para obscurecer a origem dos fundos.

Dentro de horas dessa consolidação, começou a atividade de drenagem de liquidez em centenas de pools de tokens.

Execução técnica do esvaziamento

Um relato detalhado de analistas de segurança on-chain da Coinsult descreveu o mecanismo usado para extrair fundos do sistema de lockers da DxSale.

O contrato atacante, implantado pouco antes do incidente, não estava verificado e foi construído usando Solidity 0.8.33. Funcionou como um orquestrador único, permitindo que múltiplas ações fossem executadas dentro de uma única transação por meio de lógica de autochamada.

A sequência de execução mirou a mecânica interna do contrato de locker.

Primeiro, o atacante acionou uma função que reduziu a taxa de bloqueio para 1 wei, removendo efetivamente barreiras de custo para modificar posições bloqueadas.

Isso foi seguido por uma segunda ação que definiu o timestamp de expiração do bloqueio para 68 segundos após a época Unix, redefinindo o bloqueio para um momento que já não protegia a liquidez depositada.

Após isso, o parâmetro de taxa foi elevado para um valor extremamente alto, aproximadamente 1e29, que aparentemente foi usado para perturbar o comportamento normal de interação com o contrato durante a execução.

Uma vez que o estado interno foi modificado, o atacante iniciou chamadas repetidas de retirada que permitiram a extração de tokens do locker.

Esses fundos foram então convertidos em WBNB e BNB antes de serem movimentados por múltiplas rotas para obscurecer a trilha das transações.

A estrutura do contrato fazia com que, uma vez alterados os parâmetros administrativos, o status de “bloqueado” da liquidez deixasse de refletir restrições reais de retirada.

Por que o sistema de lockers de LP virou alvo

DxSale foi amplamente usado durante o boom de memecoins de 2021 na BNB Chain como uma ferramenta padrão de bloqueio de liquidez.

Muitos lançamentos de tokens dependiam dele para demonstrar segurança a investidores iniciais, bloqueando tokens de pools de liquidez por períodos prolongados.

No entanto, o modelo de segurança do sistema dependia fortemente do controle administrativo em vez de uma lógica contratual totalmente imutável.

Segundo a análise, funções como ajuste de taxas e configuração de bloqueio continuavam acessíveis por meio de papéis privilegiados de propriedade.

Analistas de segurança observaram que o exploit tornou-se possível porque o contrato de locker ainda possuía uma chave de proprietário ativa capaz de modificar parâmetros críticos.

Isso significava que a liquidez “bloqueada” não era rigidamente aplicada por código imutável, mas sim governada por configurações contratuais ajustáveis.