GMX enfrentou uma grande vulnerabilidade de segurança, com perdas de até 40 milhões de dólares.
Recentemente, um grave incidente de segurança direcionado a uma plataforma de negociação descentralizada chamou a atenção da indústria. Os atacantes exploraram uma vulnerabilidade de reentrada no sistema, abrindo posições vendidas com a funcionalidade de alavancagem ativada, e conseguiram executar o ataque, resultando em perdas para a plataforma de mais de 40 milhões de dólares.
O problema central do evento reside no uso 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 de ativos, manipulando o estado interno, e o valor final dos ativos resgatados ultrapassou em muito o valor real dos tokens GLP que possuía.
Em condições normais, o GLP, como token de provedor de liquidez, representa a participação do usuário nos ativos do cofre da plataforma. Quando os usuários resgatam GLP, o sistema calcula a quantidade de ativos a ser devolvida com base na proporção do GLP que o usuário detém em relação à oferta total, bem como ao total de ativos sob gestão (AUM). O cálculo do AUM envolve vários fatores, incluindo o valor total de todos os pools de tokens, ganhos e perdas não realizados de posições curtas globais, entre outros.
No entanto, quando a plataforma ativou a funcionalidade de alavancagem, os atacantes encontraram uma oportunidade para explorar vulnerabilidades do sistema. Antes de resgatar o GLP, os atacantes abriram uma grande posição de venda a descoberto em WBTC. Devido a um defeito de design do sistema, a nova posição de venda a descoberto faria com que o AUM aumentasse artificialmente, embora na realidade não trouxesse valor adicional ao tesouro. Isso fez com que o montante de resgate calculado com base no AUM inflacionado superasse em muito a parte que os atacantes deveriam receber.
Este incidente expôs sérias falhas no design do mecanismo de alavancagem e na proteção contra reentrância da plataforma. O problema central reside na lógica de resgate de ativos, que confia excessivamente no valor do AUM, sem realizar uma verificaçã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 críticas também carece de verificações obrigatórias.
Este evento alerta novamente os desenvolvedores de projetos de blockchain que, ao lidar com operações que envolvem grandes somas de dinheiro, devem garantir que o estado do sistema não seja manipulado maliciosamente. Especialmente ao introduzir lógicas financeiras complexas, como negociação com margem e produtos derivados, é necessário prevenir rigorosamente os riscos sistêmicos que podem resultar de ataques de reentrada e contaminação de estado.
Para os usuários, este evento também nos lembra de manter vigilância ao participar de projetos de finanças descentralizadas, avaliando cuidadosamente a segurança da plataforma e a capacidade de controle de riscos. Para as equipes dos projetos, será especialmente importante fortalecer as auditorias de segurança, introduzir mecanismos de validação múltipla e implementar uma gestão de permissões mais rigorosa.
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 40 milhões de dólares, com uma vulnerabilidade de reentrada expondo o risco do DEX
GMX enfrentou uma grande vulnerabilidade de segurança, com perdas de até 40 milhões de dólares.
Recentemente, um grave incidente de segurança direcionado a uma plataforma de negociação descentralizada chamou a atenção da indústria. Os atacantes exploraram uma vulnerabilidade de reentrada no sistema, abrindo posições vendidas com a funcionalidade de alavancagem ativada, e conseguiram executar o ataque, resultando em perdas para a plataforma de mais de 40 milhões de dólares.
O problema central do evento reside no uso 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 de ativos, manipulando o estado interno, e o valor final dos ativos resgatados ultrapassou em muito o valor real dos tokens GLP que possuía.
Em condições normais, o GLP, como token de provedor de liquidez, representa a participação do usuário nos ativos do cofre da plataforma. Quando os usuários resgatam GLP, o sistema calcula a quantidade de ativos a ser devolvida com base na proporção do GLP que o usuário detém em relação à oferta total, bem como ao total de ativos sob gestão (AUM). O cálculo do AUM envolve vários fatores, incluindo o valor total de todos os pools de tokens, ganhos e perdas não realizados de posições curtas globais, entre outros.
No entanto, quando a plataforma ativou a funcionalidade de alavancagem, os atacantes encontraram uma oportunidade para explorar vulnerabilidades do sistema. Antes de resgatar o GLP, os atacantes abriram uma grande posição de venda a descoberto em WBTC. Devido a um defeito de design do sistema, a nova posição de venda a descoberto faria com que o AUM aumentasse artificialmente, embora na realidade não trouxesse valor adicional ao tesouro. Isso fez com que o montante de resgate calculado com base no AUM inflacionado superasse em muito a parte que os atacantes deveriam receber.
Este incidente expôs sérias falhas no design do mecanismo de alavancagem e na proteção contra reentrância da plataforma. O problema central reside na lógica de resgate de ativos, que confia excessivamente no valor do AUM, sem realizar uma verificaçã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 críticas também carece de verificações obrigatórias.
Este evento alerta novamente os desenvolvedores de projetos de blockchain que, ao lidar com operações que envolvem grandes somas de dinheiro, devem garantir que o estado do sistema não seja manipulado maliciosamente. Especialmente ao introduzir lógicas financeiras complexas, como negociação com margem e produtos derivados, é necessário prevenir rigorosamente os riscos sistêmicos que podem resultar de ataques de reentrada e contaminação de estado.
Para os usuários, este evento também nos lembra de manter vigilância ao participar de projetos de finanças descentralizadas, avaliando cuidadosamente a segurança da plataforma e a capacidade de controle de riscos. Para as equipes dos projetos, será especialmente importante fortalecer as auditorias de segurança, introduzir mecanismos de validação múltipla e implementar uma gestão de permissões mais rigorosa.