Resumen Técnico: Un poco de un "Close Talker": Una guía práctica para ataques de co-ubicación en la nube sin servidor (Serverless)

Declaración del Problema

La computación sin servidor (serverless) ofrece eficiencia y rentabilidad al delegar la gestión de la infraestructura a los proveedores de la nube. Sin embargo, este modelo introduce vulnerabilidades de seguridad, específicamente ataques de canal lateral microarquitectónicos (por ejemplo, Prime+Probe), que requieren que las instancias atacante y víctima estén co-ubicadas en el mismo servidor físico. Aunque los hosts dedicados pueden prevenir la co-ubicación, son prohibitivamente costosos (más de 10 veces el costo de serverless).

La investigación existente ha explorado la co-ubicación en nubes tradicionales "con servidor" (serverful) y en plataformas específicas como Google Cloud Run, pero existe una falta de una metodología universal para explotar los planificadores (schedulers) de la nube sin servidor. Los atacantes carecen actualmente de un enfoque sistemático para realizar ingeniería inversa a los algoritmos de planificación y construir ataques de co-ubicación utilizando únicamente interfaces de usuario estándar (invocando funciones) sin acceso privilegiado.

Metodología

El artículo propone un marco de tres etapas para lograr la co-ubicación en entornos sin servidor:

1. Identificación de la huella del planificador (Paso 0)

Los autores introducen un método para revelar características explotables de los algoritmos de planificación de serverless mediante la observación de secuencias de colocación. El proceso consta de tres fases de invocación de funciones:

• Fase 1: Invocar repetidamente una sola función para detectar la Localidad de Invocación (F1) (reutilización de hosts para evitar arranques en frío/cold starts) y el Escalado Automático (F2) (dispersión de hosts bajo carga).
• Fase 2: Invocar la función original junto con una función distinta pero funcionalmente idéntica para detectar la Localidad de los de Arranque en Frío (F3) (si las instancias relanzadas regresan a los mismos servidores) y la Localidad de la Cuenta (F4) (si las funciones de un usuario están confinadas a un conjunto específico de servidores).
• Fase 3: Invocar funciones con parámetros de configuración variables (por ejemplo, diferentes dependencias de paquetes) para detectar la Localidad Basada en la Configuración (F5), como la planificación consciente de los paquetes.

2. Construcción del Ataque (Paso 1)

Basándose en las características identificadas, los autores proponen estrategias de ataque específicas:

• Para la Localidad de Invocación (F1): Construir múltiples funciones de ataque distintas para aumentar la probabilidad de impactar el mismo conjunto limitado de hosts "calientes" (warm hosts).
• Para el Escalado Automático (F2): Crear ráfagas de invocaciones para forzar al planificador a escalar hacia afuera, dispersando las instancias del atacante a través del clúster.
• Para la Localidad Basada en la Configuración (F5):
  • Targeting Preciso: Si se conocen las dependencias de la víctima, construir una función de ataque con dependencias idénticas para forzar la co-ubicación.
  • Basado en Dispersión (Scatter-Based): Si las dependencias son desconocidas, construir múltiples funciones con diversas dependencias para cubrir la lógica de planificación del clúster.

3. Evaluación

La metodología fue evaluada utilizando:

• Simulador: Un simulador en C++ que modela aproximadamente 2000 líneas de código con 4 algoritmos de planificación (Random, Helper, OpenWhisk, Package-Aware Scheduler).
• Experimentos de Clúster: Un clúster CloudLab de 50 nodos ejecutando una plataforma sin servidor basada en Dask.
• Caso de Estudio en el Mundo Real: Microsoft Azure Functions (Plan de Consumo).

Contribuciones Clave

1. Método de Identificación de Huella del Planificador: Un enfoque sistemático para realizar ingeniería inversa a las políticas de planificación de serverless (F1–F5) utilizando únicamente interfaces de usuario normales.
2. Estrategia de Ataque Universal: Una guía para construir ataques de co-ubicación adaptados a características de planificación específicas, incluyendo enfoques de "dispersión" y "targeting preciso".
3. Validación Empírica: Demostración exitosa de ataques de co-ubicación en:
   • Plataformas de código abierto (OpenWhisk, sistemas basados en Dask).
   • Infraestructura comercial (Microsoft Azure Functions).
   • Diferentes algoritmos de planificación (Random, Helper, PASch).
