viernes, mayo 30, 2008

Ataques a LDAP (III de IV)

***************************************************************************************
Ataques a LDAP (I de IV)
Ataques a LDAP (II de IV)
Ataques a LDAP (III de IV)
Ataques a LDAP (IV de IV)
***************************************************************************************
2.3.- Ataque 3: Captura de información transmitida

Una vez realizada la conexión entre el cliente y el servidor, se produce la transmisión de los datos solicitados por el cliente. Esta transmisión, por defecto se realiza sin utilizar ningún tipo de cifrado. Cualquier usuario que tenga acceso a las comunicaciones, mediante una conexión de red insegura podrá acceder a los datos.
Una red insegura puede ser cualquiera de los siguientes entornos:

- Redes Wifi: Las redes inalámbricas tienen la peculiaridad de estar al alcance cualquiera que esté cerca. Si la red inalámbrica no tiene autenticación o cifrado, o si el cifrado y autenticación que usa es WEP o si se está usando WPA-PSK y la contraseña no es robusta, es decir, de longitud corta, poca complejidad y no es cambiada cada cierto tiempo, entonces esa red Wireless es potencialmente insegura.

- Redes Cableadas: Si la red utiliza un concentrador de conexiones (hub) o usa switches sin IPSec o IPSec con Pre-Shared Key, sin detectores de Sniffers y sin detectores de técnicas envenenamiento (ARP-Poisoning) entonces esa red es potencialmente insegura.

En esas redes, el uso de Sniffers, o analizadores de tráfico, puede permitir a un atacante acceder a la información transmitida. La siguiente captura, realizada con el popular sniffer de red Wireshark en una red cableada con un concentrador de conexiones, ofrece al atacante los datos transmitidos tras la ejecución de una consulta de la carpeta USERS para ver su contenido.

Captura de datos transmitidos desde el árbol LDAP con Wireshark

Para evitar este tipo de ataques, reconocidos también en la RFC 4422, como ataques pasivos, se debe fortificar y cifrar el protocolo LDAP mediante el uso de LDAP-s y certificados digitales. No obstante, es posible realizar un ataque de Hijacking[21] de sesión, como se verá en el Ataque 4, mediante el uso de certificados digitales falsos si no existe una férrea comprobación de los certificados.

2.4.- Ataque 4: Hijacking LDAP-s. Paso 1: Configuración LDAP-s

La utilización de un sistema LDAP-s, es decir, encapsular las conexiones LDAP mediante un túnel SSL, puede ofrecer a los administradores la falsa tranquilidad y confianza en tener un sistema seguro. No obstante, el uso de esta tecnología no es garantía de éxito para conseguir evitar los ataques y existen pruebas de concepto públicas para atacar a estos entornos.

Para probar el riesgo de este ataque, es necesario implementar un sistema de certificados en el lado del servidor. Para realizar esta prueba se ha utilizado el Directorio Activo de un Windows Server 2003. A través del siguiente proceso, vamos a establecer los mecanismos para configurar un controlador de dominio Windows 2003 para trabajar con conexiones LDAP-s. Para ello utilizaremos una Entidad Certificadora de Microsoft de tipo independiente[22], instalada sobre el mismo controlador de dominio, y para las pruebas de conexión emplearemos el cliente LDP de Microsoft que viene con el grupo de herramientas SupportTools[23] disponibles de forma gratuita. En este entorno se va a configura las conexiones a través del puerto “well-known” asignado a las conexiones LDAP-s, es decir, el puerto 636.

El primer elemento del proceso, consiste en la petición de un certificado para la autentificación del servidor. Para realizar la petición del certificado se utiliza un fichero de petición X.509[24] para la autentificación de servidor con el siguiente formato.

Se genera un fichero en texto plano para realizar la petición de un certificado X.509. En él se configuran los parámetros necesarios para que pueda ser utilizado en el cifrado de conexiones LDAP-s

Este fichero servirá para la creación del archivo de solicitud, que se generará mediante el uso de la aplicación certreq, disponible por defecto en los sistemas Microsoft Windows Server.

A partir del fichero creado, con la utilidad certreq se crea un fichero de solicitud .req que será enviado a la entidad certificadora

Con posterioridad se procede a enviar, usando la utilidad certreq, la solicitud a la Entidad Certificadora, en este caso la entidad certificadora es una Entidad de tipo Independiente denominada “caI64”.

El fichero de solicitud es enviado a la entidad certificadora para que ésta emita el certificado digital asociado a esa petición

Una vez enviada, se comprueba que la petición ha llegado satisfactoriamente y se procede a emitir un certificado asociado a esa petición.

La entidad certificadora procede a la emisión del certificado asociado a la petición

Una vez que la petición ya ha sido emitida, se procede a generar la copia del certificado codificándolo en base64, para su instalación posterior en el servidor correspondiente.

Se exporta el certificado usando una codificación Base-64 para que pueda ser instalado en el servidor dónde se está ejecutando el servicio LDAP

Una vez que el certificado ha sido emitido, debe ser instalado en el servidor dónde esté instalado el árbol LDAP. Para aceptar e instalar el certificado emitido, se utilizará nuevamente la utilidad certreq, en este caso con el modificador –accept que dejara totalmente funcional el certificado.

En el servidor se acepta e instalación el certificado digital mediante certreq

Se comprueba a través de la consola de certificados del equipo local, que este ha sido instalado satisfactoriamente y que tenemos la clave privada correspondiente como medida de seguridad adicional.

Se comprueba el certificado digital instalado mediante el uso de la herramienta de gestión de certificados digitales del servidor

Una vez configurado el Servidor, en la parte Cliente lo único que se necesita es confiar en la Entidad Emisora de Certificados que emitió el certificado del Servidor. Este proceso es importante, pues si no se puede comprobar la autenticidad del certificado, su uso no sería válido, y, como veremos, no protege la conexión frente a los ataques.

Como último paso se puede proceder a realizar una conexión LDAP-s. En este caso se ha utilizado la herramienta LDP de Microsoft. Como se puede ver en la captura se configura el uso de SSL y el puerto 636 para realizar la transmisión de datos.

Una vez configurado se procede a la solicitud de la conexión usando el protocolo LDAP-S

A partir de este momento, toda la transmisión de datos se realiza mediante el uso del protocolo SSL que cifra las conexiones extremo a extremo. Este cifrado evita que alguien que no esté situado en un extremo del túnel SSL pueda acceder a los datos.

La conexión LDAP-S establecida

Una vez implantado este entorno LDAP-s se podría pensar que la arquitectura es segura, sin embargo, se han hecho públicas herramientas que implementan un ataque basado en Hijacking de sesiones LDAP-s. Una de esas herramientas es Cain&Abel, a partir de su versión 4.9.6 y en el siguiente apartado se puede ver cómo funciona este ataque.

***************************************************************************************
Ataques a LDAP (I de IV)
Ataques a LDAP (II de IV)
Ataques a LDAP (III de IV)
Ataques a LDAP (IV de IV)
***************************************************************************************

2 comentarios:

Anónimo dijo...

Chema, una preguntilla: ¿Tienes el artículo completo (como .PDF)?
Quiero imprimirlo, y, aunque puedo copiar y pegar, es mejor así.

Siempre que no tenga problemas de copyright, claro.

Chema Alonso dijo...

Pues no lo tengo en PDF, ya en la cuarta entrega quedará listo para sentencia ;)

Saludos!

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares