Skip to main content
AltoProtected by PowerWAF

Ataque de Bomba ZIP

CategoríaArchivos y RutasOWASPA05:2021 – Configuración de Seguridad IncorrectaPrimera aparición1996Tiempo de lectura8 minVerificado2026-03-12
DEFINICIÓN

Una bomba ZIP (también llamada bomba de descompresión o zip de la muerte) es un archivo comprimido malicioso diseñado para colapsar o incapacitar el sistema que lo descomprime. Al explotar las enormes ratios de compresión alcanzables con datos repetitivos, un archivo pequeño — a veces de solo 42 kilobytes — puede expandirse a petabytes de datos, agotando el espacio en disco, la memoria y los recursos de CPU. Las bombas ZIP apuntan a escáneres antivirus, procesadores de subida de archivos, gateways de correo electrónico y cualquier sistema automatizado que extraiga archivos comprimidos.

Cómo Funciona Ataque de Bomba ZIP

Los algoritmos de compresión como DEFLATE logran sus mejores ratios con datos altamente repetitivos. Un archivo que consiste enteramente en bytes nulos (0x00) puede comprimirse con ratios que exceden 1000:1. Una bomba ZIP arma este principio ya sea anidando archivos comprimidos dentro de otros (bomba recursiva) o usando entradas de archivo superpuestas que referencian el mismo núcleo de datos comprimidos (bomba quine/plana). Cuando el sistema de la víctima descomprime el archivo — ya sea para escanearlo en busca de malware, procesar una subida o extraer adjuntos — los datos descomprimidos inundan el almacenamiento y la memoria disponible, causando denegación de servicio.

1

Construir la carga útil

El atacante crea una bomba ZIP usando una de tres técnicas: (1) Bomba recursiva clásica: un archivo ZIP que contiene múltiples archivos ZIP, cada uno conteniendo más archivos ZIP, creando crecimiento exponencial a través de capas — el famoso 42.zip tiene 42 KB comprimido pero se expande a 4.5 petabytes a través de 6 capas de 16 archivos cada una; (2) Bomba plana (no recursiva): un ZIP de una sola capa que usa entradas de archivo superpuestas que referencian el mismo núcleo de datos comprimidos — la investigación de David Fifield de 2019 produjo un zip de 46 MB que se expande a 4.5 petabytes sin anidamiento, derrotando las defensas de profundidad de recursión; (3) Bomba quine: un archivo auto-referencial que contiene una copia de sí mismo, creando recursión infinita cuando una herramienta intenta extraer recursivamente todos los archivos anidados.

2

Entregar la bomba al objetivo

La entrega depende del sistema objetivo: (1) Adjunto de correo electrónico — envía la bomba ZIP a direcciones protegidas por un gateway de correo que auto-escanea adjuntos; el antivirus del gateway intenta descomprimir y escanear, agotando los recursos del servidor; (2) Subida de archivo — sube la bomba a una aplicación web que procesa archivos comprimidos (conversores de documentos, procesadores de imágenes, pipelines CI/CD, importadores de medios de CMS); (3) Endpoint de API — envía la bomba a APIs que aceptan cuerpos de solicitud comprimidos (Content-Encoding: gzip, deflate) o subidas de archivos comprimidos; (4) Evasión de escaneo de malware — envuelve malware real dentro de capas de una bomba ZIP para que los escáneres antivirus colapsen o agoten el tiempo antes de alcanzar la carga maliciosa.

3

Activar la descompresión

El sistema objetivo descomprime automáticamente el archivo como parte de su pipeline de procesamiento normal. Los escáneres antivirus descomprimen para inspeccionar contenido de archivos. Los procesadores de subida extraen archivos para validar o transformar el contenido. Los gateways de correo descomprimen para escanear adjuntos. Los sistemas CI/CD extraen archivos para procesamiento de compilación. En cada caso, la operación de descompresión comienza a llenar los recursos disponibles: el espacio en disco se llena primero (si escribe datos extraídos), o la memoria se llena primero (si descomprime en memoria). Las bombas planas modernas son particularmente peligrosas porque descomprimen en una sola pasada sin recursión, evadiendo las defensas de límite de profundidad.

4

Agotamiento de recursos y denegación de servicio

