~$1,35M Perdidos: BarnBridge, DeFiTuna

Durante a semana passada (13/07/2026 - 19/07/2026), os seguintes 2 incidentes de segurança notáveis são destacados, envolvendo aproximadamente $1,35M em perdas totais no Ethereum e na Solana.

Data	Incidente	Tipo	Perda Estimada
15/07/2026	BarnBridge	Governança Inadequada	~$776K
16/07/2026	DeFiTuna	Verificação de Saúde Falha	~$570K

DeFiTuna: A verificação de saúde da posição aceitou valor zero de ativos como saudável com dívida não-zero; o atacante usou roteamento de swap controlado e um pool separado de baixa liquidez para acionar essa falha e criar uma posição de dívida inadimplente.
BarnBridge: Um sistema de governança depreciado foi explorado para modificar configurações críticas do protocolo e drenar fundos aprovados pelos usuários.

Destaque da Semana: DeFiTuna

A causa raiz foi uma ramificação de valor zero falha na verificação de saúde da posição: uma posição com valor zero de ativos e aproximadamente $570K de dívida pendente foi aceita como saudável. O atacante acionou essa falha roteando o swap por um pool separado de baixa liquidez, mas a verificação de saúde era o controle que deveria ter detectado a dívida inadimplente resultante.

Em 16 de julho de 2026, a DeFiTuna, um protocolo de empréstimo na Solana que suporta posições spot alavancadas, foi explorada por aproximadamente $570K em USDC [1]. A causa raiz foi uma ramificação de valor zero falha na verificação de saúde da posição que aceitava uma posição como saudável mesmo quando seu valor de ativos era zero e sua dívida era não-zero. O atacante abriu uma posição alavancada com colateral zero, tomou emprestado USDC do cofre do protocolo e roteou o swap por um pool de baixa liquidez controlado pelo atacante, fazendo com que a posição recebesse uma quantidade insignificante do token alvo. O truncamento de precisão arredondou o valor da posição para zero, e a verificação de saúde aceitou a posição como saudável, criando aproximadamente $570K de dívida inadimplente.

Contexto

A DeFiTuna é um protocolo de empréstimo na Solana que suporta negociação com margem. Um usuário pode abrir uma posição spot fornecendo um token como colateral, tomando emprestado de um cofre do protocolo e trocando os fundos emprestados por um token alvo. A posição resultante é então verificada em relação à dívida para determinar se está saudável.

Em um mercado spot da DeFiTuna, os dois tokens do pool são referenciados como token A e token B. No mercado atacado, o token A era TUNA e o token B era USDC.

USDC era o token de colateral (collateral_token). O usuário deposita USDC como margem, toma emprestado USDC adicional do cofre da DeFiTuna, e o USDC emprestado é então trocado por TUNA.
TUNA era o token de posição (position_token), o ativo que a posição mantém após o swap. O efeito líquido é uma posição comprada alavancada em TUNA financiada por dívida em USDC.
As contas do cofre mantêm a liquidez dos credores e são a fonte dos fundos emprestados.
O pool AMM fornece liquidez de mercado e contexto de preço para o par TUNA/USDC.

A DeFiTuna roteia swaps de posição pelo Jupiter, um agregador de swaps da Solana. O caminho do swap é fornecido à instrução da DeFiTuna como dados de rota e contas de rota do Jupiter. Como o chamador fornece essas contas, o chamador controla qual pool o swap utiliza. Antes de executar o swap, a DeFiTuna realiza uma verificação de preço pré-swap comparando o preço do pool de mercado normal com um oráculo.

Análise de Vulnerabilidade

O programa com falha é a DeFiTuna (tuna4u...nogD).

A causa raiz foi uma ramificação de valor zero falha na verificação de saúde da posição. Após um swap, a DeFiTuna valorava a posição convertendo o TUNA mantido em termos de USDC. Se o saldo de TUNA fosse pequeno o suficiente para ser arredondado para zero, o campo total tornava-se 0. A lógica da verificação de saúde tratava total == 0 como um estado saudável sem exigir que debt == 0.

