Estas aquiContenido / Investigador argentino informa sobre vulnerabilidad en NSlookup de Windows
Investigador argentino informa sobre vulnerabilidad en NSlookup de Windows
Iván Sánchez (de Null Code Services) ha informado de la existencia de una vulnerabilidad en la utilidad Nslookup de Microsoft Windows, una herramienta de línea de comandos que se utiliza para comprobar los servidores DNS.
La vulnerabilidad (sobre la que aún no se han dado detalles) permitiría la ejecución de código arbitrario en la máquina víctima, incluso si ésta ejecuta Windows XP SP2 totalmente parcheado.
De momento no existe parche. Microsoft asegura estar estudiando la situación, mientras algunos medios afirman que la vulnerabilidad ya está siendo activamente explotada...
Referencias:
- Microsoft Windows 'NSlookup.exe' Unspecified Remote Code Execution Vulnerability [Security Focus].
- Vídeo mostrando prueba de concepto [Null Code Services].
- Microsoft investigating NSlookup.exe flaw, reported attacks [ZDNet].
- Monthly Security Bulletin Webcast Q&A - August, 2008 [Microsoft, ver pregunta y respuesta número 3].
- Nslookup [Microsoft].
Versión para imprimirEtiquetas
Se agradece el aviso pero aun consultando todas las fuentes solo es posible saber que algo pasa en nslookup... pero no sabemos muy bien el qué.
Según Security Focus "es" explotable de forma remota, pero la PoC sólo muestra un cuelgue que "podría" dejar el sistema vulnerable.
¿Que pasa con Vista o XP con el SP3?
La coincidencia de esta vulnerabilidad con la de Kaminsky resulta MUY sospechosa, pero tampoco se dice nada al respecto.
En resumen: o habla Iván, o habla Microsoft, o asi no hay quien se entere de nada.
Analizando deprisa lo que sucede cuando se lleva a cabo esa secuencia de comandos, que tampoco hay tiempo para mucho más, y dado no se produce comunicación directa con telmex.com.ar, los paquetes devueltos no parecen malformados, y no se emite ningún paquete AXFR ( la petición que origina el comando ls -d ), esto huele a vapor de Agua y/o humillo veraniego.
No obstante, y como el verano es aburrido, en un rato se obtiene la pauta para reproducirlo, que es bastante trivial.
Primero: Buscar un nombre de dominio que cumpla la siguiente condición. No tener resolución a un dominio A en su TLD local. Es decir, en el caso de kriptopolis.org que no exista dominio A para ese nombre de dominio. ¿Por qué? Porque cualquier dominio de segundo nivel es aceptado como "sitio de resolución" aunque su nombre devuelva un SOA y no un registro A, es decir, aunque allí no haya ningún servidor escuchando nada.
Segundo: Una vez localizado y asignado como server a nslookup es trivial producir una segmentación.
EJEMPLO 1: RENFE.ES
> server renfe.es
Servidor predeterminado: renfe.es
> server kernelpanik.org
---> SEGMENTACION
EJEMPLO 2: RENFE.ES
> server renfe.es
Servidor predeterminado: renfe.es
> ls -d renfe.es
---> SEGMENTACION
EJEMPLO 3: UMA.ES
> server uma.es
> server djfklasjflkasjflkasj
---> SEGMENTACION
En fin ... estos son los 2 céntimos de hoy.
De lo poquito que sé de gestionar DNS, siempre recuerdo dos cosas:
- Que el MX primario no debe ser un CNAME
- Que el TLD siempre debe tener un registro A
Si me dais tiempo busco los enlaces, pero vamos, me cuesta creer que todavía existan dominios cuyo TLD no tenga un A... lo cual no quita para que a pesar de eso, el nslookup de windozes no debería colgarse por ello
Saludos,
tienes toda la razón del mundo al decir que nslookup no debería colgarse porque no existiera un lugar para resolver, pero parece que es producto de un error de chequeo absurdo.
Básicamente, nslookup te acepta como servidor para resolver nombres cualquier dominio de segundo nivel que sea "resoluble", aunque ese dominio no resuelva a un registro A, es decir, aunque no haya una IP asociada para resolver en ella.
Ejemplo 1: TLD con registro A
> server kriptopolis.org
Servidor predeterminado: kriptopolis.org
Address: 213.149.236.75
> google.es
Servidor: kriptopolis.org
Address: 213.149.236.75
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** La petición a kriptopolis.org ha caducado
Con kriptópolis, debido a que el TLD tiene un registro A, es capaz de decir: "Vale, esto es 213.149.236.75 y allí resolvemos".
Y luego, cuando quieres hacer un query, pues lanza los paquetes hacia la 213.x, aunque evidentemente nadie conteste, y por ello obtengas timeout.
Sin embargo, y como se puede ver a continuación
Ejemplo 2: TLD sin registro A
> server renfe.es
Servidor predeterminado: renfe.es
> server cualquiercosa
(CRASH)
Cuando no hay un registro A en el TLD, dice "vale, el servidor es renfe.es y aunque no tenga una IP en la que resolver me lo creo"
¿Qué sucede después?. Pues que hay determinadas operaciones como "server" o "ls -d" que cuando son ejecutadas probablemente accedan directamente a la zona de memoria donde debería estar "el registro A" (es decir, una IP) sobre el que resolver, pero como no están, seguramente accedan a un puntero nulo o a una dirección de memoria incorrecta y por eso se produce una excepción.
Volviendo sobre el tema de DNS:
¿El MX no debe ser un CNAME? Esto te lo cuentan en el RFC, así tal cual, pero está un poco mal justificado. Originalmente, allá por los 90, hacerlo podría tener traer 2 consecuencias: que se perdiesen correos, y que se tuvieran que hacer más peticiones para resolver un MX. Evidentemente, el riesgo era que se perdiesen correos, porque algunos smtpd´s se confundían cuando el MX obtenido era un CNAME. Actualmente, esto ya no es así, salvo configuraciones muy concretas y ningún correo queda en el limbo por ello. Aunque en términos generales, se siga aceptando como válido que el MX no debe ser un CNAME.
¿El dominio principal siempre debe tener un registro A? Sinceramente, no recuerdo obligatoriedad para ello en ninguno de los RFC´s, es más, incluso hay ejemplos en los propios RFC´s en los que el dominio principal, únicamente contiene las entradas SOA, NS y MX, por tanto si encuentras la información, añádela.
Si eso las faltas de ortografia:
nslookup 1.2.3.4 1.2.3.4
*** La peticion a UnKnown a caducado
El segundo "A" va con H, deberia ser "HA".