Spectre en la nube: cómo se filtró un JWT entre Cloudflare Workers

La nube funciona sobre una promesa esencial: diferentes clientes pueden compartir infraestructura física sin tener acceso a los datos de los demás.

Ese principio permite ofrecer servicios rápidos, globales y eficientes. Sin embargo, una investigación reciente sobre Cloudflare Workers demuestra que el aislamiento lógico no siempre elimina todos los canales por los que una aplicación podría inferir información de otra.

Un equipo de Cloudflare y colaboradores académicos logró ejecutar un ataque remoto de la familia Spectre en el entorno de producción de Workers. La prueba extrajo, bit por bit, un token JSON Web Token — mejor conocido como JWT — que había sido colocado intencionalmente en la memoria de otro Worker controlado por los propios investigadores.

La velocidad alcanzó hasta 12 bits por segundo, con una precisión superior al 99 %. Puede parecer lenta frente a una descarga convencional, pero representa una mejora de aproximadamente 360 veces respecto a la demostración publicada en 2021. Para secretos de tamaño limitado, una filtración de esta naturaleza puede pasar de ser una posibilidad teórica a un riesgo técnicamente relevante.

También es fundamental comenzar con tres precisiones: la investigación no demostró el robo de contraseñas, no accedió a información real de clientes y Cloudflare afirma que ya implementó medidas de mitigación. La empresa tampoco encontró indicadores de explotación activa durante los últimos tres años.

El valor del caso está en otra parte: muestra que, en plataformas compartidas, incluso las señales casi imperceptibles del procesador deben formar parte del modelo de seguridad.

Cloudflare Workers no se refiere a trabajadores

El nombre puede producir confusión al traducirse literalmente. Cloudflare Workers no son empleados de la compañía.

Workers es una plataforma de cómputo en el borde que permite ejecutar aplicaciones JavaScript cerca de los usuarios, sin que cada cliente tenga que administrar servidores tradicionales. En este modelo, múltiples aplicaciones de diferentes organizaciones pueden compartir una misma máquina e incluso un mismo proceso del sistema operativo.

Cada Worker se ejecuta dentro de un "isolate" de V8, el motor de JavaScript utilizado también por navegadores basados en Chromium. Cada isolate mantiene su propio espacio lógico de memoria y debería permanecer separado de los demás.

Esta arquitectura ofrece ventajas importantes. Permite iniciar aplicaciones con rapidez, atender solicitudes con baja latencia y utilizar los recursos de forma eficiente. Al mismo tiempo, crea una pregunta de seguridad compleja: ¿qué ocurre si dos aplicaciones están separadas en el nivel del lenguaje, pero comparten componentes físicos como núcleos de procesamiento y memoria caché?

Spectre aprovecha precisamente esa frontera.

Qué es Spectre y por qué sigue siendo relevante

Los procesadores modernos intentan anticipar las instrucciones que probablemente necesitarán ejecutar. Este mecanismo, conocido como ejecución especulativa, mejora el rendimiento porque permite avanzar antes de conocer con certeza el siguiente paso.

Cuando la predicción es incorrecta, el procesador descarta el resultado lógico. Sin embargo, pueden permanecer rastros diminutos en su estado interno, especialmente en la memoria caché.

Spectre explota esos rastros.

Un atacante manipula la ejecución especulativa para provocar un acceso transitorio a información que normalmente estaría fuera de sus límites. Después mide diferencias de tiempo extremadamente pequeñas para inferir si determinados datos pasaron por la caché.

No se trata de romper el cifrado del secreto ni de leer directamente un archivo. Es un canal lateral: la información se reconstruye observando efectos indirectos del procesamiento.

Desde su divulgación en 2018, Spectre ha sido especialmente difícil de eliminar porque surge de optimizaciones presentes en el diseño de los procesadores. Las defensas suelen combinar cambios en hardware, sistemas operativos, compiladores y plataformas de ejecución.

En un entorno remoto, el ataque es todavía más complejo. El adversario debe obtener mediciones suficientemente estables a pesar del ruido de la red, la actividad de otros procesos, los cambios de contexto y las restricciones impuestas por la plataforma.

La investigación demuestra que estas dificultades pueden reducirse con nuevas técnicas.

El reto de medir el tiempo desde un Worker

Los ataques de canal lateral necesitan un reloj preciso. Si el atacante no puede medir cuánto tarda una operación, le resulta difícil distinguir si un dato estuvo o no en la caché.

Cloudflare Workers limita deliberadamente los temporizadores locales. Durante la ejecución del código, funciones como Date.now() y performance.now() no ofrecen un reloj de alta resolución que avance de manera normal. La plataforma tampoco permite memoria compartida o múltiples hilos con los que una aplicación pudiera construir su propio temporizador.

Estas restricciones habían elevado considerablemente el costo de un ataque remoto.

Los investigadores encontraron una alternativa: utilizar comunicación remota y amplificación para convertir diferencias muy pequeñas en señales observables. El trabajo combinó el comportamiento de WebSockets y Durable Objects con técnicas de calibración capaces de funcionar bajo las condiciones variables de producción.

En lugar de depender de una sola medición perfecta, el sistema repetía pruebas, comparaba distribuciones y aplicaba votación para clasificar cada bit. Así logró separar con alta precisión los valores cero y uno.

La lección es profunda: eliminar un reloj local no garantiza que no exista otra forma de medir el tiempo. Una plataforma compleja puede ofrecer, sin proponérselo, componentes que juntos recuperen la capacidad restringida.

La cohabitación era una condición necesaria

El ataque no podía dirigirse de manera arbitraria contra cualquier Worker del mundo.

Para observar memoria mediante el mismo proceso, el Worker atacante y el Worker víctima tenían que quedar ubicados en condiciones compatibles dentro de la infraestructura compartida. Los investigadores desarrollaron métodos para confirmar esa cohabitación y mantener la ejecución el tiempo suficiente para realizar las mediciones.

Este requisito reduce la facilidad práctica del ataque, pero no elimina su importancia. En seguridad cloud, la capacidad de intentar repetidamente la colocación de cargas junto a un objetivo ha sido estudiada durante años.

La defensa no puede depender únicamente de que resulte difícil coincidir con otra aplicación. También debe limitar qué puede inferirse después de lograrlo.

Por eso, el caso debe analizarse como un problema de aislamiento entre clientes, no como una vulnerabilidad tradicional de una página web.

Se filtró un JWT, no una contraseña

La imagen que circula en redes sociales habla de contraseñas, pero la demostración publicada se enfocó en un JWT colocado deliberadamente en el Worker víctima.

La diferencia importa.

Un JWT es un formato utilizado para transportar afirmaciones firmadas sobre una identidad, una sesión o los permisos de un servicio. Dependiendo de su propósito, quien posee un token válido puede presentarlo ante una aplicación para demostrar que está autenticado o autorizado.

El ataque no rompió la firma criptográfica del JWT. Tampoco descubrió la contraseña con la que un usuario inició sesión. Extrajo la representación del token desde la memoria mientras estaba disponible para la aplicación.

Esto ilustra una regla clásica de seguridad: el cifrado y las firmas protegen los datos en ciertos estados, pero un secreto debe estar disponible en memoria cuando un sistema necesita utilizarlo.

Si un atacante obtiene un token vigente, su impacto depende de varios factores:

— El tiempo restante antes de su expiración.

— Los permisos y recursos asociados.

— La posibilidad de revocarlo.

— La validación de audiencia y emisor.

— La existencia de controles adicionales vinculados al dispositivo o a la sesión.

— La capacidad de detectar un uso anómalo.

Por lo tanto, proteger la identidad no termina al elegir un algoritmo seguro. También exige reducir el valor y la vida útil de cualquier credencial que pudiera quedar expuesta.

Por qué 12 bits por segundo sí importan

Doce bits por segundo es una velocidad insignificante para copiar documentos o bases de datos completas. Sin embargo, los ataques de canal lateral no necesitan comenzar por grandes volúmenes.

Los adversarios buscan secretos pequeños que abran puertas más grandes: tokens, claves, identificadores, fragmentos de credenciales o información que permita ampliar el acceso.

La investigación de 2021 había alcanzado alrededor de 120 bits por hora. A ese ritmo, la defensa Dynamic Process Isolation — DyPrIs — podía detectar comportamientos sospechosos y mover el Worker a un proceso separado antes de que la filtración avanzara demasiado.

La nueva prueba llegó a 12 bits por segundo, aproximadamente 43 mil bits por hora. Este salto comprime el tiempo disponible para detectar y aislar la actividad.

