A partir del 23/03/2022 16:20:08 UTC+8, CashioApp fue objeto de un ataque que vació la cuenta de tokens de garantía y causó pérdidas de aproximadamente 52 millones. El ataque fue posible porque la comprobación de las cuentas de entrada era insuficiente, lo que permitió al atacante acuñar 20 mil millones de tokens $CASH sin realizar ningún depósito. A continuación, presentamos los detalles técnicos.
Resumen
El incidente se debió a un error en el programa Brrr, diseñado para gestionar la acuñación y la quema de tokens $CASH respaldados por Saber LP Arrows. En concreto, los usuarios pueden emitir $CASH, es decir, acuñar $CASH, mediante el depósito de tokens LP de Arrow. Cabe señalar que el token LP de Arrow recibe el token LP de Saber como token subyacente. La instrucción print_cash, que puede acuñar $CASH, recibe una lista de cuentas que incluye la cuenta Bank y la cuenta Collateral. Estas se utilizan para registrar y hacer seguimiento de la garantía (es decir, los tokens LP de Arrow) que puede emplearse para acuñar $CASH. Por diseño, solo el administrador debería inicializar y autorizar estas dos cuentas. Sin embargo, el programa no comprueba la validez de la cuenta Bank. Como resultado, el atacante puede crear una serie de cuentas falsas (incluida la cuenta Bank) y proporcionarlas a la instrucción print_cash para emitir $CASH prácticamente gratis (el único costo son las comisiones de transacción).
Detalles
Comencemos el análisis por las cuentas utilizadas en la instrucción print_cash que se muestra a continuación.
El atributo common (línea 75) es una estructura cuyo tipo en el programa es BrrrCommon. En BrrrCommon, el administrador inicializa y autoriza la cuenta bank y la cuenta collateral. crate_token es la cuenta del token $CASH, que almacena información sobre $CASH, como la clave pública de crate_mint (línea 107), las claves públicas de los roles de administrador y otros datos. crate_collateral_tokens es una cuenta de depósito que custodia los tokens de garantía transferidos por los usuarios. Dado que la garantía debe consistir en tokens LP de Arrow, que reciben los tokens LP de Saber, los usuarios deben proporcionar las cuentas relacionadas con saber_swap. Los dos últimos atributos de la estructura BrrrCommon son los ID de los programas de destino utilizados en la instrucción. Cabe señalar que los cuatro últimos atributos de la estructura PrintCash son la cuenta de sistema del usuario (que también firma la transacción), la cuenta de garantía del usuario, la cuenta de tokens $CASH del usuario que recibe los $CASH acuñados y la clave pública de la cuenta que tiene autoridad para acuñar $CASH.
La transacción del ataque
Tras comprender la función de las cuentas anteriores, pasamos a analizar la transacción del ataque: 0x4fgL…z2K5. Este ataque se inicia desde la dirección del atacante (ubicada en 0x6D7f) y la lista de cuentas de entrada de la instrucción PrintCash se muestra a continuación.
La dirección Account #1 (0x5aha) que aparece arriba corresponde a la cuenta Bank. Observamos que es distinta de la dirección publicada en el sitio web oficial de CashioApp (0xEm1P), ¡lo que significa que la validación de la cuenta Bank es insuficiente!
Validación
Examinemos más de cerca la validación de la estructura BrrrCommon en el código para entender cómo se elude.
La única comprobación de la cuenta Bank proporcionada como entrada consiste en verificar que la cuenta Collateral proporcionada esté asociada a la cuenta Bank (línea 12). Sin embargo, esta comprobación puede eludirse fácilmente proporcionando también una cuenta Collateral falsa. Además, para evitar aportar activos de garantía reales, el atacante proporcionó cuentas saber_swap falsas. Cabe señalar que el atacante pretende depositar activos de garantía sin valor para emitir tokens $CASH valiosos, por lo que las direcciones crate_token y crate_mint proporcionadas por el atacante deben ser auténticas. En otras palabras, la comprobación insuficiente de la cuenta Bank permite al atacante crear una serie de cuentas falsas para emitir $CASH con una garantía sin valor.
La corrección
La corrección consiste en añadir la instrucción assert_keys_eq!(self.bank.crate_mint, self.crate_mint). Esta instrucción garantiza que el campo crate_mint de la cuenta Bank contenga el crate_mint correcto para $CASH. Sin embargo, ¿cómo garantiza que la cuenta Bank sea válida? Examinemos la estructura NewBank (en el programa bankman) y la estructura NewCrate (en el programa crate_token) para encontrar la respuesta.
De hecho, la cuenta Bank es una PDA cuyas semillas contienen la dirección de crate_token. A su vez, crate_token también es una PDA cuyas semillas contienen la dirección de crate_mint. Esto garantiza que la cuenta Bank sea válida si el crate_mint proporcionado como entrada es válido. Sin un crate_mint correcto, los atacantes no pueden acuñar $CASH ni llevar a cabo los ataques.
Acerca de BlockSec
BlockSec es una empresa pionera en seguridad blockchain, fundada en el año 2021 por un grupo de expertos en seguridad de reconocimiento mundial. La empresa se dedica a mejorar la seguridad y la facilidad de uso del emergente mundo Web3 para 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 Security para el desarrollo de soluciones de seguridad y el bloqueo proactivo de amenazas, la plataforma MetaSleuth para el rastreo de fondos y la investigación, y la extensión MetaSuites para que los desarrolladores de web3 se desenvuelvan con eficiencia en el mundo de las criptomonedas.
Hasta la fecha, la empresa ha prestado servicios a más de 300 clientes destacados, como MetaMask, Uniswap Foundation, Compound, Forta y PancakeSwap, y ha obtenido decenas de millones de dólares estadounidenses en dos rondas de financiación de inversores de renombre, entre ellos Matrix Partners, Vitalbridge Capital y Fenbushi Capital.
Sitio web oficial: https://blocksec.com/
Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam
