A Corrida Contra o Tempo e a Estratégia: Sobre o Resgate do AnySwap e as Lições Aprendidas

Em 18 de janeiro, nosso sistema de monitoramento detectou um ataque contra o projeto AnySwap (também conhecido como Multichain). A vulnerabilidade se deve à função anySwapOutUnderlyingWithPermit() com falha, cujo mecanismo de verificação pode ser contornado para retirar os tokens aprovados.

Embora o projeto tenha adotado diferentes abordagens (por exemplo, enviando transações aos usuários, conforme mostrado na Figura 1) para notificar os usuários afetados, alguns deles não tomaram ações oportunas (ou seja, revogar as aprovações) para proteger seus fundos. Como resultado, os atacantes poderiam continuar lançando o ataque para obter os fundos das vítimas.

Para proteger potenciais vítimas, após muita deliberação, nossa equipe decidiu realizar um resgate de emergência para o contrato vulnerável do AnySwap (0x6b7a87899490EcE95443e979cA9485CBE7E71522) no Ethereum. Especificamente, podemos transferir os fundos da conta vulnerável para nossa carteira white hat, que é uma carteira multisig (0xd186540FbCc460f6a3A9e705DC6d2406cBcc1C47) no Ethereum.

Para tornar nosso resgate white-hat transparente, documentamos nossa intenção em um arquivo pdf e compartilhamos o hash do arquivo com a comunidade. Isso pode diferenciar nosso resgate de emergência do ataque, ao mesmo tempo que não revela os detalhes (já que a vulnerabilidade ainda pode ser explorada). Lançamos o resgate de emergência de 21 de janeiro de 2022 a 11 de março de 2022, e as mensagens correspondentes foram divulgadas ao público, conforme segue:

O resgate de emergência não é uma tarefa trivial. De fato, existem vários desafios, incluindo questões técnicas e não técnicas, para realizar um resgate bem-sucedido. Como o resgate de emergência já foi encerrado, podemos revisar de forma abrangente todo o processo e compartilhar as lições que aprendemos. Acreditamos que essa experiência pode lançar alguma luz sobre como proteger o ecossistema DeFi.

Principais Conclusões (TL;DR)

• Existem competições entre diferentes participantes, incluindo os whitehats e os atacantes. A taxa de pagamento para o Flashbots aumentou rapidamente com o passar do tempo.
• O Flashbots nem sempre funcionou. Em vez disso, alguns atacantes recorreram ao uso do mempool normal para lançar um ataque bem-sucedido adotando algumas estratégias sofisticadas.
• Alguns atacantes foram "anistiados" ao devolver parte dos fundos roubados, enquanto o restante foi mantido como recompensa. Esse fenômeno, embora não seja a primeira ocorrência, é controverso na comunidade porque tal incentivo pode não ser justo para os verdadeiros whitehats.
• Para convencer a comunidade, é uma boa prática para o whitehat tornar a ação publicamente conhecida com antecedência sem vazar informações detalhadas e sensíveis.
• A comunidade pode trabalhar em conjunto para realizar o resgate de forma mais eficaz e eficiente. Por exemplo, construindo um mecanismo de coordenação para reduzir/evitar competições entre whitehats.

A seguir, primeiro apresentamos o panorama geral do resgate durante esse período. Em seguida, ilustramos nossa forma de realizar o resgate e os desafios que precisam ser resolvidos. Depois disso, discutimos algumas lições que aprendemos com o resgate. Por fim, fornecemos alguns pensamentos/sugestões que podem ser significativos para proteger o ecossistema.

0x1 Resgates e Ataques

0x1.1 Resultado Geral

Os ataques e resgates que observamos e investigamos neste relatório duraram meses, variando do bloco 14028474 (18 de janeiro de 2022) ao bloco 14421215 (20 de março de 2022).

As contas que realizaram resgates e ataques estão resumidas na tabela a seguir. Por simplicidade, apenas os primeiros quatro bits do endereço são fornecidos para representar uma EOA. Uma conta é classificada como conta de resgate ou conta de ataque. Vale notar que o tipo de uma conta é determinado com base nas etiquetas marcadas pelo Etherscan.io ou nos endereços de destino de transferência que observamos.

