El fork bomb nos salvó

El malware en LiteLLM 1.82.8 contenía un archivo .pth que se ejecutaba en cada inicio de Python. Recopilaba claves SSH, credenciales de nube, billeteras de criptomonedas y secretos de CI/CD, los cifraba con una clave RSA de 4096 bits y exfiltraba el archivo a un dominio controlado por el atacante. El payload estaba bien diseñado. El cifrado era sólido. La exfiltración era limpia.¹ Este incidente forma parte de mi serie sobre seguridad de agentes, que aborda las fallas del mundo real que determinan cómo construimos confianza en sistemas automatizados.

El archivo .pth también generaba un proceso hijo de Python para realizar su trabajo. Ese proceso hijo activaba el archivo .pth de nuevo, lo que generaba otro proceso hijo, que lo activaba otra vez. Un fork bomb exponencial que consumía el 100% del CPU y más de 5 GB de RAM en cuestión de segundos.²

El fork bomb fue un bug. El atacante no pretendía que el malware fuera visible. Una versión correctamente implementada habría ejecutado silenciosamente en cada invocación de Python en cada sistema infectado, potencialmente durante semanas. En cambio, los desarrolladores notaron que sus máquinas se paralizaban, investigaron y encontraron el ladrón de credenciales. PyPI puso en cuarentena ambas versiones 46 minutos después de la publicación.¹

Cuarenta y seis mil instalaciones en cuarenta y seis minutos. El mecanismo de detección fue un error de implementación en el malware.

TL;DR

• El bug: El ladrón de credenciales de LiteLLM 1.82.8 tenía un bug de fork bomb que hacía que las máquinas infectadas se paralizaran. Sin el bug, el ladrón habría ejecutado silenciosamente durante semanas.
• La brecha: El análisis estático, el monitoreo de comportamiento y la revisión de código fallaron en detectar el ataque. Cada capa de detección asumía que otra capa lo atraparía. Ninguna lo hizo.³
• La curva: La calidad del atacante mejora con la iteración. La técnica del .pth ahora está documentada públicamente. El siguiente atacante la hereda sin el bug.
• Lo que funciona sin suerte: Verificación de antigüedad de dominio en el tráfico saliente, línea base de comportamiento para instalaciones de paquetes, canarios en el sistema de archivos, aislamiento de instalación. Cada uno funciona independientemente de la calidad del payload.
• La asimetría: El defensor elige el entorno. Si el entorno de instalación no tiene credenciales que robar, un payload perfecto no cosecha nada.

Tuvimos suerte

Elimina el fork bomb del payload y el ataque tiene éxito silenciosamente. El archivo .pth se ejecuta antes de cualquier import, antes de cualquier código de aplicación, antes de cualquier sandbox a nivel de Python. No hay punto de enganche. No hay entrada en el log. El ladrón de credenciales ejecuta, cifra, exfiltra, y el proceso de Python continúa normalmente. El desarrollador no ve nada. El pipeline de CI no ve nada. El escáner de seguridad no ve nada, porque el escáner de seguridad era el vector de ataque en primer lugar.³

La historia de detección de LiteLLM 1.82.8 no es “nuestro monitoreo lo detectó”. La historia de detección es “el atacante publicó un bug”.

Esta no es una base cómoda para la seguridad de la cadena de suministro. Como argumento en tu sandbox de agente es una sugerencia, los límites que asumimos que existen entre código confiable y no confiable son mucho más porosos de lo que la mayoría de los equipos creen.

La curva de calidad del atacante

La calidad del software mejora con la iteración. Esto aplica tanto para atacantes como para defensores. La campaña de TeamPCP atacó cinco ecosistemas en una semana: GitHub Actions, Docker Hub, npm, Open VSX y PyPI.⁴ Cada compromiso de ecosistema utilizó credenciales cosechadas del anterior. La campaña demostró sofisticación operativa: registro de dominio 24 horas antes de la entrega del payload, secuestro de tags en referencias mutables y evasión de rotación de credenciales mediante cambios incompletos de claves de Aqua Security.

El fork bomb fue el único error en una operación por lo demás competente. La próxima campaña no cometerá ese error. La técnica del archivo .pth ahora está documentada públicamente, analizada por CrowdStrike, Microsoft, Wiz y Palo Alto.³ El siguiente atacante hereda la técnica sin el bug.

La capacidad adversarial sigue la misma curva de mejora que la capacidad defensiva. La técnica es pública. El análisis es público. El siguiente atacante comienza donde TeamPCP terminó. Exploro lo que esta curva significa para sistemas autónomos en lo que realmente se rompe sin supervisión.

La detección no puede depender de los errores del atacante

El modelo actual de detección en la cadena de suministro tiene tres capas, y las tres fallaron con LiteLLM:

El análisis estático no lo detectó. El archivo .pth es una función legítima de Python. El payload estaba doblemente codificado en base64 y se decodificaba en tiempo de ejecución. Los escáneres estáticos que buscan patrones maliciosos conocidos no encuentran nada porque el patrón es nuevo.

El monitoreo de comportamiento no lo detectó. El ladrón de credenciales realizó una única solicitud HTTPS POST saliente a un dominio que parecía un servicio legítimo (models.litellm.cloud). El monitoreo de tráfico saliente que inspecciona dominios de destino necesitaría saber que este dominio específico fue registrado 24 horas antes. La mayoría de los monitores de tráfico saliente no verifican la antigüedad del dominio.

La revisión de código no lo detectó. Las versiones maliciosas se publicaron directamente en PyPI, evitando por completo el pipeline de CI/CD de GitHub. No hubo pull request que revisar. No hubo diff que inspeccionar. El atacante usó credenciales de publicación robadas para subir paquetes preconstruidos.

Cada capa de detección asumió que una parte diferente de la cadena de ataque atraparía el problema. Ninguna lo hizo. El fork bomb atrapó el problema.

Qué realmente detecta malware silencioso

Si no puedes depender de los errores del atacante, necesitas mecanismos de detección que funcionen independientemente de la calidad de la implementación.

Verificación de antigüedad de dominio en solicitudes salientes. El dominio de exfiltración fue registrado 24 horas antes del ataque. Una regla de firewall que marque solicitudes salientes a dominios con menos de 7 días de antigüedad lo habría detectado. La regla es simple, la tasa de falsos positivos es manejable y captura el patrón de exfiltración más común.

Línea base de comportamiento para procesos de Python. Un pip install que de repente realiza solicitudes HTTPS POST a un dominio desconocido es anómalo. El monitoreo de comportamiento a nivel de proceso que rastrea la actividad de red durante la instalación de paquetes marcaría esto.

Canarios en el sistema de archivos. Coloca una clave SSH falsa en una ruta canario y una credencial AWS falsa en otra ruta canario. Monitorea cualquier proceso que lea estos archivos. Un ladrón de credenciales que barre rutas estándar leerá los canarios. Un proceso legítimo no lo hará. El canario activa una alerta antes de que se complete la exfiltración.

Aislamiento de instalación. Ejecuta pip install en un entorno sin acceso a credenciales reales. Copia los paquetes instalados al entorno de producción después. El archivo .pth se activa durante el propio proceso de Python de pip, lo que significa que el ladrón de credenciales se ejecuta durante la instalación. Si el entorno de instalación no tiene credenciales que robar, el ataque no cosecha nada.

Ninguno de estos mecanismos requiere que el atacante cometa un error. Funcionan independientemente de la calidad del payload. El patrón arquitectónico —diseñar entornos donde incluso un ataque perfecto no cosecha nada— es el mismo principio detrás de despliega y defiende: la paradoja de confianza del agente.

La asimetría

La defensa tiene una ventaja estructural: el defensor elige el entorno. El atacante debe trabajar dentro del entorno en el que se instale el paquete. Si ese entorno no tiene credenciales, no tiene acceso a la red y tiene canarios en el sistema de archivos, el payload tiene éxito técnico pero fracasa operativamente.

El ataque a LiteLLM funcionó porque el entorno de instalación era el mismo entorno que contenía las credenciales de publicación, claves SSH y tokens de nube. El fork bomb era irrelevante para la arquitectura de seguridad. Era relevante para la línea de tiempo.

La próxima vez, el fork bomb no estará ahí. Las credenciales seguirán en el mismo entorno que el gestor de paquetes. La pregunta es si habrás cambiado el entorno antes de que el siguiente atacante publique un payload limpio. Mi análisis de la arquitectura del agente Ralph muestra cómo estructurar sistemas de agentes para que los componentes comprometidos no puedan escalar más allá de su límite de aislamiento.

FAQ

¿Por qué el atacante no probó el fork bomb?

El archivo .pth generando un proceso hijo es una decisión de implementación razonable para ejecutar un payload sin bloquear el proceso padre. La activación recursiva es una interacción sutil entre .pth y la inicialización de site.py de Python. Es el tipo de bug que aparece en pruebas de integración pero no en pruebas unitarias, y los autores de malware tienen oportunidades limitadas para realizar pruebas de integración en entornos realistas.

¿Podría el fork bomb haber sido intencional?

Poco probable. El fork bomb hizo que el malware fuera inmediatamente visible, que es lo opuesto al objetivo del atacante. Un ladrón de credenciales silencioso que ejecuta durante semanas cosecha órdenes de magnitud más credenciales que uno detectado en 46 minutos.

¿Es práctica la verificación de antigüedad de dominio a escala?

Sí. La antigüedad del dominio está disponible a través de WHOIS o APIs de fecha de registro DNS. La verificación añade milisegundos de latencia por solicitud. La mayoría de las organizaciones pueden crear listas blancas de dominios nuevos conocidos.

Sources