Rematando MS-CHAP v2: Microsoft aconseja dejar de usarlo sin encapsular (II)

Finalmente, Microsoft ha publicado un aviso de seguridad donde pide a sus usuarios que dejen de utilizar MS-CHAPv2 como método de autenticación en conexiones PPTP (al menos sin encapsular). El protocolo sufría varias debilidades que lo hacen inseguro desde 1999, pero desde la revelación de nuevos métodos por Moxie Marlinspike, usarlo es un grave riesgo.

Para hacernos una idea del alcance del fallo descubierto, vamos a repasar cómo funciona MS-CHAPv2, las debilidades del protocolo y cómo se pueden aprovechar.

¿Cómo se realiza la conexión?

En resumen, y si nos centramos en los pasos débiles del protocolo, el handshake de MS-CHAPv2 sigue el siguiente proceso:

1.El cliente solicita al servidor un desafío de autenticación.

2.El servidor genera un desafío aleatorio de 16 bytes y lo envía al cliente.

3.El cliente concatena el desafío del servidor, un número aleatorio de 16 bytes (Peer Authenticator Challenge) y el nombre de usuario. Con esta cadena consigue un hash SHA1, del que toma los 8 primeros bytes (En adelante, C).

Paralelamente, codifica la contraseña del usuario usando la función NTPasswordHash. Este hash tiene 16 bytes, se expande hasta llegar a los 21 bytes y se divide en tres bloques de 7, que se utilizan como clave DES para cifrar sendas copias del hash C. Esto da lugar a tres cadenas de 8 bytes que, concatenadas, forman la respuesta al servidor.

4.El servidor toma el hash de la contraseña del usuario que tiene almacenada y la usa para descifrar la respuesta. Si corresponde al desafío, entonces el cliente es autenticado.

5.Tras esto, servidor y cliente toman el Peer Authentication Challenge y el NTPasswordHash y calculan una respuesta del autenticador. Si los cálculos de ambos coinciden, el servidor también es autenticado en el cliente.

Primer error: Pasar información en claro o fácilmente derivable

Si la conexión no está cifrada, PPP pasa información altamente sensible en claro a través la red. Este es el caso de la respuesta de 24 bytes que el cliente envía al servidor, y que contiene el hash de la contraseña de usuario. Otra información que se averigua fácilmente a partir de otras trazas transmitidas, de nuevo, en claro.

Así, lo único que no conocemos de este handshake es la contraseña del cliente, o lo que es equivalente, el NTPasswordHash.

Segundo error: Expandir la respuesta con bytes de ceros.

El NTPasswordHash se expande hasta llegar a los 21 bytes. Esta operación se realiza añadiendo cinco bytes más, formados únicamente por ceros. Como estos 21 bytes se dividen en tres bloques de siete, topamos con que el último bloque está compuesto por los dos últimos bytes del NTPasswordHash y cinco bytes de ceros.

Es casi trivial obtener estos dos últimos bytes utilizando fuerza bruta. Sólo habría que probar las 2¹⁶ combinaciones de dos bytes seguidos por ceros como clave. Nos restaría, por tanto, averiguar los restantes 14 bytes.

Tercer error: Hash como autenticador y ataques de diccionario.

Se debe desechar una aproximación de fuerza bruta para obtener la contraseña, ya que (si la contraseña es compleja) tendría un alto coste. De todas formas, no se necesita: para el proceso de autenticación solo se precisa el hash de la contraseña, que puede actuar como esta. Mediante fuerza bruta seguirían siendo 2¹¹²operaciones, lejos de ser computable.

En estos casos, se puede realizar un ataque de diccionario. Se obtendría el NTPasswordHash de todas las entradas de un diccionario dado y filtraríamos aquellos cuyos últimos 2 bytes coincidan con los que ya hemos obtenido. Posteriormente, estos se dividen en bloques de 7 y se prueban como clave. Si los valores coinciden, tendríamos nuestro hash y contraseña. Sin embargo el éxito de esta aproximación depende en buena parte de la contraseña elegida por el usuario. En otras palabras: no es peligroso mientras se utilice una buena contraseña.

Este es el procedimiento de "ataque" aceptado hasta hoy, y que se definía en la publicación "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)", de Schneier, Wagner y Mudge (1999). Existen multitud de aplicaciones, como asleap, que son capaces de realizar ataques de diccionario offline dada una captura de red de MS-CHAPv2.

Veamos, en la próxima entrega, qué hizo Moxie y qué aportó para debilitar finalmente este protocolo.

Más información:

Unencapsulated MS-CHAP v2 Authentication Could Allow Information Disclosure