Mais de 40 milhões de dólares foram roubados, a GMX sofreu um ataque preciso.

Original | Odaily Odaily (@OdailyChina)

Autor | Asher（**@Asher_ 0210 ）

Na noite passada, a plataforma GMX, um dos principais protocolos DeFi em blockchain, sofreu um grave incidente de segurança, com mais de 40 milhões de dólares em ativos criptográficos sendo roubados por hackers, envolvendo vários tokens de destaque como WBTC, WETH, UNI, FRAX, LINK, USDC, USDT. Após o incidente, a Bithumb emitiu um comunicado anunciando que os serviços de depósito e retirada da GMX seriam suspensos até que a rede estivesse estável.

Devido a este incidente de roubo, o token GMX caiu mais de 25% em 4 horas, com o preço a cair temporariamente abaixo dos 11 dólares, agora cotado a 11,8 dólares. De acordo com os dados da DefiLlama, o TVL do GMX caiu de 500 milhões de dólares antes do incidente de roubo para 400 milhões de dólares, com uma queda temporária de até 20%.

A TVL da plataforma GMX foi afetada pelo incidente de roubo, caindo temporariamente para 400 milhões de dólares.

A seguir, o Odaily apresenta um resumo das razões para o incidente de roubo do GMX, a resposta da equipe e os últimos desenvolvimentos do hacker.

Atacantes exploram vulnerabilidades de reentrância

A causa fundamental do incidente de roubo da GMX reside na existência de uma vulnerabilidade de reentrada na função central executeDecreaseOrder. O primeiro parâmetro dessa função deveria ser uma conta externa (EOA), mas o atacante enviou um endereço de contrato inteligente, o que permitiu ao atacante reentrar no sistema durante o processo de resgate, manipulando o estado interno e, no final, os ativos resgatados superaram em muito o valor real do GLP que possuía.

O parceiro da Slow Fog e Chief Information Security Officer 23pds publicou na plataforma X que, na versão V1 do GMX, a criação de posições short será atualizada imediatamente no preço médio global de shorts (globalShortAveragePrices), e este preço afeta diretamente o cálculo do total dos ativos sob gestão (AUM), o que, por sua vez, afeta a avaliação e o valor de resgate do token GLP.

Os atacantes exploraram o design da GMX, que ativou a funcionalidade timelock.enableLeverage durante a execução de ordens (o que é uma condição prévia para abrir posições de venda em grande escala), e acionaram a vulnerabilidade de reentrada da função executeDecreaseOrder através de chamadas de contrato. Aproveitando essa vulnerabilidade, os atacantes criaram repetidamente posições de venda, elevando artificialmente o preço médio global de venda sem realmente alterar o preço de mercado.

Devido ao AUM depender deste preço para cálculo, a plataforma erroneamente contabilizou as perdas de posição vendida inflacionadas no total de ativos, levando a uma sobrevalorização do GLP. O atacante então resgatou o GLP, retirando ativos muito além da sua parte devida, realizando assim um lucro colossal.

Exemplo de transação de ataque: line= 93

Resposta oficial da GMX: O pool de liquidez GLP da versão V1 do GMX na Arbitrum foi alvo de um ataque de vulnerabilidade, a versão V2 do GMX não foi afetada.

Em resposta a este grave incidente de segurança, a equipe GMX já se pronunciou oficialmente. Eles publicaram na plataforma X que o pool GLP do GMX V1 na plataforma Arbitrum foi alvo de um ataque de vulnerabilidade, cerca de 40 milhões de dólares em tokens foram transferidos do pool GLP para uma carteira desconhecida, e parceiros de segurança já estão envolvidos na investigação deste ataque.

Atualmente, as plataformas Arbitrum e Avalanche desativaram as transações da versão GMX V1, bem como a função de emissão e troca do GLP, para evitar quaisquer ataques adicionais, mas essa vulnerabilidade não afeta a versão GMX V2, nem o próprio token GMX.

Devido ao ataque à versão GMX V1, os usuários podem realizar as seguintes ações para reduzir o risco:

• Desativar a função de alavancagem: pode-se chamar Vault.setIsLeverageEnabled (false) para desativá-la; se o Vault Timelock foi utilizado, deve-se chamar Timelock.setShouldToggleIsLeverageEnabled (false).
• Defina o maxUsdgAmounts de todos os tokens para “1”: use Vault.setTokenConfig ou Timelock.setTokenConfig para evitar que o GLP seja mais cunhado. É importante notar que este valor deve ser definido como “1” e não “0”, pois definir como 0 significa sem limite, o que pode levar a vulnerabilidades continuadas.

De acordo com a atualização mais recente, a equipe oficial confirmou que o ataque foi direcionado apenas à versão GMX V1, enquanto o contrato da versão GMX V2 não utiliza o mesmo mecanismo de cálculo. No entanto, por precaução, a GMX atualizou o limite de tokens da versão GMX V2 nas redes Arbitrum e Avalanche, portanto, a emissão de novos tokens na maioria dos pools de liquidez está atualmente restrita, e essa restrição será comunicada assim que for levantada.

Além disso, os dados on-chain mostram que a GMX deixou uma mensagem para o endereço do hacker, reconhecendo a exploração da vulnerabilidade da versão GMX Vl e oferecendo uma recompensa de 10% para hackers éticos. Se os 90% restantes dos fundos forem devolvidos dentro de 48 horas, prometem não tomar mais ações legais.

A GMX deixou uma mensagem para o endereço do hacker, oferecendo uma recompensa de 10% como recompensa de chapéu branco.

Hackers transferiram mais de 30 milhões de dólares para um novo endereço

Do que se pode ver na cadeia, esta é uma ação premeditada, o capital inicial do hacker foi transferido há alguns dias do protocolo de mistura de moedas privadas Tornado Cash, indicando que ele já se preparou bem para este ataque.

Após roubar mais de 40 milhões de dólares em ativos criptográficos, os hackers rapidamente transferiram mais de 30 milhões de dólares em ativos. De acordo com os dados on-chain, o endereço marcado do hacker do GMX (endereço: 88 BTC (no valor de cerca de 9,8 milhões de dólares), mais de 2200 ETH (no valor de cerca de 5,85 milhões de dólares), mais de 3 milhões de USDC, mais de 1,3 milhão de DAI foi transferido para o novo endereço 0x99cdeb84064c2bc63de0cea7c6978e272d0f2dae; mais de 4300 ETH (no valor de cerca de 11 milhões de dólares) foi transferido para o novo endereço 0x6acc60b11217a1fd0e68b0ecaee7122d34a784c1. No total, mais de 30 milhões de dólares em fundos foram transferidos para outros novos endereços.

Hackers roubaram mais de 40 milhões de dólares em ativos

O endereço do hacker ainda tem 10 milhões de dólares em fundos não transferidos.

“Detetive da cadeia” ZachXBT publicou na plataforma X criticando a Circle por sua inação em relação aos ataques de hackers. Ele afirmou que já se passaram de 1 a 2 horas desde o ataque ao GMX, mas a Circle não tomou nenhuma ação contra os hackers. Os atacantes até usaram o protocolo de transferência cruzada da Circle, CCTP, para mover os fundos roubados de Arbitrum para Ethereum.

Resumo

Este incidente de roubo não só revelou as falhas críticas na verificação de permissões de chamadores, na sequência de atualização de estado e no design do mecanismo de alavancagem da versão GMX V1, mas também soou novamente o alarme para toda a indústria: em sistemas que envolvem lógicas financeiras complexas (como alavancagem e preços dinâmicos) e caminhos de execução de contratos entrelaçados, qualquer entrada desprotegida pode evoluir para o ponto de partida de um evento cisne negro.

É importante notar que os hackers converteram a maior parte dos ativos roubados em criptomoedas mais difíceis de congelar, especialmente ativos descentralizados como ETH e DAI, e dispersaram os fundos através de vários novos endereços, tornando ainda mais difícil o rastreamento e a recuperação. A proposta do GMX de “10% de recompensa para hackers éticos em troca de isenção de responsabilidade” também expõe a realidade da falta de um mecanismo legal unificado de responsabilização no atual mundo Web3.

Para os desenvolvedores de DeFi, talvez a questão que deveriam considerar não seja “como os hackers conseguiram”, mas sim – quando o sistema gerencia ativos reais dos usuários, se mecanismos suficientes foram estabelecidos para limitar a ocorrência dos caminhos de ataque mais extremos. Caso contrário, mesmo a lógica de produto mais perfeita, uma vez que falta um design de limite de segurança, acabará inevitavelmente enfrentando o custo do risco sistêmico.