Escanear una DMZ con Cadenas de Conexión a MySQL
Hace ya tiempo que publiqué el artículo de "Connection String Attacks" pero estos días he tenido ganas de volver a revisar algunas cosas, ya que estoy haciendo algo con la parte del trabajo que estaba destinada a hacer un escaneo de los servidores internos de la DMZ y los puertos mediante una polución en la cadena de conexión que permite cambiar el Host.
La idea era tan sencilla como aprovechar paneles de control de bases de datos que autentican mediante la construcción de una cadena de conexión contra la base de datos e inyectar en ella un nuevo atributo Data Source con una nueva dirección IP y un nuevo Puerto y luego simplemente analizar las respuestas del interfaz web para conocer el estado de ese puerto en esa dirección IP.
Figura 1: Mensajes de error en MyLittleAdmin para escanear una DMZ |
Esta misma idea se puede hacer con cualquier panel de acceso a bases de datos en los que se pueda elegir el hostname al que se quiere conectar, o se pueda inyectar en la cadena de conexión, sin importar si la base de datos es SQL Server ni si el código del panel de control es .NET o no.
Jugando un rato con esta idea di con Chive, un panel de control para bases de datos MySQL escrito en PHP que permite elegir en el login de conexión tanto el Host como el Puerto en el que está la base de datos que se quiere administrar desde el interfaz web.
Tocando un poco los parámetros, se puede ver que si el servidor existe pero el puerto, el usuario o la contraseña no son correctos, el resultado que se obtiene es un mensaje de error que informa de que no se ha conseguido hacer la conexión a la base de datos. Nada sospechoso al inicio.
Sin embargo, si el servidor que va en Host es un servidor que no existe, entonces se genera un error en la aplicación que no está controlado, y que solo puede resolverse a nivel de servidor web. Este mensaje permite por tanto, conocer si un servidor existe o no en la red interna.
Es decir, si el servidor web tiene configurado el cliente DNS apuntando al servidor DNS interno de la organización, entonces se podría hacer un escaneo de los registros usando un diccionario para ver cuál existe o no.
Figura 4: Mensaje de error cuando no se puede resolver el nombre de un Host |
Es decir, si el servidor web tiene configurado el cliente DNS apuntando al servidor DNS interno de la organización, entonces se podría hacer un escaneo de los registros usando un diccionario para ver cuál existe o no.
Con esas pruebas, busqué servidores que supiera que existían en la red haciendo un análisis del servidor DNS de la red con FOCA, y probé un servidor. Lo que me sorprendió es que si el servidor existía, pero no había posibilidad de conectarse a él, el error cambia, y se informa de que hay un problema de conexión de red.
Figura 5: Network is unreachable con esta cadena de conexión |
Ese mensaje de error es el típico de un problema de conectividad que se obtiene desde un equipo haciendo un ping cuando no hay conexión con el destino. Probando otro destinos, apareció también un Time-Out, por lo que ya tenemos dos de los tres mensajes que necesitamos para conocer la estructura de la red interna.
Figura 6: Time-Out al hacer una conexión a una dirección IP local |
La siguiente prueba, era evidente, buscar un servidor que existiera y probar un puerto abierto en ese servidor, pero en el que no hubiera una base de datos MySQL. Lo que elegí fue algo sencillo, conectar la cadena de conexión contra el servidor DNS de la organización por el puerto 53. El resultado fue un nuevo mensaje de error. Esto permite que se pueda conocer mucho más de la infraestructura de red y cómo están conectados los servidores.
Con estos mensajes ya es bastante sencillo hacer pruebas con direccionamiento interno de la red para saber qué puertos abiertos tienen los servidores. Esto siempre que el administrador del servidor web no haya fortificado los web servers para cortar cualquier mensaje de error, algo de lo que ya se ha hablado por aquí muchas veces.
En cualquier caso, baste este ejemplo para decir que cualquier panel de administración web que permita a un usuario no autenticado forzar una conexión a un servidor arbitrario puede terminar convirtiendo al panel de administración en una arma de destrucción masiva para terceros.
Saludos Malignos!
No hay comentarios:
Publicar un comentario