4. Propuesta de Mitigación (Double-Dip): Un nuevo algoritmo de planificación diseñado para proporcionar un aislamiento de usuario "suave". Prioriza la colocación de la nueva función de un usuario en un host donde ya está activo; si no existe uno, selecciona el host con la menor variedad de usuarios activos para minimizar la superposición entre usuarios.

Resultados

Identificación de Huella y Éxito del Ataque

• Identificación de Características: El método de identificación de huellas logró identificar comportamientos distintos en diferentes planificadores. Por ejemplo, el planificador Helper (que imita a Google Cloud Run) exhibió auto-escalado y localidad de arranque en frío, mientras que PASch exhibió localidad de paquetes.
• Eficiencia del Ataque:
  • Localidad Basada en la Configuración (F5): Explotar esta característica produjo las tasas de éxito más altas. En el planificador PASch, los atacantes lograron casi un 100% de éxito en la co-ubicación al igualar las dependencias de los paquetes.
  • Escalado Automático (F2): Explotar el auto-escalado fue menos eficiente. Aunque aumentó la cobertura, la tasa de éxito se estancó porque no todas las invocaciones activaron la creación de nuevos hosts.
  • Planificación Aleatoria (Random): Contrario a la intuición, se encontró que la planificación puramente aleatoria es vulnerable; los atacantes pueden lograr una alta cobertura simplemente desplegando un gran número de funciones.
• Caso de Estudio de Azure Functions:
  • La identificación de la huella reveló que Azure Functions considera la localidad de invocación y escala automáticamente, pero no confina las funciones de un mismo usuario a un pequeño conjunto de servidores (no hay Localidad de Cuenta). Sin embargo, sí coloca las funciones de una misma aplicación en la misma máquina física.
  • Resultado del Ataque: Usando 64 funciones de ataque a través de diferentes aplicaciones, el atacante logró la co-ubicación con al menos un host víctima en cada experimento (5 ensayos). El ataque cubrió un promedio de 230 máquinas y costó menos de $25 USD.

Evaluación de la Mitigación (Double-Dip)

• Resistencia a la Co-ubicación: En simulaciones con hasta 50 atacantes, el planificador Double-Dip mantuvo una tasa de éxito de co-ubicación significativamente menor en comparación con el planificador Helper. Para 50 atacantes, Helper alcanzó el 100% de éxito, mientras que Double-Dip se mantuvo en el 30.6%.
• Sobrecarga de Rendimiento: Double-Dip preservó la mayoría de los beneficios de "arranque en caliente" (warm-start) del planificador Helper (altas proporciones de warm-start) e introdujo solo una modesta sobrecarga de rendimiento, escalando bien a medida que aumentaban el número de usuarios y el volumen de solicitudes.

Significancia y Reivindicaciones

El artículo afirma cerrar una brecha crítica en la seguridad de serverless al proporcionar una guía práctica para que los atacantes construyan ataques de co-ubicación sin acceso privilegiado. Los autores enfatizan que:

• El Diseño del Planificador es Crítico: Los planificadores actuales de serverless a menudo priorizan el rendimiento (reducción de arranque en frío, equilibrio de carga) sobre la seguridad, creando inadvertidamente patrones de colocación deterministas que los atacantes pueden explotar.
• La Aleatoriedad no es una Panacea: La planificación puramente aleatoria no garantiza la seguridad; de hecho, puede ser explotada por atacantes para dispersar instancias y aumentar la cobertura.
• El Aislamiento Suave es Viable: El algoritmo propuesto Double-Dip demuestra que es posible mitigar los riesgos de co-ubicación a través de la lógica de planificación ("aislamiento suave") sin recurrir a hardware dedicado costoso, aunque no ofrece una garantía del 100%.

Los autores concluyen que comprender y explotar las características de los planificadores es esencial tanto para atacantes como para defensores, y que los futuros sistemas de planificación de serverless deben equilibrar la optimización del rendimiento con la imprevisibilidad de la seguridad.