Revisão e Reflexão sobre a Ação de Resgate de Emergência Web3
No dia 18 de janeiro de 2022, o nosso sistema de monitoramento de transações anômalas detectou um ataque ao projeto AnySwap (, ou seja, Multichain ). Devido a uma vulnerabilidade na função anySwapOutUnderlyingWithPermit(), os tokens autorizados pelos usuários a este projeto podem ser roubados por atacantes.
Apesar de a equipe do projeto ter adotado várias formas de alertar os usuários afetados (, como o envio de lembretes de transação ), ainda há muitos usuários que não revogaram a autorização a tempo, permitindo que os atacantes continuem a lucrar.
Dado que o ataque ainda está em andamento, a equipe BlockSec decidiu tomar medidas de resposta de emergência para proteger potenciais vítimas. Estamos focando principalmente nas contas afetadas na Ethereum, transferindo os fundos relevantes para uma conta de multiassinatura criada especificamente para esse fim. Para garantir a transparência da ação, vamos divulgar o hash do arquivo do resumo do plano (, não o conteúdo ), para a comunidade, de modo a diferenciar nossas ações das dos atacantes, sem revelar detalhes. A operação de resgate começou em 21 de janeiro de 2022 e terminou em 11 de março.
A resposta a emergências enfrenta muitos desafios técnicos e não técnicos. Agora que a ação terminou, podemos rever todo o processo e compartilhar experiências e aprendizados com a comunidade, na esperança de que isso possa contribuir para a segurança do ecossistema DeFi.
Resumo
O uso generalizado dos Flashbots levou a uma intensa competição entre os white hats e os atacantes, bem como dentro de cada um dos seus respectivos grupos, com as taxas pagas a crescer rapidamente ao longo do tempo.
Flashbots não são uma solução perfeita, certos atacantes optam por usar o mempool, executando ataques com transações astutamente organizadas.
Alguns atacantes chegaram a um acordo com a equipe do projeto, devolvendo parte dos ganhos e mantendo uma parte como recompensa, conseguindo assim "lavar" o dinheiro. Esta prática gerou controvérsia na comunidade.
O chapéu branco pode agir publicamente para a comunidade sem revelar informações sensíveis, e esse método de ganhar confiança é eficaz.
A colaboração de várias forças da comunidade pode tornar o socorro mais rápido e eficaz, como a colaboração entre hackers éticos para reduzir a competição inútil.
Vamos discutir a seguir em quatro aspectos: primeiro, revisar a situação geral do evento; em seguida, apresentar os métodos de resgate e os desafios enfrentados; depois, compartilhar as experiências e aprendizados da ação; e, por último, apresentar algumas sugestões.
Visão geral dos ataques e operações de resgate
Resultado Geral
O intervalo de tempo que observamos é de 18 de janeiro de 2022 a 20 de março de 2022. A situação geral é a seguinte:
9 contas de resgate protegeram 483.027693 ETH, das quais 295.970554 ETH foram pagos em taxas da Flashbots, ocupando 61.27%(.
21 contas de ataque lucraram 1433.092224 ETH, pagaram taxas da Flashbots 148.903707 ETH) representa 10.39%(
É importante notar que, devido a algumas situações complexas ), como o retorno de parte dos lucros após negociações entre atacantes e a equipe do projeto (, esses dados são apenas estatísticas aproximadas.
Os "white hats" precisam competir com os atacantes para enviar transações Flashbots a fim de implementar resgates, e as taxas pagas refletem o nível de competição. Estabelecemos a proporção das taxas Flashbots para transações de ataque e resgate com base nos blocos de transação.
No início, as taxas de Flashbots para transações de ataque eram 0, indicando que os atacantes ainda não estavam utilizando Flashbots. Em seguida, a proporção das taxas aumentou rapidamente, chegando a 80% e 91% em alguns blocos. Isso indica que evoluiu para uma corrida armamentista de taxas para a disputa pelo direito de registrar em Flashbots.
As ações de resgate que implementamos e os desafios que enfrentamos
) A linha de pensamento básica da ação de resgate
Monitorizamos uma série de contas potenciais vítimas que autorizaram WETH a um contrato problemático. Quando WETH é transferido para essas contas, utilizamos uma vulnerabilidade do contrato para transferi-lo para a carteira multi-assinatura de "chapéu branco". O essencial é satisfazer os seguintes três pontos:
Localização eficaz da transação de transferência para a vítima ### transação de transferência (
Construir corretamente a transação de resgate ) salvar transação (
Conseguir antecipar-se ao ataque de ) ou de outros terceiros ( em transações ) ataque de transações (
Os dois primeiros pontos não constituem um obstáculo para nós, pois temos um sistema de monitoramento do mempool e ferramentas para construir automaticamente transações de resgate. Mas o terceiro ponto ainda é desafiador.
Embora teoricamente seja possível ganhar um front-running com Flashbots, na prática não é uma tarefa fácil. Primeiro, os atacantes também podem usar Flashbots, e a taxa de sucesso depende do valor da oferta. Em segundo lugar, a intensa concorrência faz com que Flashbots nem sempre seja a melhor opção, e também enviamos transações normais através do mempool. Por fim, também competimos com outros "white hats", e certos comportamentos de alguns "white hats" são, na verdade, bastante suspeitos.
) Situação competitiva
Estamos a tentar proteger 171 contas potenciais de vítimas independentes. Destas, 10 revogaram a autorização de forma atempada, e entre as restantes 161, apenas conseguimos resgatar 14. As falhas envolvem 3 contas de resgate e 16 contas de ataque.
Durante o processo de resgate, fomos derrotados 12 vezes por outros concorrentes, incluindo 2 contas de resgate e 10 contas de ataque.
A nossa estratégia é relativamente conservadora, tendendo a definir taxas de Flashbots mais baixas para proteger os interesses das vítimas. A menos que já existam transações de ataque bem-sucedidas que utilizem Flashbots, não iremos usar ou aumentar proativamente as taxas. No entanto, essa estratégia tem tido um desempenho fraco, pois os adversários costumam ser mais agressivos:
Um atacante definiu a proporção de taxas em 70%
Um hacker ético definiu a proporção de taxas em 79%, 80%
Outro hacker ético definiu a proporção de taxas como 81%
O atacante, em seguida, aumentou a proporção de taxas para 86%
Parece ser um jogo de soma zero, onde é necessário modelar e explorar os padrões de comportamento das partes envolvidas. Na prática, é um desafio encontrar a estratégia ótima para vencer a concorrência, ao mesmo tempo em que se tenta reduzir custos.
A intensa concorrência faz com que os Flashbots nem sempre funcionem. Enviando transações normais através do mempool, se puderem ser posicionadas adequadamente ### logo após a transação de transferência (, também pode ser possível alcançar o objetivo.
Um atacante utilizou esta estratégia para obter um lucro de 312 ETH, sem precisar pagar as taxas da Flashbots. Por exemplo:
Bloco 14051020: a transação do vítima está na posição 65, a transação de ataque está na posição 66
Bloco 14052155: Transação do vítima localizada em 161, transação de ataque localizada em 164
Esta estratégia engenhosa combina praticidade e inspiração, merecendo atenção.
Identificar um white hat nem sempre é straightforward. Por exemplo, uma conta inicialmente marcada como atacante, após negociação com a equipe do projeto, concordou em manter 50 ETH como recompensa e devolver os outros lucros, sendo posteriormente remarcada como white hat.
Este fenómeno não é novo e a equidade do seu mecanismo de incentivo gerou controvérsia na comunidade.
Competição de White Hats
É necessário que a comunidade estabeleça um mecanismo de coordenação para reduzir a competição entre os hackers éticos. Essa competição não só desperdiça recursos, como também eleva os custos de resgate. Por exemplo, nós e outras três organizações de hackers éticos tentamos simultaneamente proteger 54 vítimas ### envolvendo 450 ETH(. Sem um mecanismo de coordenação, é difícil para os hackers éticos desistirem ou pararem essa competição.
) Melhorar as operações de resgate
Os hackers éticos podem agir em público na comunidade sem divulgar informações sensíveis, e essa prática tem bons resultados.
As várias partes da comunidade podem colaborar para aumentar a eficiência do resgate:
Flashbots/miners fornecem um canal verde para white hats confiáveis
A equipe do projeto assume os custos da Flashbots
A equipe do projeto adotou um mecanismo de alerta para usuários mais conveniente
A equipe do projeto adicionou medidas de emergência no código.
Através do esforço conjunto de todas as partes, podemos enfrentar melhor os desafios de segurança no ecossistema Web3 e proteger os interesses dos usuários.
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.
18 gostos
Recompensa
18
5
Partilhar
Comentar
0/400
SchrodingerAirdrop
· 08-06 16:46
Prevenir é melhor que remediar.
Ver originalResponder0
ShibaSunglasses
· 08-05 22:39
Análise de casos clássicos de Hacker
Ver originalResponder0
LiquiditySurfer
· 08-05 22:28
O resgate foi rápido e muito profissional
Ver originalResponder0
MidnightTrader
· 08-05 22:25
Prevenir é sempre mais importante do que socorrer.
Ver originalResponder0
SmartContractWorker
· 08-05 22:18
O código do contrato deve ser auditado mais vezes.
Registro de Ataques e Defesas em Web3: Experiências e Lições da Operação de Resgate AnySwap
Revisão e Reflexão sobre a Ação de Resgate de Emergência Web3
No dia 18 de janeiro de 2022, o nosso sistema de monitoramento de transações anômalas detectou um ataque ao projeto AnySwap (, ou seja, Multichain ). Devido a uma vulnerabilidade na função anySwapOutUnderlyingWithPermit(), os tokens autorizados pelos usuários a este projeto podem ser roubados por atacantes.
Apesar de a equipe do projeto ter adotado várias formas de alertar os usuários afetados (, como o envio de lembretes de transação ), ainda há muitos usuários que não revogaram a autorização a tempo, permitindo que os atacantes continuem a lucrar.
Dado que o ataque ainda está em andamento, a equipe BlockSec decidiu tomar medidas de resposta de emergência para proteger potenciais vítimas. Estamos focando principalmente nas contas afetadas na Ethereum, transferindo os fundos relevantes para uma conta de multiassinatura criada especificamente para esse fim. Para garantir a transparência da ação, vamos divulgar o hash do arquivo do resumo do plano (, não o conteúdo ), para a comunidade, de modo a diferenciar nossas ações das dos atacantes, sem revelar detalhes. A operação de resgate começou em 21 de janeiro de 2022 e terminou em 11 de março.
A resposta a emergências enfrenta muitos desafios técnicos e não técnicos. Agora que a ação terminou, podemos rever todo o processo e compartilhar experiências e aprendizados com a comunidade, na esperança de que isso possa contribuir para a segurança do ecossistema DeFi.
Resumo
O uso generalizado dos Flashbots levou a uma intensa competição entre os white hats e os atacantes, bem como dentro de cada um dos seus respectivos grupos, com as taxas pagas a crescer rapidamente ao longo do tempo.
Flashbots não são uma solução perfeita, certos atacantes optam por usar o mempool, executando ataques com transações astutamente organizadas.
Alguns atacantes chegaram a um acordo com a equipe do projeto, devolvendo parte dos ganhos e mantendo uma parte como recompensa, conseguindo assim "lavar" o dinheiro. Esta prática gerou controvérsia na comunidade.
O chapéu branco pode agir publicamente para a comunidade sem revelar informações sensíveis, e esse método de ganhar confiança é eficaz.
A colaboração de várias forças da comunidade pode tornar o socorro mais rápido e eficaz, como a colaboração entre hackers éticos para reduzir a competição inútil.
Vamos discutir a seguir em quatro aspectos: primeiro, revisar a situação geral do evento; em seguida, apresentar os métodos de resgate e os desafios enfrentados; depois, compartilhar as experiências e aprendizados da ação; e, por último, apresentar algumas sugestões.
Visão geral dos ataques e operações de resgate
Resultado Geral
O intervalo de tempo que observamos é de 18 de janeiro de 2022 a 20 de março de 2022. A situação geral é a seguinte:
É importante notar que, devido a algumas situações complexas ), como o retorno de parte dos lucros após negociações entre atacantes e a equipe do projeto (, esses dados são apenas estatísticas aproximadas.
![])https://img-cdn.gateio.im/webp-social/moments-502b402f7119932988948ba461367a19.webp(
) Tendência de variação das taxas Flashbots
Os "white hats" precisam competir com os atacantes para enviar transações Flashbots a fim de implementar resgates, e as taxas pagas refletem o nível de competição. Estabelecemos a proporção das taxas Flashbots para transações de ataque e resgate com base nos blocos de transação.
No início, as taxas de Flashbots para transações de ataque eram 0, indicando que os atacantes ainda não estavam utilizando Flashbots. Em seguida, a proporção das taxas aumentou rapidamente, chegando a 80% e 91% em alguns blocos. Isso indica que evoluiu para uma corrida armamentista de taxas para a disputa pelo direito de registrar em Flashbots.
![]###https://img-cdn.gateio.im/webp-social/moments-30d2c3346816e15ab7c89a6a25d0ad83.webp(
As ações de resgate que implementamos e os desafios que enfrentamos
) A linha de pensamento básica da ação de resgate
Monitorizamos uma série de contas potenciais vítimas que autorizaram WETH a um contrato problemático. Quando WETH é transferido para essas contas, utilizamos uma vulnerabilidade do contrato para transferi-lo para a carteira multi-assinatura de "chapéu branco". O essencial é satisfazer os seguintes três pontos:
Os dois primeiros pontos não constituem um obstáculo para nós, pois temos um sistema de monitoramento do mempool e ferramentas para construir automaticamente transações de resgate. Mas o terceiro ponto ainda é desafiador.
Embora teoricamente seja possível ganhar um front-running com Flashbots, na prática não é uma tarefa fácil. Primeiro, os atacantes também podem usar Flashbots, e a taxa de sucesso depende do valor da oferta. Em segundo lugar, a intensa concorrência faz com que Flashbots nem sempre seja a melhor opção, e também enviamos transações normais através do mempool. Por fim, também competimos com outros "white hats", e certos comportamentos de alguns "white hats" são, na verdade, bastante suspeitos.
) Situação competitiva
Estamos a tentar proteger 171 contas potenciais de vítimas independentes. Destas, 10 revogaram a autorização de forma atempada, e entre as restantes 161, apenas conseguimos resgatar 14. As falhas envolvem 3 contas de resgate e 16 contas de ataque.
![]###https://img-cdn.gateio.im/webp-social/moments-d22626977feebe325b02c899454022c7.webp(
Lições Aprendidas
) Configuração de taxas Flashbots
Durante o processo de resgate, fomos derrotados 12 vezes por outros concorrentes, incluindo 2 contas de resgate e 10 contas de ataque.
A nossa estratégia é relativamente conservadora, tendendo a definir taxas de Flashbots mais baixas para proteger os interesses das vítimas. A menos que já existam transações de ataque bem-sucedidas que utilizem Flashbots, não iremos usar ou aumentar proativamente as taxas. No entanto, essa estratégia tem tido um desempenho fraco, pois os adversários costumam ser mais agressivos:
Parece ser um jogo de soma zero, onde é necessário modelar e explorar os padrões de comportamento das partes envolvidas. Na prática, é um desafio encontrar a estratégia ótima para vencer a concorrência, ao mesmo tempo em que se tenta reduzir custos.
![]###https://img-cdn.gateio.im/webp-social/moments-3a365a505b5c5ac87a42a6d277af23ff.webp(
) Ordenação de transações Mempool
A intensa concorrência faz com que os Flashbots nem sempre funcionem. Enviando transações normais através do mempool, se puderem ser posicionadas adequadamente ### logo após a transação de transferência (, também pode ser possível alcançar o objetivo.
Um atacante utilizou esta estratégia para obter um lucro de 312 ETH, sem precisar pagar as taxas da Flashbots. Por exemplo:
Esta estratégia engenhosa combina praticidade e inspiração, merecendo atenção.
![])https://img-cdn.gateio.im/webp-social/moments-cb547989448abc96498684cb89da8860.webp(
Outras Reflexões
) Definição de White Hat e Atacante
Identificar um white hat nem sempre é straightforward. Por exemplo, uma conta inicialmente marcada como atacante, após negociação com a equipe do projeto, concordou em manter 50 ETH como recompensa e devolver os outros lucros, sendo posteriormente remarcada como white hat.
Este fenómeno não é novo e a equidade do seu mecanismo de incentivo gerou controvérsia na comunidade.
Competição de White Hats
É necessário que a comunidade estabeleça um mecanismo de coordenação para reduzir a competição entre os hackers éticos. Essa competição não só desperdiça recursos, como também eleva os custos de resgate. Por exemplo, nós e outras três organizações de hackers éticos tentamos simultaneamente proteger 54 vítimas ### envolvendo 450 ETH(. Sem um mecanismo de coordenação, é difícil para os hackers éticos desistirem ou pararem essa competição.
) Melhorar as operações de resgate
Os hackers éticos podem agir em público na comunidade sem divulgar informações sensíveis, e essa prática tem bons resultados.
As várias partes da comunidade podem colaborar para aumentar a eficiência do resgate:
Através do esforço conjunto de todas as partes, podemos enfrentar melhor os desafios de segurança no ecossistema Web3 e proteger os interesses dos usuários.
![]###https://img-cdn.gateio.im/webp-social/moments-adbfab235ed4a4c2a3ef7a58915c4deb.webp(