Challenge/Response en Windows NT

Trabajo práctico final Challenge/Response en Windows NT Materia: 66.69 Criptografía y seguridad informática Facultad de Ingeniería Universidad de Buenos Aires Alumnos: Lucas P. Diodati (70878) Darío A. Paita (71791) Septiembre de 1998

Objetivo Analizar el uso de Challenge/Response como medio de validación del servicio Internet Infomation Server (IIS) en el entorno del sistema operativo Windows NT 4.0 de Microsoft y estudiar sus vulnerabilidades. Introducción Es común que recursos compartidos en una Intranet o en Internet no estén ofrecidos a todo el mundo. Para realizar la autenticación de los usuarios autorizados se utilizan distintos métodos de validación. Algunos ofrecen más seguridad que otros pero lo que se intenta buscar en la su implementación es aumentar la confiabilidad del proceso. Entre estos métodos existe una conocido como Challenge/Response en el que se la validación del usuario se realiza intercambiando cierta información que revela de forma indirecta la identidad del cliente. La primera parte de este trabajo consiste en la descripción del mecanismo Challenge/Response general. Luego se describirá el algoritmo concreto utilizado por Windows NT para implementar este mecanismo. Y posteriormente se analizará un caso práctico concreto a partir de la captura de tráfico sobre una red que utilizada este método y se obtendrán conclusiones de la vulnerabilidad del sistema. Qué es el Challenge/Response? El mecanismo de Challenge/Response (Desafío/Respuesta) tiene como objetivo principal realizar la validación de un usuario mediante su Nombre de Usuario (username) y Password evitando el traslado de esa información a través de la red. Está pensado sobre todo para redes de carácter público en las que se está expuesto a un ataque de sniffing o Man-in-the-middle. Si pensamos en un esquema de validación de usuario, existen generalmente dos computadoras. Una generalmente donde se encuentra un usuario y otra donde se encuentra un recurso o servicio al cual aquel pretende acceder o utilizar. El método de validación juega un papel fundamental cuando al recurso que se comparte no se le desea dar acceso a cualquier persona sino a las predeterminadas en una lista. El mecanismo de Challenge/Response se basa en un intercambio de preguntas y respuestas entre ambas computadoras. En este diálogo cada participante devuelve los datos que le son enviados transformándolos por un método único y predefinido para el cual usa la información propia de validación. Usualmente este método es una encripción que enmascara la información privada del usuario, para nuestro caso el password. Challenge/Response en Windows NT 4.0 El mecanismo de Challenge/Response, llamado, fue elegido por Microsoft para implementar la validación de los usuarios que acceden a los recursos compartidos del servicio de publicación de páginas web o HTTP, servicios de FTP y Gopher sobre el sistema operativo Windows NT 4.0. Es la forma más segura que tiene este sistema operativo para determinar la autenticidad de quien está realizando el pedido de cierto recurso a través de una red pública como lo es Internet. En qué casos se requiere el uso de este mecanismo? Cuando no esté permitido el acceso anónimo al servidor, cuando el recurso al que se quiere acceder no esté habilitado para el usuario anónimo, y cuando el sistema de Challenge/Response esté habilitado en el servicio IIS y cuando el cliente del servicio soporte este mecanismo. Cómo se inicia este mecanismo? Cuando el cliente y el servidor satisfacen las condiciones antes enumeradas se inicia el mecanismo de la siguiente manera: 1. El cliente solicita un recurso al servidor, por ejemplo una página web. 2. El servidor verifica que esta página no es accesible por el usuario anónimo. Entonces responde con un mensaje de acceso denegado estándar (HTTP 401) pero incluyendo Facultad de Ingenieria Universidad de Buenos Aires Página 2 de 14

