NTLMv1 Bypass

Recientemente en el blog de SilverFort se ha publicado un artículo muy interesante acerca de una nueva vulnerabilidad detectada en el protocolo NTLMv1.

Situándonos en contexto

El protocolo NTLM nace del protocolo LM o Lan Manager en el año 87 que fue ideado inicialmente para un sistema operativo llamado OS/2 creado por Microsoft junto con IBM. De ahí surgieron los hashes LM. Estos primeros hashes LM tenían un problema y es que estaban restringidos a 14 caracteres y además, aunque se introdujeran mayúsculas y minúsculas todas las letras se convertían a mayúsculas. Por lo que si tu ponías una contraseña tipo PaSsWord el hash la encriptaba como PASSWORD.

Para arreglar este problema Microsoft creó el protocol NTLM (New Technology LAN MANAGER) que apareció por primera vez en el año 93 con Windows NT 3.1.

El bypass mencionado en el artículo explota una vulnerabilidad en la implementación del protocolo MS-NRPC (Netlogon Remote Protocol), que es el mecanismo que usa Windows para comunicarse entre servidores y controladores de dominio en una red.

Detalles técnicos del bypass:

1. MS-NRPC y su función de autenticación:
   • MS-NRPC es el protocolo que permite que los servidores y controladores de dominio se comuniquen para verificar las credenciales de un usuario.
   • Para autenticar a un usuario, MS-NRPC usa funciones como NetrLogonSamLogon (y sus variantes) que permiten enviar mensajes NTLM desde un servidor al controlador de dominio de forma segura.
2. Estructura del mensaje de autenticación:
   • Los mensajes de autenticación contienen información de identidad en un formato llamado NETLOGON_LOGON_IDENTITY_INFO. Esta estructura incluye campos como:
     • Nombre de dominio.
     • Nombre de usuario.
     • Nombre del equipo (workstation).
     • Y otros detalles relacionados con el contexto de inicio de sesión.
   • Dentro de esta estructura hay un campo llamado ParameterControl, que contiene ciertos “flags” (indicadores o configuraciones) que modifican cómo se procesa la autenticación.
3. El flag problemático:
   • Uno de los flags de ParameterControl, identificado con el valor O, tiene una descripción que dice: “Permitir autenticación NTLMv1 cuando solo se permite NTLMv2.”
   • Este flag esencialmente dice al sistema que ignore la configuración de la política de grupo (Group Policy) que deshabilita NTLMv1, permitiendo que un cliente use NTLMv1 incluso cuando está explícitamente bloqueado en la red.

Cómo funciona el bypass:

El investigador del artículo menciona que se preguntó si Microsoft realmente permitía a las aplicaciones usar NTLMv1 cuando estaba deshabilitado por políticas de seguridad. Descubrió que era posible:

1. Construcción de la estructura maliciosa:
   • El investigador creó una aplicación maliciosa que construyó un mensaje NTLM con la estructura NETLOGON_LOGON_IDENTITY_INFO y activó el flag en el campo ParameterControl.
2. Ejecución del bypass:
   • Al activar el flag, el mensaje NTLMv1 fue aceptado por el sistema y procesado como si NTLMv1 estuviera permitido, a pesar de que la política de seguridad de la red lo había deshabilitado.
3. Resultado:
   • Esto significa que un atacante puede forzar a un servidor a utilizar NTLMv1 (inseguro) incluso en redes donde la política prohíbe explícitamente su uso. Esto abre la puerta a vulnerabilidades, ya que NTLMv1 es susceptible a ataques como cracking de contraseñas y ataques de relé.

Por qué funciona este bypass:

El problema radica en cómo Microsoft diseñó y documentó el protocolo MS-NRPC. El flag en ParameterControl permite que un servidor ignore la configuración de seguridad de la red, lo cual es una debilidad en la implementación. Si bien Microsoft puede haber tenido razones históricas o de compatibilidad para incluir este flag, en la práctica representa un riesgo significativo de seguridad.

Impacto:

Impacto en la eliminación de NTLMv1:

• Aunque una política de grupo (Group Policy) puede deshabilitar NTLMv1 en la red, las aplicaciones mal diseñadas o inseguras pueden seguir solicitando a los clientes generar mensajes NTLMv1.
• Clientes de Windows: Si el cliente tiene configurado LMCompatibilityLevel 3 o superior (lo que es común en versiones modernas de Windows), rechazará generar NTLMv1 aunque la aplicación lo pida.
• Clientes que no son de Windows: Los dispositivos que no son de Windows (por ejemplo, sistemas operativos Unix/Linux o dispositivos IoT) no están protegidos de la misma manera y pueden cumplir con la solicitud de la aplicación para usar NTLMv1.
• Esto significa que un controlador de dominio aún puede aceptar una autenticación NTLMv1 si el cliente no la bloquea y la aplicación lo solicita.

Problema:

• Muchas organizaciones creen que han eliminado NTLMv1 al activar las políticas adecuadas, pero debido a este bypass, es difícil verificar si una aplicación vulnerable sigue utilizando NTLMv1.
• Las aplicaciones inseguras pueden funcionar sin que el administrador de la red lo sepa, lo que deja abiertas puertas para ataques.

¿Como mitigar esta vulnerabilidad?

• Habilitar registros de auditoría para todas las autenticaciones NTLM en el dominio.
• Mapear todas las aplicaciones que usan autenticación NTLM, ya sea como opción principal o como respaldo.
• Detectar aplicaciones vulnerables que soliciten a los clientes usar mensajes NTLMv1.
• Proteger todas las autenticaciones NTLM con un método de autenticación moderno.

Fuente : Think You Blocked NTLMv1? Bypassing NTLM Authentication Is Still Possible | Silverfort