Análise do Ataque

Duas propriedades de design deram ao atacante controle sobre o destino dos fundos emprestados. Primeiro, a DeFiTuna aceitava dados RouteV2 do Jupiter fornecidos pelo chamador sem derivar sua própria saída mínima aceitável de TUNA a partir do preço do oráculo e do valor emprestado. Segundo, a verificação do oráculo pré-swap apenas validava o pool de mercado normal da DeFiTuna, não o pool que a rota do Jupiter realmente utilizaria.

Nota: A análise pós-incidente endossada pela equipe do projeto [1] descreve o pool criado pelo atacante como inicializado próximo ao preço legítimo do oráculo. Evidências on-chain mostram que o pool foi inicializado a um preço extremo; a verificação pré-swap passou porque validou o pool de mercado normal separado, não o pool controlado pelo atacante.

A análise a seguir é baseada na transação 4x33Dq...EXj1. Múltiplas transações de ataque foram executadas; esta ilustra a técnica central.

Passo 1: O atacante criou um novo pool Fusion TUNA/USDC. Esse pool usava os mints reais de TUNA e USDC, mas era separado do pool de mercado normal da DeFiTuna. O pool foi inicializado a um preço extremo próximo ao tick 208636, precificando TUNA em aproximadamente 1,149 bilhões de USDC por TUNA. A esse preço, mesmo uma quantidade mínima de TUNA poderia absorver centenas de milhares de USDC em um swap.

Passo 2: O atacante colocou duas pequenas ordens de limite de venda no novo pool. Cada ordem depositou 0,000526 TUNA, totalizando 0,001052 TUNA. Como o preço do pool era extremamente alto, essa minúscula oferta de TUNA poderia absorver todo o valor de USDC emprestado quando o swap fosse executado.

Passo 3: Com o pool preparado, o atacante abriu uma posição spot na DeFiTuna com TUNA como token de posição e USDC como token de colateral. O atacante forneceu 0 USDC como colateral e tomou emprestado 570.000 USDC do cofre de USDC da DeFiTuna.

Passo 4: Antes do swap, a DeFiTuna comparou o preço do pool de mercado normal com o preço do oráculo. O preço spot do pool normal estava próximo ao oráculo, então a verificação passou. Essa verificação apenas validou o pool de mercado normal da DeFiTuna; não validou o pool Fusion que a rota do Jupiter utilizaria.

Passo 5: O swap seguiu a rota do Jupiter fornecida pelo atacante, que direcionou os fundos pelo pool Fusion controlado pelo atacante com a saída mínima efetivamente definida como zero. Após a taxa do protocolo, 569.601 USDC foram roteados para o pool de ataque, enquanto a posição da DeFiTuna recebeu apenas 494 unidades brutas de TUNA (0,000494 TUNA).

Passo 6: Após o swap, a posição tinha aproximadamente 570.000 USDC de dívida e apenas uma quantidade irrisória de TUNA. Quando a DeFiTuna converteu esse saldo de TUNA em valor de USDC, o resultado foi arredondado para 0. A verificação de saúde tratou total == 0 como saudável, então a posição de dívida inadimplente foi aceita.

Passo 7: O atacante retirou o USDC acumulado no pool Fusion controlado pelo atacante. As duas retiradas foram quase iguais, correspondendo às duas posições de ordens de limite criadas no Passo 2.

Conclusão

A causa raiz foi a ramificação total == 0 da verificação de saúde aceitar uma posição como saudável independentemente da dívida pendente. O roteamento e a liquidez controlados pelo atacante criaram as condições para acionar essa falha, mas a verificação de saúde era o controle final que deveria ter impedido a dívida inadimplente.