en el mismo la lista de los métodos de validación que acepta, para nuestro caso Challenge/Response (). 3. Si el cliente soporta este tipo de autenticación vuelve a pedir la página. 4. El servidor contesta por segunda vez con un mensaje de acceso denegado (HTTP 401) pero incluye en el mismo una cadena de caracteres generada en forma aleatoria, el Challenge. 5. El cliente, al recibirla, la encripta utilizando el hash de su password como clave privada, generando así un nuevo hash único y privado para esta transacción. 6. La conexión entre cliente y servidor se marca como Keep-Alive. 7. El nuevo hash generado por el cliente, el nombre del usuario y el dominio son enviados al servidor a través de la misma conexión. Solamente alguien que posee el has del password del usuario y el Challenge puede generar este nuevo hash. 8. El servidor una vez que recibe estos tres parámetros, los envía junto con el Challenge original al controlador de dominio para que realice la verificación. 9. El controlador de dominio que puede estar funcionando o no en el mismo servidor de IIS realiza la verificación del password según los datos enviados desde el cliente y la base de datos de usuarios (SAM). Para esto realiza la encripción del Challenge utilizando el hash del password del usuario que está almacenado en la base de datos (SAM). El hash resultado de esta encripción es comparado con el hash enviado por el cliente para realizar la autenticación. 10. Si el proceso resulta exitoso se le devuelve al cliente la página solicitada. Si hay un intruso escuchando o capturando tráfico mientras este mecanismo se realiza no tendrá la posibilidad de dar con el password del usuario sino con un hash resultado de una cadena de caracteres aleatorios más otro hash (el del password del usuario). Codificación del Challenge A continuación se explicará el método utilizado para realizar la codificación del Challenge a partir del hash del password. Este proceso es realizado tanto por el cliente al querer autenticarse como por el controlador de dominio al realizar la validación. Como se explicaba en párrafos anteriores, el Challenge consiste en una cadena de caracteres generada aleatoriamente por el servidor que desafía al cliente a demostrar su identidad. Para el entorno de Windows NT 4.0 se ha fijado un tamaño de Challenge de 8 bytes codificados en base 64 (letras mayúsculas, minúsculas, números y algunos signos). Por su lado, el cliente posee el hash del password correspondiente al usuario que se quiere autenticar, el hash utilizado es el MD4. El tamaño del hash del password es de 16bytes. A éstos se les concatenan 5 bytes nulos obteniendo un nuevo hash de 21 bytes. Este último hash es a su vez separado en 3 partes de 7 bytes cada una. 16 bytes del hash del Password 5 bytes Nulos Primeros 7 bytes Segundos 7 bytes Terceros 7 bytes Ejemplo: C23413A8A1E7665FAAD3B435B51404EE 0000000000 C23413A8A1E766 5FAAD3B435B514 04EE0000000000 Cada una de las cadenas de 7 bytes representan las claves para realizar las encripciones utilizando el algoritmo DES. Para ello se transforman en claves de 8 bytes de paridad impar utilizando la API conocida como STR_TO_KEY. Cada una de esas claves se utiliza para encriptar de forma separada el Challenge. Y los resultados de la encripción de estos tres procesos se concatenan en el mismo orden de las partes Facultad de Ingenieria Universidad de Buenos Aires Página 3 de 14

originales para formar un Response de 24 bytes. Este último es devuelto por el cliente para realizar la autenticación y es usado también por el controlador de dominio para realizar la validación. Facultad de Ingenieria Universidad de Buenos Aires Página 4 de 14

Armado del Response a partir del Challenge 16 bytes del hash del Password 5 bytes Nulos Primeros 7 bytes Segundos 7 bytes Terceros 7 bytes C23413A8A1E766 5FAAD3B435B514 04EE0000000000 Challenge de 8 bytes 0001020304050607 8 bytes (7 bytes más paridad) 8 bytes (7 bytes más paridad) 8 bytes (7 bytes más paridad) DES DES DES 8 bytes 8 bytes 8 bytes Response Facultad de Ingenieria Universidad de Buenos Aires Página 5 de 14

Captura de tráfico HTTP Captura de tráfico durante una validación completa Nombre de Computadora Cliente: MONITOR Nombre de Servidor HTTP: ARTEARNT5 PETICIÓN HTTP El cliente pide el recurso al IIS del servidor. RESPUESTA HTTP Primera respuesta negativa del servidor. PETICIÓN HTTP El cliente vuelve a pedir el recurso al IIS del servidor. RESPUESTA HTTP Segunda respuesta negativa del servidor. PETICIÓN HTTP El cliente vuelve a pedir el recurso al IIS del servidor con la codificación del Challenge. RESPUESTA HTTP El servidor informa de la validación GET /cables/default.asp HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Language: es Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT) Host: artearnt5 Connection: Keep-Alive HTTP/1.0 401 Access Denied Server: Microsoft-IIS/3.0 Date: Thu, 17 Sep 1998 19:58:35 GMT Content-type: text/html Set-Cookie: ASPSESSIONID=UZDRQZHNBNKYOIFU; path=/ Cache-control: private GET /cables/default.asp HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Language: es Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT) Host: artearnt5 Connection: Keep-Alive Cookie: ASPSESSIONID=UZDRQZHNBNKYOIFU Authorization: TlRMTVNTUAABAAAAA7IAAAYABgAnAAAABwAHACAAAABNT05JVE9S QVJURUFS TlRMTVNTUAACAAAAAAAAACgAAAABggAA4LXJniOAB7cAAAAAAAAA AE== Connection: keep-alive GET /cables/default.asp HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Language: es Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT) Host: artearnt5 Connection: Keep-Alive Cookie: ASPSESSIONID=UZDRQZHNBNKYOIFU Authorization: TlRMTVNTUAADAAAAGAAYAHQAAAAYABgAjAAAAAwADABAAAAAGg AaAEwAAAAOAA4AzgAAAAAAAACkAAAAAYIAAEEAUgBUAEUAQQBS AGEAZABtAGkAbgBpAHMAdAByAGEAZABvAHIATQBPAE4ASQBUAE8 AUgDZgj8+ypwPrge+6CcxQxcTEb8q8UsqlmFuzblaqgq6nC5HcoP5TQnVu e7dia7b6ng= HTTP/1.0 200 OK Server: Microsoft-IIS/3.0 Date: Thu, 17 Sep 1998 19:58:36 GMT Facultad de Ingenieria Universidad de Buenos Aires Página 6 de 14

positiva al cliente. RESPUESTA HTTP El servidor le envía la página solicitada al cliente. Content-type: text/html Set-Cookie: ASPSESSIONID=BGIFUVQNSFVPQQLR; path=/ Cache-control: private <html> <head> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> <meta name="generator" content="microsoft FrontPage 3.0"> <title>cables</title> </head> <frameset rows="15%,*,8%"> <frame FRAMEBORDER=0 MARGINHEIGHT=2 name="main" src="agencias.asp"> <frameset cols="30%,*" rows="100%,*"> <frame FRAMEBORDER=1 name="titulos" scrolling="auto" src="tituloshtm.asp"> <frame FRAMEBORDER=0 name="cable" scrolling="auto" src="bienvenida.asp"> </frameset> <frame FRAMEBORDER=0 name="toolbarinf" scrolling="auto" src="urgen.asp"> <noframes> <body> <p>esta página usa frames y su browser no lo soporta.</p> </body> </noframes> </frameset> </html> Captura de tráfico durante reiteradas peticiones PETICIÓN HTTP El cliente pide el recurso al IIS del servidor. 1er RESPUESTA HTTP 2da. RESPUESTA HTTP 3er. RESPUESTA HTTP 4ta. RESPUESTA HTTP 5ta. RESPUESTA HTTP GET /cables/ HTTP/1.0 User-Agent: http sample Host: www.canal13.artear.com.ar Authorization: TlRMTVNTUAABAAAABoIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAA AAAAAwAAAA TlRMTVNTUAACAAAABgAGACgAAAAGggEAjfECy0wSyO4AAAAAAAAAAEFS VEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEAXW2Dnt3hPjwAAAAAAAAAAEFS VEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEAlbbZ5LVy1wMAAAAAAAAAAEFS VEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEA3uf/rEnKASkAAAAAAAAAAEFSV EVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEAn8/o5faWuG8AAAAAAAAAAEFS VEVBUg== Facultad de Ingenieria Universidad de Buenos Aires Página 7 de 14

6ta. RESPUESTA HTTP RESPUESTA HTTP RESPUESTA HTTP TlRMTVNTUAACAAAABgAGACgAAAAGggEAImdqXz1YGmsAAAAAAAAAAEF SVEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEAi05VTXIrq8IAAAAAAAAAAEFSV EVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEA6NnlK4vT8L0AAAAAAAAAAEFS VEVBUg== Extracción de los Challenge de la captura anterior TlRMTVNTUAACAAAABgAGACgAAAAGggEAjfECy0wSyO4AAAAAAAAAAEFSVEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEAXW2Dnt3hPjwAAAAAAAAAAEFSVEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEAlbbZ5LVy1wMAAAAAAAAAAEFSVEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEA3uf/rEnKASkAAAAAAAAAAEFSVEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEAn8/o5faWuG8AAAAAAAAAAEFSVEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEAImdqXz1YGmsAAAAAAAAAAEFSVEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEAi05VTXIrq8IAAAAAAAAAAEFSVEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEA6NnlK4vT8L0AAAAAAAAAAEFSVEVBUg== TlRMTVNTUAACAAAABgAGACgAAAAGggEAs9Hu/HtvRroAAAAAAAAAAEFSVEVBUg== Facultad de Ingenieria Universidad de Buenos Aires Página 8 de 14

