Hoy quiero hablar de un ataque viejo que vuelve a ser nuevo y que puede afectar a tus sistemas de producción: la bomba zip.
Aquí no hay nada reciente. Según la Wikipedia, el término zip bomb se usó por primera vez en 2001.
TL;DR
La idea es simple. Un atacante construye un fichero zip con truco: no se puede descomprimir de verdad. Un zip diminuto, que apenas ocupa nada en disco, puede crecer hasta los petabytes cuando la víctima intenta abrirlo.
Ya te imaginas lo bien que sienta que un fichero necesite petabytes de tu disco :)
En qué punto están las bombas zip
La mayoría de las herramientas de zip ya detectan un fichero con pinta de bomba. Avisan al usuario y se niegan a descomprimirlo:
Vale, buena noticia. ¿Entonces cuál es el problema?
En 2019, el investigador de seguridad David Fifield construyó un tipo nuevo de bomba zip. Funciona hoy y a los programas que manejan ficheros zip les cuesta mucho detectarla.
Bombas zip y DevSecOps
Llegados aquí, igual te preguntas qué tiene que ver una bomba zip con DevSecOps. Sobre el papel suena a problema de hardening de los sistemas de producción, ¿no? Lo siento, pero no.
Uno de los objetivos de DevSecOps es la automatización: recortar el tiempo entre desarrollo y producción. Eso significa que construir un artefacto a partir del código fuente y llevarlo a producción suele ser (¡debe ser!) automático.
Construir un artefacto no es magia. Los desarrolladores escriben las instrucciones exactas para hacerlo, y el sistema de CI las ejecuta.
¿Qué pasa si un desarrollador mete un paso que genera una bomba zip y el sistema de CI la sube a producción?
Ficheros zip y sistemas de producción
Vale. Hemos conseguido colar un zip en producción. ¿Y qué?
Muchas aplicaciones usan el formato zip para empaquetar ficheros y contenido. Un .docx de Microsoft Word, sin ir más lejos, es un zip con otra extensión.
Muchos servidores de aplicaciones web hacen lo mismo. Apache Tomcat usa la extensión .war para una web Java empaquetada como zip.
Siguiendo ese ejemplo, lo primero que hace Tomcat para arrancar un .war es descomprimirlo. Y justo ahí Tomcat puede ser vulnerable a una bomba zip.
Demo: Apache Tomcat contra una bomba zip
Para la demo creamos una bomba zip y la renombramos a .war. Tomcat despliega ese formato de forma automática cuando el fichero aparece en un directorio concreto que se configura previamente.
Preparando el escenario
Montamos una máquina virtual en VirtualBox con Tomcat y abrimos una consola con tres vistas de monitorización:
- Espacio en disco.
- Memoria.
- Uso de CPU por proceso.
Se ve en la imagen:
Desplegando la bomba zip
Con los monitores listos, copiamos la bomba zip al directorio de Tomcat:
Viendo qué pasa
El vídeo está acelerado. El tiempo real transcurrido se ve en la esquina superior derecha.
Al final, la máquina virtual se cae.
Conclusiones
Algunas cosas que podemos sacar de aquí:
-
Los ataques de toda la vida vuelven a colarse cuando automatizas un proceso y quitas por el camino las comprobaciones manuales.
-
Fallar rápido es el objetivo en DevOps, y DevSecOps tiene que jugar con las mismas reglas. Algunos ataques que tradicionalmente dejábamos para la fase de hardening también se pueden cubrir con un buen pipeline de seguridad.
-
Hay que revisar los ficheros de construcción y los comandos que generan los artefactos finales, no solo el código fuente de la aplicación.
Más posts de la serie DevSecOps
DevSecOps series No. 1 — Rompiendo el CI/CD usando repositorios Git maliciosos
DevSecOps series No. 2: Comprobación automática de seguridad en Dockerfiles
DevSecOps series No. 4: Protegiendo las variables de entorno en los sistemas de CI más conocidos
