Buenas gente,

Hace unos dias vi una vulnerabilidad llamada Microsoft Windows XP/Vista TCP/IP Orphaned Connections Vulnerability. Me parecio re interesante y como nunca he visto exploits sobre vulnerabilidades de este tipo, comence a hacer algo para aprender un poco y queria compartir con ustedes los resultados. Parece que no hay actualizacion disponible a pesar de que hace unos meses que salio.
El problema es en el manejo de las conexiones con zero-window en la implementacion del tcp-ip stack en windows. Para probar esta vulnerabilidad hay que establecer una conexion tcp con tamaño de ventana cero.

Supongamos que apenas se realiza la conexion con el servidor, el mismo desea enviar datos al cliente (por ej. el banner de un server ftp). Como el tamaño de la ventana de la conexion tcp es 0, Windows va a comenzar a enviar "ZeroWindowProbe" (ZWP) para actualizar la ventana y esperar que sea mayor a cero para poder transmitir los datos. La idea de la vulnerabilidad, segun entiendo , es de reconocer esos ZeroWindowProbes, o sea enviar "ZeroWindowAck" (ZWA). Luego de un tiempo la conexion pasara al estado FIN_WAIT_1 debido a que el server cierra el socket (timeout de la conexion) y luego el kernel continua enviando ZWPs. Dentro de cada ZWP se envia 1 byte de los datos que el servidor deseaba enviarle al cliente, hasta que se agotan. Una vez agotados los datos, la conexion queda colgada en este estado.

Ahora, como hacer el exploit?.

Es claro que hay que injectar paquetes, o sea armar la conexion tcp con tamaño de ventana cero y luego reconocer todos los ZWPs con tamaño de ventana cero tambien. En mi caso, utilice libnet para inyectar los paquetes y libpcap para recibir las respuestas. Libnet tiene muchos ejemplos utiles. Y para el uso de libpcap hay tutos muy completos en internet. Con el wireshark miraba todos los paquetes.

Les comento maso los resultados durante el proceso de creacion del exploit.
Primeramente comence por crear el paquete SYN para iniciar la conexion. Uso ubuntu 9.10 como cliente y windows xp sp3 con un servidor ftp corriendo (Cerberus) a fin de probar todo. De ahora en mas distinguire las maquinas como linux y windows simplemente.

Esta fue mi primera prueba de envio de un paquete con el flag SYN activado al puerto 21 desde el puerto 54321.


La maquina 192.168.9.1 (servidor) tiene windows y la 192.168.9.140 (cliente) linux.
Envio el SYN y recibo bien el SYNACK correspondiente, pero al parecer hay un paquete RST que termina la conexion enviada por linux. El problema es que no hay PCB asociado a la conexion (es logico, el paquete fue injectado) y linux se lo comunica en seguida a windows con un RST. Para evitar este tipo de respuestas del kernel, hay que hacer que dropee todo paquete que llega desde windows. Se puede hacer con iptables de la siguiente manera:

La segunda prueba me dio como resultado
Ahi se puede ver que no hay mas RST (es decir que linux esta dropeando todo) y windows tratando de establecer la conexion en 2 reenvios de los SYNACK. Despues de 3 seg el primer reenvio y al cabo de 9 el ultimo.

Ahora lo siguiente es mandar el ACK para pasar la conexion al estado ESTABLISHED. Aca les muestro los resultados.


Y esto es lo que sucede. Al establecerse la conexion al cabo del ACK (3er paquete) windows comienza a enviar los ZWPs. Esto pasa porque en realidad el servidor ftp Cerberus envia datos luego de establecida la conexion, y como la ventana es cero los datos deben permanecer en el buffer del enviador. Se comienzan a mandar los ZWPs para actualizar el valor de la misma.
En este caso todavia no se estan mandando los ZWAs y se puede ver los retardos de retransmision involucrados.
Si se ejecuta un netstat en windows durante la transmision de los ZWPs se observa lo siguiente
La conexion ha pasado efectivamente al estado ESTABLISHED y 30 segundos despues de haber enviado el paquete nro 8 windows cierra la conexion.

Ahora miren lo que pasa cuando se envian los ZWAs.