Vulnerabilidades Por Fuerza Bruta La validación a través de Challenge-Response actualmente solo puede hacerse si en la máquina cliente se utiliza el browser Internet Explorer (IE) versiones 3.02 o 4.x de Microsoft. En el Website de Microsoft existe un Plug-in para poder utilizar este método en el browser Navigator versiones 2.x y 3.x de Netscape, orientado especialmente a los servicios de Proxy de Microsoft que utilizan este método para validar a los usuarios. Si se piensa en realizar un ataque de fuerza bruta sobre tres DES esto puede llevar mucho tiempo, pero a partir de cómo está implementada la seguridad en Windows esto se reduce apreciablemente. En la mayoría de los casos solo habrá que realizar un ataque de fuerza bruta sobre uno de los DES nada más. El proceso empieza capturando de alguna forma los pares de CHALLENGEs generados aleatoriamente por el servidor y RESPONSEs armados según el hash del password del usuario a partir del Challenge. Como se explicaba en párrafos anteriores para armar el Response el cliente concatena 5 bytes nulos al hash del password y divide estos 21 bytes en grupos de 7 bytes. Estos 7 bytes son las claves utilizadas para tres DES junto con el Challenge 16 bytes del hash del Password 5 bytes nulos Challenge de 8 bytes Primeros 7 bytes Segundos 7 bytes Terceros 7 bytes 8byteDeskey1 8byteDeskey2 8byteDeskey3 DES 1 DES 2 DES 3 Ejemplo: 0XC23413A8A1E7665FAAD3B435B51404EE 0000000000 0x0001020304050607 C23413A8A1E766 5FAAD3B435B514 04EE0000000000 8byteDeskey1 8byteDeskey2 8byteDeskey3 DES 1 DES 2 DES 3 CHALLENGE ENCRIPTADO CON LAS CLAVES UTILIZANDO DES 0xAAAAAAAAAAAAAAAA 0xBBBBBBBBBBBBBBBB 0xCCCCCCCCCCCCCCCC Facultad de Ingenieria Universidad de Buenos Aires Página 9 de 14

Según el ejemplo presentado el Response de 24 bytes devuelto al servidor que produjo el Challenge será: 0xAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCC. Ya se tiene el Challenge y el Response, ahora hay que empezar el ataque. Se empieza con el tercer DES, se supone el caso más común, cuando el tamaño del password del usuario no es mayor que 8 caracteres. Si esto sucede, que probablemente ocurra en la mayoría de los usuarios, los últimos 7 bytes utilizados para formar la tercer clave para el DES son 0x04EE0000000000, esto sucede siempre. Para verificar esto simplemente se realiza el encriptando del Challenge con 0x04EE0000000000 y se verifica que se obtenga 0xCCCCCCCCCCCCCCCC. Ahora si estamos ante este caso, 8 bytes de password, los segundos 7 caracteres para armar la segunda clave DES van a ser 0x??AAD3B435B514, donde?? son dos bytes que no se conocen. Para esto hay que realizar un ataque de fuerza bruta con 256 combinaciones. Para esto se prueban las 256 distintas claves buscando cual coincide con la parte del medio del Challenge, o sea 0xBBBBBBBBBBBBBBBB. Solo queda realizar un ataque de fuerza bruta con los primeros 7 bytes que forman la clave DES para el principio del Challenge. Aquí habrá que intentar con (7 x 8)^2= 3136 combinaciones. Esto demuestra que el Challenge-Response de Microsoft es perfectamente crackeable por fuerza bruta. Para capturar los pares de Challenge-Response puede usarse un sniffer en una máquina que se encuentra en la misma red que el servidor o que el cliente. A partir de las credenciales Utilizando un servidor NT con IIS y un servidor SMB puede desencriptarse de una forma sencilla el password de un usuario. El método se basa en que una vez que el browser realizó el intercambio del Challenge y el Response, utiliza las credenciales obtenidas del usuario para acceder a todos los recursos sucesivos. esto se hace con el objetivo de evitar que el usuario deba ingresar el usuario y el password cada vez que pide una página, una imagen, etc. Para realizar esto puede armarse una página HTML sencilla que contiene una imagen. La página se ofrece por medio del IIS del primer servidor y de se niega el acceso al usuario anónimo para forzar la validación Challenge-Response. La imagen que contiene la página se encuentra en el segundo servidor, SMB. Cuando el usuario solicita la página al IIS del primer servidor se produce el proceso del Challenge-Response interrogando al usuario por sus datos, usuario y password. Se realiza el proceso de validación, se encripta el Challenge a partir del password y si todo sale bien el servidor envía la página solicitada. Pero el llegar a la imagen el browser debe solicitarla al otro servidor. Para no interrogar nuevamente al usuario se intenta realizar la validación ante el nuevo servidor a partir de los datos usuario y password ingresados anteriormente, este es el punto: Qué pasa si el Challenge enviado por el servidor SMB es de todos caracteres blancos? Bueno, el browser encriptará el hash "todo blanco" y lo enviará al servidor. A partir del hash "todo blanco" y del Challenge encriptado el servidor puede realizar un ataque de diccionario rápido o un ataque de fuerza bruta donde por ser el hash "todo blanco" las cuentas se hacen muy fáciles. De esta forma se puede obtener el hash del password de un usuario que para el caso de un entorno NT es casi lo mismo que tener el password. Facultad de Ingenieria Universidad de Buenos Aires Página 10 de 14

