MS-CHAP v2: Microsoft aconseja dejar de usarlo sin encapsular
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).
Proceso copia.jpg
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.
Proceso2 copia.jpg
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^16 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^112 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.
NOTA: Los interesados en información sobre contrato de soporte Asistencia Tecnica de SATINFO y/o licencia de uso/actualizaciones de sus utilidades, contacten con info@satinfo.es
__________
Este blog no se hace responsable de las opiniones y comentarios de los textos en los que se cita la Fuente, ofreciendo su contenido solo para facilitar el acceso a la información del mismo.
Puedes seguir cualquier respuesta a esta entrada mediante el canal RSS 2.0. Los comentarios y los pings están cerrados.
Los comentarios están cerrados.