Introdução
Nos últimos três anos, observamos vários incidentes de segurança no ecossistema DeFi. Para defender contra as ameaças, métodos centrados em código, como auditoria estática de código, ferramentas de varredura de contratos inteligentes ou fuzzing dinâmico, são adotados pela comunidade. Embora tenham demonstrado eficácia, argumentamos que a abordagem centrada em código não pode resolver sozinha os problemas de segurança e proteger os ativos dos usuários dos projetos. Por exemplo, existem vários casos em que contratos vulneráveis foram auditados por múltiplas empresas de auditoria de código respeitáveis.
Acreditamos que, além das abordagens existentes centradas em código, uma solução de prevenção de ameaças mais proativa deve existir para se defender contra as ameaças. Deliberamos internamente essa ideia no final de 2021 e desenvolvemos um sistema chamado IronDome no início de 2022. Implantamos o sistema internamente na BlockSec desde então. Em 2022, o IronDome bloqueou com sucesso múltiplos ataques e salvou mais de 5 milhões de dólares em ativos de usuários, incluindo o caso que impediu a exploração da Saddle Finance 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 do nosso sistema e perspectivas sobre a direção futura da prevenção de ameaças.
Arquitetura Geral do Sistema
A ideia básica do IronDome é monitorar o pool de transações pendentes do Ethereum, detectar a transação de ataque por meio do nosso sistema de pré-execução de transações Mopsus, e bloquear o ataque sintetizando automaticamente uma transação de resgate que transferirá os ativos vulneráveis para nossa conta segura, e realizando um front-running da transação de ataque via FlashBot. A figura a seguir mostra a arquitetura.
Monitoramento do Mempool
O IronDome monitora as transações pendentes no pool de memória por meio do nosso cliente Geth personalizado. O ponto crítico é que nosso sistema deve monitorar as transações prontamente e monitorar o maior número de transações possível.
Detecção de Ataques
Cada transação pendente será alimentada no módulo de detecção de ataques. Como essas transações ainda não estão na blockchain, utilizaremos 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.
Síntese de Tx de Resgate
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 ao da 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 atacante. Por exemplo, podemos implantar automaticamente contratos auxiliares semelhantes aos contratos de ataque, mas substituindo o endereço de transferência de tokens pela nossa conta segura. Claro, abordagens mais complexas precisam ser usadas para algumas transações de ataque.
Para a transação de resgate, precisamos fazê-la chegar à blockchain antes da transação de ataque. No sistema atual, estamos utilizando o FlashBot para esse propósito. Primeiro, devemos garantir que outros não possam monitorar nossa tx de resgate. Segundo, podemos adotar algumas estratégias para colocar 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 com sucesso múltiplos ataques. Esta tabela 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 de detecção da transação de ataque e sintetizou automaticamente a tx de resgate em menos de um segundo. Devolvemos todos os fundos resgatados à Saddle Finance. Clique no link para ver a tx de hack original e nossa tx de resgate a seguir.
- Tx de hack original: https://etherscan.io/tx/0xd9bc83688e8eddde39bd9073c363665b1419d475dd4498e81b52cce41d7c76b3
- Nossa tx de resgate: https://etherscan.io/tx/0x9549c0cb48ec5a5a2c4703cbbbbea5638028b2d8c8adc103220ef1c7fe5e99a3
Considerações Éticas
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 apresenta problemas éticos.
- Primeiro, nosso sistema não está explorando ativamente o contrato vulnerável. Ele apenas reage quando detecta uma transação de ataque pendente e sintetiza automaticamente uma semelhante (para bloquear a transação de ataque). Nunca cria a transação de ataque em primeiro lugar.
- Segundo, nos comunicamos ativamente com o protocolo afetado e devolvemos os fundos salvos.
Limitações
Embora o IronDome tenha demonstrado sua eficácia, o sistema ainda possui algumas limitações. A seguir, ilustraremos essas limitações e discutiremos direções futuras na prevenção proativa de ameaças.
- Primeiro, nosso sistema monitora as tx pendentes no mempool. Se o atacante utilizar algum serviço de transação privada, como o FlashBot, a transação de ataque não estará no mempool e, portanto, não poderá ser detectada. Para resolver esse problema, pedimos colaboração com o provedor de serviços de transação privada para detectar e bloquear a transação de ataque (utilizando uma forma semelhante de detectar a transação maliciosa como o nosso sistema). Além disso, mesmo que nosso sistema não consiga bloquear a tx de ataque na ferramenta de pendentes, ainda pode detectar a tx de ataque na blockchain e enviar uma tx de resgate para impedir novas transações de ataque. Observe que, em muitos casos, há mais de uma transação de ataque.
- Segundo, a segurança é uma corrida armamentista. Vimos casos em que os atacantes elevam o nível de dificuldade para sintetizar a transação de resgate. Por exemplo, eles podem dividir uma transação de ataque em múltiplas e ofuscar o endereço de lucro. Embora esses problemas possam ser resolvidos, acreditamos que a corrida armamentista não cessará. Estamos trabalhando em soluções para resolver esses problemas.
- Terceiro, como fazer a transação de resgate chegar à blockchain antes da tx de ataque ainda é uma questão em aberto. Embora algumas estratégias de licitação possam melhorar a chance de nossa tx de resgate ser incluída no bloco, não podemos ter uma garantia de 100%.
Referências e Leituras Adicionais
[1] How to Make the BlockChain Attack "Blockable" | by BlockSec
[2] The Block: Stablecoin DEX Saddle Finance hacked for $10 million
[3] Lend Exploit Post-Mortem — HomeCoin (mirror.xyz)
[5] FSWAP on Twitter: "Os detalhes do progresso do ataque à 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/
