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:
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: Popular cache Squid skids as hacker pops lid
como elimino icloud
ResponderEliminarimeil:013885001988764
5s