No total, há 9 contas de resgate que resgataram 483,027693 ETH (com taxa de 295,970554 ETH, ou seja, 61,27% do valor total) e 21 contas de ataque que obtiveram 1433,092224 ETH (com taxa de 148,903707 ETH, ou seja, 10,39% do valor total), respectivamente. Vale notar que a perda é uma estimativa aproximada devido a algumas interações complicadas. Por exemplo, uma conta de ataque pode se tornar uma conta de resgate após negociar com o AnySwap, e discutiremos tal fenômeno mais adiante. A última coluna da tabela indica a taxa enviada ao minerador, que foi usada para vencer a competição de uso do Flashbots.

0x1.2 A Tendência da Taxa para Licitar o Flashbots

Como mencionado anteriormente, os whitehats precisam competir com os atacantes para enviar as transações. Como resultado, o percentual da taxa para o minerador (nas transações do Flashbots) pode refletir o nível da competição. Para medi-la quantitativamente, investigamos o percentual da taxa (incluindo transações de ataque e transações de resgate, respectivamente) para cada bloco.

A Figura 4 mostra a tendência que observamos até agora (do bloco 14028474 ao bloco 14369199). As primeiras transações de ataque não envolvem nenhuma taxa, o que significa que havia poucas (ou nenhuma) competições durante esse período. Isso é razoável porque esses ataques iniciais podem não ter sido bem conhecidos por outros.

De fato, o primeiro ataque com taxa (10%) ocorreu no bloco 14029765. Desde então, o percentual da taxa aumentou rapidamente à medida que mais participantes se envolveram. Por exemplo, o percentual atingiu 80% no bloco 14072385 e logo chegou a 91% no bloco 14129449.

Em resumo, a tendência sugere que é definitivamente uma corrida armamentista para vencer a competição ajustando mais taxa para o(s) minerador(es).

0x2 Nosso Resgate e os Desafios

0x2.1 A Forma de Realizar o Resgate

A ideia básica para realizar o resgate é bastante direta. Especificamente, precisamos monitorar as contas que aprovaram WETH para o contrato vulnerável. Quando houver qualquer WETH transferido para a conta, podemos transferi-lo diretamente para nossa carteira multi-sig explorando o contrato AnySwap vulnerável. Os requisitos principais são:

• R1: Localizar eficientemente as transações que transferem tokens para as contas das vítimas. Denominamos essas transações de TXs transferidas a seguir.
• R2: Elaborar corretamente as transações para realizar o resgate. Denominamos essas transações de TXs de resgate a seguir.
• R3: Executar com sucesso o frontrunning das transações enviadas pelos atacantes (e quaisquer outros terceiros). Denominamos essas transações de TXs de ataque a seguir.

R1 e R2 não são obstáculos para nós. Especificamente, construímos um sistema interno para monitorar o mempool, o que nos permite localizar oportunamente as transações de transferência. Enquanto isso, também desenvolvemos uma ferramenta para construir as transações automaticamente.

No entanto, R3 continua sendo um desafio. Pode-se esperar que o Flashbots possa ser usado para vencer a competição. No entanto, não é tão fácil alcançar o objetivo. Em primeiro lugar, os atacantes também podem adotar o Flashbots. Como um sistema de licitação por taxa, a taxa de sucesso pode depender da taxa especificada para o minerador. A estratégia para definir a taxa precisa ser determinada. Em segundo lugar, usar o Flashbots pode não ser uma boa escolha devido à intensa competição. Portanto, também enviamos transações normais usando o mempool. Para garantir o sucesso, a estratégia para posicionar a transação na posição correta precisa ser considerada. Por fim, também competimos com outros whitehats, cujo comportamento parece ser suspeito em alguns casos.

0x2.2 Competições em que Estivemos Envolvidos

No total, tentamos proteger 171 potenciais vítimas distintas, enquanto 10 delas se protegeram revogando as aprovações logo antes de tentarmos realizar o resgate. Para as 161 vítimas válidas restantes, conseguimos resgatar apenas 14 delas devido às competições. Os casos de falha estão resumidos na tabela a seguir, envolvendo 3 contas de resgate e 16 contas de ataque.

Portanto, existem algumas lições que estamos dispostos a compartilhar com a comunidade.

