DNS Poisoning sobre Microsoft SMTP

Hace unos días, la gente de Core Security publicaba en su web un Advisory en el que comentaban haber descubierto la corrección de dos vulnerabilidades de gran importancia en los servicios SMTP de Microsoft. Según parece, Microsoft corrigió estas vulnerabilidades en el parche MS10-024, pero sin notificar su existencia ni su criticidad, ya que el "Maximum Security Impact" (impacto de seguridad máximo) de dicho parche era de Denegación de Servicio, lo cual parece no ser exacto a tenor del descubrimiento del equipo de Core Security.

Según el Advisory, las vulnerabilidades consisten en la utilización por parte de los servicios Microsoft SMTP y Exchange de una rutina propia para la resolución de nombres DNS a la hora de realizar el envío de correos electrónicos, la cual presentaba 2 vulnerabilidades que podrían permitir a un atacante realizar un envenenamiento de la caché del servidor de correo, y por tanto provocar una redirección del correo con destino al dominio envenenado a un servidor arbitrario (controlado por un atacante, claro). Veamos las vulnerabilidades:

1. Predecibilidad en los IDs:

El problema de predecibilidad en los IDs de DNS fue corregido por la mayoría de los fabricantes allá por el 2008, con la aparición del famoso Ataque Kaminsky del que ya hablamos en un par de ocasiones y que causó tanto revuelo en aquel momento debido a su criticidad. Sin embargo, esta rutina empleada por los servicios SMTP de Microsoft ha mantenido este problema hasta la aparición del pache MS10-024.

Para comprobar esta vulnerabilidad y verla con nuestros propios ojos, podemos realizar una sencilla prueba empleando el módulo de Metasploit server/fakedns, el cual nos va a permitir levantar un servicio DNS que devuelva ante todas las peticiones la respuesta que nosotros queremos, pero esa funcionalidad en estos momentos no nos interesa, sino que nos basta con poder ver el log que deja ante dichas peticiones, para observar la aleatoriedad de los IDs, puertos, etc.

# ./msfconsole

msf > use server/fakedns

msf auxiliary(fakedns) > set TARGETHOST 172.16.24.150

TARGETHOST => 172.16.24.150

msf auxiliary(fakedns) > run

En ese momento Metasploit nos devuelve el control de la consola, pero nuestro servicio se ha quedado ya a la escucha y nos va a ir logando por pantalla toda la información que queremos, así que solo tenemos que ir a un sistema Windows (en mi caso un Windows 2003 Server) y realizar dos sencillas prueba: en primer lugar abrimos un cmd.exe y resolvemos el nombre de varios dominios aleatoriamente, los que prefiramos, y en segundo lugar nos conectamos al puerto 25 de dicho servidor e intentamos mandar un correo electrónico a cuentas de dominios igualmente aleatorios. Tras hacer ambas pruebas, el resultado en nuestro servidor Fake DNS es el siguiente:

Como se puede observar, en las primera pruebas (desde cmd.exe) vemos que el ID (marcado como XID) es aleatorio, o al menos no parece visiblemente predecible (luego nunca se sabe, que se lo digan a los de Debian). Sin embargo, en la segunda tanda de pruebas (desde el servidor SMTP) vemos que la generación de los XID es claramente diferente. Podemos ver marcado en rojo como el XID inicial es 1 (la máquina se acababa de arrancar), y que sucesivamente se ha ido incrementando con cada petición, aunque hayamos cambiado de dominio, por lo que os podéis imaginar que la predecibilidad es total.

Además, si pegamos un vistazo a los puertos de origen (marcados en azul) vemos que tampoco se ha hecho un gran esfuerzo por hacerlo aleatorio, ya que podemos observar que son casi secuenciales (seguramente el puerto que falta entre medias es el intento de conexión SMTP o similar).

Por lo tanto, si tanto el ID como el puerto de origen son algo trivialmente predecible y son la única medida que protege al protocolo DNS de la realización de ataques de DNS Spoofing... nos encontramos con que, al igual que sucedía con el Ataque Kaminsky, es posible lanzar una ráfaga de paquetes con IP y puerto de origen falseado que contentan una resolución falsa que nos permita, en este caso, redirigir TODOS los correos enviados a un dominio a un servidor de nuestra elección.

2. No utilización de los IDs para validar la respuesta:

Yo me quedé de piedra con esta. Como lo oís: además de generar los IDs de forma secuencial... directamente no se comprueba que la respuesta DNS tenga el mismo ID que fue generado para la petición DNS, así que el ataque anterior se acaba de volver mucho más sencillo, ya que no es necesario intentar obtener el último ID utilizado para realizar el ataque, sino simplemente el último puerto.

Para comprobarlo, realizamos una pequeña modificación en el módulo de Metasploit que ya utilizamos anteriormente, el server/fakedns. Este módulo, toma la petición que le enviamos, le incorpora un campo donde se encuentra la resolución solicitada y quizá algún campo ocasional, y lo devuelve al origen de la petición, conservando en todo momento el ID con el que llegó dicha petición. Para ver con nuestros propios ojos esto de que el servicio SMTP de Microsoft no hace ni caso del ID vamos a realizar una modificación de este módulo para hardcodear el valor del ID, de tal manera que forcemos que las respuestas tengan un ID diferente a las peticiones. Para ello, partiendo del directorio raíz de Metasploit (donde está msfconsole), editamos el fichero modules/auxiliary/server/fakedns.rb y buscamos la cadena "send", lo cual nos llevará a la instrucción en la que la respuesta es enviada. Una vez en esa zona del código, introducimos la siguiente modificación:

Esta modificación lo que nos permite es fijar el valor del ID de los paquetes de respuesta a "69" (por ejemplo :P), independientemente del origen. Veamos ahora si sigue funcionando (recordad reiniciar Metasploit para que se vuelva a cargar este módulo, sino no va a funcionar):

Parece que el asunto funciona, o al menos eso nos muestra Metasploit, pero vamos a ir al que "nunca nos miente", al tcpdump, a ver que está pasando realmente por debajo:

Efectivamente, hemos conseguido lo que queríamos, vemos que el servidor SMTP nos está pidiendo la resolución DNS con ID 1, y que nosotros estamos enviando una respuesta válida, con el puerto adecuado, desde la IP adecuada, pero con un ID totalmente inventado. Ahora nos falta por ver si el servidor SMTP se lo ha tragado, y para ello lo mejor es poner un NetCat en el puerto 25 para ver si el servidor realiza conexión TCP contra esta máquina, ya que si lo hace quiere decir que "ha picado" y que se dispone a enviar el correo a la IP de la respuesta malformada (con ID diferente):

Parece que el asunto ha colado. Increíble pero cierto.

En resumen, todos aquellos servidores SMTP de Microsoft a los que no se les haya aplicado el parche MS10-024 son vulnerables a envenenamiento de sus DNSs y por tanto a la redirección de correos a servidores arbitrarios, con tan solo ser capaces de predecir el puerto de origen (trivial, como podemos ver) y tener un poco de suerte a la hora de que las respuestas maliciosas sean un poco más rápidas que las auténticas.

Se recomienda por tanto a todos los administradores de servidores de este tipo que apliquen este parche, aunque Microsoft no lo catalogue con la criticidad correspondiente.