Nuevo Libro: "Hacking Web Applications: Client-Side Attacks" de @0xWord

Ayer ya se puso a la venta el nuevo libro de 0xWord, titulado "Hacking Web Applications: Client-Side Attacks" y escrito por el gran Enrique Rando, que ya tiene en su haber la participación en los libros de "Hacking con Buscadores", "Hacking Web Applications: SQL Injection" y "Hacking Web Technologies", además de decenas de artículos escritos por aquí.

Figura 1: Nuevo libro de 0xWord "Hacking Web Applications: Client-Side Attacks"

El texto se centra en algo fundamental en los test de intrusión, como son los Client-Side Attacks, y que tantas veces hemos visto como primera fase de un APT de muchos de los grandes incidentes de seguridad que llegan a los medios de comunicación.

Figura 2: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

En palabras del propio autor, el libro tiene la siguiente descripción:

"Usuarios, navegadores y aplicaciones web. Cada cual con sus propios problemas, formando un curioso triángulo. Personas que, como suele decirse, son el eslabón más débil de la ya de por sí frágil cadena de la seguridad. Navegadores cuya complejidad, siempre en aumento, los convierte en poco menos que nuevos sistemas operativos con fallos y características susceptibles de ser usadas con fines ilegítimos. Y programas que, de forma casi inevitable, presentan fallos. 

Por si fuera preciso empeorar las cosas, todo esto ocurre no en el Centro de Proceso de Datos, donde todo es más fácil de gestionar, sino en los puestos de usuario. Lejos del confortable control del personal informático, quizá a cientos de kilómetros gracias a la conectividad que Internet proporciona. Lejos del servidor de aplicaciones, sí, pero interactuando con la parte cliente de éstas. Lejos del servidor de bases de datos, pero cerca, muy cerca, de los datos y de la gestión que de ellos se realiza. 

Este escenario presenta sus propias vulnerabilidades y sus ataques característicos. Quizá los más conocidos sean los de Cross Site Scripting, sobre los que tanto se ha hablado y cuyas repercusiones no siempre se ha sabido explicar. Pero hay otros, menos populares pero igual de devastadores, como Cross Site Request Forgery o Clickjacking. O técnicas como las de Typosquatting, abuso de nombres de dominio internacionalizados o Tabnabbing. O manipulaciones de la interfaz de usuario de los navegadores y de las características, cada vez más avanzadas, que éstos ofrecen gracias a las APIs asociadas a HTML 5. O prácticas habituales en el desarrollo de aplicaciones web que pueden tener consecuencias inesperadas. 

Este libro trata de esos “enemigos olvidados”, presentándolos a través una serie de pruebas de concepto que ponen en evidencia no sólo lo fácil que puede llegar a ser explotarlos sino también cuán graves que pueden ser sus efectos."

Pero para que veas los detalles completos, tienes el índice del libro subido a SlideShare.

Figura 3: Índice el Libro "Hacking Web Applications: Client-Side Attacks"

Éste es el libro número 50 de 0xWord, un hito para nosotros, así que probablemente hagamos algún acto en Madrid (o en Móstoles) para celebrarlo, en el que podáis estar con muchos de los escritores para compartir experiencias y charlas.

Saludos Malignos!

Big Data Security Tales: Los Known-Bugs en WSO2 Carbon Server #BigData #Pentesting

Por supuesto, el software que se utiliza en los entornos de Big Data es susceptible de contener fallos de seguridad que van siendo descubiertos a lo largo del tiempo. La gestión de las actualizaciones es un proceso fundamental que debe tomarse en serio. A veces esta gestión no es trivial, y la ventana de oportunidad para explotar un bug conocido (Known-Bug) puede ser grande, por lo que hay que prestar especial cuidado a las listas de seguridad, y tener los procesos de gestión de parches bien engrasados.

Figura 1: Los known-bugs en WSO2 Carbon Server Technologies

En la conferencia de Big Problems with Big Data que os dejé hace unos artículos, el ponente ponía el ejemplo de cuál es el proceso de aplicación de un parche de, por ejemplo, una librería como JQuery en un entorno de Big Data. 

El ciclo de vida de un Known-Bug

