Se descubre un gran atraco: una herramienta de conveniencia se vuelve fatal cuando los piratas informáticos desvían $ 270 millones de Drift en Solana Blockchain
El ataque al Drift Protocol no fue un hack en el sentido tradicional.
Nadie encontró un error ni descifró una clave privada. Tampoco hubo un exploit de préstamo flash ni un oráculo manipulado.
En cambio, un atacante utilizó una característica legítima de Solana, 'nonces duraderos', para engañar al consejo de seguridad de Drift para que aprobara previamente transacciones que se ejecutarían semanas después, en un momento y en un contexto que los firmantes nunca pretendieron.
El resultado fue una fuga de al menos 270 millones de dólares que tardó menos de un minuto en ejecutarse pero más de una semana en prepararse.
Qué son los nonces duraderos y por qué existen
En Solana, cada transacción incluye un 'blockhash reciente', esencialmente una marca de tiempo que demuestra que la transacción se creó recientemente. Ese blockhash caduca después de unos 60 a 90 segundos. Si la transacción no se envía a la red dentro de esa ventana, deja de ser válida. Esta es una característica de seguridad y ayuda a evitar que las transacciones antiguas y obsoletas se repitan más adelante.
Los nonces duraderos anulan esa característica de seguridad. Reemplazan el blockhash que expira con un 'nonce' fijo, un código de un solo uso almacenado en una cuenta especial en cadena, que mantiene la transacción válida indefinidamente hasta que alguien decide enviarla.
La función existe por razones legítimas. Las carteras de hardware, las configuraciones de firma fuera de línea y las soluciones de custodia institucional necesitan la capacidad de preparar y aprobar transacciones sin verse obligados a enviarlas en 90 segundos.
Pero las transacciones con validez indefinida crean un problema. Si se puede lograr que alguien firme una transacción hoy, se puede ejecutar la próxima semana o el próximo mes, según las reglas codificadas del sistema. El firmante no tiene forma de revocar su aprobación una vez otorgada, a menos que la cuenta nonce se avance manualmente, lo que la mayoría de los usuarios no monitorean.
Cómo los usó el atacante
El protocolo de Drift se regía por un 'Consejo de Seguridad multifirma', un sistema en el que varias personas (en este caso, cinco) comparten el control, y cualquier acción requiere la aprobación de al menos dos de ellas. Las firmas múltiples son una práctica de seguridad estándar en DeFi, donde la idea es que comprometer a una sola persona no es suficiente para robar fondos.
Pero el atacante no necesitaba comprometer las claves de nadie. Todo lo que necesitaban eran dos firmas, y parecen haberlas obtenido a través de lo que Drift describe como "aprobaciones de transacciones no autorizadas o tergiversadas", lo que significa que los firmantes probablemente pensaron que estaban aprobando una transacción de rutina.
Aquí está la línea de tiempo que Drift publicó en una publicación del jueves X.
El 23 de marzo se crearon cuatro cuentas nonce duraderas. Dos de ellos estaban asociados con miembros legítimos del Consejo de Seguridad de Drift. Dos de ellos fueron controlados por el atacante. Esto significa que el atacante ya había obtenido firmas válidas de dos de los cinco miembros del consejo, encerradas en transacciones nonce duraderas que no expirarían.
El 27 de marzo, Drift ejecutó una migración planificada del Consejo de Seguridad para cambiar a un miembro del consejo. El atacante se adaptó. El 30 de marzo, apareció una nueva cuenta nonce duradera, vinculada a un miembro del multisig actualizado, lo que indicaba que el atacante había vuelto a obtener el umbral de aprobación requerido de dos de cinco bajo la nueva configuración.
El 1 de abril, el atacante fue ejecutado.
En primer lugar, Drift realizó una retirada de prueba legítima de su fondo de seguros. Aproximadamente un minuto después, el atacante envió las transacciones nonce duraderas prefirmadas. Dos transacciones, separadas por cuatro espacios en la cadena de bloques de Solana, fueron suficientes para crear y aprobar una transferencia de administrador maliciosa, luego aprobarla y ejecutarla.
En cuestión de minutos, el atacante tenía control total de los permisos a nivel de protocolo de Drift. Usaron ese control para introducir un mecanismo de retiro fraudulento y vaciar las bóvedas.
Qué se llevó y adónde fue
Los investigadores de Onchain rastrearon los flujos de fondos en tiempo real. El desglose de los activos robados, compilado por el investigador de seguridad Vladimir S., ascendió a aproximadamente 270 millones de dólares en docenas de tokens.
La categoría individual más grande fue de 155,6 millones de dólares en tokens JPL, seguida de 60,4 millones de dólares en USDC, 11,3 millones de dólares en CBBTC (bitcoin envuelto en Coinbase), 5,65 millones de dólares en USDT, 4,7 millones de dólares en éter envuelto, 4,5 millones de dólares en DSOL, 4,4 millones de dólares en WBTC, 4,1 millones de dólares en FARTCOIN y cantidades más pequeñas en JUP, JITOSOL, MSOL, BSOL. EURC y otros.
La billetera principal se financió ocho días antes del ataque a través de intentos del protocolo NEAR, pero permaneció inactiva hasta el día de la ejecución. Los fondos robados se transfirieron a carteras intermediarias que se financiaron justo el día anterior a través de Backpack, un intercambio de cifrado descentralizado que requiere verificación de identidad, lo que podría dar una pista a los investigadores.
Desde allí, los fondos se trasladaron a direcciones de Ethereum a través de Wormhole, un puente entre cadenas. Esas direcciones de Ethereum habían sido prefinanciadas utilizando Tornado Cash, el mezclador de privacidad autorizado.
ZachXBT, un destacado investigador de la cadena, señaló que más de $230 millones en $USDC fueron puenteados de Solana a Ethereum a través del CCTP (Protocolo de transferencia entre cadenas) de Circle en más de 100 transacciones.
Criticó a Circle, el emisor centralizado de $USDC,