Time-Based XSPA (Cross-Site Port Attack) en DBKISS

No hace demasiados días os hablé de un bug de Time-Based XSPA en los scripts de instalación de WordPress, y hoy os quiero hablar de otro caso similar con un WebGUI para administrar motores de bases de datos MySQL y PostgreSQL que se llama DBKiss. Es un bug curioso que en este caso se explota bien con el driver de PostgreSQL. Os lo explico en este post.

Figura 1: Time-Based XSPA (Cross-Site Port Attack) en DBKiss

Los bugs de XPSA (Cross-Site Port Attack) se basan en la explotación de un SSRF (Server-Side Request Forgery) mediante la que un atacante fuerza a la aplicación a realizar una determinada conexión a un servicio que se encuentra en un servidor corriendo por un puerto para poder así escanear los puertos de un servidor objetivo. En este caso, aprovechándonos de que la aplicación vulnerable es un WebGUI que muchos usuarios implanta en sus sitios web para gestionar la base de datos MySQL de WordPress o de cualquier otro CMS, basta con manipular los datos de la cadena de conexión.

Figura 2: Un DBKiss gestionando el MySQL de un WordPress

Hay que tener cuidado con publicar estos scripts a la ligera, pues muchas veces son herramientas en proceso de desarrollo o con vulnerabilidades conocidas. Basta con ver el código fuente de DBKiss para darse cuenta de que aún le quedan muchas cosas que corregir a esta herramienta antes de poder instalarse y publicarse a Internet, ya que se estarían asumiendo muchos riesgos.

Figura 3: Cosas aún por solucionar en los comentarios de DKiss (XSS y CSRF)

El peligro de poner estos scripts vulnerables a estas técnicas de XSPA es que el servidor objetivo al que se quiere escanear puede estar dentro de la DMZ, es decir, con direccionamiento en la red local, ya que basta con que el servidor web tenga conectividad con ellos. Con un aplicación web vulnerable a XSPA en un servidor de la DMZ, un atacante podría hacer un mapa detallado de todos los servidores y todos los puertos que estos tienen abiertos.

Time-Based XSPA en DBKiss

En el caso de los ataques de Time-Based XSPA, el atacante mide el tiempo de respuesta de cada conexión para saber si es un resultado que indica que el puerto está abierto, o un un resultado que indica que el puerto está cerrado. Para esto, en las cadenas de conexión a bases de datos el bug se aprovecha de que la configuración de la conexión no tenga un Time-Out bien configurado que evite que el atacante pueda medir las diferencias temporales en las respuestas sin error.

Figura 4: Con la conexión al puerto 80 usando el driver de PostgreSQL el tiempo de respuesta es corto

Como se puede ver, si forzamos una conexión con DBKiss contra un servidor con un puerto abierto, en este caso contra el puerto 80 de la web de Eleven Paths utilizando el driver de PostgreSQL, podemos ver que se obtiene un tiempo de respuesta muy corto.

Figura 5: Con el puerto cerrado el tiempo de respuesta es muy alto y salta el Time-Out por defecto

Si hacemos lo mismo contra un puerto que esté cerrado, lo que pasamos a obtener es un tiempo de respuesta muy largo que llega a generar un Time-Out en la web, es decir, que el tiempo configurado por defecto de Time-Out en la conexión de la base de datos es mayor que el Time-Out configurado en el servidor web.

Figura 6: Hay que configurar el Time-Out en la conexión a PostgreSQL para evitar este leak

Al final, estas vulnerabilidades abren la captura de información de la infraestructura de una organización a un atacante que en un APT será de gran utilidad para poder planificar el siguiente paso del ataque. Cuidado con lo que publicas en tu servidor web.

Saludos Malignos!