Bueno fijense que ahora se envian los ZWAs correspondientes. El esquema de tiempos es muy similar al caso anterior (sin ZWAs). Justo despues de haber enviado el ACK al SYNACK netstat en windows dice lo siguiente:

Luego del paquete nro 14, el server me tira como mensaje un connection time-out y netstat dice:

Por lo que efectivamente el estado de la conexion paso a FIN_WAIT_1. Una vez en este estado, los ZWPs se envian cada 30seg.
La longitud de datos de los ZWP es efectivamente 1, y el dato enviado es el "2". Que resulta ser el primer caracter de la respuesta del servidor en conexiones normales.
Lo deje un buen tiempo, mandando ZWAs y siempre recibia como dato de prueba en los ZWPs un "2". Cuando supuestamente deberia recibir byte por byte los datos que el servidor ftp pretendia enviar.
Si se dejan de enviar los ZWAs con la conexion en el estado FIN_WAIT_1, al cabo de 3 ZWPs la conexion pasa a CLOSED.

Todo esto para decir que mi windows no es vulnerable o bien estoy haciendo algo mal en mis tests. Si alguien tiene ganas de ponerse a probar un rato me gustaria que me comentaran sus resultados, mas abajo paso el codigo fuente.

Probando conexiones de zero-window descubri que si se establece una conexion zero-window al puerto 135, la misma permanece en ESTABLISHED indefinidamente!. No hay ZWPs porq deberia enviarle algunos datos para hacer que el servicio responda y se bloquee (lo probare mas adelante y posteare resultados).

Aca les dejo el codigo que hize para realizar estas pruebas.
zerowin.c

Libnet la pueden encontrar en el siguiente link:
Libnet

Para libpcap pueden hacer un sudo apt-get install y libpthread la deberian tener.
Para compilarlo una vez que estan todas las lib instaladas,

Mirando el codigo van a ver comentarios en ingles y en español . Bue, los efectos del copy&paste . En fin, la idea era de tener algo como para hacer estas pruebas. Mas adelante comentare el codigo para explicar maso como arme los paquetes y el sniffer (si alguno sabe de alguna tool, pls pasenla).
Bueno eso, queria mostrar algunos de los resultados que obtuve en el analisis de esta vulnerabilidad y lo que encontre por jugar con otras cosas .

Saludos.

Gracias Anon. Ahi subi de vuelta el archivo. Tenes razon, acabo de ver lo del zero-window size en el MS09_048 ^_^, parece que descubri la rueda!! jaja. Bue, entonces el codigo serviria como exploit. Como habia dicho, conectando al 135 con zero-window la conexion queda indefinidamente en ESTABLISHED. Tocando el codigo lo puse para que cree la conexion nomas y con un script:

Ahi abre 1000 conexiones al 135 desde los puertos 5000 al 6000. Lo deje y windows seguia aceptando conexiones entrantes aunque quedaron las 1000 conexiones en ESTABLISHED definitivamente . Alguien sabe donde encontrar el limite de conexiones en ESTABLISHED en windows?.

Bueno, probe contra el 139 a ver que pasaba y obtuve lo siguiente:

Curiosamente windows cierra la conexion con un RST despues de 30seg. Ni idea porque se comporta diferente, pienso que en este caso es el servicio que cierra la conexion. Seguire haciendo otro tipo de pruebas, cualquier idea es bienvenida.
Espero que a alguien mas le interese,

Saludos.

mmm eso es para conexiones semiabiertas. Yo decia para conexiones ya establecidas. Busque tambien pero no encuentro nada, o sea algunas paginas dicen hasta 10 simultaneas oO. Llegue hasta casi 2000 y no pasaba nada, asi que en mi caso no puede ser.

Miuchas veces ponen cosas similares a "Code Execution Vulnerability" etc...

Y eso muchas veces indica que la vulnerabilidad es explotable, el problema que solo lo sabe el que lo reporto en primer lugar.

Hay entonces que empezar a depurar que pasa con el timestamp sin embargo en windows es mas dificil, si se puede pero hay que nadar entre codigo y mas codigo. Y ademas como es un procesos del kernel de windows entonces va a ser mas dicifil decidir por donde empezar.

Saludos