¿Puede JavaScript anular la asignación aleatoria del puerto de origen?

Question

¿Puede JavaScript anular la asignación aleatoria del puerto de origen?

#1 de Thomas Pornin (2 votos)

3

¿Puede JavaScript malintencionado anular la aleatorización de origen y puerto en los navegadores?

Estoy leyendo documento de investigación que parece afirmar que la respuesta es afirmativa:

muchos navegadores parecen asignar siempre un número de puerto local aleatorio   para diferentes páginas web que hace predicción de puerto [fuente]   muy dificil. Para superar el reto, diseñamos un   Estrategia simple para ocupar intencionalmente tantos puertos locales.   como sea posible para que el siguiente puerto utilizado se seleccione de una   piscina mucho más pequeña.

Específicamente, el sitio web malicioso puede instruir al cliente   para abrir muchas conexiones al sitio malicioso (o cualquier   otro servidor) para consumir una gran cantidad de puertos locales. En   Además, los números de puerto ocupados tienden a ser contiguos   Según nuestro experimento, probablemente debido a la originación.   desde el mismo JavaScript. Un reto es que el SO   Puede limitar el número total de puertos que una aplicación   puede ocupar, evitando así que el atacante se abra también   Muchas conexiones concurrentes. Sin embargo, encontramos tales   límite se puede omitir si las conexiones establecidas son   Inmediatamente cerrado (que ya no cuenta para el   límite). Los números de puerto locales todavía no se han publicado desde   Las conexiones cerradas ingresan al estado TCP TIME WAIT.   por una duración de 1-2 minutos. Si un atacante puede lograr   Abre suficientes conexiones, puede usar fuerza bruta fácilmente   [para adivinar el puerto de origen de la siguiente solicitud].

Conceptualmente, el ataque parece ir así. Supongamos que la víctima visita una página web maliciosa, evil.com, controlada por el atacante. evil.com presenta un JavaScript que abre muchas conexiones con evil.com, en un intento de agotar el conjunto de puertos de origen locales. Luego, el JavaScript redirige el navegador a www.amazon.com (o abre un iframe a www.amazon.com). La afirmación es que su método les permite predecir el número de puerto de origen TCP que se utilizará en esa conexión a www.amazon.com.

¿Esto es correcto? ¿Funciona este ataque?

Si el ataque funciona, tengo algunas preguntas sobre cómo / por qué funciona el ataque:

¿Los navegadores administran un grupo de puertos locales o piden al sistema operativo que les asigne un puerto local? ¿Qué grupo se está agotando aquí?
Si el sistema operativo está asignando el puerto de origen, ¿no es el puerto de origen específico para el servidor de destino? (Puedo abrir muchas conexiones a evil.com y agotar todos los puertos locales disponibles a evil.com, pero espero que una nueva conexión a www.amazon.com pueda usar cualquier puerto de origen, incluso uno que se esté usando actualmente con www.evil.com o se ha utilizado recientemente con www.evil.com. ¿Estoy malinterpretando algo?)
¿O es que el navegador de alguna manera está administrando manualmente un grupo de puertos locales que está preparado para usar para las conexiones? Si es así, ¿qué estrategia utiliza? ¿Depende este navegador?
¿Cómo predice el atacante qué número de puerto de origen se utilizará para la conexión a www.amazon.com?

Esperaba que alguien pudiera ayudarme a entender lo que está pasando aquí, y completar los detalles que faltan.

attacks web-browser

pregunta D.W. 27.09.2012 - 22:19

fuente

1 respuesta

Lea otras preguntas en las etiquetas attacks web-browser

Obtenga información sobre la red y la seguridad para proteger un servidor ¿Cómo analiza los datos recopilados del software honeypot?

score 2 · Accepted Answer

Por lo que sé, el kernel asignará un nuevo puerto local para cada conexión saliente (a menos que la aplicación imponga un valor de puerto específico con bind() , esto puede hacerse incluso para un cliente TCP) y no permitirá Dos conexiones salientes para usar el mismo puerto local simultáneamente. De hecho, si intenta forzar a dos conexiones de cliente a usar el mismo número de puerto local, con llamadas de bind() explícitas, el segundo bind() debería fallar.

Un Linux asignará puertos locales en el rango de 32768-61000 (consulte esta página ). Esto es para todo el sistema.

Dudo que los navegadores web seleccionen puertos locales específicos. No veo qué les compraría esto y, además, se perderá al atravesar un enrutador que hace algo de NAT - Una cosa muy común, tanto para usuarios domésticos como para empresas.

Adivinar el puerto local por adelantado no le da una ventaja per se al atacante, puede ser parte de un ataque más grande que también adivina los números de secuencia de TCP (lo que parece más difícil).

Editar: en realidad, Linux permitirá que un puerto se reutilice para otra conexión, mientras que la primera aún está activa, pero esto no sucede a menudo. Linux aleatoriza los puertos efímeros (consulte RFC 6056 ), por lo que generalmente se usará un nuevo puerto. Cuando la aplicación realiza una conexión previa explícita bind() , necesariamente se asigna un nuevo puerto, ya que en ese momento, el kernel aún no conoce la dirección de destino. Para un connect() de bind-less, se usa otro algoritmo, que tiende a preferir el uso de un nuevo puerto, pero puede reutilizar un antiguo. Consulte esta publicación del blog para un análisis.