0x3 Algumas Lições que Aprendemos

0x3.1 Como Determinar o Valor da Taxa para o Minerador do Flashbots?

Em resumo, fomos superados por 12 competidores, incluindo 2 contas de resgate e 10 contas de ataque, que estavam usando o Flashbots.

Nossa estratégia para definir a taxa do minerador era bastante conservadora. Especificamente, nosso objetivo era proteger as vítimas gastando a menor taxa possível. Portanto, não usávamos/aumentávamos ativamente a taxa a menos que algumas TXs de ataque bem-sucedidas já tivessem definido a taxa. Por exemplo, se um atacante define a taxa em 10% dos fundos, poderíamos usar 11% para o próximo resgate para competir com esse atacante. No entanto, o resultado sugere que essa estratégia não funcionou, pois os atacantes (ou até mesmo alguns whitehats) frequentemente (senão sempre) aumentavam agressivamente a taxa para superar os outros, conforme segue:

• A Figura 5 mostra que o atacante 0x5738** definiu o percentual da taxa em 70% no bloco 14071986.
• A Figura 6 mostra que o whitehat 0x14ca** definiu o percentual da taxa em 79% no bloco 14072255.
• A Figura 7 mostra que o whitehat 0x14ca** definiu o percentual da taxa em 80%, no bloco 14072385.
• A Figura 8 mostra que o whitehat 0x9117** definiu o percentual da taxa em 81% no bloco 14072417.
• A Figura 9 mostra que o atacante 0x5738** definiu o percentual da taxa em 86% no bloco 14073395.

Em resumo, parece ser um jogo de soma zero que requer modelar os comportamentos dos diferentes participantes para vencer a competição.

Na prática, no entanto, é desafiador descobrir estratégias melhores/ótimas e, ao mesmo tempo, reduzir o custo o máximo possível.

0x3.2 Como Posicionar Corretamente no Mempool?

Agora parece que o resgate dependeria da corrida armamentista de competição por taxas para licitar o Flashbots. No entanto, descobrimos que usar o Flashbots não era uma panaceia devido à intensa competição de outros participantes que não tinham nada a ver com o resgate e o ataque. Nesse caso, mesmo a maior taxa especificada por uma TX de ataque não pode garantir a vitória na chance de usar o Flashbots.

Alternativamente, uma transação normal com a posição correta no mempool pode ter a oportunidade de atingir o objetivo. A posição correta aqui significa que a TX de resgate/ataque deve ser colocada na posição logo após a TX transferida, e a posição deve ser muito próxima à TX transferida (quanto mais próxima, melhor). Note que, usando essa estratégia, o atacante 0x48e9** obteve 312,014657 ETH sem pagar nenhuma taxa aos mineradores do Flashbots.

As quatro figuras a seguir demonstram os 2 maiores lucros que o atacante obteve:

• A Figura 10 mostra que uma vítima depositou 50 ETH na posição 65 do bloco 14051020, e a Figura 11 mostra que o atacante obteve os 50 ETH na posição 66 do mesmo bloco.
• A Figura 12 mostra que uma vítima depositou 200 ETH na posição 161 do bloco 14052155, e a Figura 13 mostra que o atacante obteve os 200 ETH na posição 164 do mesmo bloco.

Obviamente, essa estratégia sofisticada é bastante útil e esclarecedora, e merece mais atenção e esforços para aprender algo com ela.

0x4 Alguns Outros Pensamentos

0x4.1 Hack de Whitehat ou Ataque?

Quando se trata do reconhecimento dos hacks de whitehat, eles podem não ser tão simples quanto se poderia esperar.

Por exemplo, o endereço 0xfa27 foi rotulado como Multichain Exploiter 4 (Whitehat) pelo Etherscan.io. Na verdade, no início, foi rotulado como Multichain Exploiter 4. Após várias rodadas de negociação entre o atacante e o projeto AnySwap, o atacante foi persuadido a devolver parte dos fundos roubados.

• Na TX 0x3c3d**, o AnySwap entrou em contato com o atacante:

