Vulnerabilidad crítica de envenamiento de caché en proxies Squid

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone

Vulnerabilidad de envenamiento en caché proxies squid.

Squid-cache_proxy

Jianjun Chen, un estudiante de la Universidad de Tsinghua, ha reportado una vulnerabilidad crítica de envenenamiento de caché en el servidor proxy Squid, recordemos uno de los cachés transparentes más desplegados por los proveedores de servicios de Internet.

La vulnerabilidad, todavía sin CVE, permite a un atacante redireccionar el tráfico de los usuarios que utilizan el proxy a sitios maliciosos mediante una única petición, siempre que el tráfico no sea HTTP cifrado. “El ataque permite envenenamiento de caché de cualquier sitio web HTTP sin cifrar“, confirma Chen, y por ejemplo podría realizarse de forma silenciosa mediante anuncios Flash maliciosos.

Para explotarlo con éxito, un atacante debe ser capaz de enviar peticiones a un sitio web (como attack.com) a través del servidor proxy. Bajo este escenario, el atacante primero establece una conexión TCP contra el servidor web attack.com. Al funcionar Squid en modo proxy transparente, estas solicitudes son interceptadas y transmitidas. A continuación, el atacante inicia la siguiente petición HTTP:

GET http://victim.com/ HTTP/1.1 Host: attack.com

El módulo de caché utiliza la dirección de host de la cadena de la petición (victim.com) para crear la clave; sin embargo, el módulo de verificación utiliza el encabezado de host (attack.com) para comprobar la comunicación entre el host y la dirección IP. Esto es lo que hace posible el ataque.

Chen ha publicado también el siguiente vídeo con la PoC:

Ya se ha publicado el parche para las versiones diarias (dayly builds), pero aún no se distribuido para las regulares y el ataque puede ser ejecutado contra las versiones anteriores a la 3.5.18 y 4.0.10. Mientras, como workaround, se recomienda activar la opción host_verify_strict y usar la siguiente regla de Suricata:

por motivos de espacio se ha fraccionado la regla que estaba escrita en una sola linea.

alert http $HOME_NET any -> $HOME_NET $HTTP_PORTS 
(msg: "[PT Open] Possible Squid cache poisoning";
 content: "GET"; http_method; content: "http://"; http_raw_uri; pcre:
 "/GET\s+\w+:\/\/\S+\s+.*?[\r\n].*?Host: +[\w\.:]+\b/is"; pcre:! 
"/GET\s+\w+:\/\/([^\/\s]+)[\/\s]\S*.+?Host:\s*\1\S*\b/is";
 classtype: attempted-recon; sid: 10000035; rev: 1; )
Fuente:http://www.enhacke.com/

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone