Como sabéis últimamente he estado repasando la seguridad de algunos WebGUIs para SGBDs mirando a ver si hacían los deberes en seguridad o si podrían ser un autentico problema tenerlos instalados en un sitio web público. Hoy le toca el turno al último de los que he mirado - por ahora - y he de decir que tampoco sale muy bien parado. En su defensa debo remarcar que los creadores del WebGUI para MySQL del que habla este artículo, de nombre Vty PHO, parece que hace tiempo que dejaron de darle soporte, así que si lo has instalado será bajo tu responsabilidad.
En este caso VTY es un gestor web para MySQL - aunque en pruebas parece que estaban también trabajando para MS SQL Server - escrito en PHP y basado en un único script llamado Vty.php. Tampoco tiene gestor de usuarios y contraseñas para la herramienta y su funcionamiento es tan sencillo como un panel de conexión a MySQL con el que se valida al usuario, y luego una serie de opciones para manipular los objetos de las bases de datos MySQL que haya almacenados en el SGBD.
Jugando un poco con él, rápidamente se puede ver que el número de bugs que tiene es alto y que tenerlo publicado a Internet no es una buena idea. Aquí van algunos ejemplos.
1.- Info Leak: MySQL User
Con el portal de Vty.php, haciendo una conexión desde Internet sin poner usuario y contraseña, la cadena de conexión que usa Vty.php intenta realizar un acceso al motor MySQL con el usuario que se configura en el script por defecto, por lo que es fácil saber el nombre del usuario de MySQL con el que se gestiona esta herramienta.
Figura 2: Sin introducir ningún usuario en el formulario, el usuario que utiliza Vty.PHP en la conexión a MySQL es mostrado en el mensaje de error. |
Como se puede ver, se accede al nombre del usuario de gestión, lo que podría ayudar a un atacante a saber qué siguientes pasos deben darse para conseguir el objetivo final de un ataque. De momento, se conoce el nombre del usuario de MySQL.
2.- XSS en panel sin conexión
No solo el panel de login permite a un atacante acceder al nombre del usuario de MySQL, sino que además el formulario no filtra correctamente los datos en backend y cuando se imprime el mensaje de error se puede inyectar código JavaScript, por lo que un atacante podría realizar un ataque de XSS tal y como se ve en la imagen.
El resultado es que el mensaje de error inyecta el código JavaScript en el usuario sin filtrar los datos de entrada.
Si esta aplicación se cuelga dentro del dominio principal y la política de seguridad de las cookies no está fortificada, un atacante podría utilizar este bug de XSS para hacer ataques de robo de sesión a los usuarios del sitio principal o para realizar ataques de phishing, etc...
3.- XSPA (Cross-Site Port Attack)
Por supuesto, como en otros paneles web de administración de páginas bases de datos, los mensajes de error se pueden utilizar para, cambiando la dirección del servidor de MySQL al que nos queremos conectar y modificando el puerto de conexión, escanear un servidor - tanto de Internet como de la DMZ - y averiguar qué puertos tiene abiertos. Si el puerto está cerrado obtenemos un mensaje como el que sigue.
Si el puerto está abierto, el mensaje de error es completamente distinto y como se puede ver se establece la conexión inicial aunque luego el panel de gestión no puede negociar la conexión al motor de MySQL.
Y si, el puerto está abierto y hay un servidor de MySQL, el mensaje de error es el que ya conocemos del punto 1. Es decir, no se puede establecer conexión con ese usuario.
Este es un error muy común que ya hemos visto en todos los paneles de administración web para SGDB, así que si se decide usar una de estas herramientas lo mejor es no publicarla para todo el mundo en Internet.
Otros bugs en otros Web Database GUI
Los gestores de bases de datos basados en entornos web son difíciles de asegurar al 100%, y ya hemos visto en el pasado problemas en una buena cantidad de ellos. Si tienes uno de estos gestores, lo recomendable es que limites su acceso por medio de una protección extra basada en el servidor web, en el firewall o en el acceso solo local. S´lo como recordatorio, os dejo la lista de gestores de bases de datos de los que se ha hablado por aquí y los bugs que se han encontrado en ellos:
Saludos Malignos!
Los gestores de bases de datos basados en entornos web son difíciles de asegurar al 100%, y ya hemos visto en el pasado problemas en una buena cantidad de ellos. Si tienes uno de estos gestores, lo recomendable es que limites su acceso por medio de una protección extra basada en el servidor web, en el firewall o en el acceso solo local. S´lo como recordatorio, os dejo la lista de gestores de bases de datos de los que se ha hablado por aquí y los bugs que se han encontrado en ellos:
- MyLittleAdmin: CSPP -> XSPA, Login ByPass, Credential Leakage
- WebDataAdministrator: CSPP -> XSPA, Login ByPass, Credential Leakage
- ASP.NET Enterprise Manager: CSPP -> XSPA, Login ByPass, Credential Leakage
- MyLittleBackup: Data Leakage, CSPP -> XSPA, Login ByPass, Credential Leakage
- Chive: XSPA
- SIDU: XSPA, Server Data Leakage (info.php)
- MySqlDumper: XSPA, Login ByPass, Credential Leakage, Unsafe Data Manipulation, Server Data Leakage
- Vty PHP: XSPA, XSS, User Info Leak
Como veis, estas herramientas suelen ser especialmente peligrosas si están expuestas a Internet sin ningún control extra en su acceso. Lo suyo es que la pongas en tu red local y con acceso remoto vía VPN.
Y una vez más, excelente investigación para tener en cuenta en sistemas.
ResponderEliminarSaludos
Pues nada, usare el menos "malo" XD.
ResponderEliminar