Recentemente, tem havido muita atenção sobre o "contra-exploit" para mover fundos do MakerDao Vault usando o multisig da Oasis. Enquanto isso, recebemos algumas perguntas sobre se a BlockSec é o "whitehat" por trás desta operação, já que estivemos envolvidos no contra-exploit para ajudar a Platypus a resgatar 2,4 milhões em 18 de fevereiro. Queremos esclarecer que a BlockSec não está envolvida em nenhuma das ações no caso Jump. Após uma análise detalhada (Parabéns pela excelente análise publicada no BlockWorks por Dan Smith), achamos que a forma envolvida no "contra-exploit" da Jump é fundamentalmente diferente do caso Platypus.
No entanto, de acordo com nossa análise, as etapas principais do contra-exploit são:
- Desabilitar a execução com atraso. Isso é projetado para ser feito pelo proprietário do contrato Service Registry, que é a carteira Oasis Multisig.
- Alterar o endereço do contrato registrado para funções críticas, incluindo AUTOMATION_EXECUTOR para o contrato AutomationBot e MCD_VIEW, MULTIPLY_PROXY_ACTIONS para o contrato CloseCommand. Isso permite que a carteira multisig da Oasis invoque diretamente o AutomationBot para executar o comando de fechamento, cuja operação realmente executada é substituída por uma nova para transferir os Vaults do Explorador.
Nossa análise sugere que essas etapas principais NÃO se devem às vulnerabilidades alegadas no acesso ao multisig de administrador.
Aviso: Este blog foi escrito com base em transações on-chain e informações públicas. Se você tiver alguma dúvida ou comentário, sinta-se à vontade para nos contatar em [email protected].
O Processo Geral
Alguns endereços estiveram envolvidos durante esta operação. Listamos alguns deles no seguinte documento do Google.
https://docs.google.com/spreadsheets/d/1k0PEci8wQ16X7JT7KRq9SvhaCA2yerJcqLn6EfAoPZs/edit?usp=sharing
Especificamente, a ideia de alto nível para o contra-exploit da Jump é a seguinte.
-
Os Maker Vaults do Explorador podem ser gerenciados pelo contrato inteligente AutomationBot da Oasis, já que o Explorador habilita os serviços de venda e compra automática oferecidos pela Oasis.
-
O AutomationBot só pode ser operado pelo endereço com a função AUTOMATION_EXECUTOR. Este endereço é uma configuração no contrato Oasis Service Registry, que pode ser atualizado pela carteira multisig da Oasis. No entanto, a atualização da configuração do contrato Oasis Service Registry tem um mecanismo de execução com atraso, que pode ser desabilitado pela carteira multisig da Oasis.
-
O contrato real e a função executada pelo AutomationBot também são configuráveis no Oasis Service Registry.
Portanto, a carteira multisig da Oasis primeiro desabilita a execução com atraso do contrato Oasis Service Registry e altera a configuração no contrato Oasis Service Registry para definir a função AUTOMATION_EXECUTOR como ela mesma (carteira multisig). A alteração entra em vigor imediatamente. Em seguida, a carteira multisig invoca o AutomationBot para executar um comando que pode assumir o controle dos Maker Vaults do Explorador (shift e give). Como o AutomationBot pode gerenciar os Vaults do Explorador, toda a operação pode ser bem-sucedida.
Achamos que esse processo é fundamentalmente diferente do caso Platypus, onde encontramos uma vulnerabilidade no contrato do atacante e a compartilhamos com a Platypus. Em seguida, a Platypus explorou o contrato do atacante para mover os fundos que pertenciam a eles mesmos. No entanto, no caso Jump, o multisig da Oasis desabilita o mecanismo de execução com atraso, atualiza as configurações críticas que podem alterar completamente o comportamento do contrato e aproveita a função de gerenciamento do AutomationBot para operar nos Vaults do Maker em nome do Explorador.
A seguir, detalharemos todo o "contra-exploit" da Jump.
As Etapas Detalhadas
A operação envolve múltiplos protocolos e partes, incluindo Jump, Oasis, Wormhole Exploiter e Maker. Observe que o Maker não realiza nenhuma ação durante a operação.
Especificamente, o Explorador cria Maker Vaults (30100 e 30179) e usa ETH como garantia, e toma emprestado DAI do vault. O Explorador também utilizou os serviços de venda e compra automática oferecidos pela Oasis para gerenciar a taxa de colateralização do vault do Maker.
Para usar o serviço de automação da Oasis, um contrato inteligente chamado AutomationBot oferecido pela Oasis precisa ser adicionado à lista de gerenciamento do Vault. Isso significa que o AutomationBot tem controle sobre o Maker Vault criado pelo Explorador. Após isso, o AutomationBot pode manipular o Vault e transferir o colateral e a dívida do Vault para outro, que é controlado pela Jump. Este é o processo básico do "contra-exploit." Observe que, para invocar o AutomationBot, a transação precisa ser invocada a partir do endereço registrado como AUTOMATION_EXECUTOR no contrato ServiceRegistry.
Etapa 1: adicionar o endereço 04e1 na carteira multisig da Oasis
A transação adiciona o endereço 04e1 na carteira multisig da Oasis. Esta carteira atualmente possui 12 endereços, com confirmações de quatro signatários.
Etapa 2: Desabilitar a execução com atraso do Oasis Service Registry
Esta transação desabilita a execução com atraso do Oasis Service Registry invocando changeRequiredDela(0). Observe que o Oasis Service Registry é um contrato inteligente que armazena informações de configuração críticas que serão usadas pelo AutomationBot. Normalmente, a alteração de configuração possui um mecanismo de execução com atraso para operações críticas, por exemplo, updateNamedService, que será usado no "contra-exploit." Geralmente, a execução com atraso é um mecanismo de segurança para transparência, de modo que a atualização de informações críticas não entre em vigor imediatamente, permitindo que outros possam dar uma segunda olhada.
Observe que a execução para invocar changeRequiredDelay é restringida pela execução com atraso (já que a alteração para reqDelay) ainda não entrou em vigor.
Etapa 3: Executar o contra-exploit
Esta transação executa o contra-exploit. Vamos mergulhar no rastreamento de execução gerado pelo Phalcon, a ferramenta de análise de transações desenvolvida pela BlockSec.
Observe que esta transação é inicializada a partir do endereço 04e1 e executada através da carteira multisig da Oasis, o que significa que a operação é assinada por pelo menos quatro signatários.
Etapa 3.1 Desabilitar a execução com atraso
Como mostrado no rastreamento, o atraso é definido como zero novamente. Isso é para aplicar a ação de desabilitar a execução com atraso da etapa 2.
Etapa 3.2: Criar dois contratos e atualizar o registro de serviços
Dois novos contratos são criados, que serão usados como os contratos MCD_VIEW e MULTIPLY_PROXY_ACTIONS.
- MCD_VIEW: 0xceca8d8410797bc6c575fd8ba957708d1e85ed36
- MULTIPLY_PROXY_ACTIONS: 0xcaef24016d0fba2c1a9427371e0d79c5781b6ea8
Em seguida, esses dois contratos serão atualizados no contrato de registro de serviços da Oasis.
Etapa 3.3: Alterar o Executor de Automação
O multisig da Oasis é registrado como o AUTOMATION_EXECUTOR no contrato ServiceRegistry. Isso é necessário, pois somente o contrato registrado com esta função pode invocar o contrato AutomationBot.
Etapa 3.4: Solicitar ao AutomationBot que feche o Vault do Explorador
O processo crítico começa pela função execute do AutomationBot. As funções detalhadas executadas são passadas através dos argumentos.
Para entender todo o processo, primeiro damos uma olhada nesta função.
A lógica de alto nível é que o bot primeiro retira DAI do vault (linha 268) e depois invoca o contrato de comando concreto para executar no vault (especificado por cdpId) (linha 274 a linha 278). Durante o processo, o endereço do comando é o contrato CloseCommand. Após isso, uma verificação de isExecutionCorrect é necessária.
O seguinte mostra a função execute do contrato CloseCommand. Ele obtém o endereço real do contrato executor do contrato de registro de serviços usando a CHAVE MULTIPLY_PROXY_ACTIONS. Observe que o endereço do contrato correspondente ao MULTIPLY_PROXY_ACTIONS foi atualizado para um novo. Assim, a execução real do CloseCommand é controlável para realizar operações arbitrárias no novo contrato.
Lembre-se de que o isExecutionCorrect é invocado no CloseCommand para verificar se a execução foi bem-sucedida (linha 278 no AutomationBot.sol). Como o endereço de visualização foi atualizado, o valor de retorno da verificação viewerContract.getVaultInfo(cdpId) pode ser um valor arbitrário que pode passar na verificação da linha 24 (CloseCommand.sol).
Após percorrer o código, vamos observar o rastreamento de execução. A partir do rastreamento, podemos ver que o automationBot invoca o contrato CloseCommand. O contrato CloseCommand pode invocar o contrato MULTIPLY_PROXY_ACTIONS substituído para abrir um novo Vault (30231), transferir o Vault 30100 (o do Explorador) para o 30231 (o recém-criado) e entregar o novo Vault 30231 para a Carteira Multisig da Oasis. Uma operação semelhante é realizada no outro Vault do Explorador (30179).
Etapa 3.5 Restaurar o estado
Restaurar a entrada alterada no Service Registry e habilitar novamente a execução com atraso.
Etapa 3.6 Entregar os Vaults para o endereço 1536
Agora os novos Vaults (30231 e 30232) são controlados pela Carteira Multisig da Oasis. Em seguida, os Vaults são entregues para 0x15364305a06ba3ac6ba13dfe97ca0bad639adf41 nestas transações [TX1 TX2]. Em seguida, este endereço pode pagar a dívida no Vault e retirar o colateral (Ethereum). Como a taxa de colateralização é alta (em torno de 293% para o vault 30100), pagar de volta e retirar o colateral pode recuperar cerca de 120 mil Ethereum com o custo de pagar aproximadamente 76 milhões em dívida do vault 30100. Os leitores podem consultar a documentação do protocolo Maker para mais informações sobre estas operações.
Sobre a BlockSec
A BlockSec é uma empresa pioneira em segurança blockchain fundada em 2021 por um grupo de especialistas em segurança mundialmente reconhecidos. 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 com eficiência 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