La velocidad, por sí sola, no determina el riesgo. También intervienen la longitud del secreto, los errores, la estabilidad, la cohabitación y las medidas de respuesta. Pero demuestra que una mitigación adecuada frente a una generación de técnicas puede quedar rezagada cuando mejora la capacidad de amplificar señales.

La seguridad debe evaluarse contra el ataque actual, no contra el que se conocía al diseñar el control.

La limitación de DyPrIs

Cloudflare desarrolló Dynamic Process Isolation después de su investigación de 2021.

DyPrIs observa contadores de rendimiento del hardware y busca comportamientos compatibles con Spectre. Cuando identifica un Worker sospechoso, lo traslada a un proceso independiente. La separación a nivel del sistema operativo agrega barreras que no existen entre isolates del mismo proceso.

La nueva investigación encontró una limitación en la implementación de esta defensa. Las técnicas actualizadas permitieron conservar una señal útil y filtrar información antes de que el aislamiento detuviera el ataque.

Esto no significa que DyPrIs fuera inútil. Significa que una defensa dinámica depende de la calidad y velocidad de su detección. Si el adversario cambia su comportamiento o acelera la extracción, los umbrales deben evolucionar.

Cloudflare informó que mejoró las capacidades de DyPrIs como parte de la respuesta.

Las mitigaciones aplicadas por Cloudflare

Según la publicación oficial y el artículo académico, el ataque presentado ya fue mitigado en producción.

Cloudflare reforzó varias capas:

— Mejoró la detección de Dynamic Process Isolation.

— Integró el V8 Sandbox para limitar el alcance de determinados accesos y reducir la utilidad de punteros de 64 bits.

— Incorporó aislamiento dentro del proceso con apoyo de Memory Protection Keys, o MPK, para separar la memoria de cada cliente mediante protecciones del hardware.

— Fortaleció el modelo general de aislamiento alrededor del entorno de ejecución.

La combinación es importante. Ninguna capa aislada resuelve por completo todos los canales de ejecución especulativa. La defensa se construye reduciendo las oportunidades, limitando el alcance de lectura, detectando patrones y separando cargas cuando el riesgo aumenta.

Cloudflare señala que no encontró indicadores de que la técnica haya sido utilizada activamente y que el experimento se realizó con aplicaciones controladas por el equipo de investigación.

Esta información debe impedir interpretaciones alarmistas. El estudio demuestra una capacidad y una limitación corregida; no documenta una campaña conocida contra clientes.

Lo que sí pueden hacer las organizaciones usuarias

La corrección principal corresponde al proveedor de la plataforma. Un cliente de Workers no puede modificar el aislamiento interno de V8 ni instalar mitigaciones en los procesadores de Cloudflare.

Sin embargo, las organizaciones sí pueden reducir el impacto potencial de una exposición de memoria.

Primero, utilizar credenciales de corta duración. Un token que expira pronto disminuye la ventana en la que puede reutilizarse.

Segundo, aplicar mínimo privilegio. Los JWT y las identidades de servicio deben permitir únicamente las operaciones necesarias para cada función.

Tercero, evitar secretos permanentes cuando existan mecanismos de identidad temporal o credenciales administradas.

Cuarto, separar entornos y funciones. Producción, desarrollo y administración no deberían compartir las mismas credenciales ni la misma autoridad.

Quinto, contar con revocación y rotación rápidas. Detectar un token expuesto sirve de poco si la organización no puede invalidarlo.

Sexto, monitorear el uso, no solo la emisión. Una credencial válida puede utilizarse desde un contexto inesperado, con un volumen anormal o contra recursos que normalmente no consulta.

Séptimo, reducir los datos sensibles presentes en memoria y evitar incluir información confidencial innecesaria dentro de los propios tokens.

Estas prácticas no sustituyen la seguridad del proveedor. Limitan el radio de impacto cuando una barrera falla.

La responsabilidad compartida también incluye la arquitectura del proveedor

En la nube, el modelo de responsabilidad compartida suele explicar qué configura el cliente y qué protege el proveedor.

Los canales laterales muestran por qué esta división no siempre es visible. El usuario puede desplegar código seguro, mantener sus dependencias actualizadas y aplicar mínimo privilegio, pero sigue dependiendo de decisiones internas sobre colocación, aislamiento, temporizadores y hardware.