El bug es descubierto y publicado en JQuery que después se aplica a la siguiente distribución de Django. Este framework se utiliza para construir Apache HUE, por lo que en la siguiente compilación en la que se compruebe que la nueva versión de Django no rompe nada se aplicará, con la consiguiente corrección del bug que había en JQuery. Apache HUE saca su nueva versión, y esta debe ser empaquetada en la nueva compilación de Apache Hadoop, por lo que para que el known-bug de JQuery esté parcheado en la versión de Apache HUE que acompaña tu distribución de Apache Hadoop hay que esperar un paso más.

Figura 2: Ciclo de vida de actualizaciones de un Know-Bug

Esto, por supuesto, se alarga si has utilizado una distribución como Cloudera o HortonWorks que deberán hacer su nueva release en la que haya probado que la nueva distribución de Apache Hadoop que lleva la nueva versión de Apache HUE compilada y probada con la nueva versión del framework de DJango que incorpora la nueva versión de JQuery parcheada no rompe nada. Y después deberá instalarlo el cliente si ha decidido ir a un entorno de Big Data basado en una instalación OnPremise, o en Cloud pero gestionada por él mismo.

Esto por supuesto no es siempre un proceso tan lento, y cuando un bug de seguridad es crítico se acortan los plazos al máximo, pero aún así hay una ventana temporal de explotación de known-bugs muy grande. Por eso es especialmente importante estar al día de los posibles bugs que puedan ser descubiertos en los programas que usas en tu instalación de Big Data. 

Known-Bugs en WSO2 Carbon Server

En el caso de WSO2 Carbon Server, recientemente se publicaron en las listas de seguridad una serie de ellos que deben tenerse en cuenta. Lo curioso es que al ir a mirar el histórico de los Security Advisories de todos los productos de la familia, solo pude localizar Security Advisories en 2016 y solo los que había leído en la lista de contactos.

Figura 3: Security Advisories en WSO2

Sin embargo, si entramos en la lista de parches disponibles sí que podemos ver todo el histórico de parches de seguridad para todos los productos, y ahí podemos revisar si en una determinada instalación existen o no vulnerabilidades.

Además, en los productos de WSO2 es extremadamente sencillo descubrir la versión de un determinado producto ya que sin necesidad de tener iniciada una sesión se puede acceder al botón de "About" y conocer qué versión exacta es la que está instalada. 

Figura 4: Versión exacta de una instalación de WSO2 Identity Server

Una vez conocida la versión, revisar la lista de parches da exactamente la lista de known-bugs que se tiene en esta instalación concreta. Para nuestro sistema de pentesting persistente Faast esto es perfecto ya que nos permite avisar a nuestros clientes rápidamente cuando una versión desactualizada es detectada.

Figura 5: Known-Bugs en la versión 5.0.0 de WSO2 Identity Server

Gracias a ello es sencillo localizar versiones inseguras, pero también para la propia organización detrás del software, por lo que sería sencillo localizar clientes a los que hacer un aviso de seguridad personalizado con el objeto de ayudarles a estar más seguros.

PoC con WSO2 Data Services Server

Una de las versiones inseguras de WSO2 Data Services Server permite la ejecución de código en Java desde la consola de Tools, a la que se puede acceder sin necesidad de haberse autenticado en la plataforma. Desde esa misma consola es posible ver cómo cuando se intenta hacer una conexión, la página web pone el código que esta ejecutando.

Figura 6: Se muestra el comando y el mensaje de error

Tener este panel, expone en primer lugar los servidores de la DMZ para hacer un ataque de XSPA, pero también es vulnerable el interfaz con un bug de HTML Injection que permite hacer cosas como este Ataque de David Hasselhoff.

Figura 7: Un HTML Injection con un homenaje de Ricardo Martín al David Hasselhoff Attack

Y si además hay una gestión de credenciales insegura en alguna de las bases de datos de la DMZ y se llega a un servidor como este con un usuario sa de Microsoft SQL Server sin contraseña, sin necesidad de haberse conectado al servidor WSO2 Data Services Server es posible acceder a ficheros del servidor viendo el código en el mensaje de error.

Figura 8: Un LFI en el mensaje de error

Al final, la gestión de parches es algo fundamental, y es verdad que el número de aplicaciones y tecnologías que suele tener un entorno de Big Data en una empresa es grande, pero si no se hace esa gestión de forma robusta y planificada al igual que se hace con el resto de las tecnologías, explotar un "Known-Bug" va a ser muy sencillo para un atacante.

