Blast é uma rede Ethereum Layer 2 lançada por Pacman (Tieshun Roquerre, também conhecido como Tieshun), o fundador do Blur. Lançou a rede principal em 29 de fevereiro. Atualmente, aproximadamente 19.500 ETH e 640.000 stETH estão prometidos na rede principal Blast.
O projeto atacado Munchables é um projeto de alta qualidade que venceu a competição Bigbang organizada pela Blast.
Os funcionários do Blast emitirão pontos comuns para usuários que prometerem ETH na rede principal do Blast:
A fim de incentivar os usuários a participarem de projetos DeFi no ecossistema Blast, os funcionários do Blast selecionarão projetos de alta qualidade para recomendação e incentivarão os usuários a comprometer ETH uma segunda vez no DeFi para obter aumento mais rápido de pontos e pontos de ouro, para que haja bastante poucos usuários prometeram o ETH prometido na rede principal do Blast para o projeto DeFi recém-criado.
A maturidade e a segurança destes projetos DeFi ainda não foram examinadas, e se estes contratos têm considerações de segurança suficientes para proteger dezenas de milhões ou mesmo centenas de milhões de dólares dos utilizadores.
Visão geral do evento
Menos de um mês após a rede principal do Blast entrar no ar, ocorreu um ataque ao Token SSS (Super Sushi Samurai) em 21 de março de 2024. Houve um erro de lógica de transferência no contrato do Token, que permitiu ao invasor aumentar o Token SSS do conta especificada fora do equilíbrio, o projeto acabou perdendo mais de 1.310 ETH (aproximadamente US$ 4,6 milhões).
Menos de uma semana após o ataque ao token SSS, outro ataque maior ocorreu no Blast: o projeto Munchables foi varrido pelos invasores com 17.413,96 ETH, um total de aproximadamente 62,5 milhões de dólares americanos.
Meia hora após a transação do ataque, 73,49 WETH no contrato do projeto também foram roubados por um hacker de outro endereço.
Neste momento, ainda existem 7.276 WETH, 7.758.267 USDB e 4 ETH armazenados no endereço do contrato da parte do projeto, que cairá nas mãos de hackers a qualquer momento. O hacker tem autoridade para retirar todos os fundos de todo o projeto, totalizando aproximadamente 97 milhões de dólares.Exposto a riscos.
Imediatamente após o incidente, o conhecido detetive da rede X (Twitter), zachXBT, apontou que a causa raiz deste ataque foi a contratação de hackers de um determinado país.
Vamos dar uma olhada mais de perto em como um “hacker de um determinado país” completou um ataque no valor de quase US$ 100 milhões.
Restauração no local
Vítimas falam
[UTC+ 0] Às 21h37 do dia 26 de março de 2024 (5 minutos após o ataque), Munchables postou oficialmente no X (Twitter) informando que estava sob ataque.
De acordo com a investigação do detetive Zach, o invasor veio fazer algum trabalho de desenvolvimento de jogos. Ele era muito rude e realmente parecia um hacker chinês. Nós o demitimos em um mês. Ele também tentou nos convencer a contratar um de seus amigos, que provavelmente também era um hacker. hacker."
Como este ataque causou enormes perdas aos usuários da comunidade, lançamos imediatamente uma investigação on-chain. Vamos dar uma olhada em detalhes nos detalhes do ataque deste “hacker de um determinado país”.
Primeira cena
[UTC+ 0] Às 21h32 do dia 26 de março de 2024, ocorreu um ataque envolvendo 17.413,96 ETH.
Através do Blastscan podemos ver esta transação de ataque:
O contrato danificado (0x 29..1 F) é um contrato proxy que armazena os fundos prometidos pelo usuário. Podemos ver que o invasor chamou a função de desbloqueio do contrato de penhor, passou em todas as verificações de permissão e o transferiu. Todos os ETH em o contrato vai para o endereço do invasor 1 (0x 6 E..c 5).
Parece que o invasor chamou uma função de desbloqueio com comportamento semelhante ao de retirada e retirou a maior parte do ETH do contrato comprometido (0x 29..1 F).
A equipe do projeto esqueceu de trancar o cofre?
Existem duas verificações relacionadas para desbloqueio no contrato danificado (0x 29..1 F). Vamos examiná-las uma por uma.
Primeiro, descobrimos que durante o processo de verificação de permissão, o método isRegistered do contrato (0x 16..A 0) foi chamado para verificar se o msg.sender atual, ou seja, o endereço do hacker 1 (0x 6 E..c 5) Já cadastrado:
A resposta é: passou na verificação.
Isso envolve o contrato (0x 16..A 0) e seu último contrato lógico correspondente (0x e 7..f 1)
[UTC+ 0] Às 08h39 do dia 24 de março de 2024 (2 dias antes do ataque), o contrato lógico correspondente ao contrato (0x 16..A 0) foi atualizado.
Transação de atualização de contrato lógico:
O contrato lógico é atualizado para 0x e 7..f 1 .
O endereço lógico original do contrato pode ser visto aqui, que é 0x 9 e..CD.
Neste momento, suspeitamos que o hacker atualizou o contrato de implementação lógica do contrato do agente, que será 0x 9 e.. CD torna-se malicioso 0x e 7..f 1 , completando o desvio das permissões de verificação.
É realmente?
Na Web3.0, você nunca precisa adivinhar ou ouvir os outros. Você só precisa dominar a tecnologia para obter a resposta sozinho.
Ao comparar os dois contratos (não contratos de código aberto), existem algumas diferenças óbvias entre o contrato 0x 9 e..CD original e o 0x e 7..f 1 atualizado:
A parte da função de inicialização de 0x e 7..f 1 é implementada da seguinte forma:
A parte da função de inicialização de 0x 9 e..CD é implementada da seguinte forma:
Pode-se observar que o invasor definiu o endereço do invasor (0x 6 e..c 5) como registro no contrato lógico original (0x 9 e..CD), e também existem outros dois endereços do invasor 0x c 5 ..0 d, 0x bf..87 também são registrados e seu campo 0 é configurado para o tempo do bloco durante a inicialização. O uso do campo 0 será explicado posteriormente.
Na verdade, ao contrário do que imaginávamos, o verdadeiro contrato lógico com backdoor existia desde o início e as atualizações subsequentes foram normais!
Espere, esta atualização apareceu às 08h39 do dia 24 de março de 2024 [UTC+ 0] (2 dias antes do ataque). Ou seja, antes deste incidente, o contrato lógico havia se tornado um contrato sem backdoors. Por quê? O invasor ainda pode concluir o ataque?
Isso ocorre por causa do delegado, então a atualização real do armazenamento do estado está no contrato (0x 16..A 0), o que resulta no fato de que mesmo que o contrato lógico seja atualizado posteriormente para o contrato lógico sem backdoor 0x e 7.. f 1 , o slot alterado no contrato (0x 16..A 0) ainda não será restaurado.
Vamos verificar:
Como você pode ver, o slot correspondente no contrato (0x 16....A 0) possui um valor numérico.
Isso permite que um invasor passe na verificação do método isRegistered:
Posteriormente, o invasor altera o contrato do backdoor para um contrato normal para esconder o fato de que o backdoor já foi plantado.
Além disso, o processo de desbloqueio também envolve uma segunda verificação:
Em relação à verificação do tempo de bloqueio, esta parte serve para garantir que os ativos bloqueados não serão transferidos antes do vencimento.
O invasor precisa garantir que o tempo de bloqueio quando o desbloqueio é chamado seja maior que o tempo de expiração do bloqueio necessário (campo 3).
Esta parte da verificação envolve o contrato danificado (0x 29..1 F) e o contrato lógico correspondente 0x f 5..cd.
Em uma transação às 11h54 do dia 21 de março de 2024 [UTC+ 0] (5 dias antes do ataque),
Podemos ver que o contrato lógico original do contrato danificado (0x 29..1 F) era 0x 91..11, e apenas quatro minutos depois, em
Atualizado para 0x f 5..cd.
Também comparamos os dois contratos e podemos descobrir que o invasor também fez truques na função de inicialização como antes.
Implementação parcial da função de inicialização de 0x f 5..cd:
Implementação parcial da função de inicialização de 0x 91..11:
Pode-se observar que é óbvio que o mesmo método foi usado novamente para alterar a quantidade de ETH e o tempo de desbloqueio, e depois o substituiu pelo contrato normal para enganar os outros.Quando a equipe do projeto e os pesquisadores de segurança estavam depurando, todos os contratos lógicos vistos são normais e, como todos os contratos são contratos de código não aberto, é ainda mais difícil ver claramente o cerne do problema.
Até agora, entendemos essa transação envolvendo 17413 ETH e como o invasor fez isso, mas será que existe tanta informação por trás desse incidente?
Em nossa análise acima, vimos que o hacker incluiu 3 endereços no contrato:
0x 6 e..c 5 (endereço do invasor 1)
0x c 5..0 d (endereço do invasor 2)
0x bf..87 (endereço do invasor 3)
No entanto, na transação de ataque que encontramos acima, vimos apenas 0x 6 e..c 5. O que os outros dois endereços fizeram? E quais segredos estão ocultos em address(0), _dodoApproveAddress, _uniswapV3Factorty?
Segunda cena
Vamos primeiro dar uma olhada no endereço 3 do invasor (0x bf..87), que roubou 73,49 WETH através do mesmo método:
E ataque o endereço de origem do gás (0x 97..de) e forneça taxas de manuseio para 0x c 5..0 d (endereço do invasor 2) e 0x bf..87 (endereço do invasor 3).
A fonte do 0,1 ETH que ataca o endereço da fonte de gás (0x 97..de) vem de owlto.finance (ponte cross-chain).
0x c 5..0 d (endereço do invasor 2) não realizou nenhum ataque após receber a taxa de manuseio, mas na verdade assumiu um plano oculto. Vamos continuar a analisá-lo.
Na verdade, de acordo com a transação oficial de resgate, o endereço original do contrato danificado (0x 29..1 F) não era apenas 73,49 WETH. Até o final do ataque, ainda havia 7276,5 WETH e 7758267 USDB.
Acordo de resgate:
O invasor planejou originalmente roubar esses ativos. Você pode ver que o endereço 0x c 5..0 d (endereço do invasor 2) foi originalmente usado para roubar USDB.
O _dodoApproveAddress aqui é 0x00000000000000000000004300000000000000000000000000000000003
é o endereço do usdb
0x bf..87 (endereço do invasor 3) Este endereço é usado para roubar:
A fábrica _uniswap V3 aqui é 0x0000000000000000000000430000000000000000000000000000000004
é o endereço de wet
E 0x 6 e..c 5 (endereço do invasor 1) é responsável por roubar o endereço (0), que é o ativo nativo ETH.
Ao definir o campo 0, o invasor pode roubar os ativos correspondentes através da seguinte lógica:
pergunta
Por que o invasor não roubou todos os ativos?
Teoricamente ele pode roubar todos os ativos, nomeadamente o WETH e o USDB restantes.
0x bf..87 (endereço do invasor 3) roubou apenas 73,49 WETH. 0x bf..87 (endereço do invasor 3) pode realmente tirar todos os 7350 WETH, ou você pode usar 0x c 5..0 d (endereço do invasor 2) levou descarte todos os 7758267 USDB. Por que parou depois de levar apenas um pouco de WETH? Não sabemos. Pode ser necessário que um detetive da cadeia bem conhecido conduza uma investigação interna aprofundada.
Por que o invasor não transferiu 17413 ETH para a rede principal Ethereum?
Como todos sabemos, é possível que a rede principal do Blast intercepte esses ETH através de um método centralizado e os deixe ficar aqui permanentemente sem causar perdas substanciais aos usuários.No entanto, uma vez que esses ETH entrem na rede principal do Ethereum, não há como interceptar isto.
Avaliamos as atuais pontes cruzadas da Blast. Não há limite para o número de pontes cruzadas oficiais, mas são necessários 14 dias para sair, o que é suficiente para que os funcionários da Blast preparem um plano de interceptação.
A ponte de cadeia cruzada de terceiros pode ser creditada quase em tempo real, assim como a fonte de taxas do invasor, e pode concluir rapidamente a cadeia cruzada. Por que o invasor não cruzou a cadeia imediatamente?
Na verdade, o atacante realizou o cross-chain no primeiro momento (dentro de 2 minutos do ataque):
Além disso, demorou 20 segundos para os fundos chegarem à rede principal Ethereum. Em teoria, um invasor pode continuar a cruzar cadeias e transferir uma grande quantidade de ETH entre cadeias antes que a ponte cruzada possa intervir manualmente.
Quanto ao motivo pelo qual só pode ser 3 ETH por vez, o motivo é o limite de liquidez da ponte cross-chain, de Blast a ETH:
Outra ponte de cadeia cruzada que suporta Blast suporta ainda menos:
Após esta transação entre cadeias, o invasor não continuou outras operações entre cadeias. O motivo é desconhecido para nós. Parece que o "hacker de um determinado país" não fez os preparativos adequados para a retirada de fundos do Blast.
Desenvolvimento de eventos após o ataque
Com base no feedback do usuário da comunidade Nearisbuilding, ele encontrou mais informações de identidade do invasor e maneiras de solicitar que o invasor devolvesse os fundos.
No final, com a atenção e esforços da comunidade de criptografia, o “hacker de um determinado país”, talvez por ter medo de expor sua identidade, forneceu as chaves privadas dos três endereços dos invasores acima para a parte do projeto e devolveu todos fundos. A parte do projeto também conduziu uma transação de resgate. Transferir todos os fundos do contrato danificado para o contrato de múltiplas assinaturas para guarda.
Ver original
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.
Revisão da batalha de US$ 97 milhões da Blast Chain, os hackers de um determinado país não estão familiarizados?
fundo
Blast é uma rede Ethereum Layer 2 lançada por Pacman (Tieshun Roquerre, também conhecido como Tieshun), o fundador do Blur. Lançou a rede principal em 29 de fevereiro. Atualmente, aproximadamente 19.500 ETH e 640.000 stETH estão prometidos na rede principal Blast.
O projeto atacado Munchables é um projeto de alta qualidade que venceu a competição Bigbang organizada pela Blast.
Os funcionários do Blast emitirão pontos comuns para usuários que prometerem ETH na rede principal do Blast:
A fim de incentivar os usuários a participarem de projetos DeFi no ecossistema Blast, os funcionários do Blast selecionarão projetos de alta qualidade para recomendação e incentivarão os usuários a comprometer ETH uma segunda vez no DeFi para obter aumento mais rápido de pontos e pontos de ouro, para que haja bastante poucos usuários prometeram o ETH prometido na rede principal do Blast para o projeto DeFi recém-criado.
A maturidade e a segurança destes projetos DeFi ainda não foram examinadas, e se estes contratos têm considerações de segurança suficientes para proteger dezenas de milhões ou mesmo centenas de milhões de dólares dos utilizadores.
Visão geral do evento
Menos de um mês após a rede principal do Blast entrar no ar, ocorreu um ataque ao Token SSS (Super Sushi Samurai) em 21 de março de 2024. Houve um erro de lógica de transferência no contrato do Token, que permitiu ao invasor aumentar o Token SSS do conta especificada fora do equilíbrio, o projeto acabou perdendo mais de 1.310 ETH (aproximadamente US$ 4,6 milhões).
Menos de uma semana após o ataque ao token SSS, outro ataque maior ocorreu no Blast: o projeto Munchables foi varrido pelos invasores com 17.413,96 ETH, um total de aproximadamente 62,5 milhões de dólares americanos.
Meia hora após a transação do ataque, 73,49 WETH no contrato do projeto também foram roubados por um hacker de outro endereço.
Neste momento, ainda existem 7.276 WETH, 7.758.267 USDB e 4 ETH armazenados no endereço do contrato da parte do projeto, que cairá nas mãos de hackers a qualquer momento. O hacker tem autoridade para retirar todos os fundos de todo o projeto, totalizando aproximadamente 97 milhões de dólares.Exposto a riscos.
Imediatamente após o incidente, o conhecido detetive da rede X (Twitter), zachXBT, apontou que a causa raiz deste ataque foi a contratação de hackers de um determinado país.
Vamos dar uma olhada mais de perto em como um “hacker de um determinado país” completou um ataque no valor de quase US$ 100 milhões.
Restauração no local
Vítimas falam
[UTC+ 0] Às 21h37 do dia 26 de março de 2024 (5 minutos após o ataque), Munchables postou oficialmente no X (Twitter) informando que estava sob ataque.
De acordo com a investigação do detetive Zach, o invasor veio fazer algum trabalho de desenvolvimento de jogos. Ele era muito rude e realmente parecia um hacker chinês. Nós o demitimos em um mês. Ele também tentou nos convencer a contratar um de seus amigos, que provavelmente também era um hacker. hacker."
Como este ataque causou enormes perdas aos usuários da comunidade, lançamos imediatamente uma investigação on-chain. Vamos dar uma olhada em detalhes nos detalhes do ataque deste “hacker de um determinado país”.
Primeira cena
[UTC+ 0] Às 21h32 do dia 26 de março de 2024, ocorreu um ataque envolvendo 17.413,96 ETH.
Através do Blastscan podemos ver esta transação de ataque:
O contrato danificado (0x 29..1 F) é um contrato proxy que armazena os fundos prometidos pelo usuário. Podemos ver que o invasor chamou a função de desbloqueio do contrato de penhor, passou em todas as verificações de permissão e o transferiu. Todos os ETH em o contrato vai para o endereço do invasor 1 (0x 6 E..c 5).
Parece que o invasor chamou uma função de desbloqueio com comportamento semelhante ao de retirada e retirou a maior parte do ETH do contrato comprometido (0x 29..1 F).
A equipe do projeto esqueceu de trancar o cofre?
Existem duas verificações relacionadas para desbloqueio no contrato danificado (0x 29..1 F). Vamos examiná-las uma por uma.
Primeiro, descobrimos que durante o processo de verificação de permissão, o método isRegistered do contrato (0x 16..A 0) foi chamado para verificar se o msg.sender atual, ou seja, o endereço do hacker 1 (0x 6 E..c 5) Já cadastrado:
A resposta é: passou na verificação.
Isso envolve o contrato (0x 16..A 0) e seu último contrato lógico correspondente (0x e 7..f 1)
[UTC+ 0] Às 08h39 do dia 24 de março de 2024 (2 dias antes do ataque), o contrato lógico correspondente ao contrato (0x 16..A 0) foi atualizado.
Transação de atualização de contrato lógico:
O contrato lógico é atualizado para 0x e 7..f 1 .
O endereço lógico original do contrato pode ser visto aqui, que é 0x 9 e..CD.
É realmente?
Na Web3.0, você nunca precisa adivinhar ou ouvir os outros. Você só precisa dominar a tecnologia para obter a resposta sozinho.
Ao comparar os dois contratos (não contratos de código aberto), existem algumas diferenças óbvias entre o contrato 0x 9 e..CD original e o 0x e 7..f 1 atualizado:
A parte da função de inicialização de 0x e 7..f 1 é implementada da seguinte forma:
A parte da função de inicialização de 0x 9 e..CD é implementada da seguinte forma:
Pode-se observar que o invasor definiu o endereço do invasor (0x 6 e..c 5) como registro no contrato lógico original (0x 9 e..CD), e também existem outros dois endereços do invasor 0x c 5 ..0 d, 0x bf..87 também são registrados e seu campo 0 é configurado para o tempo do bloco durante a inicialização. O uso do campo 0 será explicado posteriormente.
Na verdade, ao contrário do que imaginávamos, o verdadeiro contrato lógico com backdoor existia desde o início e as atualizações subsequentes foram normais!
Espere, esta atualização apareceu às 08h39 do dia 24 de março de 2024 [UTC+ 0] (2 dias antes do ataque). Ou seja, antes deste incidente, o contrato lógico havia se tornado um contrato sem backdoors. Por quê? O invasor ainda pode concluir o ataque?
Isso ocorre por causa do delegado, então a atualização real do armazenamento do estado está no contrato (0x 16..A 0), o que resulta no fato de que mesmo que o contrato lógico seja atualizado posteriormente para o contrato lógico sem backdoor 0x e 7.. f 1 , o slot alterado no contrato (0x 16..A 0) ainda não será restaurado.
Vamos verificar:
Como você pode ver, o slot correspondente no contrato (0x 16....A 0) possui um valor numérico.
Isso permite que um invasor passe na verificação do método isRegistered:
Posteriormente, o invasor altera o contrato do backdoor para um contrato normal para esconder o fato de que o backdoor já foi plantado.
Além disso, o processo de desbloqueio também envolve uma segunda verificação:
Em relação à verificação do tempo de bloqueio, esta parte serve para garantir que os ativos bloqueados não serão transferidos antes do vencimento.
O invasor precisa garantir que o tempo de bloqueio quando o desbloqueio é chamado seja maior que o tempo de expiração do bloqueio necessário (campo 3).
Esta parte da verificação envolve o contrato danificado (0x 29..1 F) e o contrato lógico correspondente 0x f 5..cd.
Em uma transação às 11h54 do dia 21 de março de 2024 [UTC+ 0] (5 dias antes do ataque),
Podemos ver que o contrato lógico original do contrato danificado (0x 29..1 F) era 0x 91..11, e apenas quatro minutos depois, em
Atualizado para 0x f 5..cd.
Também comparamos os dois contratos e podemos descobrir que o invasor também fez truques na função de inicialização como antes.
Implementação parcial da função de inicialização de 0x f 5..cd:
Implementação parcial da função de inicialização de 0x 91..11:
Pode-se observar que é óbvio que o mesmo método foi usado novamente para alterar a quantidade de ETH e o tempo de desbloqueio, e depois o substituiu pelo contrato normal para enganar os outros.Quando a equipe do projeto e os pesquisadores de segurança estavam depurando, todos os contratos lógicos vistos são normais e, como todos os contratos são contratos de código não aberto, é ainda mais difícil ver claramente o cerne do problema.
Até agora, entendemos essa transação envolvendo 17413 ETH e como o invasor fez isso, mas será que existe tanta informação por trás desse incidente?
Em nossa análise acima, vimos que o hacker incluiu 3 endereços no contrato:
0x 6 e..c 5 (endereço do invasor 1)
0x c 5..0 d (endereço do invasor 2)
0x bf..87 (endereço do invasor 3)
No entanto, na transação de ataque que encontramos acima, vimos apenas 0x 6 e..c 5. O que os outros dois endereços fizeram? E quais segredos estão ocultos em address(0), _dodoApproveAddress, _uniswapV3Factorty?
Segunda cena
Vamos primeiro dar uma olhada no endereço 3 do invasor (0x bf..87), que roubou 73,49 WETH através do mesmo método:
E ataque o endereço de origem do gás (0x 97..de) e forneça taxas de manuseio para 0x c 5..0 d (endereço do invasor 2) e 0x bf..87 (endereço do invasor 3).
A fonte do 0,1 ETH que ataca o endereço da fonte de gás (0x 97..de) vem de owlto.finance (ponte cross-chain).
0x c 5..0 d (endereço do invasor 2) não realizou nenhum ataque após receber a taxa de manuseio, mas na verdade assumiu um plano oculto. Vamos continuar a analisá-lo.
Na verdade, de acordo com a transação oficial de resgate, o endereço original do contrato danificado (0x 29..1 F) não era apenas 73,49 WETH. Até o final do ataque, ainda havia 7276,5 WETH e 7758267 USDB.
Acordo de resgate:
O invasor planejou originalmente roubar esses ativos. Você pode ver que o endereço 0x c 5..0 d (endereço do invasor 2) foi originalmente usado para roubar USDB.
O _dodoApproveAddress aqui é 0x00000000000000000000004300000000000000000000000000000000003
é o endereço do usdb
0x bf..87 (endereço do invasor 3) Este endereço é usado para roubar:
A fábrica _uniswap V3 aqui é 0x0000000000000000000000430000000000000000000000000000000004
é o endereço de wet
E 0x 6 e..c 5 (endereço do invasor 1) é responsável por roubar o endereço (0), que é o ativo nativo ETH.
Ao definir o campo 0, o invasor pode roubar os ativos correspondentes através da seguinte lógica:
pergunta
Por que o invasor não roubou todos os ativos?
Teoricamente ele pode roubar todos os ativos, nomeadamente o WETH e o USDB restantes.
0x bf..87 (endereço do invasor 3) roubou apenas 73,49 WETH. 0x bf..87 (endereço do invasor 3) pode realmente tirar todos os 7350 WETH, ou você pode usar 0x c 5..0 d (endereço do invasor 2) levou descarte todos os 7758267 USDB. Por que parou depois de levar apenas um pouco de WETH? Não sabemos. Pode ser necessário que um detetive da cadeia bem conhecido conduza uma investigação interna aprofundada.
Por que o invasor não transferiu 17413 ETH para a rede principal Ethereum?
Como todos sabemos, é possível que a rede principal do Blast intercepte esses ETH através de um método centralizado e os deixe ficar aqui permanentemente sem causar perdas substanciais aos usuários.No entanto, uma vez que esses ETH entrem na rede principal do Ethereum, não há como interceptar isto.
Avaliamos as atuais pontes cruzadas da Blast. Não há limite para o número de pontes cruzadas oficiais, mas são necessários 14 dias para sair, o que é suficiente para que os funcionários da Blast preparem um plano de interceptação.
A ponte de cadeia cruzada de terceiros pode ser creditada quase em tempo real, assim como a fonte de taxas do invasor, e pode concluir rapidamente a cadeia cruzada. Por que o invasor não cruzou a cadeia imediatamente?
Na verdade, o atacante realizou o cross-chain no primeiro momento (dentro de 2 minutos do ataque):
Além disso, demorou 20 segundos para os fundos chegarem à rede principal Ethereum. Em teoria, um invasor pode continuar a cruzar cadeias e transferir uma grande quantidade de ETH entre cadeias antes que a ponte cruzada possa intervir manualmente.
Quanto ao motivo pelo qual só pode ser 3 ETH por vez, o motivo é o limite de liquidez da ponte cross-chain, de Blast a ETH:
Outra ponte de cadeia cruzada que suporta Blast suporta ainda menos:
Após esta transação entre cadeias, o invasor não continuou outras operações entre cadeias. O motivo é desconhecido para nós. Parece que o "hacker de um determinado país" não fez os preparativos adequados para a retirada de fundos do Blast.
Desenvolvimento de eventos após o ataque
Com base no feedback do usuário da comunidade Nearisbuilding, ele encontrou mais informações de identidade do invasor e maneiras de solicitar que o invasor devolvesse os fundos.
No final, com a atenção e esforços da comunidade de criptografia, o “hacker de um determinado país”, talvez por ter medo de expor sua identidade, forneceu as chaves privadas dos três endereços dos invasores acima para a parte do projeto e devolveu todos fundos. A parte do projeto também conduziu uma transação de resgate. Transferir todos os fundos do contrato danificado para o contrato de múltiplas assinaturas para guarda.