MagnoSec
Servidor proxy Squid con fuga de datos representando vulnerabilidad Squidbleed de 29 años de antigüedad

MagnoSec Blog

Squidbleed: Un Bug de 29 Años en Squid Proxy Expone Peticiones HTTP en Claro de Millones de Servidores

Por Equipo MagnoSec4 min de lectura

El contexto: qué ha pasado y por qué importa

Hay vulnerabilidades que existen desde antes de que muchos profesionales de la ciberseguridad nacieran. Squidbleed es una de ellas: 29 años después de la primera versión de Squid —el proxy cache más utilizado del mundo, presente en CDNs, ISPs, universidades y redes corporativas—, se descubre que el mecanismo de inspección de mensajes ICAP/ECAP puede ser manipulado para filtrar peticiones HTTP en texto claro. Squid es el software que acelera internet cacheando contenido cerca de los usuarios. Squidbleed permite que un atacante lea lo que esos usuarios están pidiendo, incluyendo URLs completas con tokens de sesión, parámetros de autenticación y datos embebidos en la query string.

Antecedentes y evolución de la amenaza

El mecanismo técnico de Squidbleed es sutil y por eso ha pasado desapercibido casi tres décadas. Squid utiliza protocolos de adaptación de contenido (ICAP y ECAP) para inspeccionar, modificar o bloquear peticiones y respuestas HTTP en tránsito. Estos protocolos permiten a Squid enviar una petición a un servidor de inspección externo —típicamente un antivirus de red o un filtro de contenido— y decidir si la deja pasar. El fallo reside en cómo Squid maneja ciertos códigos de error del servidor de inspección: bajo condiciones específicas, Squid reenvía la petición original al servidor upstream incluso cuando debería rechazarla, y en ese reenvío incluye metadatos que revelan el contenido de otras peticiones en la caché. Un atacante que controle un servidor ICAP/ECAP malicioso —o que pueda interceptar la comunicación entre Squid y un servidor legítimo— puede extraer peticiones HTTP completas de otros usuarios.

Así funciona: los detalles técnicos

El impacto de Squidbleed es proporcional a la ubicuidad de Squid. Estamos hablando de universidades que cachean contenido académico, ISPs que aceleran la navegación de millones de hogares, CDNs que sirven contenido estático para los sitios web más grandes del mundo, y redes corporativas que utilizan Squid como proxy de salida a internet para miles de empleados. En cada uno de estos escenarios, Squidbleed permite a un atacante con acceso a la red del proxy leer las peticiones HTTP de todas las sesiones que pasan por él. Si el tráfico va por HTTPS —que es la mayoría hoy en día—, el atacante no ve el contenido del cuerpo de la petición, pero sí ve la URL completa con todos sus parámetros. Eso incluye tokens de acceso en query strings, identificadores de sesión, claves de API y cualquier dato sensible que la aplicación haya decidido poner en la URL.

Impacto real en organizaciones y empresas

Lo más preocupante de Squidbleed es el vector de explotación masiva. Un atacante no necesita comprometer el servidor Squid en sí. Le basta con poder hacerse pasar por un servidor ICAP/ECAP legítimo —mediante ARP spoofing, DNS poisoning o simplemente configurando un servidor malicioso en la misma red— para empezar a recibir peticiones HTTP de todas las sesiones que Squid procesa. En entornos donde Squid está configurado para usar ICAP/ECAP —algo común en despliegues corporativos que inspeccionan tráfico en busca de malware o filtraciones de datos—, Squidbleed convierte el propio mecanismo de seguridad en una superficie de ataque. Es el equivalente a instalar una cámara de seguridad que, bajo ciertas condiciones, transmite la señal a cualquiera que lo pida.

Cómo MagnoSec aborda esta amenaza en sus auditorías

En MagnoSec, las auditorías de infraestructura incluyen la revisión de proxies, cachés y sistemas de inspección de tráfico como vectores de ataque específicos. Squid, Varnish, NGINX caching, Apache Traffic Server y otros proxies similares son evaluados no solo en su configuración de seguridad básica, sino también en cómo interactúan con los sistemas de inspección y filtrado. Durante un pentesting de red interna, los proxies de salida son objetivos de alto valor porque concentran el tráfico de toda la organización. Un Squid vulnerable a Squidbleed en una red corporativa es un punto único de compromiso para la privacidad de todas las comunicaciones web de la empresa. La pregunta no es si Squidbleed es grave —lo es—, sino por qué ha tardado 29 años en descubrirse y qué otras vulnerabilidades similares duermen en el código que internet lleva décadas ejecutando.

Qué puedes hacer ahora: acciones concretas

La mitigación de Squidbleed es inmediata: actualizar Squid a la versión parcheada (6.12 o superior) y, para quienes no puedan actualizar de inmediato, deshabilitar los protocolos ICAP/ECAP si no son estrictamente necesarios. Pero la lección de fondo es más importante: el software que forma la columna vertebral de internet —BIND, Squid, Postfix, Apache httpd, OpenSSH— lleva décadas en producción y, como demuestra Squidbleed, todavía esconde vulnerabilidades que no se han descubierto porque nadie ha mirado con suficiente atención. La seguridad del software legacy no depende de su antigüedad —depende de cuántos ojos expertos lo hayan auditado. Y Squidbleed es la prueba de que 29 años y millones de despliegues no garantizan que alguien haya mirado lo suficiente.

Temas tratados

Squidbleed · Squid proxy · vulnerabilidad proxy · cache poisoning · HTTP cleartext · CDN · proxy cache · bug 29 años

¿Quieres saber si tu empresa tiene estas vulnerabilidades?

Auditamos la seguridad de empresas de toda España con alcance cerrado por escrito, informe técnico y ejecutivo, y retest de las correcciones. Presupuesto en 24 horas y primera consultoría sin coste. Si no sabes por dónde empezar, haz el test de seguridad de 15 preguntas.

¿Quieres más información?