A medida que la descompresión avanza, los recursos del sistema se consumen sistemáticamente: (1) El espacio en disco se llena al máximo, potencialmente afectando otras aplicaciones que comparten el mismo sistema de archivos — las bases de datos colapsan, los logs no se pueden escribir, las aplicaciones fallan; (2) El agotamiento de memoria activa el OOM killer del SO (Linux) o causa degradación a nivel de sistema; (3) La CPU es consumida por la operación de descompresión en sí, especialmente con altas ratios de compresión que requieren computación intensiva; (4) El servicio afectado colapsa o deja de responder, causando denegación de servicio. Si el objetivo es un servicio compartido (gateway de correo, escáner AV centralizado, servidor CI/CD), el radio de explosión se extiende a todos los usuarios y sistemas que dependen de él.

Ejemplos Reales

2001

42.zip — La bomba ZIP original

El archivo 42.zip se convirtió en el ejemplo canónico de una bomba ZIP: un archivo de 42 kilobytes que se descomprime a 4.5 petabytes (4,503,599,627,370,496 bytes). Consiste en 16 archivos ZIP anidados 6 niveles de profundidad, cada archivo del nivel inferior conteniendo 4.3 GB de bytes nulos. Cuando los programas antivirus intentaban escanear el archivo, colapsaban o quedaban colgados indefinidamente. 42.zip expuso una debilidad fundamental en la arquitectura AV: la suposición de que la descompresión es segura. Forzó a toda la industria antivirus a implementar límites de descompresión — profundidad máxima de recursión, ratio máxima de expansión y tamaño máximo descomprimido — cambiando fundamentalmente cómo las herramientas de seguridad manejan archivos comprimidos.

2019

Investigación de bomba ZIP no recursiva (David Fifield)

El investigador de seguridad David Fifield publicó una investigación demostrando que las bombas ZIP pueden lograr ratios de expansión masivas sin recursión, evadiendo los límites de profundidad de recursión que los proveedores de AV habían implementado después de 42.zip. Su técnica usa la característica de ZIP que permite a múltiples entradas de archivo referenciar los mismos datos comprimidos — un archivo de 46 MB se expande a 4.5 petabytes en una sola pasada de descompresión sin anidamiento. Una variante más pequeña de 10 MB se expande a 281 TB. La investigación forzó a los proveedores de seguridad a replantear sus salvaguardas de descompresión, ya que verificar archivos anidados ya no era suficiente.

2023

Ataques de bomba ZIP a firewalls de aplicaciones web

Investigadores de seguridad demostraron que varios WAFs comerciales y gateways de API eran vulnerables a ataques de bomba ZIP mediante cuerpos de solicitudes HTTP comprimidos (Content-Encoding: gzip). Al enviar una solicitud pequeña comprimida con gzip que se expandía a gigabytes, los atacantes podían colapsar o deshabilitar temporalmente el WAF, creando una ventana para entregar cargas maliciosas sin protección a la aplicación upstream. El ataque apuntó a la infraestructura de defensa en sí en lugar de la aplicación, destacando que las herramientas de seguridad deben protegerse a sí mismas contra DoS basado en descompresión.

Impacto y Evaluación de Riesgo

Las bombas ZIP se clasifican como Altas porque explotan la confianza fundamental que los sistemas depositan en los datos comprimidos. El impacto principal es la denegación de servicio: colapsar escáneres antivirus crea ventanas para la entrega de malware, colapsar procesadores de subida de archivos interrumpe las operaciones del negocio, y colapsar gateways de correo bloquea la comunicación organizacional. En entornos de infraestructura compartida (hosting en la nube, plataformas CI/CD, SaaS multi-inquilino), una bomba ZIP que afecte un servicio puede propagarse para impactar a otros inquilinos y servicios que comparten los mismos recursos. Más allá del DoS, las bombas ZIP sirven como técnica de evasión — al colapsar o agotar el tiempo del escáner de seguridad, la carga maliciosa real (anidada dentro o entregada junto con la bomba) evade la detección. La baja complejidad de crear bombas ZIP (las herramientas y archivos preconstruidos están disponibles gratuitamente) combinada con la dificultad de defenderse contra todas las variantes la convierte en una amenaza persistente.

Cómo Detectar Ataque de Bomba ZIP

Implementar detección consciente de descompresión en cada punto donde se procesan datos comprimidos: (1) Verificar ratios de compresión antes de la descompresión completa — marcar archivos donde el tamaño no comprimido declarado excede un umbral relativo al tamaño comprimido (ratios por encima de 100:1 para un solo archivo, o 1000:1 en agregado, justifican inspección); (2) Monitorear el consumo de recursos durante la descompresión: establecer límites estrictos en la asignación de memoria, escritura en disco y tiempo de CPU para cualquier operación de descompresión; (3) Detectar archivos anidados y imponer una profundidad máxima de recursión (típicamente 2-3 niveles es suficiente para uso legítimo); (4) Para bombas planas (no recursivas), verificar entradas de archivo superpuestas en el directorio central del ZIP — los archivos legítimos raramente tienen múltiples entradas apuntando al mismo offset de datos comprimidos; (5) Monitorear indicadores a nivel de sistema: consumo repentino de espacio en disco, presión de memoria o picos de CPU que se correlacionen con eventos de procesamiento de archivos indican posible actividad de bomba de descompresión.

Cómo Prevenir Ataque de Bomba ZIP

Aplicar límites defensivos en cada frontera de descompresión: (1) Establecer límites de tamaño máximo descomprimido — rechazar archivos cuyo tamaño descomprimido declarado o real exceda un umbral razonable (ej., 100 MB para subidas de usuarios, apropiado al caso de uso); (2) Imponer límites de ratio de compresión máxima — rechazar archivos con ratios que excedan un umbral (ej., 100:1); (3) Limitar la profundidad de recursión para archivos anidados (máx 2-3 niveles); (4) Descomprimir en un sistema de archivos dedicado o contenedor con cuotas de disco y límites de memoria — usar cgroups en Linux o límites de recursos en runtimes de contenedores para contener el radio de explosión; (5) Descompresión en streaming con conteo de bytes: descomprimir incrementalmente y abortar cuando el total acumulado de bytes descomprimidos exceda el límite, en lugar de intentar descomprimir todo primero; (6) Para cuerpos de solicitudes HTTP con Content-Encoding: gzip/deflate, imponer un tamaño máximo de cuerpo descomprimido a nivel de servidor web o proxy reverso (ej., client_max_body_size de Nginx se aplica después de la descompresión); (7) Usar protección basada en timeout: establecer un tiempo máximo de reloj de pared para cualquier operación de descompresión; (8) Desplegar un WAF con detección de bombas de descompresión que inspeccione subidas comprimidas y cuerpos de solicitudes antes de que lleguen a la aplicación.

Ejemplos de Código

Vulnerable: Extracting ZIP without limits
import zipfile
import os

# VULNERABLE: No size or ratio checks
def extract_upload(zip_path: str, dest_dir: str):
with zipfile.ZipFile(zip_path, 'r') as zf:
# Extracts everything — a zip bomb fills the disk
zf.extractall(dest_dir) # DANGER!

# A 42 KB zip bomb will attempt to write 4.5 PB to disk
# The server crashes long before that, but the damage is done:
# - Disk fills to 100%, crashing other services
# - OOM killer terminates critical processes
# - The application becomes unresponsive
Secure: Safe extraction with multiple limits
import zipfile
import os
from pathlib import Path

class ZipBombError(Exception):
pass

def safe_extract(
zip_path: str,
dest_dir: str,
max_files: int = 100,
max_total_size: int = 100 * 1024 * 1024, # 100 MB
max_ratio: float = 100.0, # 100:1 compression ratio
max_depth: int = 2 # Max nesting depth
) -> list[str]:
"""Safely extract a ZIP file with bomb detection."""
zip_size = os.path.getsize(zip_path)
if zip_size == 0:
raise ZipBombError('Empty archive')

with zipfile.ZipFile(zip_path, 'r') as zf:
members = zf.infolist()

# 1. Check number of files
if len(members) > max_files:
raise ZipBombError(
f'Too many files: {len(members)} > {max_files}')

# 2. Check total uncompressed size
total_uncompressed = sum(m.file_size for m in members)
if total_uncompressed > max_total_size:
raise ZipBombError(
f'Total size {total_uncompressed} exceeds limit {max_total_size}')

# 3. Check compression ratio
total_compressed = sum(m.compress_size for m in members)
if total_compressed > 0:
ratio = total_uncompressed / total_compressed
if ratio > max_ratio:
raise ZipBombError(
f'Compression ratio {ratio:.1f}:1 exceeds limit {max_ratio}:1')

extracted = []
running_total = 0
dest = Path(dest_dir).resolve()

for member in members:
# 4. Prevent path traversal in filenames
member_path = (dest / member.filename).resolve()
if not str(member_path).startswith(str(dest) + os.sep):
raise ZipBombError(
f'Path traversal detected: {member.filename}')