- Big Data Security Tales: ¡Vigila que tu MongoDB no le de tus datos a cualquiera! (Level 100)
- Big Data Security Tales: Cómo funcionan las MongoDB Injection
- Big Data Security Tales: MongoDB y Cassandra (Level 101)
- Big Data Security Tales: Apache Hadoop expuesto por no configurar HUE (Level 102)
- Big Data Security Tales: Django en HUE en modo DEBUG y con Directory Listing (Level 103)
- Big Data Security Tales: Las Interfaces de acceso al HDFS
- Big Data Security Tales: Apache Amabari Default Admin
- Big Data Security Tales: WSO2 Carbon y la ayuda para el Login
- Big Data Security Tales: Los Known-Bugs en WSO2 Carbon Server
- Big Data Security Tales: Kibana & ElasticSearch objetivos del ransomware
- Big Data Security Tales: Apache CouchDB Relax... o no
- Big Data Security Tales: Riak NoSQL Database

Saludos Malignos!

Magento Repair Tool: Un XSPA a quitar de tu e-Commerce

El framework Magento es uno de los entornos Open Source más populares dentro del mundo del e-Commerce. Está detrás de una gran cantidad de tiendas en Internet y es fácil toparse con él en una auditoría de seguridad web. En el pasado os había hablado de él cuando me topé con Magento Chek, una pequeña utilidad de comprobación del estado de configuración del framework que podría ser muy útil para hacer una pentesting a la tecnología web, y hoy os vengo a hablar de otro.

Figura 1: Magento Database Repair Tool. Un XSPA a quitar de tu e-Comerce

En esta ocasión se trata de una herramienta especial para corregir un error en la instalación del servidor. En concreto se llama Magento Database Repair Tool, y es una utilidad para troubleshooting en caso de que la base de datos se quede corrupta por alguna de las situaciones explicadas en la documentación de dicha herramienta.

Figura 2: Cuándo usar Magento Database Repair Tootl

Localizarla en Internet, como me apuntó mi amigo rootkit, no es nada complicado. Basta con usar un dork como éste que se ve en la imagen para que, con un poco de Hacking con Buscadores lleguemos a muchos servidores con ella instalada.

Figura 3: Dork para localizar Magento Database Repair Tool en Google.

Una vez que tenemos esta herramienta, es fácil darse cuenta que puede ser utilizada para hacer ataques de XSPA (Cross-Site Port Attack), ya que con poner en la dirección del servidor con la base de datos corrupta la dirección IP y el puerto a escanear, tenemos los mensajes de error que necesitamos para diferenciar un puerto abierto o un puerto cerrado.

XSPA: Escaneado de puertos con Magento Database Repair Tool 

Si el puerto está cerrado, el mensaje de error que obtenemos (después de esperar unos segundos) nos dirá se ha perdido la conexión con el servidor y que no se ha podido hacer nada.

Figura 4: Puerto cerrado. El mensaje informa de "Lost Connection" 

Por el contrario, si el puerto está abierto, el mensaje nos dirá que no se ha podido conectar a la base de datos MySQL que supuestamente debería estar allí. 

Figura 5: Puerto abierto. El mensaje informa de "Can´t connect to MySQL"

Por supuesto, si en ese puerto nos encontráramos con una base de datos MySQL, el mensaje de error volvería a cambiar a un Login Failed que nos indicaría que no tenemos credenciales adecuadas para conectarse con el servidor de bases de datos (y si las tenemos, aún mejor).

Escaneo de DMZ y fortificación de Magento

Con estos mensajes de error, es fácil automatizar un ataque de XSPA para escanear cualquier servidor de Internet o de la DMZ, tal y como se ve en este equipo en el que descubrimos una dirección IP interna con un puerto de Telnet abierto.

Figura 6: Servidor en la DMZ con puerto 23 abierto

Al final, esta herramienta que se instala aparte, no debería estar dentro del path de publicación del sitio web en Internet, así que si la tienes, restringe el acceso a Magento Database Recovery Tool con una lista de control de acceso.

Figura 7: Configuración y uso de Latch en Magento Community

Para terminar, solo como recordatorio, acuérdate de quitar (o restringir su acceso) a Magento Check y añade para fortificar aún más tu entorno Latch a Magento que desde el año pasado está disponible una integración de Latch con Magento Community que tienes disponible.

Saludos Malignos!

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!

WordPress: Time-Based XSPA (Cross-Site Port Attack) #WordPress #XSPA #Pentest

Si tienes un WordPress funcionando en tu web, seguro que has ido a través del proceso de instalación que se hace direcatmente desde el propio servidor. Invocando el script de install.php llegas a setup-config.php y ahí le pones los datos necesarios para realizar la conexión al motor de bases de datos MySQL y listo. A comenzar el proceso de puesta en marcha de tu WordPress.

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

Sin embargo, como descubrió mi amigo de los dorks "rootkit", en Google se pueden encontrar muchos de estos ficheros con instalaciones a medias, es decir, que no están completadas y por tanto el servidor deja jugar con ellas, lo que puede ser un problema para el servidor web que dejó el WordPress a medio instalar y una ventaja para un atacante en la red.

Figura 2: Ficheros de configuración de WordPress indexados en Google

Los scripts de install.php y setup-config.php son dos de los archivos que se buscan siempre en los procesos de fuzzing a un servidor web, ya que puedes acabar topándote con algo turbio y, si tienes un WordPress, lo mejor es que los quites o los protejas con una ACL. Si la instalación está realizada y se invoca uno de estos scripts - y están aún en el servidor -, el resultado que se obtendrá es algo como esto.

Figura 3: Instalación de WordPress realizada pero script aún en el servidor web

No obstante, aunque esté hecha correctamente y no se pueda lanzar el asistente, lo recomendable es quitarlos o protegerlos como ya he dicho, ya que pueden generar problemas eventualmente en el futuro por culpa de una credencial perdida o robada.

Figura 4: Setup-config.php en el servidor de WordPress

Si das con un servidor en el que el asistente no se ha ejecutado aún, es decir, se han copiado los scripts pero no se ha hecho la instalación, entonces llegarás a una pantalla en la que puedes configurar los patrones de conexión a la base de datos.

Figura 5: Un panel de setup de WordPress expuesto en Internet

Si has estado atento a la serie que le he dedicado el mes pasado a los paneles de gestión de las bases de datos - como Vty PHP, SIDU, Chive o MySQLDumper -  recordarás que los ataques de XSPA (Cross-Site Port Attack) son de lo más común cuando tienes un panel que intenta conectarse a una base de datos, que es al final lo que intenta hacer este script tal y como se puede ver en el código.

Figura 6: Código de conexión a la base de datos en el script de Setup-config.php de WordPress

Es decir, que desde ese panel, jugando con los puertos y las direcciones IP de los servidores se puede obtener un resultado u otro cuando el puerto está abierto o cuando el puerto está cerrado. Y esto se puede hacer también con este panel.

Time-Based XSPA [Cross-Site Port Attack]

Lo cierto es que el mensaje de error que se obtiene es siempre el mismo, pero prestando un poco de atención es posible detectar que el tiempo de respuesta es totalmente distinto cuando el puerto está abierto o está cerrado, por lo que que se podría escanear la DMZ o cualquier servidor de Internet haciendo unas mediciones de tiempo en las respuestas. 

Figura 7: Error que se obtiene cuando no se puede conectar a la base de datos

Para este ejemplo he elegido la web de Eleven Paths donde está abierto el puerto 80 y el puerto 443, pero no tiene abiertos los puertos 4444 ni el puerto 23. Como se puede ver en la imagen superior el mensaje de error será siempre el mismo, pero si lo llevamos a Burp y lo metemos en el Repeater podremos ver los cambios en los tiempos. 

Figura 8: El tiempo de respuesta al intentar conectar al puerto 443 es muy alto

En la imagen anterior se ve que para un intento de conexión al puerto 443 hemos obtenido un tiempo de respuesta muy alto mientras que para el puerto 4444 en la imagen inferior hemos obtenido un tiempo de respuesta infinitamente más corto.

Figura 9: El puerto 4444 da una respusta muy corta en tiempo. Está cerrado.

Si repetimos el mismo experimiento con el puerto 80 y con el puerto 23 veremos un comportamiento en los tiempos similares.

Figura 10: Tiempo de respuesta al intentar al puerto 80 es muy alto

Es decir, un retardo largo de tiempo cuando el puerto está abierto y un retardo corto cuando el puerto está cerrado.

Figura 11: Tiempo de respuesta muy corto. El puerto 23 está cerrado

Al final los tiempos dependen de muchos factores. Del tráfico de la red, del comportamiento de los firewalls de salida y entrada tanto del servidor WordPress que se está utilizando para escanear como del servidor que está siendo escaneado, y por supuesto de la configuración de los servicios y protocolos, que pueden generar bloqueos en muchos puntos de la red. 

Figura 12: Cuando el puerto está abierto se hace el 3-Way Handshake

Pero al final, si el puerto está abierto y se hace el 3-Way Handshake y hay algún servicio esperando paquetes de un determinado tipo el tiempo de respuesta será distinto que si se hace un envío del RESET cuando el puerto esté cerrado y nadie espera nada ahí.

Figura 13: El puerto 2728 está cerrado y se reciben los RESETS

Artículos sobre seguridad en WordPress: Toma nota

En cualquier caso, si tienes un WordPress, ten presente que está en el punto de mira de los atacantes en Internet, así que fortificalo todo lo que puedas. Aquí te dejo una lista de artículos de seguridad en WordPress que te pueden interesar:

- Fortificar WordPress frente ataques de fuerza bruta
- Hackear WordPress con ataques de NetWork Packet Manipulation

- WordPress: Fortificación de la comunicación con MySQL para evitar ataques de Network Packet Manipulation.
- WordPress: XSS en el plugin de WP-UserAgent
- WordPress Troyanizados roban usuarios y contraseñas
- Cómo robarle las contraseñas a los administradores de WordPress con un ataque XSS haciendo uso de Unfiltered HTML.


Figura 14: Proteger WordPress con Latch en 10 minutos
- WPHardening: Automatizar la fortificación de WordPress
- Ataques para listar los plugins de WordPress
- Buscar exploits para WordPress
- WordPress: SQL Injection en plugin de Scarcity Builder
- Agrupar el control de varios WordPress bajo un solo Latch
- WordPress: Ten cuidado con el cacheo de los borradores
- WordPress: Drama de malware por un bug de RFU en MailPoet
- WordPress: Command Injection en plugin TimThumb
- Registrate en WordPress y evalúa su seguridad

Saludos Malignos!

Vty PHP: Otro WebGUI para MySQL también con bugs

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.

Figura 1: Vty PHP: Otro Web GUI para MySQL también con bugs

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.

Figura 3: Inyección de JavaScript en el User Name

El resultado es que el mensaje de error inyecta el código JavaScript en el usuario sin filtrar los datos de entrada.

Figura 4: Ejecución de código inyectado en el mensaje de error

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.

Figura 5: El servidor no tiene ningún servicio Telnet abierto

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.

Figura 6: El servidor tiene un servicio FTP abierto en el puerto 21

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.

Figura 7: Puerto abierto y además hay un servidor MySQL

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:

- 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.

Saludos Malignos!

SIDU: Un Database Web GUI para escanear servidores

Este domingo por la noche no conseguía dormirme con la vuelta al trabajo por lo que aproveché para revisar algunas cosas en Internet. Esta vez le tocó el turno a los ataques a cadenas de conexión de bases de datos, así que, como ya hiciera tiempo atrás con Chive, con SQL Web Data Administrator, MyLittleAdmin, MyLittleBackup, ASP.NET Enterprise Manager o las aplicaciones Citrix, busqué algún nuevo panel de control de bases de datos por medio de un interfaz web, y di con SIDU, una herramienta que permite gestionar motores de bases de datos MySQL, Postgres, SQLite y CUBRID.

Figura 1: SIDU - Un DB Web GUIO con bugs de XSPA

Encontrar la herramienta publicada en Internet no es difícil. Hay muchas organizaciones que tienen este tipo de aplicaciones en sus sitios web, para poder administrar sus bases de datos, y ésta, en concreto, viene con muchas posibilidades.

Figura 2: Lista de bases de datos a las que se puede conectar para lanzar comandos SQL

Como se puede ver, permite hasta Microsoft SQL Server, por lo que podría ser una víctima propicia para los ataques de Connection String Parameter Polution, pero lo cierto es que necesita un driver especial en los entornos en los que mirado. Pero sí que se pueden hacer otras cosas, como vamos a ver.

