GMX foi alvo de um Hacker, com perdas superiores a 40 milhões de dólares
Recentemente, uma conhecida plataforma de negociação descentralizada sofreu um ataque de Hacker, resultando em perdas superiores a 40 milhões de dólares. Os atacantes exploraram habilmente uma vulnerabilidade de reentrância e, com a funcionalidade de alavancagem ativada na plataforma, realizaram este ataque através de operações de venda a descoberto.
O problema central do 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 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, finalmente, resgatando ativos muito superiores ao valor real de GLP que possuía.
Em condições normais, o GLP, como token de fornecedor de liquidez, representa a participação do usuário nos ativos do cofre. 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 o 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, lucros e perdas não realizados em aberto globais, entre outros.
No entanto, após ativar a função de alavancagem, o sistema apresentou uma vulnerabilidade. O atacante abriu uma grande posição de venda a descoberto em WBTC antes de resgatar GLP. Como a abertura da posição de venda a descoberto aumentou imediatamente o tamanho total da posição a descoberto, sem que o preço se alterasse, o sistema contabilizou essa parte da perda não realizada como parte dos "ativos" do tesouro, resultando em um aumento artificial do AUM. Embora o tesouro não tenha realmente obtido valor adicional, o cálculo do 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 reentradas da plataforma. O problema central reside na confiança excessiva da lógica de resgate de ativos no AUM, sem a devida verificação de segurança prudente em seus componentes (como perdas não realizadas). Ao mesmo tempo, a suposição sobre a identidade do chamador nas funções-chave carece de validação obrigatória.
Este evento lembra novamente aos desenvolvedores de projetos de blockchain 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), é necessário estar atento aos riscos sistêmicos trazidos por reentradas e contaminação de estado. Para os usuários, também é importante aumentar a vigilância e reconhecer que mesmo projetos conhecidos podem ter vulnerabilidades de segurança, sendo necessário avaliar cuidadosamente os riscos ao participar em atividades DeFi.
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 hackers, com uma falha de alavancagem que resultou em perdas superiores a 40 milhões de dólares.
GMX foi alvo de um Hacker, com perdas superiores a 40 milhões de dólares
Recentemente, uma conhecida plataforma de negociação descentralizada sofreu um ataque de Hacker, resultando em perdas superiores a 40 milhões de dólares. Os atacantes exploraram habilmente uma vulnerabilidade de reentrância e, com a funcionalidade de alavancagem ativada na plataforma, realizaram este ataque através de operações de venda a descoberto.
O problema central do 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 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, finalmente, resgatando ativos muito superiores ao valor real de GLP que possuía.
Em condições normais, o GLP, como token de fornecedor de liquidez, representa a participação do usuário nos ativos do cofre. 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 o 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, lucros e perdas não realizados em aberto globais, entre outros.
No entanto, após ativar a função de alavancagem, o sistema apresentou uma vulnerabilidade. O atacante abriu uma grande posição de venda a descoberto em WBTC antes de resgatar GLP. Como a abertura da posição de venda a descoberto aumentou imediatamente o tamanho total da posição a descoberto, sem que o preço se alterasse, o sistema contabilizou essa parte da perda não realizada como parte dos "ativos" do tesouro, resultando em um aumento artificial do AUM. Embora o tesouro não tenha realmente obtido valor adicional, o cálculo do 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 reentradas da plataforma. O problema central reside na confiança excessiva da lógica de resgate de ativos no AUM, sem a devida verificação de segurança prudente em seus componentes (como perdas não realizadas). Ao mesmo tempo, a suposição sobre a identidade do chamador nas funções-chave carece de validação obrigatória.
Este evento lembra novamente aos desenvolvedores de projetos de blockchain 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), é necessário estar atento aos riscos sistêmicos trazidos por reentradas e contaminação de estado. Para os usuários, também é importante aumentar a vigilância e reconhecer que mesmo projetos conhecidos podem ter vulnerabilidades de segurança, sendo necessário avaliar cuidadosamente os riscos ao participar em atividades DeFi.