Primeiramente, obrigado por pegar o weth. Não estava ciente do hack e percebi a situação apenas porque o weth nunca chegou à minha carteira após a transação do cowswap. Considerando o valor em jogo, você aceitaria 50 eth como uma gorjeta justa? Aqui está minha transação: 0x2db9a6a51604e2be8b2c3469773afb201f0b48a318fb7e5f5e49175e818df5ba 0xe50ed602bd916fc304d53c4fed236698b71691a95774ff0aeeb74b699c6227f7

• Na TX 0xd360**, o atacante respondeu:

Por favor, verifique enviando-me de volta uma tx. Vou te enviar os outros 258 eth. 39 eth foram para os mineradores porque havia outros atacantes, então tive que pagar essa gorjeta para salvar o dinheiro.

• Na TX 0x354f**, o AnySwap agradeceu após receber os fundos:

Recebido, obrigado pela sua honestidade.

Obviamente, esse atacante foi "anistiado" e também obteve algum lucro com o ataque. Casos semelhantes ocorreram várias vezes no passado, e ainda são controversos na comunidade porque tal incentivo pode não ser justo.

0x4.2 Competição Entre Hacks de Whitehat?

É necessário construir um mecanismo de coordenação para reduzir/evitar competições entre os whitehats. Tal competição inevitavelmente leva a um desperdício do poder de resgate. Neste resgate, existem 54 vítimas (com 450 ETH de fundos) que foram protegidas por outros três whitehats, enquanto também tentamos realizar o resgate.

A competição entre whitehats não apenas desperdiçou o poder de resgate, mas também aumentou o custo de realizá-lo. Por exemplo, conforme mostrado nas figuras 7 e 8, as taxas gastas pelas duas TXs de resgate com diferentes whitehats são 80% e 81%, respectivamente.

Infelizmente, os whitehats não darão um passo atrás a menos que exista algum mecanismo para coordenar entre si. Caso contrário, é impossível fazer a competição desaparecer.

0x4.3 Como Realizar um Resgate Melhor

Por um lado, para convencer a comunidade, é uma boa prática para o whitehat tornar a ação publicamente conhecida com antecedência sem vazar informações detalhadas e sensíveis. Há tempo suficiente para fazer isso, pois o resgate geralmente é uma batalha de vai-e-vem com múltiplas tentativas, o que é diferente de algum esforço único como bloquear um ataque específico. Claro, as informações detalhadas sobre as vulnerabilidades não devem ser vazadas.

Para conseguir isso, as informações detalhadas não serão divulgadas no início e serão divulgadas à comunidade após a conclusão do resgate, assim como fizemos para o resgate do AnySwap. No entanto, o hash do documento com a intenção do whitehat pode ser compartilhado com a comunidade.

Por outro lado, a comunidade pode fazer mais coisas para realizar o resgate de forma mais eficaz e eficiente, incluindo, mas não se limitando a:

• O Flashbots/Minerador pode fornecer algum canal verde para os whitehats certificados. O canal verde pode fornecer alta prioridade para fazer frontrunning das TXs dos atacantes e evitar competição entre whitehats.
• Os projetos atacados cobrem o custo do Flashbots/mineradores.
• Os projetos podem aplicar mecanismos de notificação convenientes e rápidos aos usuários.
• O projeto pode aplicar o mecanismo de emergência no código.

Sobre a BlockSec

A BlockSec é uma empresa pioneira em segurança blockchain estabelecida em 2021 por um grupo de especialistas em segurança de renome mundial. A empresa está comprometida em aprimorar a segurança e a usabilidade para o emergente mundo Web3, a fim de facilitar sua adoção em massa. Para isso, a BlockSec oferece serviços de auditoria de segurança de contratos inteligentes e chains EVM, a plataforma Phalcon para desenvolvimento de segurança e bloqueio proativo de ameaças, a plataforma MetaSleuth para rastreamento e investigação de fundos, e a extensão MetaSuites para construtores web3 navegarem eficientemente no mundo cripto.

Até o momento, a empresa atendeu mais de 300 clientes estimados, como MetaMask, Uniswap Foundation, Compound, Forta e PancakeSwap, e recebeu dezenas de milhões de dólares americanos em duas rodadas de financiamento de investidores proeminentes, incluindo Matrix Partners, Vitalbridge Capital e Fenbushi Capital.

Site oficial: https://blocksec.com/

Conta oficial no Twitter: https://twitter.com/BlockSecTeam