Exploit no UNCX revela falha na contabilização de cotas por trás de prejuízo de US$ 1,5 milhão

ETH
BNB
LINK
SUI
UNI
Vulnerabilidade de Contrato Inteligentecontabilização de cotasImmunefiexploraçãoVestingperda
há 3 horasFonte: crypto.news
Exploit no UNCX revela falha na contabilização de cotas por trás de prejuízo de US$ 1,5 milhão

O exploit do Vesting V2 da UNCX expôs uma falha de contabilização de cotas que permitiu aos atacantes inflar suas reivindicações sobre tokens em pool, explicou o chefe de segurança da Immunefi após relatos de aproximadamente US$ 1,5 milhão drenados em quatro redes.

Resumo

  • As funções de saque e cancelamento deixaram a contabilização de cotas desequilibrada, segundo Magalhães.
  • As perdas relatadas chegaram a aproximadamente US$ 1,5 milhão em quatro redes, com carteiras copiadoras e bots envolvidos.
  • Magalhães aconselhou contato privado com as equipes afetadas antes de avisos públicos de saque, quando possível.
  • Provedores e projetos afetados compartilham a responsabilidade de trabalhar para o reembolso, disse ele.

Gonçalo Magalhães, chefe de segurança da Immunefi, disse ao crypto.news que o contrato falhou em manter seus contadores de cotas consistentes quando os usuários sacavam tokens adquiridos e cancelavam posições.

Saques da UNCX deixaram uma contagem de cotas desatualizada

No relato de Magalhães, a fraqueza começou com a função de liberação do contrato, que permite a um beneficiário sacar tokens que se tornaram disponíveis sob um cronograma de vesting.

Após um saque, a função falhou em subtrair as cotas liberadas do contador da posição, disse ele. Quando a função de cancelamento subsequentemente leu esse valor inalterado, subtraiu novamente a porção não adquirida, distorcendo a contabilização do pool.

Segundo o chefe de segurança, a combinação inflou o valor atribuído às cotas restantes. Um atacante poderia então usar uma posição deixada no pool para sacar mais tokens do que deveria ter recebido.

Descrevendo um ataque, Magalhães disse que o explorador abriu três posições de vesting e sacrificou duas por meio das funções de saque e cancelamento. A posição restante tornou-se elegível para um saque carregando o que ele descreveu como um "lucro massivo".

Ele identificou a falha central como a ausência de uma regra de contabilização consistente entre as funções do contrato.

"Em última análise, o contrato inteligente falhou em garantir que nenhuma função pudesse quebrar a invariante em torno do contador global de cotas."

Sua explicação coloca a fraqueza em como as funções atualizavam e reutilizavam os saldos de cotas. A salvaguarda que ele identificou foi uma regra garantindo que toda operação preservasse a precisão da contagem total de cotas.

O Crypto Times relatou em 15 de outubro que a Blockaid havia estimado perdas em aproximadamente US$ 1,49 milhão em Ethereum, BNB Chain, Base e Robinhood Chain. Seu relato atribuiu 11 transações de drenagem à atividade envolvendo o atacante original, carteiras copiadoras e bots de valor máximo extraível, ou MEV.

Intervenção privada vem antes de avisos públicos

Questionado sobre como as empresas de segurança devem responder quando um exploit permanece ativo, Magalhães disse que a resposta disponível depende do protocolo e das pessoas que podem intervir.

"Uma vez esgotadas todas as opções, há pouco a fazer além de apelar publicamente aos usuários para sacarem seus fundos imediatamente."

Magalhães não apresentou um único cronograma de divulgação adequado para todos os incidentes. Sua resposta, em vez disso, descreveu uma sequência de possíveis intervenções, começando com pessoas que poderiam ser capazes de interromper o ataque ou remover depósitos expostos.

Um relato de 6 de outubro de um cofre Base não identificado descreveu um obstáculo separado à intervenção privada. Naquele caso, Magalhães disse que um pesquisador enfrentou incerteza legal porque os operadores do cofre não foram identificados e não havia um canal claro de divulgação. O briefing do incidente estimou o roubo em aproximadamente US$ 6 milhões.

Históricos de carteiras ajudam investigadores a separar participantes

Para investigadores examinando a UNCX, Magalhães disse que os históricos de transações fornecem um ponto de partida para distinguir o explorador original de outros participantes.

A pessoa que primeiro executou o ataque geralmente aparece entre os primeiros a se mover, disse ele. Usuários estabelecidos têm registros de interações anteriores com o protocolo, enquanto carteiras de negociação automatizadas podem mostrar um histórico consistente com atividade de bot.

Investigadores podem comparar transações posteriores com a sequência usada pelo atacante original, segundo Magalhães. Um cliente anterior ainda poderia ter copiado o exploit, então um relacionamento existente com o protocolo não resolve a questão.

“Em última análise, a linha fica nebulosa e difícil de traçar.”

Um incidente separado em 15 de setembro envolvendo 2.900 rsETH na Ethereum ilustra por que os investigadores examinam a ordenação de transações. Pesquisadores de segurança disseram que o bot Yoink executou antes do suposto atacante no mesmo bloco, enquanto a transação de exploit original falhou. O bot recebeu ativos avaliados em aproximadamente US$ 7,8 milhões na época.

Sobre negociações de recuperação, o CEO da Immunefi, Mitchell Amador, levou em conta uma questão diferente de autorização em comentários sobre a Liquid Network publicados em 21 de setembro. Ele disse que os pesquisadores devem usar canais privados de divulgação e termos de recompensa acordados em vez de tomar ativos do usuário e definir uma recompensa depois.

Provedores e projetos devem trabalhar para o reembolso

Questionado sobre projetos cujos tokens estavam mantidos em infraestrutura de vesting compartilhada, Magalhães disse que as equipes devem ter seu próprio pessoal de segurança examinando qualquer provedor que adotem.

A reputação de um provedor faz parte dessa avaliação, disse ele, mas sua recomendação colocou a revisão técnica com a equipe que escolhe a infraestrutura.

Sobre a responsabilidade após um exploit, Magalhães disse que tanto o provedor responsável pelo bug quanto os projetos que o selecionaram devem trabalhar para ressarcir os usuários.

“A responsabilidade de trabalhar para ressarcir os usuários recai tanto sobre o provedor com o bug quanto sobre os projetos que confiaram nesse provedor.”

Seus comentários descreveram a responsabilidade de buscar reembolso, sem estabelecer uma fórmula de compensação ou atribuir uma porcentagem das perdas a qualquer um dos lados.

Para auditores, Magalhães distinguiu uma vulnerabilidade não detectada de uma garantia de que o código revisado não pode falhar. Ele disse que um serviço de auditoria não promete “código à prova de falhas”.

O Crypto Times relatou que a resposta da UNCX incluiu taxas mais altas destinadas a desencorajar mais exploração e coordenação com equipes afetadas, autoridades policiais e SEAL 911. De acordo com esse relato de 15 de outubro, a UNCX disse que seus bloqueadores de liquidez e contratos de vesting legados não foram afetados e planejava publicar descobertas técnicas e um plano de recuperação proposto.