GMX sofreu um ataque de vulnerabilidade de segurança significativa, com perdas superiores a 40 milhões de dólares
Recentemente, a conhecida plataforma de negociação descentralizada GMX enfrentou um grave incidente de segurança, resultando em perdas superiores a 40 milhões de dólares. Os atacantes exploraram uma vulnerabilidade de reentrada e realizaram o ataque através de operações de venda a descoberto, sob a condição de que o contrato ativasse a função de alavancagem.
O problema central deste ataque reside no uso incorreto da função executeDecreaseOrder. O primeiro parâmetro dessa função deveria ser o endereço de uma conta externa, mas o atacante astutamente passou um endereço de contrato inteligente. Isso permitiu que o atacante entrasse repetidamente no sistema durante o processo de resgate, manipulando o estado interno e, no final, os ativos extraídos superaram em muito o valor real de GLP que ele possuía.
No funcionamento normal do GMX, o GLP é um token de provedor de liquidez que representa a quota dos usuários nos ativos do fundo (como USDC, ETH, WBTC). Quando os usuários resgatam GLP, o sistema calcula a quantidade de ativos a serem devolvidos com base na proporção de GLP que o usuário possui e no valor total dos ativos sob gestão (AUM) atual. O cálculo do AUM envolve vários fatores, incluindo o valor total de cada pool de tokens, os lucros e perdas não realizados das posições curtas globais, entre outros.
No entanto, quando a funcionalidade de negociação alavancada da plataforma foi ativada, os atacantes encontraram uma maneira de explorar uma vulnerabilidade do sistema. Antes de resgatar o GLP, os atacantes abriram grandes posições em venda a descoberto de WBTC. Como as posições em venda a descoberto aumentam a escala global de vendas a descoberto assim que são abertas, sem que o preço tenha mudado, o sistema considera essa parte da venda a descoberto como uma perda não realizada. Essa "perda" foi erroneamente contabilizada como "ativos" no cofre, levando a um aumento artificial do AUM. Embora, na verdade, o cofre não tenha obtido valor adicional, o cálculo de resgate foi baseado nesse AUM inflacionado, fazendo com que os atacantes obtivessem ativos muito além do que realmente lhes era devido.
Este incidente expôs falhas significativas na concepção do mecanismo de alavancagem e na proteção contra reentrância da plataforma. O problema central reside na confiança excessiva da lógica de resgate de ativos no AUM, falhando em realizar uma validação de segurança adequada sobre seus componentes (como perdas não realizadas). Ao mesmo tempo, a suposição sobre a identidade do chamador nas funções-chave (se é uma conta externa ou um contrato inteligente) também carece de verificações obrigatórias.
Este incidente de segurança serve novamente como um lembrete para os desenvolvedores de projetos de blockchain de que, ao lidar com operações sensíveis a fundos, é crucial garantir que o estado do sistema não possa ser manipulado maliciosamente. Especialmente ao introduzir lógicas financeiras complexas (como negociação com margem e derivados), é ainda mais necessário prevenir rigorosamente os riscos sistêmicos que podem advir de ataques de reentrada e contaminação do estado. Para os usuários, isso também é um alerta para que sejam mais cautelosos ao participar de projetos de finanças descentralizadas, prestando atenção à segurança e à capacidade de gestão de riscos do projeto.
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 foi atacado por uma vulnerabilidade de segurança de 40 milhões de dólares, com falhas significativas no design do mecanismo de alavancagem.
GMX sofreu um ataque de vulnerabilidade de segurança significativa, com perdas superiores a 40 milhões de dólares
Recentemente, a conhecida plataforma de negociação descentralizada GMX enfrentou um grave incidente de segurança, resultando em perdas superiores a 40 milhões de dólares. Os atacantes exploraram uma vulnerabilidade de reentrada e realizaram o ataque através de operações de venda a descoberto, sob a condição de que o contrato ativasse a função de alavancagem.
O problema central deste ataque reside no uso incorreto da função executeDecreaseOrder. O primeiro parâmetro dessa função deveria ser o endereço de uma conta externa, mas o atacante astutamente passou um endereço de contrato inteligente. Isso permitiu que o atacante entrasse repetidamente no sistema durante o processo de resgate, manipulando o estado interno e, no final, os ativos extraídos superaram em muito o valor real de GLP que ele possuía.
No funcionamento normal do GMX, o GLP é um token de provedor de liquidez que representa a quota dos usuários nos ativos do fundo (como USDC, ETH, WBTC). Quando os usuários resgatam GLP, o sistema calcula a quantidade de ativos a serem devolvidos com base na proporção de GLP que o usuário possui e no valor total dos ativos sob gestão (AUM) atual. O cálculo do AUM envolve vários fatores, incluindo o valor total de cada pool de tokens, os lucros e perdas não realizados das posições curtas globais, entre outros.
No entanto, quando a funcionalidade de negociação alavancada da plataforma foi ativada, os atacantes encontraram uma maneira de explorar uma vulnerabilidade do sistema. Antes de resgatar o GLP, os atacantes abriram grandes posições em venda a descoberto de WBTC. Como as posições em venda a descoberto aumentam a escala global de vendas a descoberto assim que são abertas, sem que o preço tenha mudado, o sistema considera essa parte da venda a descoberto como uma perda não realizada. Essa "perda" foi erroneamente contabilizada como "ativos" no cofre, levando a um aumento artificial do AUM. Embora, na verdade, o cofre não tenha obtido valor adicional, o cálculo de resgate foi baseado nesse AUM inflacionado, fazendo com que os atacantes obtivessem ativos muito além do que realmente lhes era devido.
Este incidente expôs falhas significativas na concepção do mecanismo de alavancagem e na proteção contra reentrância da plataforma. O problema central reside na confiança excessiva da lógica de resgate de ativos no AUM, falhando em realizar uma validação de segurança adequada sobre seus componentes (como perdas não realizadas). Ao mesmo tempo, a suposição sobre a identidade do chamador nas funções-chave (se é uma conta externa ou um contrato inteligente) também carece de verificações obrigatórias.
Este incidente de segurança serve novamente como um lembrete para os desenvolvedores de projetos de blockchain de que, ao lidar com operações sensíveis a fundos, é crucial garantir que o estado do sistema não possa ser manipulado maliciosamente. Especialmente ao introduzir lógicas financeiras complexas (como negociação com margem e derivados), é ainda mais necessário prevenir rigorosamente os riscos sistêmicos que podem advir de ataques de reentrada e contaminação do estado. Para os usuários, isso também é um alerta para que sejam mais cautelosos ao participar de projetos de finanças descentralizadas, prestando atenção à segurança e à capacidade de gestão de riscos do projeto.