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údos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
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.