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


http://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/ldap.asp


 


User-Workstations Attribute


http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/a_userworkstations.asp 


 


User Security Attributes


http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/security_properties.asp


 

Comments (0)