Recientemente, ha habido mucha atención sobre el "contraataque" para mover fondos desde MakerDao Vault usando el multisig de Oasis. Mientras tanto, hemos recibido algunas consultas sobre si BlockSec es el "whitehat" detrás de esta operación, ya que participamos en el contraataque para ayudar a Platypus a rescatar 2.4M el 18 de febrero. Queremos aclarar que BlockSec no está involucrado en ninguna de las acciones del caso Jump. Después de un análisis detallado (Felicitaciones al excelente análisis publicado en BlockWorks por Dan Smith), creemos que la forma involucrada en el "contraataque" de Jump es fundamentalmente diferente al caso de Platypus.
Sin embargo, según nuestro análisis, los pasos clave del contraataque son:
- Deshabilitar la ejecución diferida. Esto está diseñado para ser realizado por el propietario del contrato del Registro de Servicios, que es la billetera Oasis Multisig.
- Cambiar la dirección del contrato registrado para roles críticos, incluyendo AUTOMATION_EXECUTOR para el contrato AutomationBot y MCD_VIEW, MULTIPLY_PROXY_ACTIONS para el contrato CloseCommand. Esto permite que la billetera multisig de Oasis invoque directamente el AutomationBot para ejecutar el comando de cierre, cuya operación real ejecutada es reemplazada por una nueva para transferir los Vaults del Explotador.
Nuestro análisis sugiere que estos pasos clave NO se deben a las vulnerabilidades alegadas en el acceso al multisig de administración.
Descargo de responsabilidad: Este blog está escrito basándose en transacciones en cadena e información pública. Si tiene alguna pregunta o comentario, no dude en contactarnos en [email protected].
El Proceso General
Varias direcciones estuvieron involucradas durante esta operación. Listamos algunas de ellas en el siguiente documento de Google.
https://docs.google.com/spreadsheets/d/1k0PEci8wQ16X7JT7KRq9SvhaCA2yerJcqLn6EfAoPZs/edit?usp=sharing
Específicamente, la idea general del contraataque de Jump es la siguiente.
-
Los Maker Vaults del Explotador pueden ser administrados por el contrato inteligente AutomationBot de Oasis, ya que el Explotador habilita los servicios de venta y compra automatizados ofrecidos por Oasis.
-
El AutomationBot solo puede ser operado por la dirección con el rol AUTOMATION_EXECUTOR. Esta dirección es una configuración en el contrato del Registro de Servicios de Oasis, que puede ser actualizada por la billetera multisig de Oasis. Sin embargo, la actualización de la configuración del contrato del Registro de Servicios de Oasis tiene un mecanismo de ejecución diferida, que puede ser deshabilitado por la billetera multisig de Oasis.
-
El contrato real y la función ejecutada por el AutomationBot también son configurables en el Registro de Servicios de Oasis.
Por lo tanto, la billetera multisig de Oasis primero deshabilita la ejecución diferida del contrato del Registro de Servicios de Oasis y cambia la configuración en el contrato del Registro de Servicios de Oasis para establecer el rol AUTOMATION_EXECUTOR como sí misma (billetera multisig). El cambio es inmediatamente efectivo. Luego, la billetera multisig invoca el AutomationBot para ejecutar un comando que puede tomar el control de los Maker Vaults del Explotador (transferir y ceder). Dado que el AutomationBot puede administrar los Vaults del Explotador, toda la operación puede tener éxito.
Creemos que este proceso es fundamentalmente diferente al caso de Platypus, donde encontramos una vulnerabilidad en el contrato del atacante y la compartimos con Platypus. Luego, Platypus explotó el contrato del atacante para mover los fondos que les pertenecían. Sin embargo, en el caso de Jump, el multisig de Oasis deshabilita el mecanismo de ejecución diferida, actualiza las configuraciones críticas que pueden cambiar totalmente el comportamiento del contrato y aprovecha el rol de administración del AutomationBot para operar en los Vaults de Maker en nombre del Explotador.
A continuación, elaboraremos el conjunto del "contraataque" de Jump.
Los Pasos Detallados
La operación involucra múltiples protocolos y partes, incluyendo Jump, Oasis, el Explotador de Wormhole y Maker. Tenga en cuenta que Maker no toma ninguna acción durante la operación.
Específicamente, el Explotador crea Maker Vaults (30100 y 30179) y usa ETH como garantía, y toma prestado DAI del vault. El Explotador también aprovechó los servicios de venta y compra automatizados ofrecidos por Oasis para gestionar la tasa de colateralización del vault de Maker.
Para usar el servicio de automatización de Oasis, un contrato inteligente llamado AutomationBot ofrecido por Oasis debe ser agregado a la lista de administración del Vault. Esto significa que el AutomationBot tiene control del Maker Vault creado por el Explotador. Después de eso, el AutomationBot puede manipular el Vault y transferir el colateral y la deuda del Vault a otro, que está controlado por Jump. Este es el proceso básico del "contraataque". Tenga en cuenta que, para invocar el AutomationBot, la transacción debe ser invocada desde la dirección que está registrada como AUTOMATION_EXECUTOR en el contrato ServiceRegistry.
Paso 1: agregar la dirección 04e1 a la billetera multisig de Oasis
La transacción agrega la dirección 04e1 a la billetera multisig de Oasis. Esta billetera actualmente tiene 12 direcciones, con la confirmación de cuatro firmantes.
Paso 2: Deshabilitar la ejecución diferida del Registro de Servicios de Oasis
Esta transacción deshabilita la ejecución diferida del Registro de Servicios de Oasis invocando changeRequiredDela(0). Tenga en cuenta que el Registro de Servicios de Oasis es un contrato inteligente que almacena información de configuración crítica que será utilizada por el AutomationBot. Típicamente, el cambio de configuración tiene un mecanismo de ejecución diferida para la operación crítica, por ejemplo, updateNamedService, que se utilizará en el "contraataque". Usualmente, la ejecución diferida es un mecanismo de seguridad para la transparencia, de modo que la actualización de información crítica no sea efectiva de inmediato, y otros puedan revisarla con más detenimiento.
Tenga en cuenta que la ejecución para invocar changeRequiredDelay está restringida por la ejecución diferida (ya que el cambio a reqDelay) aún no ha entrado en vigor.
Paso 3: Realizar el contraataque
Esta transacción realiza el contraataque. Profundicemos en el seguimiento de ejecución generado por Phalcon, la herramienta de análisis de transacciones desarrollada por BlockSec.
Tenga en cuenta que esta transacción se inicializa desde la dirección 04e1 y se ejecuta a través de la billetera multisig de Oasis, lo que significa que la operación está firmada al menos por cuatro firmantes.
Paso 3.1 Deshabilitar la ejecución diferida
Como se muestra en el seguimiento, el retraso se establece nuevamente en cero. Esto es para aplicar la acción de deshabilitar la ejecución diferida en el paso 2.
Paso 3.2: Crear dos contratos y actualizar el registro de servicios
Se crean dos nuevos contratos, que se utilizarán como contratos MCD_VIEW y MULTIPLY_PROXY_ACTIONS.
- MCD_VIEW: 0xceca8d8410797bc6c575fd8ba957708d1e85ed36
- MULTIPLY_PROXY_ACTIONS: 0xcaef24016d0fba2c1a9427371e0d79c5781b6ea8
Luego, estos dos contratos se actualizarán en el contrato del registro de servicios de Oasis.
Paso 3.3: Cambiar el Ejecutor de Automatización
El multisig de Oasis se registra como AUTOMATION_EXECUTOR en el contrato ServiceRegistry. Esto es necesario ya que solo el contrato registrado con este rol puede invocar el contrato AutomationBot.
Paso 3.4: Solicitar al AutomationBot que cierre el Vault del Explotador
El proceso crítico comienza desde la función execute del AutomationBot. Las funciones ejecutadas en detalle se pasan a través de los argumentos.
Para entender todo el proceso, primero echemos un vistazo a esta función.
La lógica de alto nivel es que el bot primero extrae DAI del vault (línea 268) y luego invoca el contrato de comando concreto para ejecutarse en el vault (especificado por cdpId) (línea 274 a línea 278). Durante el proceso, la dirección del comando es el contrato CloseCommand. Después de eso, se necesita una verificación de isExecutionCorrect.
A continuación se muestra la función execute del contrato CloseCommand. Obtiene la dirección real del contrato ejecutor del contrato del registro de servicios usando la CLAVE MULTIPLY_PROXY_ACTIONS. Tenga en cuenta que la dirección del contrato correspondiente a MULTIPLY_PROXY_ACTIONS ha sido actualizada a una nueva. De esta manera, la ejecución real del CloseCommand es controlable para realizar operaciones arbitrarias en el nuevo contrato.
Recuerde que isExecutionCorrect se invoca en el CloseCommand para verificar si la ejecución fue exitosa (línea 278 en AutomationBot.sol). Dado que la dirección de vista ha sido actualizada, el valor de retorno de la verificación viewerContract.getVaultInfo(cdpId) podría ser un valor arbitrario que puede pasar la verificación en la línea 24 (CloseCommand.sol).
Después de revisar el código, veamos el seguimiento de ejecución. Del seguimiento, podemos ver que el automationBot invoca el contrato CloseCommand. El contrato CloseCommand puede invocar el contrato MULTIPLY_PROXY_ACTIONS reemplazado para abrir un nuevo Vault (30231), transferir el Vault 30100 (el del Explotador) al 30231 (el recién creado) y ceder el nuevo Vault 30231 a la Billetera Multisig de Oasis. Una operación similar se realiza en el otro Vault del Explotador (30179).
Paso 3.5 Restaurar el estado
Restaurar la entrada modificada en el Registro de Servicios y habilitar nuevamente la ejecución diferida.
Paso 3.6 Ceder los Vaults a la dirección 1536
Ahora los nuevos Vaults (30231 y 30232) están controlados por la Billetera Multisig de Oasis. Luego, los Vaults se ceden a 0x15364305a06ba3ac6ba13dfe97ca0bad639adf41 en estas transacciones [TX1 TX2]. Luego, esta dirección puede pagar la deuda en el Vault y retirar el colateral (Ethereum). Dado que la tasa de colateralización es alta (alrededor del 293% para el vault 30100), pagar y retirar el colateral puede recuperar alrededor de 120K Ethereum con el costo de pagar alrededor de 76M de deuda del vault 30100. Los lectores pueden consultar el documento del protocolo Maker para obtener más información sobre estas operaciones.
Acerca de BlockSec
BlockSec es una empresa pionera en seguridad blockchain establecida en 2021 por un grupo de expertos en seguridad de renombre mundial. La empresa está comprometida a mejorar la seguridad y la usabilidad del emergente mundo Web3 con el fin de facilitar su adopción masiva. Con este fin, BlockSec ofrece servicios de auditoría de seguridad de contratos inteligentes y cadenas EVM, la plataforma Phalcon para el desarrollo de seguridad y el bloqueo proactivo de amenazas, la plataforma MetaSleuth para el seguimiento e investigación de fondos, y la extensión MetaSuites para que los desarrolladores de web3 naveguen eficientemente en el mundo cripto.
Hasta la fecha, la empresa ha servido a más de 300 estimados clientes como MetaMask, Uniswap Foundation, Compound, Forta y PancakeSwap, y ha recibido decenas de millones de dólares estadounidenses en dos rondas de financiamiento de destacados inversores, incluyendo Matrix Partners, Vitalbridge Capital y Fenbushi Capital.
Sitio web oficial: https://blocksec.com/
Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam
