Hace unos días, Microsoft anunció que finalmente optará por “deprecar” NTLM. Aunque esto pueda parecer un cambio drástico en la postura de Windows y su conocida retro-compatibilidad, lo cierto es que se trataba de “una muerte anunciada”. Este cambio era previsible, y tanto Microsoft como sus empleados lo han estado manifestando desde octubre de 2023 a través de diferentes medios.
Figura 1: Microsoft declara oficialmente obsoleto el protocolo
de autenticación NTLM en Windows
Podemos verlo en esta charla de Steve Syfuhs, Principal Engineer en Microsoft, y también en este post del blog de Microsoft escrito por Matthew Palko, donde ambos hablan de la evolución de la autenticación en Windows y cómo NTLM está quedando relegado por Kerberos. NTLM siempre ha sido uno de los grandes problemas de seguridad que obliga a tomar medidas de fortificación en Windows para evitar riesgos.
Sin embargo, no ha sido hasta ahora, el 11 junio de 2024, que Microsoft, en su lista de funcionalidades “deprecated” para Windows ha anunciado oficialmente la desaparición y “deprecación” del mítico protocolo de autenticación NTLM, que será oficialmente reemplazado por Kerberos siempre que sea posible. Esto significa, que Microsoft dejará de mantener de forma activa este protocolo y priorizará el soporte de otros como Kerberos.
Si bien en el anuncio se comenta que seguirá funcionando en la próxima versión de Windows Server y en la próxima versión anual de Windows, es cierto que todas las llamadas a NTLM deberían intentar autenticarse haciendo uso de Kerberos, de esta forma solo se recurriría a NTLM en los casos que sea estrictamente necesario.
Figura 3: Anuncio de que NTLM está en la lista de
Si bien en el anuncio se comenta que seguirá funcionando en la próxima versión de Windows Server y en la próxima versión anual de Windows, es cierto que todas las llamadas a NTLM deberían intentar autenticarse haciendo uso de Kerberos, de esta forma solo se recurriría a NTLM en los casos que sea estrictamente necesario.
Funcionamiento y Riesgos de NTLM
Ya sabéis que NTLM, tuvo un predecesor (y también unos cuantos sucesores o alternativas), todos conoceréis LM o LAN Manager. Este protocolo que nació en 1987 cuando Microsoft, junto con IBM, desarrollaban un sistema operativo de redes, el denominado OS/2. No tardaron en mostrarse al mundo las vulnerabilidades inherentes del algoritmo de hash LM.
Ya sabéis que NTLM, tuvo un predecesor (y también unos cuantos sucesores o alternativas), todos conoceréis LM o LAN Manager. Este protocolo que nació en 1987 cuando Microsoft, junto con IBM, desarrollaban un sistema operativo de redes, el denominado OS/2. No tardaron en mostrarse al mundo las vulnerabilidades inherentes del algoritmo de hash LM.
Para crear estos hashes, comenzamos con la primera de las restricciones, contraseñas de un máximo de 14 caracteres. Luego, a pesar de permitir introducir mayúsculas y minúsculas, todas las letras se convertían a mayúsculas, por lo que el conjunto de caracteres se reducía a la mitad, y contraseñas como “HaCkEr” o “hacker” generaban el mismo hash.
Por último, y para más “inri”, se generaban dos hashes concatenados al segmentar la contraseña de 14 caracteres en dos de 7 caracteres cada una. El resultado, cómo podéis imaginar, todo un protocolo digno de aplicar un ataque de fuerza bruta. En la siguiente imagen os dejo una explicación básica de este algoritmo:
Figura 4: Funcionamiento del Hash LM
Microsoft tenía que hacer algo, y nació NTLM (New Technology LAN Manager), el protocolo de autenticación sucesor de LAN Manager. Este protocolo, que apareció por primera vez en 1993 junto a Windows NT 3.1, utiliza un mecanismo de desafío-respuesta para autenticar a un cliente en un servidor mediante una contraseña. El flujo de funcionamiento de NTLM es el siguiente:
1) El cliente comienza una negociación con un servidor y envía un NEGOTIATE_MESSAGE anunciando sus capacidades y características de seguridad soportadas.
2) Una vez negociados los detalles de la comunicación (por ejemplo, la versión de LDAP a utilizar), el servidor responde con un CHALLENGE_MESSAGE, que incluye un nonce (un número aleatorio) que el cliente tendrá que cifrar con el hash de su contraseña (que debe ser igual al hash NTLM guardado en la SAM). Este nonce es de 8 bytes en NTLMv1 y de 16 bytes en NTLMv2.
3) Tras esto, el cliente responde con un AUTHENTICATE_MESSAGE, que contiene el nonce cifrado con el hash NT de la contraseña del usuario, junto con otros datos de autenticación.
- En el caso de un entorno de Active Directory, el servidor envía el desafío y la respuesta enviada por el cliente al controlador de dominio para que este verifique su validez.
- El controlador de dominio verifica la respuesta y envía la confirmación de autenticación al servidor.
4) Finalmente, si la verificación enviada por el controlador de dominio es correcta, el servidor validará correctamente al usuario o, por el contrario, devolverá un error.
Figura 5: Flujo de autenticación NTLM
Como se puede comprobar, en este proceso de autenticación NTLM no se ha utilizado en ningún momento la contraseña del usuario de manera directa, sino que se emplea para crear su hash NTLM, hash que está almacenado en la SAM (Security Account Manager) del equipo. Debido a la ausencia de “salting” y que el hash NTLM y la contraseña son equivalentes a nivel de secreto en el protocolo NTLM, el conocido ataque PassTheHash tiene sentido. En este tipo de ataque, un atacante que ha obtenido el hash NTLM de un usuario puede autenticarse como ese usuario sin necesidad de conocer su contraseña en texto plano.
Por último, comentar acerca del sucesor definitivo de NTLM, Kerberos, un protocolo de autenticación creado por el MIT en 1989, de código abierto y mantenido por una gran comunidad, entre la cual se encuentra Microsoft que desarrolla su propia versión (compatible en gran medida con la “oficial”).
Kerberos, deja atrás el método de desafío-respuesta propio del protocolo de autenticación NTLM y pasa a utilizar un sistema de tickets para autenticar a los usuarios. En Kerberos encontramos componentes claves como el centro de distribución de claves (KDC), el servidor de autenticación (AS), el servidor de concesión de tickets (TGS), … Todo esto, da para verlo con más detalle en otro post.
La misión de Kerberos es establecerse como la plataforma universal de autenticación en todas las redes del mundo, así lo comentan kerberos.org. Actualmente, Kerberos es el protocolo de autenticación principal por defecto, mientras que NTLM interviene en circunstancias específicas. Por ejemplo, se utiliza NTLM cuando se autentica a través de sistemas configurados en un grupo de trabajo en lugar de un dominio, en la autenticación local en controladores que no forman parte de un dominio o en aplicaciones que no soportan otros tipos de protocolos.
Tú mismo puedes hacer uso de un Fiddler (un proxy que registra todo el tráfico HTTP/HTTPS entre el equipo e Internet) para recopilar todas las peticiones realizadas, y mediante la observación de las cabeceras, detectar en qué casos se está usando Kerberos o NTLM. En una cabecera de autorización, si el token comienza por “YII” estaremos ante un caso donde se está utilizando Kerberos. Si, por el contrario, comienza por “TlR” estaremos ante un protocolo de autenticación distinto a Kerberos (normalmente NTLM). Por ejemplo:
Kerberos, deja atrás el método de desafío-respuesta propio del protocolo de autenticación NTLM y pasa a utilizar un sistema de tickets para autenticar a los usuarios. En Kerberos encontramos componentes claves como el centro de distribución de claves (KDC), el servidor de autenticación (AS), el servidor de concesión de tickets (TGS), … Todo esto, da para verlo con más detalle en otro post.
Figura 7: Misión de Kerberos.org
La misión de Kerberos es establecerse como la plataforma universal de autenticación en todas las redes del mundo, así lo comentan kerberos.org. Actualmente, Kerberos es el protocolo de autenticación principal por defecto, mientras que NTLM interviene en circunstancias específicas. Por ejemplo, se utiliza NTLM cuando se autentica a través de sistemas configurados en un grupo de trabajo en lugar de un dominio, en la autenticación local en controladores que no forman parte de un dominio o en aplicaciones que no soportan otros tipos de protocolos.
Tú mismo puedes hacer uso de un Fiddler (un proxy que registra todo el tráfico HTTP/HTTPS entre el equipo e Internet) para recopilar todas las peticiones realizadas, y mediante la observación de las cabeceras, detectar en qué casos se está usando Kerberos o NTLM. En una cabecera de autorización, si el token comienza por “YII” estaremos ante un caso donde se está utilizando Kerberos. Si, por el contrario, comienza por “TlR” estaremos ante un protocolo de autenticación distinto a Kerberos (normalmente NTLM). Por ejemplo:
- Cabecera de autenticación de Kerberos:
- Authorization: Negotiate YIIVDAYGKwYBE...
- Cabecera de autenticación no perteneciente a Kerberos:
- Authorization: Negotiate TlRMTVNTUA...
 |
| Figura 8: Libro de Ethical Hacking 2ª Edición de 0xWord escrito por Pablo González Pérez |
Ahora toca esperar y ver cómo Microsoft sigue moviendo ficha hasta que veamos por completo la eliminación de NTLM. No obstante, es un cambio positivo ya que pasamos de utilizar un protocolo de autenticación donde el conocimiento del hash del usuario rompe por completo la seguridad; a utilizar por defecto un protocolo más seguro como es Kerberos. Y para los Ethical Hacking, pues a ponerse las pilas con Pass-the-ticket.
Saludos,
No hay comentarios:
Publicar un comentario