¿Por qué la línea de defensa de seguridad de Drift es tan ineficaz, desde la firma previa hasta la pérdida de permisos?
Escrito por: Four Pillars
Compilado por: AididiaoJP, Noticias Foresight
Puntos clave
1 de abril de 2026 a las 16:05 (hora UTC), el protocolo Drift sufrió un importante ataque de aproximadamente 285 millones de dólares. Drift es un intercambio descentralizado de contratos perpetuos líder en el ecosistema de Solana. Este ataque pertenece a un complejo esquema de manipulación de colaterales: los atacantes utilizaron una clave de administrador filtrada para lanzar un nuevo mercado de intercambio de un token sin valor, luego desactivaron el mecanismo de protección de retiros y finalmente extrajeron activos reales mediante el valor de colaterales falsificados.
Este ataque combinó tecnología de pre-firmas basada en números aleatorios persistentes con tácticas avanzadas de ingeniería social. Desde el 23 de marzo, el atacante creó cuentas de números aleatorios persistentes para dos firmantes de múltiples firmas y dos cuentas controladas por el atacante. Incluso después de que el protocolo realizó una migración de múltiples firmas legítima el 27 de marzo, el atacante logró recuperar el acceso a los dos firmantes en la nueva múltiples firmas. El atacante obtuvo pre-firmas del firmante legítimo al engañarlo con el contenido de la transacción y almacenó estas pre-firmas utilizando números aleatorios persistentes, ejecutándolas en masa el 1 de abril, lo que finalmente resultó en la adquisición de permisos de administrador. Este evento no involucró la filtración de frases de recuperación ni vulnerabilidades en el contrato inteligente.
Este evento es otro gran error de seguridad operativa, ocurriendo solo 10 días después del ataque de Resolv. El colapso de Resolv se debió a que no estableció un mecanismo de múltiples firmas; mientras que Drift, a pesar de tener uno, también falló debido a un umbral demasiado bajo y la falta de mecanismos de seguridad adicionales. Ambos eventos indican que es urgente rediseñar fundamentalmente la arquitectura de privilegios.
Resumen del evento
Fuente: @DriftProtocol
El 1 de abril de 2026 a las 16:05 (hora UTC), el protocolo Drift, un intercambio descentralizado de contratos perpetuos de primera línea en Solana, sufrió un ataque masivo. Drift es un protocolo que ofrece trading con margen, trading spot, préstamos y otros muchos servicios de finanzas descentralizadas, cuya arquitectura combina creadores de mercado automáticos virtuales con libros de órdenes en cadena. Justo antes del ataque, el valor total bloqueado del protocolo era aproximadamente de 309 millones de dólares.
Fuente: @PeckShieldAlert
Alrededor de las 18:10 (hora UTC), aproximadamente dos horas después del inicio del ataque, el equipo de Drift publicó en la plataforma X pidiendo a los usuarios que suspendieran los depósitos. Posteriormente, el equipo confirmó el incidente del ataque y suspendió todas las funciones de depósito y retiro. Varias empresas de seguridad y análisis en cadena, incluidas PeckShield y Lookonchain, estimaron las pérdidas en aproximadamente 285 millones de dólares. La billetera Phantom tomó rápidamente medidas para bloquear el acceso al protocolo.
Este evento es especialmente llamativo porque ocurrió solo 10 días después del ataque de Resolv, convirtiéndose en otro incidente de filtración masiva de claves de administrador en un corto período de tiempo. Ambos incidentes comparten una raíz común: la causa fundamental no son las vulnerabilidades del código del contrato inteligente, sino errores en la seguridad operativa.
Análisis de la causa raíz
El núcleo de este ataque radica en que los atacantes utilizaron permisos de administrador filtrados para llevar a cabo la manipulación del colateral. Si el evento de Resolv fue "la clave con permisos de acuñación fue filtrada", el evento de Drift es "la clave con permisos de lanzamiento en el mercado y configuración de seguridad fue filtrada". Aunque se presentan de manera diferente, la raíz es la misma. A continuación, se analizará el proceso del ataque paso a paso.
Fuente: Dexscreener
La herramienta más directa utilizada en este ataque fue el CarbonVote Token (CVT), un token con muy baja liquidez. Una de las direcciones controladas por los atacantes (FnYXwy...LpAjjx) emitió este token tres semanas antes del ataque. La oferta total de CVT es de aproximadamente 750 millones de unidades, de las cuales el monedero del atacante posee más del 80%. Los atacantes crearon un grupo de liquidez mínimo de aproximadamente 500 dólares en Raydium y luego llevaron a cabo transacciones de volumen de manera continua.
La función initializeSpotMarket en el protocolo Drift permite al administrador especificar directamente la dirección del oráculo y sus parámetros de origen. Al revisar la configuración del kit de herramientas de desarrollo de software para los mercados spot existentes, se puede ver que cada mercado define individualmente el oráculo, la fuente del oráculo y los campos de acuñación de tokens. Esto significa que, incluso tokens como el CVT que no tienen precios de Pyth, siempre que el atacante obtenga permisos de administrador, puede utilizar cualquier fuente de oráculo para lanzarlo como mercado.
En este ataque, el atacante designó un precio de Switchboard como su oráculo para el mercado de CVT. Switchboard es una red de oráculos donde crear precios personalizados es relativamente fácil. El atacante configuró un precio controlado por él que valoró 785 millones de CVT en cientos de millones de dólares. Las plataformas de seguimiento de precios como Dexscreener muestran que el precio del CVT es de aproximadamente 1 dólar, pero su liquidez de mercado real y valor intrínseco son prácticamente cero.
La billetera de vaciamiento utilizada en el ataque (HkGz4K...ovpZES) apareció activa aproximadamente ocho días antes, el 24 de marzo. Esta billetera intentó obtener un predepósito a través del protocolo NEAR, y los registros en cadena muestran que hasta el día del ataque, esta billetera completó un total de 325 transacciones.
El historial de actividad en cadena del firmante de administrador utilizado el día del ataque (H7PiGq...y7ZgL) también merece atención. Esta clave registró un total de 29 transacciones. La primera transacción ocurrió el 31 de marzo a las 15:05 (hora UTC), un día antes del ataque; la última transacción ocurrió el 1 de abril a las 18:05 (hora UTC), el mismo día del ataque. La existencia de esta clave en la cadena fue de aproximadamente 27 horas. La razón es clara a partir de los registros en cadena.
Los permisos de administrador del protocolo Drift no son gestionados por una sola cuenta externa, sino que se implementan a través de un mecanismo de múltiples firmas. Sin embargo, las investigaciones posteriores revelaron que la ruta de ataque era mucho más compleja que simplemente una invasión de múltiples firmas. Aproximadamente nueve días antes del ataque, el atacante creó cuatro cuentas de números aleatorios persistentes. Dos de ellas estaban asociadas con los firmantes de múltiples firmas del comité de seguridad de Drift, y las otras dos eran controladas por el atacante. Los números aleatorios persistentes son un mecanismo en Solana que puede eludir el período de validez del hash del bloque de aproximadamente un minuto en transacciones normales, permitiendo la recopilación anticipada de firmas y su ejecución posterior. Se cree que el atacante utilizó este mecanismo para obtener pre-firmas del firmante legítimo al engañarlo con el contenido de las transacciones.
Cuatro días después, el equipo de Drift realizó una migración de múltiples firmas planificada debido a un cambio en los miembros del comité de seguridad. Esta migración formaba parte de un procedimiento operativo regular, pero el atacante se adaptó exitosamente a este cambio.
Un día antes del ataque, el atacante creó una nueva cuenta de números aleatorios persistentes para un firmante en la múltiples firmas migrada (6UJbu9...Pvu924). En este momento, el atacante ya había recuperado el acceso efectivo a dos quintas partes de los firmantes en la múltiples firmas actualizada. Esto indica que el atacante había penetrado profundamente en el sistema y podía manejar cambios inesperados como la migración de múltiples firmas.
El día del ataque, el equipo de Drift realizó un retiro de prueba rutinario desde el fondo de seguro. Aproximadamente un minuto después, el atacante ejecutó rápidamente dos transacciones pre-firmadas de números aleatorios persistentes.
Fuente: solscan
La primera transacción ejecutó las instrucciones VaultTransactionCreate, ProposalCreate y ProposalApprove en la múltiples firmas de Squads, creando una propuesta de transferencia de administrador maliciosa y registrando la primera aprobación.
A continuación, la segunda transacción utilizó números aleatorios persistentes para ejecutar las instrucciones ProposalApprove y VaultTransactionExecute. Se alcanzó el umbral de dos quintas partes, y dado que el tiempo de bloqueo estaba configurado en cero segundos, la transacción se ejecutó de inmediato. En ese momento, se llamó a la instrucción UpdateAdmin en el programa Drift V2, transfiriendo la dirección del administrador al atacante (H7PiGq...y7ZgL).
El detalle clave aquí es que ambas transacciones habían sido completamente firmadas de antemano y se enviaron en masa el día del ataque. Es probable que los firmantes en ese momento no comprendieran completamente el contenido de las transacciones que firmaron. El término "malentendido de transacciones" utilizado por el equipo de Drift indica que los firmantes fueron engañados para firmar transacciones maliciosas disfrazadas como operaciones regulares de transferencia de administrador. La función de los números aleatorios persistentes es almacenar estas pre-firmas indefinidamente, permitiendo al atacante ejecutarlas en el momento que elija.
El firmante de administrador reemplazado luego llamó al programa Drift V2 (dRifty...cn33UH), realizando dos operaciones.
Fuente: solscan
Primero, el atacante registró el CVT como un nuevo mercado spot en Drift mediante la instrucción initializeSpotMarket. Durante este proceso, se creó una nueva cuenta de mercado spot (BY3WYn...FVU1Cf) y dos cuentas de token CVT, y se configuró la dirección derivada del programa del tesoro de Drift (PDA, JCNCMF...XXJfrw) como propietaria del token.
Drift opera un sistema de colateralización multi-activo, lo que significa que los tokens registrados en el nuevo mercado spot pueden ser utilizados inmediatamente como colateral. Sin embargo, para ser considerados como colateral elegible, los parámetros initial_asset_weight y maintenance_asset_weight del mercado deben establecerse en valores positivos mayores que cero, mientras que los valores iniciales predeterminados son bajos o cercanos a cero. El análisis de la transacción de ataque (4a5962R...st82X) mostró que updateSpotMarketMarginWeights (o actualizaciones equivalentes de parámetros de riesgo) se ejecutaron en la misma transacción que initializeSpotMarket, donde el atacante configuró el peso de colateral del CVT al máximo.
Esto expuso un defecto clave de diseño desde la perspectiva de la defensa en profundidad: las operaciones de lanzamiento del mercado, la designación de la fuente del oráculo, la configuración del peso máximo del colateral y la desactivación de la protección de retiro pueden completarse en una sola transacción. El factor de descuento del peso, que se aplica para prevenir la concentración de riesgos en posiciones grandes, también perdió efectividad práctica una vez que el peso en sí se estableció en su máximo. Si el programa hubiera establecido un límite superior en el peso de los mercados recién creados o hubiera establecido un tiempo de bloqueo independiente para los cambios de peso, este ataque que desmantela todas las medidas de defensa de una sola vez no habría sido posible.
Fuente: solscan
En segundo lugar, en la misma transacción, el atacante llamó cinco veces a la instrucción updateWithdrawGuardThreshold, elevando el límite de retiro del mercado de activos principales a niveles extremos. Todos los límites de los mercados se establecieron en un valor unificado de aproximadamente 500 billones, lo que efectivamente empujó el umbral del mecanismo de protección contra retiros a infinito, eliminando así la función de seguridad diseñada para detener retiros anómalamente grandes.
Esta transacción (4a5962R...st82X) destruyó simultáneamente las tres líneas de defensa clave de Drift.
Primero, el mecanismo de precios fue comprometido al asignar un precio de Switchboard controlado por el atacante como oráculo. Segundo, el peso del colateral fue establecido al máximo, haciendo que un token sin valor intrínseco fuera clasificado como colateral de alta calidad. Tercero, el umbral del mecanismo de protección de retiro fue elevado a unos 500 billones, eliminando efectivamente el mecanismo de bloqueo contra retiros anómalos.
Incluyendo el cambio de permisos de administrador, el atacante desmanteló toda la arquitectura de seguridad del protocolo con solo dos transacciones. Desde la perspectiva de la auditoría de código, esto presenta una profunda paradoja: el código del contrato de Drift funciona completamente de acuerdo con lo confirmado por la auditoría. initializeSpotMarket registró el nuevo mercado como se diseñó, designó la fuente del oráculo y configuró los parámetros de peso; updateWithdrawGuardThreshold modificó los límites como se diseñó. La raíz del problema reside en el diseño del sistema en sí: este diseño permite que toda la cadena de ataque se complete en una sola transacción. Esto no se encuentra en el ámbito de las auditorías de código, sino en el ámbito del diseño de arquitecturas de privilegios y restricciones de parámetros.
Finalmente, el atacante depositó aproximadamente 785 millones de CVT como colateral a través de una nueva cuenta de usuario de Drift. El precio del oráculo de Switchboard controlado por el atacante valoró esta cantidad en cientos de millones de dólares, y al establecer el peso del colateral al máximo, reconoció casi toda la valoración como colateral válido. El sistema de márgenes de Drift funcionó completamente como se había diseñado. El problema es que cada parámetro que se ingresó en ese sistema fue manipulada maliciosamente por el atacante.