Remote XSPA (Cross-Site Port Attacks)

Estas herramientas son propensas a la vulnerabilidad de XSPA (Cross-Site Port Attacks). Al final, una cadena de conexión a una base de datos permite introducir una dirección IP o nombre de dominio de un servidor de bases de datos y un puerto, por lo que si los mensajes de error no han sido controlados, alguien podría manipular estos servicios para valores para escanear servidores. Por supuesto, esta escaneo se puede hacer a tres niveles distintos:

1.- Escanear puertos del propio servidor de bases de datos: Bastaría con manipular el valor del puerto con respecto a localhost. 

2.- Escanear puertos de cualquier servidor de Internet: Esto se podría realizar si el firewall de la infraestructura de red donde está montado el servidor web que hospeda a SIDU no controlar las conexiones de salida. 

3.- Escanear la DMZ: Esto se podría hacer si se averigua la dirección IP local del servidor en el que está hospedado SIDU.

En la última versión, en la 5.3 de SIDU, la vulnerabilidad de XSPA está presente, y basta con hacer unas sencillas pruebas para comprobarlo. En este caso vamos a ver como un puerto está abierto o cerrado según los mensajes de error. Para ello he elegido la web de un diario.

Figura 3: El puerto está cerrado

Cuando el puerto está abierto, tal y como se puede ver arriba, el mensaje de error que se obtiene es un Connection Time-Out, esto es así porque la conexión TCP nunca se abre.

Figura 4: El puerto está abierto

Por el contrario, cuando el puerto está cerrado, el mensaje que se obtiene es completamente distinto. En este caso un "MySQL Gonne Away", porque el puerto TCP se abre pero está esperando el desafío de login de MySQL que nunca llega.

Figura 5: El puerto está abierto y es un MySQL

Si el puerto estuviera abierto, y además hubiera un servidor MySQL en él, se obtendría aún un tercer mensaje de error, informando de que el usuario y la contraseña son incorrectos, con lo que tendríamos el bug de XSPA completo.

SIDU PHP Info: Local IP disclosure

Para poder hacer lo mismo en el servidor local, bastaría con cambiar el puerto con localhost, pero si lo que deseamos es hacerlo con la DMZ, entonces hay que averiguar cuál es la dirección IP de la red local con que se ha configurado el servidor web que hospeda a SIDU. Esto, gracias al propio SIDU es una tarea bastante sencilla.

Figura 6: Conexión a una base de datos SQLlite que no existe

Una de las cosas que trae SIDU, es una conexión para lanzar consultas a bases de datos SQLite que no necesita usuario ni contraseñas. Cuando seleccionas esa opción, no se valida si la base de datos existe o no, así que puedes poner lo que quieras en ella y llegar al panel interno creado para lanzar consultas SQL.

Figura 7: En el menú interno hay acceso a un PHP Info

Lo mejor de todo es que, entre las opciones que han puesto en el menú se encuentra la de lanzar un PHP Info, tal y como se ve en la pantalla.

Figura 8: Acceso a la dirección IP local del servidor que hospeda SIDU

Y por supuesto, con esto llegaríamos a la dirección IP local del servidor web en el que se encuentra hospedado SIDU. Algo bastante sencillo de hacer para cualquier visitante. 

DMZ XSPA (Cross-Site Port Attacks)

Una vez que se tiene la dirección IP local del servidor web, se puede comenzar a escanear el segmento completo, haciendo un barrido a toda la red - en este caso de tipo C - para localizar todos los servidores que allí se encuentran.

Figura 9: Escaneo por puertos de MySQL del segmento de red

Como habría que escanear todos los puertos de todos los servidores, lo suyo sería buscar los well-known más comunes, como el 80 de los servidores web, o el propio puerto de los servidores MySQL de la red.

Figura 10: Connection String Attacks @ DefCON 18

Este tipo de herramientas de administración de bases de datos, donde delegan toda la seguridad en el establecimiento de conexiones, tienen habitualmente los mismos problemas. Os dejo arriba la charla de Connection String Attacks que dimos en DefCON por si te apetece repasar los fallos más habituales, así como los ataques que se pueden hacer.

Saludos Malignos!