Conclusiones El mecanismo Challenge-Response evita el intercambio directo del usuario y el password o un hash del password entre el cliente y el servidor. Pero ante lo desarrollado en este trabajo se observa que este método no se ha aprovechado bien en la implementación por Microsoft sobre sus productos. Se ha demostrado que es fácilmente crackeable por fuerza bruta acompañada de algunos trucos de simplificación. La vulnerabilidad recae concretamente en la forma de utilizar el DES para la encriptación combinado con la premisa de que en un entorno NT los hash no se construyen con partes aleatorias y el mismo password siempre provoca el mismo hash. Una de disminuir la vulnerabilidad sin variar demasiado la operatoria hubiera sido aplicar el DES en cascada utilizando para la segunda y tercera encriptación algún valor del resulta de la encriptación anterior, pero se ha elegido el DES paralelo y simple. Otro punto de vulnerabilidad recae en el hecho de que no se le puede estar preguntando al usuario a cada rato su usuario y su password, por lo tanto una vez que el usuario ingresa estos datos el browser los mantiene en memoria y los utiliza cada vez que algún servidor le niega el acceso. Este tema afecta a todos los mecanismos de validación, no solo al Challenge-Response y la solución para esto está por afuera del alcance de este trabajo. Como último punto se recuerda que el DES fue crackeado hace pocos día contribuyendo a los puntos de vulnerabilidad de este método. Terminado se puede concluir que la idea de utilizar Challenge-Response es buena pero no está bien aprovechada en este caso concreto. Facultad de Ingenieria Universidad de Buenos Aires Página 11 de 14

Anexo A: Algoritmos de validación que soporta el Internet Explorer sobre Windows 95 y NT Para verificar que esquemas de seguridad soporta una computadora con windows 95 o NT ejecutar Regedit.exe o Regdt32.exe y buscar la siguiente KEY: HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Security\... Si tiene la siguiente entrada:...\basic\ DLLFile: wininet.dll Flags: 00 00 00 00 SchemeList: Basic SecurityName: Basic Authetication Significa que el Internet Explorer soporta autenticación básica, donde se intercambian usuario y password en clear text. Si tiene la siguiente entrada:...\\ DLLFile: winsspi.dll Flags: 08 00 00 00 SchemeList: SecurityName: SSPI Authetication Significa que el Internet Explorer soporta autenticación Challenge-Response ante Internet Information Server 3.x o 4.x. Para desactivar esta modalidad puede cambiarse donde dice winsspi.dll por, por ejemplo winsspix.dll. Si tiene la siguiente entrada:...\msn\ DLLFile: winsspi.dll Flags: 00 00 00 00 SchemeList: MSN SecurityName: MSN SSPI Authetication Significa que el Internet Explorer soporta autenticación Challenge-Response para Microsoft Network. Facultad de Ingenieria Universidad de Buenos Aires Página 12 de 14

Anexo B: DLLs que utiliza el IExplorer Facultad de Ingenieria Universidad de Buenos Aires Página 13 de 14

Bibliografía Índice MSDN 1997, publicación anual de Microsoft. TechNET 1997, publicación anual de Microsoft. http://www.l0pht.com, Web site de Criptografía. http://www.microsoft.com http://www.osp.nl/infobase/ntpass.html http://oliver.efri.hr/~crv/security/bugs/nt/iebugs.html Objetivo... 2 Introducción... 2 Qué es el Challenge/Response?...2 Challenge/Response en Windows NT 4.0... 2 Codificación del Challenge... 3 Armado del Response a partir del Challenge... 5 Captura de tráfico HTTP... 6 Captura de tráfico durante una validación completa... 6 Captura de tráfico durante reiteradas peticiones... 7 Extracción de los Challenge de la captura anterior... 8 Vulnerabilidades... 9 Por Fuerza Bruta... 9 A partir de las credenciales... 10 Conclusiones... 11 Anexo A: Algoritmos de validación que soporta el Internet Explorer sobre Windows 95 y NT... 12 Anexo B: DLLs que utiliza el IExplorer... 13 Bibliografía... 14 Índice... 14 Facultad de Ingenieria Universidad de Buenos Aires Página 14 de 14