Vulnerabilidades en equipos de un ISP argentino pueden ser causa de DoS a sus clientes

(Por El Microsaurio) Los ISP suelen usar un sistema llamado
proxy caché para manejar los pedidos de páginas web que hacen los
usuarios. En determinadas condiciones de trabajo, hay máquinas que
reciben un pedido y lo entregan al primero que lo solicita, pero luego
dejan de enviar esa misma página a los sufridos usuarios que pidan lo
mismo. Y ya se enteró todo el mundo, lo cual es un problema.
Para relatarlo brevemente, vos escribís una dirección web, tu máquina
envía el pedido a la Internet, y lo que baja a tu compu es una copia de
esa página, que quedó guardada en un equipo de tu proveedor de
servicios (el ISP) porque un usuario anterior la había solicitado
antes.
En teoría (y en la mayoría de los casos) se tarda menos en enviarte esa
copia desde el depósito (la caché) del equipo local del ISP (el proxy)
que esperar la bajada desde un servidor en algún lejano país. El ISP ha
mejorado aún más la calidad de servicio que ya disfruta su cliente. ¿No
es enternecedor?
Todo muy bonito. ¿Y qué pasa cuando ese proxy no te envía la página?
Tendría que haber una pequeña demora, y debería bajar. Pues no, querido
amigo. A veces, no. Lo que descubrió Hernán Pereira, un investigador en redes y seguridad de estas pampas, es que Speedy emplea para este propósito máquinas de varios proveedores. Y que las que son NetCache tienen
un defecto. En determinadas condiciones de trabajo, esas máquinas
reciben un pedido y lo entregan al primero que lo solicita, pero luego
dejan de enviar esa misma página a los sufridos usuarios que pidan lo
mismo. Lo cual te hace creer a vos, el usuario final, que cierto sitio
web está caído. Porque si te aburrís de esperar y escribís la dirección
de otro website, probablemente baje bárbaro y al toque.
El problema fue informado a Speedy a mediados del mes pasado. Como el
ISP no contestó durante quince días, el 31 de agosto un experto en
seguridad y redes local pero con actividad internacional, Arturo Busleiman (el Buanzo), colaborador de Pereira, publicó esta notificación
en una lista internacional de especialistas. Allí están todos los datos
técnicos que describen el problema y el procedimiento de ataque. Si
quieren un resumen en castellano, me han recomendado este, aparecido en el blog de Javier el marplatense.
Cuatro comentarios:
1) El mecanismo de ataque está detallado en esa Advisory publicada en
Internet el 31. Por lo cual los usuarios de Speedy tal vez sufran más
plantones de ahora en adelante. Copio una frase que aclara qué es lo
que observa el usuario (la traducción es mía) “…el procedimiento es
muy simple; si se envía varias veces un pedido del tipo (…) hacia la
dirección víctima, se hará que los proxies no puedan continuar
entregándolo (…) los usuarios se quedarán esperando unos dos minutos y
luego la conexión TCP se cerrará, lo cual (…) podrá ser interpretado
como una respuesta válida de longitud cero, o como un error…”
2) Esas máquinas no componen _todo_ el parque de proxies de Speedy. Esa
empresa usa también otros equipos que no están afectados por este
problema. La <advisory> dice claramente “…en algunas áreas de
Speedy Argentina…”
3) La publicación de una vulnerabilidad al no recibir una respuesta
válida de una empresa, es un procedimiento muy empleado para estimular
a las compañías. Éstas, al verse expuestas públicamente, suelen actuar
prontamente para demostrar su diligencia, siempre impulsadas por la
noción de prestar el mejor servicio posible. Risas burlonas abstenerse.

4) Interesante (por decir poco) es la frase del moderador de una lista, al ver la <advisory>: “…es
notable que el ISP no tomó una acción para mitigar el problema, o lo
hizo ineficazmente, según parece después de dos semanas de habérsele
avisado en privado, y no respondió a los autores del informe…” La observación viene de una organización donde hay miembros como Vinton Cerf o Bruce Schneier (¿te suenan…?)