GMX foi alvo de um Hacker, resultando em perdas superiores a 40 milhões de dólares. Os atacantes exploraram uma vulnerabilidade de reentrância e estabeleceram posições curtas sob a condição de o contrato ativar a funcionalidade de alavancagem para implementar o ataque.
O cerne do problema está no uso incorreto da função executeDecreaseOrder. O primeiro parâmetro dessa função deve ser uma conta externa (EOA), mas o atacante passou um endereço de contrato inteligente. Isso permitiu que o atacante reentrasse no sistema durante o processo de resgate, manipulando o estado interno, e os ativos resgatados acabaram superando em muito o valor real de GLP que possuía.
No GMX, GLP é o token de provedor de liquidez, que representa uma participação nos ativos do tesouro (como USDC, ETH, WBTC). Normalmente, quando os usuários resgatam GLP, o sistema calcula a quantidade de ativos a serem devolvidos com base na proporção de GLP detida pelo usuário e no total de ativos sob gestão (AUM) atual. O cálculo do AUM inclui o valor total de todos os pools de tokens, ganhos e perdas não realizados das posições curtas globais, montantes reservados e deduções pré-definidas.
No entanto, após ativar a função de alavancagem, o sistema apresentou uma vulnerabilidade. O atacante abriu uma grande posição curta de WBTC antes de resgatar o GLP. Como a posição curta aumentou imediatamente o tamanho total das posições curtas, sem que o preço tivesse mudado, o sistema considerou que essa posição estava em perda. Essa parte da perda não realizada foi erroneamente contabilizada como "ativos" no tesouro, levando a um aumento artificial do AUM. Embora o tesouro não tenha realmente obtido valor adicional, o cálculo de resgate foi baseado nesse AUM inflacionado, permitindo que o atacante obtivesse ativos muito além do que lhe era devido.
Este ataque expôs sérias falhas no mecanismo de alavancagem e no design de proteção contra reentrância do GMX. O problema central reside na confiança excessiva da lógica de resgate de ativos em relação ao AUM, sem realizar verificações de segurança suficientemente cautelosas sobre seus componentes (como perdas não realizadas). Ao mesmo tempo, a suposição da identidade do chamador nas funções-chave (EOA vs contrato) também carece de validação obrigatória.
Este evento lembra novamente aos desenvolvedores que, ao lidar com operações sensíveis a fundos, é essencial garantir que o estado do sistema não possa ser manipulado. Especialmente ao introduzir lógicas financeiras complexas (como alavancagem e derivados), é ainda mais necessário prevenir os riscos sistêmicos associados a reentradas e contaminação de estado. A equipe de desenvolvimento deve reavaliar o design de seus contratos, reforçar as medidas de segurança e considerar a introdução de mecanismos de autenticação mais rigorosos e verificações de estado, a fim de evitar que ataques semelhantes ocorram novamente.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
GMX sofreu um ataque de Hacker, uma vulnerabilidade de reentrada causou uma perda de 40 milhões de dólares.
GMX foi alvo de um Hacker, resultando em perdas superiores a 40 milhões de dólares. Os atacantes exploraram uma vulnerabilidade de reentrância e estabeleceram posições curtas sob a condição de o contrato ativar a funcionalidade de alavancagem para implementar o ataque.
O cerne do problema está no uso incorreto da função executeDecreaseOrder. O primeiro parâmetro dessa função deve ser uma conta externa (EOA), mas o atacante passou um endereço de contrato inteligente. Isso permitiu que o atacante reentrasse no sistema durante o processo de resgate, manipulando o estado interno, e os ativos resgatados acabaram superando em muito o valor real de GLP que possuía.
No GMX, GLP é o token de provedor de liquidez, que representa uma participação nos ativos do tesouro (como USDC, ETH, WBTC). Normalmente, quando os usuários resgatam GLP, o sistema calcula a quantidade de ativos a serem devolvidos com base na proporção de GLP detida pelo usuário e no total de ativos sob gestão (AUM) atual. O cálculo do AUM inclui o valor total de todos os pools de tokens, ganhos e perdas não realizados das posições curtas globais, montantes reservados e deduções pré-definidas.
No entanto, após ativar a função de alavancagem, o sistema apresentou uma vulnerabilidade. O atacante abriu uma grande posição curta de WBTC antes de resgatar o GLP. Como a posição curta aumentou imediatamente o tamanho total das posições curtas, sem que o preço tivesse mudado, o sistema considerou que essa posição estava em perda. Essa parte da perda não realizada foi erroneamente contabilizada como "ativos" no tesouro, levando a um aumento artificial do AUM. Embora o tesouro não tenha realmente obtido valor adicional, o cálculo de resgate foi baseado nesse AUM inflacionado, permitindo que o atacante obtivesse ativos muito além do que lhe era devido.
Este ataque expôs sérias falhas no mecanismo de alavancagem e no design de proteção contra reentrância do GMX. O problema central reside na confiança excessiva da lógica de resgate de ativos em relação ao AUM, sem realizar verificações de segurança suficientemente cautelosas sobre seus componentes (como perdas não realizadas). Ao mesmo tempo, a suposição da identidade do chamador nas funções-chave (EOA vs contrato) também carece de validação obrigatória.
Este evento lembra novamente aos desenvolvedores que, ao lidar com operações sensíveis a fundos, é essencial garantir que o estado do sistema não possa ser manipulado. Especialmente ao introduzir lógicas financeiras complexas (como alavancagem e derivados), é ainda mais necessário prevenir os riscos sistêmicos associados a reentradas e contaminação de estado. A equipe de desenvolvimento deve reavaliar o design de seus contratos, reforçar as medidas de segurança e considerar a introdução de mecanismos de autenticação mais rigorosos e verificações de estado, a fim de evitar que ataques semelhantes ocorram novamente.