A correção mais direta é rejeitar qualquer posição onde total == 0 e debt > 0. Uma posição de valor zero com dívida pendente nunca é saudável. Além disso, o protocolo deve derivar uma saída mínima aceitável de swap a partir do preço do oráculo e do valor emprestado, independentemente dos parâmetros de rota fornecidos pelo chamador. Vincular a verificação de oráculo/preço ao pool de swap real, ou verificar a saída do swap em relação a um piso calculado pelo protocolo, impediria que a verificação pré-swap fosse contornada por roteamento através de um pool não validado.

Referências

[1] Comunicado Pós-Incidente da DeFiTuna

Mais Incidentes desta Semana

BarnBridge

Em 15 de julho de 2026, a BarnBridge, um protocolo de alocação de rendimento no Ethereum, foi explorada por aproximadamente $776K em USDC [1]. A causa raiz foi o contrato de governança abandonado mantendo autoridade para modificar configurações críticas do protocolo. O atacante adquiriu poder de voto suficiente para aprovar uma proposta maliciosa que substituiu o controlador de um componente do protocolo, depois usou o novo controlador para transferir o USDC aprovado pelos usuários.

Contexto

A BarnBridge é um protocolo governado por DAO que aloca os fundos dos usuários em diferentes mercados de empréstimo para gerar rendimento. O poder de voto é determinado pela quantidade de BOND em staking e pelo período de bloqueio. Criar uma proposta requer poder de voto igual a pelo menos 1% do poder de voto total. Uma proposta deve atingir um quórum mínimo de 40% e receber pelo menos 60% dos votos totais participantes a favor para ser aprovada. Uma vez submetida, uma proposta passa por um período de aquecimento de dois dias, um período de votação de três dias e um período de fila de dois dias antes de poder ser executada.

Análise de Vulnerabilidade

A causa raiz foi o contrato de governança abandonado mantendo a autoridade para modificar configurações críticas do protocolo após o protocolo ter sido depreciado. O sistema de governança controlava a atribuição do Controller para o CompoundProvider, um contrato que os usuários haviam aprovado anteriormente para gastar seu USDC. Como a BarnBridge havia sido depreciada, o total de BOND em staking e a participação ativa caíram significativamente, tornando a aprovação de propostas hostis trivialmente alcançável.

Análise do Ataque

A análise a seguir é baseada na transação 0xd191fe...895afb.

O atacante gastou aproximadamente 0,335 ETH para adquirir cerca de 32.795 BOND, depois depositou e bloqueou 32.000 BOND, obtendo aproximadamente 43% do poder de voto total.

Passo 1: O atacante implantou um contrato proxy e submeteu uma proposta maliciosa. Após o período de aquecimento de dois dias, o atacante lançou todo o seu poder de voto a favor, satisfazendo tanto os requisitos de quórum quanto de aprovação.

Passo 2: O atacante colocou a proposta em fila. Após o período de fila de dois dias, o atacante a executou, definindo o Controller do CompoundProvider para o contrato proxy do atacante.

Passo 3: O atacante atualizou a lógica do contrato proxy e chamou _takeUnderlying(), que usou as permissões pendentes de USDC de aproximadamente 50 usuários para transferir seu USDC para o CompoundProvider. O atacante então chamou transferFees() para encaminhar os fundos para o endereço do atacante, obtendo um lucro de aproximadamente $776K em USDC.

Conclusão

Se um DAO ou protocolo está sendo depreciado, seu contrato de governança deve renunciar ou desabilitar permanentemente a capacidade de modificar configurações críticas de segurança, especialmente permissões de administrador, controlador e retirada de fundos. Medidas concretas incluem revogar o papel de administrador do contrato de governança sobre contratos downstream, transferir a propriedade para um endereço de queima ou executar uma proposta final que desabilite funções de atualização e defina referências de controlador para valores seguros imutáveis. Deixar a autoridade de governança intacta em um protocolo depreciado cria uma superfície de ataque de baixo custo: à medida que a participação diminui, o capital necessário para atingir o quórum cai proporcionalmente.

Referências

[1] Alerta Phalcon: Exploit da BarnBridge
Get Started with Phalcon Security
Detect every threat, alert what matters, and block attacks.
Try now for free