# 5. Skip nested archives beyond max depth
if member.filename.lower().endswith(('.zip', '.gz', '.tar', '.7z')):
# Log but don't recursively extract
continue

# 6. Stream extraction with byte counting
if not member.is_dir():
with zf.open(member) as src:
member_path.parent.mkdir(parents=True, exist_ok=True)
bytes_written = 0
with open(member_path, 'wb') as dst:
while True:
chunk = src.read(8192)
if not chunk:
break
bytes_written += len(chunk)
running_total += len(chunk)
if running_total > max_total_size:
# Clean up and abort
dst.close()
member_path.unlink()
raise ZipBombError(
'Actual decompressed size exceeds limit')
dst.write(chunk)
extracted.append(str(member_path))

return extracted

Preguntas Frecuentes

Una bomba ZIP no daña directamente el hardware. Causa denegación de servicio a nivel de software al agotar espacio en disco, memoria o CPU. Sin embargo, los colapsos repetidos causados por bombas ZIP pueden llevar a corrupción de datos (ej., corrupción de base de datos si el proceso de base de datos es terminado a mitad de escritura debido a OOM), y en casos extremos, llenar un disco al máximo puede hacer que un sistema no arranque si las particiones del sistema se ven afectadas. Los sistemas operativos y hardware modernos están diseñados para manejar el agotamiento de recursos de manera elegante, pero el impacto a nivel de software aún puede ser severo.
Una bomba ZIP recursiva (anidada) logra su expansión a través de capas: un archivo ZIP que contiene archivos ZIP que contienen archivos ZIP, cada capa multiplicando el tamaño total. El clásico 42.zip usa 6 capas de 16 archivos. Este tipo se derrota estableciendo una profundidad máxima de recursión para la extracción de archivos. Una bomba ZIP plana (no recursiva) logra la misma expansión masiva en una sola capa explotando características del formato ZIP — específicamente, múltiples entradas de archivo apuntando al mismo núcleo de datos comprimidos. La bomba plana de David Fifield se expande a 4.5 PB sin anidamiento. Las bombas planas evaden las defensas de profundidad de recursión y requieren límites basados en ratio o tamaño para detectarse.
Sí. Los servidores web que aceptan cuerpos de solicitud comprimidos (Content-Encoding: gzip) pueden ser atacados por bombas gzip — solicitudes pequeñas comprimidas que se expanden a cargas enormes. Si el servidor descomprime el cuerpo completo de la solicitud en memoria antes de procesarlo, esto causa agotamiento de memoria. La mayoría de los servidores web y proxies reversos modernos (Nginx, Apache, Caddy) tienen límites configurables sobre el tamaño del cuerpo descomprimido, pero estos deben establecerse explícitamente. Los gateways de API, WAFs y balanceadores de carga que inspeccionan cuerpos de solicitudes también son vulnerables si no imponen límites de descompresión.
Un WAF protege en el perímetro inspeccionando subidas comprimidas y cuerpos de solicitudes antes de que lleguen a la aplicación. PowerWAF impone límites configurables sobre tamaño máximo descomprimido, ratio de compresión y profundidad de recursión para todo el contenido comprimido — incluyendo ZIP, GZIP, DEFLATE y Brotli. Utiliza descompresión en streaming con conteo de bytes para abortar el procesamiento tan pronto como se exceden los límites, previniendo el agotamiento de recursos. Para subidas de archivos, inspecciona el directorio central del ZIP en busca de entradas superpuestas que indiquen construcción de bomba plana. Estas protecciones se aplican tanto a subidas de archivos multipart como a cuerpos de solicitudes HTTP comprimidos.
Históricamente, sí — las bombas ZIP fueron diseñadas específicamente para colapsar escáneres antivirus. Cuando el software AV encontraba un archivo comprimido, intentaba descomprimirlo completamente para escanear el contenido, llevando al agotamiento de memoria o llenado del disco. Los productos AV modernos implementan salvaguardas de descompresión (límites de tamaño, límites de ratio, límites de recursión, timeout), pero los investigadores periódicamente descubren técnicas de evasión (como las bombas planas). Los atacantes usan bombas ZIP como técnica de evasión de AV: al colapsar o hacer que el AV omita el archivo, la carga maliciosa real dentro o junto a la bomba evita la detección.

PowerWAF bloquea automáticamente Ataque de Bomba ZIP antes de que llegue a tu servidor.

Implementa en minutos. Sin cambios de código. Plan gratuito disponible.

Los cupos del plan gratuito son limitados · No credit card required