Hace mucho tiempo ya que le dediqué una entrada a este cliente de administración web para árboles LDAP escrito en PHP. En aquel entonces le dediqué el post a phpLDAPadmin porque en el interfaz es posible acceder de forma anónima a muchos árboles LDAP como si los directorios estuvieran publicados en Internet. Una forma sencilla de acceder a información de una organización.
Durante este tiempo atrás he vuelto a revisar este software debido a un par de motivos. El primero de ellos es porque en el nuevo libro de 0xWord que vamos a publicar en breve yo he tenido que hacer un par de capítulos, y uno de ellos se lo he dedicado a las tecnologías LDAP. El segundo, debido a un estudio que espero tengamos publicado en breve sobre unas técnicas de hacking que tienen que ver con estos paneles de administración.
Es por culpa de este último, que vine a comprobar si este panel de administración cumplía las características necesarias para estar incluido, y aunque no fue así, disfrute volviendo a jugar un poco con este software para descubrir tres fugas de información fáciles de extraer en el caso de que topes con él en una auditoría de seguridad.
Es por culpa de este último, que vine a comprobar si este panel de administración cumplía las características necesarias para estar incluido, y aunque no fue así, disfrute volviendo a jugar un poco con este software para descubrir tres fugas de información fáciles de extraer en el caso de que topes con él en una auditoría de seguridad.
1.- Lista de servidores LDAP y usuarios cacheados
La primera de las fugas de información es tan sencilla como que el panel de administración muestra el nombre de los servidores LDAP incluso para los usuarios desconectados. Esto es así debido a que para poder administrar uno de estos servidores LDAP con la herramienta phpLDAPadmin primero hay que dar de alta los servidores. Así, con solo ver el panel puedes saber el nombre que le han dado al servidor.
Puede no ser muy significativo, o puede que sí que lo sea, pero lo cierto es que el nombre debe estar configurado antes de que te puedas conectar y sale en el árbol de la izquierda. A veces, incluso te puedes encontrar cacheado el objeto de algún usuario por defecto con el que se realiza el proceso de Binding por defecto, tal y como se ve en este ejemplo.
2.- El modo Debug por defecto
El punto 1 que os he puesto no está puesto por casualidad. A pesar de ser una fuga de información bastante sencilla, resulta que es la causante de otra que he encontrado activada en todos paneles de administración que he visitado. Cada servidor que se da de alta en la lista de servidores a administrar recibe un server_id. Este server_id va por parámetro GET y cuando un usuario quiere hacer login uno de los servidores LDAP de la lista de árboles disponibles, debe indicarse mediante un valor numérico. El primer servidor tiene server_id=1, el segundo server_id=2, etcétera.
El problema es que cuando se pide un server_id que no existe, por ejemplo, un server_id=99, la aplicación da un error que si tienes el modo DEBUG activado, muestra por pantalla la ruta de instalación del software.
Figura 4: Error en modo DEBUG en phpLDAPadmin en el sitio oficial de demo |
El modo DEBUG viene por defecto configurado y en todas las instalaciones, incluso en la que tienen de demo en el sitio web del proyecto (que no parece que esté muy vivo pues la última versión es de 2013), se puede comprobar este comportamiento.
Figura 5: Config.php define el modo de DEBUG de phpLDAPadmin |
Si tienes este software y quieres evitar este leak de información debes cambiar el modo DEBUG para que no se muestre por pantalla toda la ruta a los ficheros del servidor.
3.- El comando Server_Info
El último de los leaks de información tiene que ver con la forma en la que se invocan los comandos. Si descargamos el código fuente de la aplicación - ya que es OpenSource - veremos que los comandos en realidad son ficheros PHP dentro del directorio que se invocan con el programa cmd.php?cmd=Nombre_fichero.
Figura 6: Archivos de phpLDAPadmin en una instalación en el servidor web |
Así, en la figura superior se puede ver que para hacer login la URL de llamada es cmd.php?=login_form&server_id=x porque el fichero PHP que hay que invocar es login_form.php. Invocando todos, uno a uno, es posible ver que server_info es posible llamarlo para obtener la información del objeto RootDSE, donde ya se puede obtener mucha información del servidor sin ni siquiera haber hecho login.
Figura 7: Acceso a la información de RootDSE sin haber hecho login. Es un OpenLDAP |
En primer lugar se puede acceder al domain_name del servidor, expresado en formato de objeto LDAP. En segundo lugar se puede sacar información importante, como la versión del software del árbol LDAP (en este caso un OpenLDAP) y los protocolos de autenticación soportados.
Figura 8: Protocolos de autenticación soportados por el servidor LDAP |
Como se puede ver, en este ejemplo estamos ante un servidor LDAP que permite autenticación sistemas de autenticación inseguros, pero en este otro se permite GSSAPI, un sistema que deja negociar autenticación SIMPLE, lo que tal y como se explica en el libro de Ataques en redes de datos IPv4&IPv6 permite ataques de man in the middle a las conexiones LDAP con downgrade de protocolo de autenticación.
Figura 9: Árbol LDAP con autenticación GSSAPI |
Al final, si tienes estos paneles de administración de servidores - ya sean de motores SGBDR, árboles LDAP, estadísticas, monitorización de servicios, etcétera, lo mejor es que no estén publicados a Internet. Si los tienes en la intranet, revisa su seguridad constantemente, ya que puede que estos proyectos se queden sin soporte o que aparezcan nuevas técnicas de explotar nuevas vulnerabilidades, así que no te relajes ni un ápice. Además de todo esto, phpLDAPadmin no tiene Segundo Factor de Autenticación, así que además de arreglar estas tres cosas, si alguien quiere un proyecto de desarrollo para hacer, integrarle Latch sería sencillo para dejarlo aún más seguro.
Saludos Malignos!
No hay comentarios:
Publicar un comentario