Por que a linha de defesa de segurança da Drift é tão fraca, desde a pré-assinatura até a perda de permissões?
Escrito por: Four Pillars
Compilado por: AididiaoJP, Foresight News
Pontos principais
Em 1º de abril de 2026, às 16:05 (horário UTC), o protocolo Drift sofreu um ataque significativo de cerca de 285 milhões de dólares. Drift é uma das principais exchanges descentralizadas de contratos perpétuos no ecossistema Solana. Este ataque pertence a um esquema complexo de manipulação de colaterais: os atacantes utilizaram uma chave de administrador vazada para lançar um novo mercado à vista de um token sem valor, depois desativaram o mecanismo de proteção de saques e, por fim, retiraram ativos reais através da falsificação do valor do colateral.
Este ataque combinou a técnica de pré-assinatura baseada em um número aleatório persistente com métodos avançados de engenharia social. Desde 23 de março, os atacantes criaram contas de números aleatórios persistentes para dois signatários multi-assinatura e duas contas controladas pelos atacantes. Mesmo após a execução de uma migração multi-assinatura legítima em 27 de março, os atacantes ainda conseguiram recuperar o acesso aos novos signatários multi-assinatura. Os atacantes obtiveram pré-assinaturas de signatários legítimos por meio da manipulação do conteúdo das transações, armazenaram-nas usando números aleatórios persistentes e, em 1º de abril, executaram em massa, finalmente assumindo o controle administrativo. Este evento não envolveu vazamento de palavras-chave ou vulnerabilidades de contratos inteligentes.
Este evento é mais um erro operacional significativo, ocorrendo apenas 10 dias após o ataque Resolv. O colapso do Resolv se deveu à sua total falta de um mecanismo de multi-assinatura; enquanto o Drift, apesar de ter um multi-assinatura, também falhou devido ao limiar muito baixo e à falta de mecanismos de segurança adicionais. Estes dois eventos indicam que uma reestruturação fundamental da arquitetura de privilégios é urgentemente necessária.
Visão geral do evento
Fonte: @DriftProtocol
Em 1º de abril de 2026, às 16:05 (UTC), o protocolo Drift, um dos principais exchanges descentralizados de contratos perpétuos na Solana, sofreu um ataque em larga escala. O Drift é um protocolo que oferece serviços de negociação alavancada, negociação à vista, empréstimos e várias outras finanças descentralizadas, cuja arquitetura combina formadores de mercado automatizados virtuais com um livro de ordens on-chain. Justo antes do ataque, o valor total bloqueado no protocolo era de aproximadamente 309 milhões de dólares.
Fonte: @PeckShieldAlert
Cerca de 18:10 (UTC), aproximadamente duas horas após o início do ataque, a equipe do Drift postou na plataforma X pedindo aos usuários que suspendessem os depósitos. Em seguida, a equipe confirmou o evento de ataque e suspendeu todas as funções de depósito e retirada. Várias empresas de segurança e análise on-chain, incluindo PeckShield e Lookonchain, estimaram uma perda de cerca de 285 milhões de dólares. A carteira Phantom rapidamente tomou medidas para bloquear o acesso ao protocolo.
Este evento é especialmente preocupante porque ocorreu apenas 10 dias após o ataque Resolv, tornando-se mais um evento em que chaves de administrador em larga escala foram vazadas em um curto período. Ambos os eventos têm uma raiz comum: a causa fundamental não é uma vulnerabilidade no código do contrato inteligente, mas sim uma falha na segurança operacional.
Análise da causa raiz
O cerne deste ataque é que os atacantes utilizaram permissões administrativas vazadas para manipulação de colateral. Se o evento Resolv foi um 'vazamento de chaves com permissões de mint', o evento Drift foi um 'vazamento de chaves com permissões de listagem de mercado e configuração de segurança'. Embora as manifestações sejam diferentes, a raiz é a mesma. A seguir, uma análise passo a passo do processo de ataque.
Fonte: Dexscreener
A ferramenta mais direta deste ataque foi o CarbonVote Token (CVT), um token com liquidez extremamente baixa. Um dos endereços controlados pelos atacantes (FnYXwy...LpAjjx) emitiu este token três semanas antes do ataque. O suprimento total de CVT é de aproximadamente 750 milhões de unidades, das quais mais de 80% estão em uma carteira dos atacantes. Os atacantes criaram um pool de liquidez mínimo no Raydium com um valor de cerca de 500 dólares, seguido por transações de volume contínuo.
A função initializeSpotMarket no protocolo Drift permite que administradores especifiquem diretamente o endereço do oráculo e suas fontes de parâmetros. A configuração do kit de ferramentas de desenvolvimento de software para os mercados existentes mostra que cada mercado define individualmente seu oráculo, fonte de oráculo e campos de emissão de tokens. Isso significa que, mesmo tokens como o CVT, que não possuem preços do Pyth, podem ser listados como mercados se os atacantes obtiverem permissões administrativas.
Neste ataque, os atacantes designaram um preço de oráculo Switchboard como o feed para o mercado CVT. O Switchboard é uma rede de oráculos que facilita a criação de feeds personalizados. Os atacantes configuraram um feed controlado por eles, avaliando o valor de 785 milhões de CVT em centenas de milhões de dólares. Plataformas de rastreamento de preços como Dexscreener mostram que o preço do CVT é de cerca de 1 dólar, mas sua liquidez de mercado real e valor intrínseco estão praticamente próximos de zero.
A carteira utilizada no ataque (HkGz4K...ovpZES) apareceu ativa cerca de oito dias antes, em 24 de março. Esta carteira pretendia obter um pré-carregamento através do protocolo NEAR, e os registros on-chain mostram que até o dia do ataque, esta carteira completou um total de 325 transações.
A história da atividade on-chain do signatário administrador utilizado no dia do ataque (H7PiGq...y7ZgL) também merece atenção. Essa chave registrou apenas 29 transações. A primeira transação ocorreu em 31 de março às 15:05 (UTC), um dia antes do ataque; a última transação ocorreu em 1º de abril às 18:05 (UTC), no dia do ataque. O tempo total de existência on-chain dessa chave foi de aproximadamente 27 horas. A razão pode ser claramente vista nos registros on-chain.
As permissões administrativas do protocolo Drift não são geridas por uma única conta externa, mas sim através de um mecanismo de multi-assinatura. No entanto, a investigação subsequente revelou que o caminho do ataque era muito mais complexo do que uma simples invasão multi-assinatura. Cerca de nove dias antes do ataque, os atacantes criaram quatro contas de números aleatórios persistentes. Duas delas estavam associadas aos signatários da multi-assinatura do comitê de segurança do Drift, e as outras duas eram controladas pelos atacantes. Os números aleatórios persistentes são um mecanismo na Solana que permite contornar a validade do hash do bloco de cerca de um minuto nas transações normais, permitindo que assinaturas sejam coletadas antecipadamente e executadas posteriormente. Acredita-se que os atacantes tenham explorado esse mecanismo, obtendo pré-assinaturas de signatários legítimos por meio da manipulação do conteúdo das transações.
Quatro dias depois, a equipe do Drift executou uma migração multi-assinatura programada devido à mudança de membros do comitê de segurança. Esta migração faz parte do processo operacional padrão, mas os atacantes conseguiram se adaptar a essa mudança.
Um dia antes do ataque, os atacantes criaram uma nova conta de número aleatório persistente para um dos signatários na nova multi-assinatura (6UJbu9...Pvu924). Neste momento, os atacantes já haviam recuperado o acesso efetivo a dois quintos dos signatários na nova multi-assinatura. Isso indica que os atacantes se infiltraram profundamente no sistema, sendo capazes de lidar até mesmo com mudanças inesperadas de migração multi-assinatura.
No dia do ataque, a equipe do Drift executou um saque de teste rotineiro do fundo de seguro. Cerca de um minuto depois, os atacantes executaram rapidamente duas transações de números aleatórios persistentes pré-assinadas.
Fonte: solscan
A primeira transação na multi-assinatura Squads executou os comandos VaultTransactionCreate, ProposalCreate e ProposalApprove, criando uma proposta maliciosa de transferência de administrador e registrando a primeira aprovação.
Em seguida, a segunda transação utilizou números aleatórios persistentes para executar os comandos ProposalApprove e VaultTransactionExecute. O limiar de dois quintos foi imediatamente alcançado e, uma vez que o bloqueio de tempo foi definido para zero segundos, a transação foi executada imediatamente. Neste momento, o comando UpdateAdmin no programa Drift V2 foi chamado, transferindo o endereço do administrador para os atacantes (H7PiGq...y7ZgL).
O detalhe crucial aqui é que ambas as transações foram completamente assinadas previamente e submetidas em massa no dia do ataque. É muito provável que os signatários não tenham compreendido plenamente o conteúdo das transações que assinaram. O termo 'declaração enganosa' usado pela equipe do Drift indica que os signatários foram enganados a assinar uma transação maliciosa de transferência de administrador disfarçada como uma operação regular. O papel dos números aleatórios persistentes é armazenar essas pré-assinaturas indefinidamente, permitindo que os atacantes as executem no momento que escolherem.
O signatário administrador substituído em seguida chamou o programa Drift V2 (dRifty...cn33UH) e executou duas operações.
Fonte: solscan
Primeiro, os atacantes registraram o CVT como um novo mercado à vista no Drift usando o comando initializeSpotMarket. Durante esse processo, uma nova conta de mercado à vista foi criada (BY3WYn...FVU1Cf) juntamente com duas contas de token CVT, e o endereço derivado do programa da tesouraria do Drift (PDA, JCNCMF...XXJfrw) foi definido como o proprietário do token.
O Drift opera um sistema de colateral de múltiplos ativos, o que significa que os tokens registrados em um novo mercado à vista podem ser imediatamente usados como colateral. No entanto, para serem considerados colaterais aceitáveis, os parâmetros initial_asset_weight e maintenance_asset_weight desse mercado devem ser definidos como valores positivos maiores que zero, enquanto os valores iniciais padrão são baixos ou próximos de zero. A análise da transação de ataque (4a5962R...st82X) mostra que updateSpotMarketMarginWeights (ou atualização equivalente de parâmetros de risco) foi executada em uma única transação junto com initializeSpotMarket, onde os atacantes definiram o peso do colateral de CVT para o máximo.
Isso expôs uma falha de design crítica sob a perspectiva da defesa em profundidade: operações como a listagem de mercado, designação de origem de oráculos, configuração do peso máximo de colateral e desativação da proteção de saques podem ser concluídas em uma única transação. O fator de desconto de peso utilizado para prevenir a concentração de riscos de grandes posições, após o peso ser definido para o máximo, perdeu sua eficácia prática. Se o programa tivesse um limite superior para a configuração de pesos de mercados recém-criados ou um bloqueio de tempo independente para alterações de peso, esse ataque que desmantela todas as medidas de defesa em uma única transação não teria sido possível.
Fonte: solscan
Em segundo lugar, na mesma transação, os atacantes chamaram cinco vezes o comando updateWithdrawGuardThreshold, elevando o limite de saque do mercado de ativos principais a níveis extremos. Os limites de todos os mercados foram definidos como um valor unificado de cerca de 500 trilhões, essencialmente levando o limiar do mecanismo de proteção de saques a um infinito, anulando assim a proteção destinada a impedir saques anormalmente grandes.
Esta transação (4a5962R...st82X) destruiu simultaneamente as três linhas de defesa principais do Drift.
Primeiro, ao alocar um preço de oráculo controlado pelos atacantes como um feed Switchboard, o mecanismo de preços foi comprometido. Em segundo lugar, o peso do colateral foi definido para o máximo, fazendo com que um token sem valor intrínseco fosse considerado um colateral de alta qualidade. Terceiro, o limiar do mecanismo de proteção de saques foi elevado para cerca de 500 trilhões, essencialmente eliminando o mecanismo de bloqueio de saques anormais.
Incluindo a mudança de permissões de administrador, os atacantes desmantelaram toda a arquitetura de segurança do protocolo com apenas duas transações. Do ponto de vista da auditoria de código, isso traz um paradoxo profundo: o código do contrato do Drift funcionou exatamente como confirmado pela auditoria. initializeSpotMarket registrou novos mercados conforme projetado, designou a origem do oráculo e definiu os parâmetros de peso; updateWithdrawGuardThreshold modificou os limites conforme projetado. A raiz do problema reside no próprio design do sistema - esse design permite que toda a cadeia de ataque seja completada em uma única transação. Isso não pertence à esfera da auditoria de código, mas sim ao domínio do design de arquitetura de privilégios e restrições de parâmetros.
Finalmente, os atacantes depositaram cerca de 785 milhões de CVT como colateral em uma nova conta de usuário do Drift. O preço do oráculo Switchboard controlado pelos atacantes avaliou esse valor em centenas de milhões de dólares, enquanto o peso do colateral definido como máximo reconheceu quase toda a avaliação como colateral válido. O sistema de margem do Drift funcionou exatamente como projetado. O problema é que cada um dos parâmetros inseridos nesse sistema foi maliciosamente manipulado pelos atacantes.