Por BlockSec

Introdução

Nos últimos três anos, observamos vários incidentes de segurança no ecossistema DeFi. Para defender as ameaças, métodos centrados em código, por exemplo, auditoria de código estático, ferramenta de verificação de contrato inteligente ou fuzzing dinâmico, são adotados pela comunidade. Embora tenham mostrado eficácia, argumentamos que a abordagem centrada no código não pode resolver apenas os problemas de segurança e os ativos dos usuários do projeto. Por exemplo, existem vários casos em que contratos vulneráveis ​​foram auditados por várias empresas de auditoria de código respeitáveis ​​.

Acreditamos que, além das abordagens existentes centradas no código, deve existir uma solução de prevenção de ameaças mais proativa para se defender contra as ameaças. Deliberamos internamente sobre essa ideia no final de 2021 e desenvolvemos um sistema chamado IronDome no início de 2022 . Implantamos o sistema internamente no BlockSec desde então. Em 2022, o IronDome bloqueou com sucesso vários ataques e economizou mais de 5 milhões de dólares em ativos de usuários, incluindo o caso que impediu a exploração de Saddle Fiance em abril de 2022 e resgatou 3,8 milhões de dólares .

Neste blog, detalharemos a arquitetura do sistema IronDome e suas histórias de sucesso. Também discutiremos as limitações e percepções de nosso sistema sobre a direção futura da prevenção de ameaças.

Arquitetura de sistema de alto nível

A ideia básica do IronDome é ouvir o pool pendente de Ethereum, detectar a transação de ataque por meio de nosso sistema de pré-execução de transação Mopsus e bloquear o ataque sintetizando automaticamente uma transação de resgate que moverá ativos vulneráveis ​​para nossa conta segura e executando a transação de ataque pelo FlashBot. A figura a seguir mostra a arquitetura.

Visão geral da arquitetura do sistema

Monitoramento de Mempool

O IronDome escuta as transações pendentes no pool de memória por meio de nosso cliente Geth personalizado. O ponto crítico é que nosso sistema deve ouvir a transação prontamente e ouvir o maior número possível de transações.

Detecção de ataque

Cada transação pendente será alimentada ao módulo de detecção de ataque. Como essas transações ainda não estão na cadeia, aproveitaremos nosso mecanismo de pré-execução de transações Mopsus para pré-executar essas transações e detectar as transações de ataque (maliciosas) com base nos estados de tempo de execução e nos resultados da transação.

Resgate Tx Sintetizando

Para a transação de ataque, o IronDome sintetizará automaticamente uma transação de resgate e seus contratos auxiliares. A transação de resgate seguirá um método semelhante à transação de ataque para “explorar” o contrato vulnerável, mas transferir o lucro para nossa conta segura (uma conta multi-sig) em vez da conta controlada pelo invasor. Por exemplo, podemos implantar automaticamente contratos auxiliares semelhantes aos contratos de ataque, mas substituir o endereço de transferência de token para nossa conta segura. Obviamente, abordagens mais complicadas precisam ser usadas para algumas transações de ataque.

Para a transação de resgate, precisamos fazê-la na cadeia antes da transação de ataque. No sistema atual, estamos aproveitando o FlashBot para essa finalidade. Primeiro, devemos garantir que outras pessoas não possam ouvir nossa tx de resgate. Em segundo lugar, podemos adotar algumas estratégias para fazer nossa transação de resgate no topo do bloco.

Histórias de sucesso representativas

Implantamos o IronDome no início de 2022. O sistema detectou e bloqueou vários ataques com sucesso. A tabela a seguir resume alguns dos casos de sucesso.

A linha do tempo a seguir mostra como nosso sistema resgatou 3,8 milhões de dólares para a Saddle Finance no final de abril de 2022. Em particular, nosso sistema concluiu todo o processo para detectar a transação de ataque e sintetizou automaticamente o tx de resgate em menos de um segundo. Devolvemos todos os fundos resgatados à Saddle Finance. Clique no link para o hack tx original e nosso tx de resgate está a seguir.

• Tx original do hack:https://etherscan.io/tx/0xd9bc83688e8eddde39bd9073c363665b1419d475dd4498e81b52cce41d7c76b3
• Nosso tx de resgate:https://etherscan.io/tx/0x9549c0cb48ec5a5a2c4703cbbbbea5638028b2d8c8adc103220ef1c7fe5e99a3

Levamos a ética de segurança a sério em nosso sistema. Embora nosso sistema esteja “explorando” o contrato vulnerável para resgatar os ativos dos usuários, acreditamos que essa ação não tem um problema ético.

• Primeiro, nosso sistema não está explorando ativamente o contrato vulnerável. Ele só reage quando detecta uma transação de ataque pendente e sintetiza automaticamente uma semelhante (para bloquear a transação de ataque). Em primeiro lugar, ele nunca cria a transação de ataque.
• Em segundo lugar, nos comunicamos ativamente com o protocolo afetado e devolvemos os fundos economizados.

Embora o IronDome tenha mostrado sua eficácia, o sistema ainda apresenta algumas limitações. A seguir, ilustraremos essas limitações e discutiremos outras direções na prevenção proativa de ameaças.

• Primeiro, nosso sistema escuta o tx pendente no mempool. Se o invasor usar algum serviço de transação privada, por exemplo, FlashBot, a transação de ataque não estará no mempool e, portanto, não poderá ser detectada. Para resolver esse problema, pedimos a colaboração do provedor de serviços de transação privada para detectar e bloquear a transação de ataque (tomando uma maneira semelhante de detectar a transação maliciosa como nosso sistema). Além disso, mesmo que nosso sistema não consiga bloquear o ataque tx no ferramenta pendente, ele ainda pode detectar o tx de ataque na cadeia e enviar um tx de resgate para evitar novas transações de ataque. Observe que, em muitos casos, há mais de uma transação de ataque.
• Em segundo lugar, a segurança é uma corrida armamentista. Vimos casos em que os invasores aumentam o nível de sintetização da transação de resgate. Por exemplo, eles podem dividir uma transação de ataque em várias e ofuscar o endereço de lucro. Embora essas questões possam ser resolvidas, acreditamos que a corrida armamentista não vai parar. Estamos trabalhando em soluções para resolver esses problemas.
• Terceiro, como fazer a transação de resgate na cadeia antes do tx de ataque ainda é uma questão em aberto. Embora algumas estratégias de lances possam melhorar a chance de que nosso tx de resgate seja compactado no bloco, não podemos ter uma garantia de 100%.

[1] Como tornar o ataque BlockChain “bloqueável” | por BlockSec | Médio

[2] The Block: Stablecoin DEX Saddle Finance hackeado por $ 10 milhões

[3] Lend Exploit Post-Mortem — HomeCoin (mirror.xyz)

[4] Equalizer Finance no Twitter: “Recuperamos os fundos dos cofres no Ethereum e no BSC. Agora a equipe está trabalhando para recuperar os recursos das cadeias Polygon e Optimism. Um grande obrigado a @BlockSecTeam que conseguiu bloquear os atacantes, proteger e devolver os ativos!” / Twitter

[5] FSWAP no Twitter: “Os detalhes do ataque ao progresso da liquidez do FSWAP” / Twitter

[6]https://forta.org/blog/blocksec-and-forta-work-to-secure-web3-beyond-audits/

[7]https://forta.org/blog/the-future-of-threat-prevention-in-web3/