Su aplicación esta lista para un ambiente seguro – PARTE II
Por: Yuri Diógenes / Diana Hernandez
1. Introducción
En Mayo de este año había escrito lo que fue la parte uno de este documento, y no daba por hecho que habría una parte 2, mas el día a día me viene mostrando dos cosas:
· Primero que muchas empresas ya se preocupan de hecho con la seguridad de la información e invierten en eso- lo cual es óptimo;
· Segundo que muchas empresas tienen aplicaciones antiguas que aun no están listas para trabajar en ambiente seguro-lo que es un hecho.
Días atrás trabajé en otro caso en donde el villano parecía ser el sistema operacional, hasta que después de varias pruebas pudimos concluir que no era; sin embargo, hasta llegar a esa conclusión muchas cosas pasaron.
Vamos a entender el escenario:
· El cliente tiene una aplicación que hace uso del protocolo LDAP para hacer consultas al Active Directory.
· El usuario se conecta al AD usando LDAP y pasa las credenciales vía línea de comando.
· En el pasado este usuario de la aplicación podía usarla sin mayores problemas y hacer sus consultas en AD también sin problemas.
· Problema: Después de la empresa implementar algunas de las políticas de seguridad el usuario no conseguía utilizar esta aplicación de ninguna forma.
2. Obteniendo Datos
Primero, fue necesario un trabajo de investigación para saber lo que había mudado con respecto de la seguridad, para mi suerte el cliente aún estaba en el inicio de la implementación lo que facilitó mi trabajo pues no tuve mucho problema para hallar una pista fundamental.
Una de las políticas que fue implementada fue la que los usuarios solo pudieran efectuar logon en la red en algunas estaciones de trabajo, una política simple pero eficaz, antigua (la tenemos desde NT 3.51) y funcional. Recuerda esa política? Esta en las propiedades de usuario como se muestra abajo:
En este momento usted debe estar pensando: fácil, basta colocar la estación en la cual el usuario está efectuando el logon y listo. Bien, no es así, a pesar que eso también me vino en mente, aun así adicionando la estación a la cual el usuario pudiera efectuar logon, continuábamos recibiendo el error de acceso negado.
Fué entonces que resolvimos hacer una prueba corriendo localmente (en el domain controller) y también tuvimos problemas, entonces colocamos el Domain Controller en la lista de computadores autorizados para que aquel usuario hiciera logon y funcionó.
Después de esto probamos con otras cosas y siempre que el Domain Controller estaba en la lista de computadores en la cual el usuario podía hacer logon la aplicación que usaba LDAP lograba hacer autenticación. Intrigante no?
3. Haciendo “Narrow Down” del problema...
En este momento hubo un cierto “stress” por parte del cliente pues en principio el encontraba que era un hueco en la política de seguridad que solo dejaba al usuario hacer logon cuando el DC estuviese en la lista. Eso fue algo que no me convenció tampoco, ya que estábamos lidiando con una aplicación de terceros y no teníamos conocimiento de cómo funcionaba entonces resolvimos usar una herramienta nuestra para hacer la prueba, fue entonces que utilizamos LDP.EXE. Cuando estamos conectando vía LDP tenemos la opción de pasar las credenciales de usuario que está haciendo el logon, conforme muestra la figura:
Entonces sacamos al DC de la lista de computadores en donde estaba permitido para el usuario efectuar logon y dejamos apenas la estación local a la cual estaba logueado. Resultado: funcionó sin problemas.
4. Y porque esto?
Ahora que ya sabemos que con nuestro LDAP funciona, resta saber porque, al final no solo tenemos que resolver pero probar el porqué y defender nuestra tesis. Para esto nada mejor que el viejo y buen Network Monitor. Recuerde: todo lo que pasa por la placa de red del computador al cual usted está investigando es capturado por el netmon, entonces la mejor forma de saber qué es lo que realmente está pasando es mirar los paquetes, claro puede llevar tiempo y puede ser algo que no es tan claro para algunos, por lo tanto le recomiendo comenzar a familiarizarse bien con esto.
Vamos entonces a la prueba número 1:
· Uso de LDP.EXE para conectarse al AD vía LDAP:
1. Cliente hace una petición en el puerto TCP 389:
192.1.16.15 192.7.11.12 TCP 4507 > ldap [SYN]
2. Servidor acepta la conexión
192.7.11.12 192.1.16.15 TCP ldap > 4507 [SYN, ACK]
3. El MS LDP (en el lado del cliente) envía entonces un “Bind Request” en donde pasa las credenciales y en este caso utiliza un método NTLM de autenticación:
192.1.16.15 192.7.11.12 LDAP MsgId=13
Bind Request, DN=(null), NTLMSSP_AUTH, User: DOMAINNAME \TestUser
Lightweight Directory Access Protocol
LDAP Message, Bind Request
Message Id: 13
Message Type: Bind Request (0x00)
Message Length: 225
Response In: 3175
Version: 3
DN: (null)
Auth Type: SASL (0x03)
Mechanism: GSS-SPNEGO
GSS-API Generic Security Service Application Program Interface
NTLMSSP
NTLMSSP identifier: NTLMSSP
NTLM Message Type: NTLMSSP_AUTH (0x00000003)
Lan Manager Response:
F1DC6D4CFFCD04F900000000000000000000000000000000
Length: 24
Maxlen: 24
Offset: 134
NTLM Response: F2988187EC1C67496EDF4F46313F401E08F688325DC541A8
Length: 24
Maxlen: 24
Offset: 158
Domain name: DOMAINNAME
Length: 18
Maxlen: 18
Offset: 72
User name: TestUser
Length: 32
Maxlen: 32
Offset: 90
Host name: COMPUTADOR1
Length: 12
Maxlen: 12
Offset: 122
Session Key: 33724B7018EADC94650FCAAB1F6741EF
Length: 16
Maxlen: 16
Offset: 182
Flags: 0xe2888215
4. El servidor envia un mensaje de autenticación con éxito:
192.7.11.12 192.1.16.15 LDAP MsgId=13 Bind Result
Lightweight Directory Access Protocol
LDAP Message, Bind Result
Message Id: 13
Message Type: Bind Result (0x01)
Message Length: 9
Response To: 3174
Time: 0.001953000 seconds
Result Code: success (0x00) <---------------------- EXITOSO
Matched DN: (null)
Error Message: (null)
Bien, con esto sabemos exactamente como nuestra aplicación se está comportando durante la autenticación, o sea , está utilizando NTLM.
Vamos entonces a la prueba número 2:
· Uso de la aplicación de terceros para conectarse al AD vía LDAP:
1. El cliente hace una petición de acceso en el puerto TCP 389 (emitiré ola visualización de los paquetes pues no hay cambio en el comportamiento)
2. El servidor acepta la petición.
3. El cliente envia entonces el “Bind Request” y ahora viene la diferencia:
192.1.16.15 192.7.11.12 LDAP MsgId=1 Bind Request, DN=CN=TestUser,OU=Test,DC=domainname,DC=local
Lightweight Directory Access Protocol
LDAP Message, Bind Request
Message Id: 1
Message Type: Bind Request (0x00)
Message Length: 83
Response In: 998
Version: 3
DN: DN=CN=TestUser,OU=Test,DC=domainname,DC=local
Auth Type: Simple (0x00) <-------------------- Método Simple de Autenticación
Password: 12345678
4. El servidor envia el siguiente resultado:
192.7.11.12 192.1.16.15 LDAP MsgId=1 Bind Result, invalidCredentials
Lightweight Directory Access Protocol
LDAP Message, Bind Result
Message Id: 1
Message Type: Bind Result (0x01)
Message Length: 94
Response To: 997
Time: 0.001954000 seconds
Result Code: invalidCredentials (0x31) <-------------- ERROR
Matched DN: (null)
Error Message: 80090308: LdapErr: DSID-0C090334, comment:
AcceptSecurityContext error, data 531, vece
Ahora que tenemos un escenario que funciona y uno que no funciona ya podemos decir que:
· Consulta LDAP vía LDP.EXE está usando el método de autenticación NTLM;
· Consulta LDAP vía aplicación de terceros está usando autenticación simple;
El protocolo LDAP implementado por Microsoft puede tener los siguientes métodos de autenticación:
Método de Autenticación |
Descripción |
LDAP_AUTH_SIMPLE |
Autenticación simple con texto limpio. |
LDAP_AUTH_NTLM |
Autenticación NT Lan Manager |
LDAP_AUTH_DPA |
Autenticación distribuida, usada por MMS (Microsoft Membership System) |
LDAP_AUTH_NEGOTIATE |
Generic security services (GSS) |
LDAP_AUTH_SSPI |
Método antiguo el cual está incluido por compatibilidad retroactiva. |
Fuente de la Tabla: White Paper Understanding LDAP
Ahora viene la pregunta: que tiene que ver el método de autenticación de usuario con la política de seguridad que define en que estaciones de trabajo el usuario se puede autenticar?
Veamos entonces como el proceso ocurre:
1. La aplicación de terceros envia una consulta LDAP para el AD usando el método de autenticación simple (LDAP_AUTH_SIMPLE). Este tipo de método enviar una cadena que contiene apenas el nombre de usuario y contraseña;
2. Cuando el DC recibe esta petición de autenticación del cliente el DC entonces verifica las credenciales de usuario así como las propiedades de conexión para verificar si el computador en el cual el usuario está localizado está en la lista de computadores autorizados para dicho usuario;
3. Como la aplicación envia una petición simple de autenticación LDAP , el nombre del computador no está incluido en el paquete entonces el DC utiliza el nombre NetBIOS de el mismo para hacer la autenticación.
4. El DC entonces verifica que el nombre NetBIOS de el mismo está contenido o no en la lista de computadores (atributo userWorkstations) autorizados y en este caso como no está entonces retorna un “Access Denied”.
Ahora nos queda fácil entender el porqué cuando colocamos el nombre del DC en la lista de autenticación funcionaba. El problema no ocurre con NTLM ya que el nombre del computador está incluido como lo muestra la captura de red presentada anteriormente. Vamos a revisar los campos contenidos en el paquete LDAP utilizando NTLM:
NTLM Response: F2988187EC1C67496EDF4F46313F401E08F688325DC541A8
Length: 24
Maxlen: 24
Offset: 158
Domain name: DOMAINNAME
Length: 18
Maxlen: 18
Offset: 72
User name: TestUser
Length: 32
Maxlen: 32
Offset: 90
Host name: COMPUTADOR1
Length: 12
Maxlen: 12
Offset: 122
Session Key: 33724B7018EADC94650FCAAB1F6741EF
Length: 16
Maxlen: 16
Offset: 182
Flags: 0xe2888215
5. Conclusión
Ambiente seguro es algo de extrema importancia en estos días, por lo tanto tan importante como esto es un ambiente de validación de las políticas de seguridad, principalmente cuando estamos saliendo de un ambiente en donde existen aplicaciones antiguas que no se preocupan por aspectos de seguridad. Implementar nuevas políticas trae beneficios al negocio pero también puede tornarse en un dolor de cabeza en caso que no sea bien planeado.
6. Referencias
Understanding LDAP
https://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/ldap.asp
User-Workstations Attribute
User Security Attributes