Por eso, la gestión de proveedores debe incluir preguntas técnicas:

— ¿Qué límites separan las cargas de diferentes clientes?

— ¿Cuándo se utiliza aislamiento por proceso?

— ¿Cómo se detectan ataques de canal lateral?

— ¿Qué telemetría revisa el proveedor?

— ¿Cómo se comunican vulnerabilidades que afectan el aislamiento?

— ¿Qué evidencia existe sobre pruebas independientes?

— ¿Cuál es el procedimiento para rotar credenciales después de un incidente?

— ¿Cómo se valida que una mitigación funciona en condiciones reales de producción?

No todas las organizaciones podrán evaluar los detalles de Spectre, pero sí pueden exigir transparencia sobre el modelo de seguridad y la respuesta.

Serverless no se volvió inseguro de un día para otro

La investigación no implica que las empresas deban abandonar Cloudflare Workers ni las plataformas de cómputo sin servidor.

Los entornos serverless reducen numerosos riesgos operativos: eliminan servidores que el cliente tendría que administrar, aceleran actualizaciones del entorno y permiten que equipos especializados protejan la infraestructura común.

El análisis responsable compara riesgos completos, no una vulnerabilidad aislada.

Operar infraestructura propia también introduce exposición por configuraciones incorrectas, parches retrasados, credenciales permanentes, servicios innecesarios y falta de monitoreo.

La decisión debe basarse en la sensibilidad de la carga, las capacidades del proveedor, los requisitos regulatorios y el impacto de una posible falla de aislamiento.

Para algunas funciones, compartir infraestructura seguirá siendo una opción adecuada. Para procesos extremadamente sensibles, puede justificarse mayor separación, controles adicionales o arquitecturas dedicadas.

La clave es tomar la decisión de forma consciente, no asumir que "nube" equivale automáticamente a aislamiento perfecto.

Tres lecciones para líderes tecnológicos

La primera lección es que la eficiencia y el aislamiento están conectados. Compartir procesos permite velocidad y densidad, pero aumenta la importancia de las barreras internas.

La segunda es que el riesgo residual cambia con el tiempo. Una defensa efectiva en 2021 puede necesitar ajustes frente a técnicas desarrolladas años después.

La tercera es que los secretos deben diseñarse para fallar de manera segura. Ninguna credencial debería ofrecer acceso amplio e indefinido solo por ser presentada correctamente.

Los líderes no necesitan convertirse en especialistas en microarquitectura. Sí deben asegurar que sus equipos consideren la dependencia de proveedores, la vida útil de tokens, el mínimo privilegio y la capacidad de respuesta.

Una señal pequeña puede revelar una frontera grande

El ataque contra Cloudflare Workers no descargó archivos completos ni rompió la criptografía de Internet. Hizo algo más sutil: convirtió diferencias diminutas en el comportamiento del procesador en una señal capaz de reconstruir un secreto.

Esa señal alcanzó 12 bits por segundo y superó una defensa diseñada para una versión mucho más lenta del problema.

Cloudflare respondió reforzando su aislamiento y señala que no hubo evidencia de explotación activa. La divulgación permite que otras plataformas revisen sus propios supuestos antes de enfrentar una demostración similar.

Para las organizaciones, la conclusión no es desconfiar de toda infraestructura compartida. Es reconocer que la confianza debe sostenerse con varias capas: seguridad del proveedor, arquitectura resiliente, credenciales limitadas, monitoreo y capacidad de recuperación.

La pregunta no es si una barrera puede fallar. La pregunta es cuánto puede alcanzar un atacante cuando ocurre y qué tan rápido puede la organización reducir el impacto.

¿Tus tokens están diseñados para seguir siendo seguros incluso después de una exposición parcial?

En TU INSIGNIA ayudamos a las organizaciones a comprender su exposición digital, evaluar riesgos en servicios cloud y fortalecer sus capacidades de protección, detección y resiliencia.

🔐 Tu empresa podría estar más expuesta de lo que crees.

Conoce nuestros servicios en https://www.tuinsignia.com

Fuentes:

https://blog.cloudflare.com/revisiting-spectre-attacks-on-workers/

https://arxiv.org/abs/2608.17043

https://developers.cloudflare.com/workers/reference/security-model/