Nuestro nuevo libro de "Hacking Web Technologies" @0xWord #pentesting #hacking

Hoy estoy contento, pues después de varios meses de trabajo ya esta disponible desde hoy un nuevo libro de 0xWord en el que he podido trabajar con grandes amigos. Haciendo equipo con Enrique Rando, Pablo González, Ricardo Martín y Amador Aparicio hemos escrito un libro orientado al pentesting y hacking de tecnologías web, y desde hoy lo puedes comprar: Hacking Web Technologies

Figura 1: Nuestro nuevo libro de "Hacking Web Technologies" @0xWord

El libro está centrado en explotar diferentes vulnerabilidades de los sistemas basados en tecnologías web, sin tocar para nada las técnicas de SQL Injection, de las que ya sabéis que escribimos otro libro Enrique Rando y yo. En éste libro nos centramos en otros tipos de ataques como son, por ejemplo, los ataques a las tecnologías LDAP, ataques a Connection String, los ataques de Info Leaks, las técnicas de Local File Inclusion o XPath Injection. 

Figura 2: Libro de Hacking Web Technologies

Además, en el libro se tocan temas como el uso de herramientas de auditoría web como ZAP Proxy de manera profesional, las técnicas de ataque de PHP Object Injection o la explotación de ataques de MongoDB Injection. El índice del libro lo he subido a SlideShare para que lo podáis ver en detalle.

Figura 3: Índice del libro "Hacking Web Technologies"

Este es el libro número 40 de la colección de libros de 0xWord, y por ahora está dentro ya del pack de Colección Completa, aunque probablemente lo incluyamos pronto en algún pack. Puedes comprarlo online y solicitarlo a nuestros distribuidores en latinoamérica para que te llegue lo antes posible.

Saludos Malignos!

MySqlDumper: Un script de backup que no debes publicar

La noche antes de mi viaje a Ecuador me dio uno de esos días de estrés en los que me cuesta dormir, así que aprovechando la tranquilidad de la noche decidí ponerme a mirar algún software de esos que tengo marcados como "sospechosos" en mi lista de tareas. Estos programas los marco para que luego todo lo que encuentre se convierta en un plugin de auditoría de nuestro sistema de Pentesting Persistente Faast. En esta ocasión le tocó el turno a MySqlDumper.

Figura 1: MySqlDumper. Un script de backup que no debes publicar.

MySqlDumper se define como un script de backup y restore para bases de datos MySQL basado en un interfaz web. Es importante entender esto, pues no es una plataforma de administración por lo que no hay ni proceso de login. Es decir, MySqlDumper no tiene usuarios, ni roles, ni nada parecido. Se configura la conexión a la base de datos y se pueden hacer copias de seguridad, restaurar bases de datos, consultar tablas, crear tablas, o consultar variables de estado de la base de datos y el servidor en general.

Figura 2: Scripts de MySqlDumper a copiar en el servidor web

Dicho esto, si publicas el script en tu web y lo configuras, cualquiera que lo encuentre podrá hacer lo que le de la gana con tus bases de datos, así que más vale que no lo hagas si no quieres tener problemas serios de seguridad y si lo usas que sea solo con acceso local o restringido por un .htaccess a tus servidor.

El usuario y la contraseña de MySQL para todo el mundo

Los scripts más importantes que hay que conocer de esta herramienta son main.php, sql.php, filemanagement.php e install.php. El último de ellos es el que configura la conexión a la base de datos y que, para que sea cómodo este script, una vez configurada la conexión, las credenciales de acceso a MySQL quedan cacheadas.

Figura 3: La instalación de MySqlDumper es completa y el usuario y la password están cacheados

Así, si estos scripts, que habitualmente se configuran en el directorio /msd/ están bien configurados en el servidor, lo que podremos ver es que el usuario y la contraseña aparecen en este mismo script si se ha terminado el proceso de instalación de MySqlDumper en este sitio web.

Figura 4: Accediendo al código fuente de install.php se pueden ver el usuario y la contraseña de MySQL

Solo deberemos echar un vistazo al código fuente para tener las credenciales necesarias para acceder a la base de datos de MySQL que hay corriendo en este servidor, así que perfecto para un auditor de seguridad que con solo consultar este fichero ya se lleva el acceso al SGDB.

Acceso a información del sistema

Si se ha completado la instalación del script, como he dicho al principio, MySqlDumper no tiene ninguna gestión de usuarios, por lo que para un atacante remoto será tan sencillo como solicitar el script main.php y tener acceso a todas las opciones disponibles que van, desde hacer backup y restore con filemanagement.php, ejecutar comandos con sql.php o incluso acceder a información del sistema operativo por medio de un PHP Info, tal y como se ve en la pantalla.

Figura 5: Acceso a main.php donde hay un PHP-Info enlazado

También se puede acceder a las variables de MySQL y conocer el estado de todas las variables del sistema de las que os hablé en el artículo de "Cómo sacar partido a las variables del sistema en un ataque de SQL Injection a MySQL". 

Figura 6: Accediendo a sql.php y seleccionando la tabla de Global_Variables de Information_Schema
se puede acceder a todas las variables del sistema

En este caso, como podéis ver, el hostseguro no queda tan seguro solo por el hecho de haber instalado este script.

Acceso a bases de datos y tablas de WordPress o Joomla!

Por supuesto, desde la opción de main.php se puede acceder a todas las bases de datos y a todas las tablas, por lo que es sencillo buscar las credenciales de los sitios web que se encuentren alojados en este motor de MySQL al que se ha conectado MySqlDumper.

Figura 7: Una tabla de usuarios y contraseñas de un sitio web con credenciales en texto claro

Pero si en la base de datos de MySql se ha configurado el repositorio de un framework como WordPress, también se puede acceder, sin necesidad de vulnerar ninguna medida de seguridad, a las tablas que almacenan los usuarios y datos de WordPress.

Figura 8: Un WordPress en un MySql con MySqlDumper configurado

O, en el caso de que hubiera otro framework, pues a sus tablas de credenciales. En este caso un framework Joomla! alojando en un SGBD MySql al que se le ha conectado MySqlDumper.

Figura 9: Un joomla en un MySql con un MySqlDumper configurado

Instalación no completada: Ataques XSPA (Cross-Site Port Attacks)

En el caso de que no se haya completado la instalación, al acceder al script de main.php podemos encontrarnos con un error como el que sigue, en el que se puede ver que las credenciales de acceso de MySql no son correctas.

Figura 10: Instalación de MySqlDumper incompleta

Aún así, accediendo al script install.php y seleccionando el idioma se llega a una pantalla en la que se pueden hacer ataques de XSPA (Cross-Site Port Attacks) para escanear la DMZ en la que se encuentra hospedado este servidor o para analizar cualquier otro servidor de Internet.

Figura 11: Script de install.php. Permite conectar a servidor y puerto y hacer XSPA

Solo se debe jugar con la dirección IP del servidor y el puerto al que se quiere conectar. Así, podremos recibir un mensaje "Credenciales No validas", lo que implicará que hay un servidor MySql en ese puerto pero el usuario no es correcto, o "MySql Server has gone away" lo que significará que el puerto está abierto aunque no hay un servidor MySql. Este es el ejemplo siguiente en el que se puede ver que en esa dirección IP de la DMZ hay un servicio FTP abierto.

Figura 12: Un FTP en un servidor de la DMZ

Si el servidor no es alcanzable, en este caso porque la máscara de red lo tiene limitado y no hay ruta hasta ese segmento de red en el router, nos toparemos con un mensaje de "No route to host".

Figura 13: No route to host

Si el puerto está cerrado o hay un filtrado de tráfico en la respuesta del servidor, se obtendrá un mensaje típico de Time-Out. 

Figura 14: Puertos bloqueados en el firewall de salida de la DMZ

Y si el puerto está cerrado y se puede acceder a la respuesta del servidor, se obtiene un mensaje de "Connection Refused", tal y como se puede ver en la imagen siguiente.

Figura 15: Connection Refused

Con estos mensajes se podría hacer un escaneo de, no solo la DMZ sino, cualquier servidor de Internet al que hubiera conectividad desde el host que hospeda el script de MySqlDumper aún sin instalar correctamente.

Unsafe data manipulation

La última de las pruebas que le hice a este caso en concreto es ver cómo gestionaba la aparición de datos inseguros en los registros a los que recibe de MySQL. Al final, "all input is evil until it proves otherwise".

Figura 16: Se ejecuta el contenido de los registros de la base de datos

Como se puede probar, es posible inyectar registros con ataques XSS en los datos de las tablas de MySQL y la aplicación no realiza el envío de los datos al cliente de forma segura.

Reflexiones sobre gestores web de bases de datos

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

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!

Connection String Parameter Pollution en aplicaciones Windows publicadas en Citrix o Terminal Services

Este puente ha tenido lugar el Cybercamp, y entre los ponentes se encontraba Stefano Di Paola, padre de las técnicas de ataque HPP (HTTP Parameter Pollution). En un rato en la sala de ponentes del evento estuvimos hablando y además de aprovechar para tirarnos una foto juntos le conté que cuando descubrimos las técnicas de ataque de Connection String Parameter Pollution fue porque desde que vimos su charla queríamos polucinar todo lo polucionable, y al final fueron las cadenas de conexión a bases de datos las que nos dieron el premio.

Figura 1: Ataques CSPP en aplicaciones Windows publicadas en Citrix

En aquel momento, cuando estábamos escribiendo el paper de Connection String Parameter Pollution, hubo un software vulnerable al que no le hicimos mucho caso, pues no tenía mucho sentido en aquel entonces el entorno de ataque. Me refiero a la Consola de Administración de SQL Server 2000, que permite la inyección de un punto y coma en cualquier campo y como consecuencia la polución de los parámetros de la cadena de conexión.

Figura 2: Connection String Parameter Pollution Attacks

No tuvo mucho sentido para nosotros publicar que era vulnerable a CSPP, pues no encontramos un entorno de ataque donde tener la Consola de Administración de SQL Server 2000, que ya de por sí permite configurar todos los parámetros para hacer una conexión a una base de datos, diera alguna ventaja al atacante pero lo cierto es que lo era y se podrían inyectar comandos.

Figura 3: Presentación de Connection String Parameter Pollution en DEFCON 18

Sin embargo, quiso el destino que ayer mismo me topara con un servidor Citrix que estaba publicando una aplicación Windows que realizaba la autenticación contra una base de datos Microsoft SQL Server. Como se puede apreciar, es un panel de login en el que no se puede elegir ni el motor de la base de datos, ni tampoco se podía tocar el nombre del servidor y la base de datos, que venían prefijado y sin posibilidad de manipular. Solo se pueden introducir valores en el campo de usuario y contraseña. 

Figura 4: Un aplicación Windows publicada en un servidor Citrix con una conexión a SQL Server

Para probar si estaba ante una cadena de conexión a bases de datos inyectable y polucionable, en el campo de Usuario introduje una cadena con el carácter ";" en medio, para ver si conseguía generar un nuevo elemento en la configuración de la conexión. Como se puede ver en el siguiente mensaje de error obtenido, mi carácter ";" aparece en la cadena como uno de los caracteres de control introducidos por el programador, así que podría probar otras cosas.

Figura 5: Mensaje de error ODBC que muestra la cadena inyectada

Teniendo en cuenta que esta aplicación está en un entorno Citrix la cosa podría ser más que interesante. Al final, al haberse publicado esta aplicación, se está publicando un usuario del sistema operativo Windows sobre el que está corriendo, lo que podría permitir hacer un ataque de Jailbreak, pero al mismo tiempo podríamos utilizar un parámetro Integrated Security en la cadena de conexión para utilizar ese usuario Windows en el motor de la base de datos.

El resultado, como puede verse en este ejemplo concreto es que ese usuario de Windows concreto sobre el que está corriendo esta aplicación Windows publicada en este entorno Citrix no tiene los privilegios de acceso a este motor SQL Server en particular, pero el ataque podría haberse realizado si hubiera estado configurado con otro usuario podría haber tenido éxito.

Figura 6: Error. El usuario no está dentro de una conexión de confianza

Al final, con esta aplicación en concreto se daba otra singularidad negativa, y es que el nombre de la base de datos había sido agregado al final de la cadena de conexión. Esto, conociendo que en la polución de los parámetros hace que el "último gane", significa que desde el campo de usuario pudieramos manipular todos los parámetros anteriores menos el nombre de la base de datos.

En este último ejemplo se puede ver como se ha polucionado el valor Server de esta cadena de conexión para obtener un resultado de que en Localhost no hay instalado ningún servidor SQL Server. Esta polución nos permitiría buscar todos los servidores SQL Server dentro de la DMZ de la organización - uno de los entornos de ataque descritos en nuestra presentación de DEFCON - e intentar realizar realizar una conexión a algún entorno de backup no publicado en Internet.

Figura 7: Conexión a server Localhost con polución de parámetro SERVER

Al final como se puede ver, aunque las técnicas de Connection String Parameter Pollution las pensamos más en aplicaciones web, con aplicaciones Windows publicadas en entornos de Citrix y/o Terminal Services en los que ya hay un usuario con una sesión abierta, también tienen su cabida. 

Saludos Malignos!

Cómo robar las BBDD de la empresa atacando al jefe

Cuando se trata de hacer un ataque a los servidores internos de una empresa siempre hay que buscar un punto de apoyo en el que apuntalar el ataque. Hace tiempo, antes de que Apple arreglara en iOS 6 las opciones de seguridad por defecto en la carga de las imágenes en los correos electrónicos que se visualizaban en el cliente iOS Mail, escribí un artículo sobre cómo aprovechar esto para hacer ataques de SQL Injection a la web de la empresa usando al jefe o hacer ataques de CSRF, y después salió alguna prueba de concepto que hacía algo similar con un CSRF usando passwords por defecto y debilidades en alertas de navegadores. Pequeñas debilidades que sumadas dan owned!.

Figura 1: Cómo robar la base de datos de la empresa usando a un empleado de la organización

En este caso, para el Security Innovation Day 2014 en Eleven Paths preparamos un ataque similar, pero usando un fichero Excel, una macro VBA (Visual Basic for Applications) y una cadena de conexión con autenticación del lado del servidor. Os lo explico.

Figura 2: Un panel de control para cocinar el ataque

La idea era demostrar como un atacante podría utilizar pequeñas debilidades en una empresa para conseguir robar una base de datos completa SQL Server sin ni tan siquiera hacer mucho ruido. Para ello, el primer paso es sencillo, un correo dirigido con una buena excusa, y adjuntar en él un fichero Excel.

Figura 3: El correo electrónico le llega a la víctima sin ningún aviso de seguridad

Si es un jefe, seguro que se te ocurren mil y una excusas para enviar un correo electrónico con un Excel adjunto. Así que usa tu imaginación en esta parte del proceso. Nosotros no le dimos demasiada importancia a esto, pero si encima el target tiene una configuración relajada del registro SPF podrás incluso suplantar a algún empleado interno de la empresa con facilidad.

Figura 4: El fichero se guarda en el equipo local con un Drag & Drop para evitar la alerta de zona de Internet

Una vez que el fichero adjunto se abra se mostrará una alerta indicando que hay algún contenido que ha sido deshabilitado, para conseguir engañar al usuario, de nuevo, puedes hacer uso de algún truco de ingeniería social. En este caso el truco es que se está cargando una imagen externa.

Figura 5: Falta una imagen porque no has aceptado la alerta de seguridad

Si el jefe activa el contenido, lo que realmente sucede es que se carga una macro VBA que realiza todo el trabajo. Para la demo hicimos una cadena de conexión con Autenticación Integrada, al igual que realizábamos en los ataques de Connection String Parameter Pollution. Para que el usuario se quede tranquilo, nosotros le mostramos la imagen como si fuera lo único que hubiera pasado en su equipo.

Figura 6: Ahora aparece la imagen en el fichero Excel

Como para la demo sabíamos el nombre del servidor SQL Server, la forma en la que se hace la cadena de conexión es muy sencilla, pero se podría haber realizado un escaneo de toda la red al estilo de Scanner CSPP que creamos, probando a conectarse a todo el rango de direcciones IP de la red.

Figura 7: La macro que se conecta al Servidor SQL Server con Autenticación Integrada, roba los datos y los manda al C&C

Cuando encuentre el servidor SQL Server y se pueda autenticar en él con las credenciales que la víctima haya utilizado para abrir su sistema operativo Windows, entonces se podría hacer un recorrido completo por el diccionario de datos y traer absolutamente todo. Para este ejemplo, tiramos una consulta contra una tabla de la base de datos y listo, eso sí, usando el For XML al estilo de los ataques de Serialized SQL Injection.

Figura 8: Datos reportados al C&C

El último paso es fácil, reportar todo a un panel de control en la web de la forma más silenciosa o sencilla. Para esta demo no quisimos complicarlo y se enviaba como parámetro GET de una petición, lo que permitía recoger la info que había en la base de datos.

Figura 9: Ningún AV de Virus Total muestra ninguna alerta de seguridad

Al final era un pequeño ejemplo de cómo la suma de pequeñas debilidades, como fugas de información de versiones utilizadas, nombres de personas de la organización, reglas relajadas en los filtros anti-spoofing SPF, políticas de seguridad de la aplicación Excel o el uso de Autenticación Integrada en SQL Server, podrían llevar a un atacante a tener éxito en el robo de datos de tu organización de forma sencilla.

Figura 10: Bosses Love Excel, Hackers Too!

Por supuesto, este fichero Excel cocinado a medida para este ejemplo no es detectado por ningún motor antimalware como algo malicioso o sospechoso. Solo es un Excel, y como dijimos Juan Garrido y yo en la charla de Defcon 19 donde explicábamos la cantidad de cosas que se pueden hacer con él, "Bosses love Excel, Hackers Too!".

Saludos Malignos!

8 malas prácticas en el proceso de gestión de un 0day

En septiembre del año 2009 estábamos a punto de presentar en la Ekoparty de aquel año las técnicas de Connection String Parameter Pollution en la que íbamos a hacer demos con varios 0days que afectaban a las herramientas MyLittleBackup, MyLittleAdmin, Microsoft Web Data Administrator y ASP.NET Enterprise Manager. Cuatro herramientas utilizadas para la gestión de bases de datos MS SQL Server que tenían el mismo bug y permitían acceder remotamente de forma sencilla a los paneles de control de todos los clientes que los tuvieran expuestos en Internet con solo poner una cadena de caracteres y que os expliqué en detalle en el artículo Connection String Attacks.

Figura 1: Presentación de Connection String Paramenter Pollution en DEFCON 18

Desde entonces han pasado varios años pero aún hay muchos sitios vulnerables a estas técnicas. Repasando lo que ha sucedido desde entonces hay una serie de lecciones aprendidas de malas cosas realizadas que ayer quise explicar a mis alumnos en la Universidad y que me he decidido a publicaros por aquí.

1.- El reporte sin solicitud de un CVE

La primera de las malas lecciones aprendidas es que no todas las empresas de desarrollo de software se toman de igual forma la gestión de los bugs de seguridad. En aquel entonces a nosotros nos importaba más la técnica de explotación que estuvimos desarrollando en detalle en el paper, que en el 0day concreto, y dejamos que los fabricantes de software optaran por gestionarlo como ellos quisieran y al final cada gestión fue un desastre... para ellos y para sus clientes.

Figura 2: El advisory en el foro que se publicó

Desde la empresa que gestiona MyLittleAdmin y MyLittleBackup no se pidió un CVE para su bug y lo único que hicieron fue publicar un mensaje en un foro en el que decían que el parche era solo para corregir una "minor security vulnerability", como se puede ver en la Figura 2. Por supuesto, ni gracias, ni mención, ni nada por el estilo, ya que no les sentó nada bien que descubriéramos este fallo.

2.- Minimizar la importancia del bug

Cuando vi el advisory me puse en contacto con ellos y les expliqué que si mirábamos la criticidad del bug usando CVSS/CVSS2 sabiendo que iba a haber un exploit público, remoto, sin necesidad de una interacción por el usuario y permitiendo acceder al 100% de los datos, probablemente nos saliera un número muy alto. Un poco forzado por la evidencia, cambió el mensaje en el foro de su sitio que hacía las veces de Security Advisory y lo dejó como "Security Vulnerability", pero simplemente modificando el texto del mensaje.

Figura 3: El advisory modificado a "security vulnerability"

En aquel entonces le dije que el tratamiento que estaba haciendo no creía que fuera bueno para sus clientes, pues después de que yo contara esto en la Ekoparty, BlackHat y DefCON, todos aquellos usuarios de su software que no lo hubieran actualizado quedarían muy vulnerables. A día de hoy, aún quedan muchos sitios publicados en Internet con versiones de MyLittleAdmin y MyLittleBackup vulnerables a esta técnica que permiten a cualquiera acceder desde Internet a sus bases de datos.

3.- No realizar una detección de clientes vulnerables

Uno de los temas que ya he contado alguna vez es que si cualquiera haciendo un poco de hacking con buscadores es capaz de encontrar los sitios vulnerables, ¿cuál es el motivo por el que no lo hacen los propios fabricantes? Esto ya lo he comentado con varios de ellos, y alguno ha comenzado a hacer algún escaneo pro-activo en Internet para localizar versiones vulnerables de sus programas para avisar vía canales oficiales a sus clientes del problema. Por supuesto, en este caso ninguno de los fabricantes parece haber realizado el proceso de aviso a sus clientes y ayuda un poco más a que sigan quedando las instalaciones vulnerables en Internet.

4.- Preocuparse más de la imagen que del fallo de seguridad

Una de las cosas que más me llamó la atención es que nada más publicar el fallo de seguridad e ir yo a contar la presentación, desde MyLittleTools se hizo una campaña de marketing dando referencias de qué clientes usaban su software.

Figura 4: Lista de clientes publicada desde MyLittleToolsb

En aquel entonces pensé: "Genial, te digo que hay un 0day que se va a publicar en Internet y tú pones las víctimas expuestas". Fail.

5.- Olvidar la fase de retiro del software

Una de las cosas que se estudian en las clases de Ingeniería del Software es que hay que pensar en la fase de retirada del software, es decir, cuándo y cómo una aplicación debe ser retirada definitivamente. En el caso de Microsoft Web Data Administrator el software se liberó vía proyecto Open Source en CodePlex, pero se siguió distribuyendo la versión antigua desde los servidores de Internet, lo que hacía que aunque el programa estaba abandonado siguiera habiendo nuevas instalaciones del software vulnerable cada día.

Figura 5: en el año 2009 se retiró Microsoft Web Data Administrator

La versión de CodePlex estaba parchada, pero la que distribuía directamente Microsoft no lo estaba, así que cuando contacté con el Microsoft Security Response Center estuvieron de acuerdo en retirar el software de la descarga.

6.- Fallos en el control de reintroducción de bugs

En este caso, a pesar de Microsoft retiró el software vulnerable de Internet, en un proceso de migración de servidores volvió a ponerse disponible en Internet al cabo del tiempo, lo que yo detecté de casualidad y tuve que volver a reportar.

Figura 6: En el año 2011 estaba otra vez disponible el software vulnerable

Al final, durante otro largo tiempo se estuvieron creando nuevas instalaciones de software vulnerable servidas otra vez desde la propia Microsoft.

7.- Uso de software abandonado

El último de los programas vulnerables que se vieron afectados con estos 0days era ASP.NET Entrerprise Manager, un programa que cuando ya descubrimos el bug estaba abandonado totalmente por sus creadores, así que no había ninguna posibilidad de poder obtener un parche. De hecho, en la presentación del fallo contábamos un ejemplo de cómo debería solucionar manualmente, algo que por supuesto dudamos que alguien hiciera.

8.- No anticiparse al bug

En la presentación de Connection String Parameter Pollution, además de hacer las demos con las cuatro versiones afectadas por los 0days, dejamos claro que aunque en Oracle y MySQL era más difícil debido a que no era común la autenticación integrada en la base de datos, el resto de exploits para escanear la DMZ, escanear los puertos o cambiar la base de datos a la que se conecta la aplicación les afectaría. Hace no demasiado yo probé esto mismo con un panel web de gestión de bases de datos MySQL que se veía afectado.

Figura 7: Un panel de gestión de bases de datos MySQL afectado por un Connection String Attack

Hay que estar atento a todo lo que se publica que afecta a versiones de software similar para saber si tu aplicación puede verse o no afectada. Anticipación es una buena práctica de gestión de seguridad.

Conclusiones

Todos estos puntos han hecho que el matar un 0day tan fácil de explotar no se haya realizado y a día de hoy aún haya paneles de las cuatro versiones de software totalmente vulnerables expuestas en Internet, y para alguien ducho en el hacking con buscadores sea más que sencillo localizarlos. Gestionar correctamente la seguridad es fundamental, y si no se hace... todo será un desastre.

Saludos Malignos!

Cadenas de conexión a Bases de Datos en Internet

Cuando estuve repasando el cheatsheet para buscar contraseñas en servidores para lograr una elevación de privilegios, eché en falta las búsquedas sobre ficheros de cadenas de conexión a bases de datos. Estos archivos de configuración suelen dar muchos frutos y permiten hacer la elevación de privilegios a través del motor de bases de datos.

Estos ficheros de configuración pueden tener distintas extensiones, pero tienen en común que en el fondo la gran mayoría son ficheros en formato texto plano, con lo que son propensos a las búsquedas de cadenas. Unos de ellos, los ficheros con extensión .UDL, dan mucho juego en Internet en los Connection String Attacks. Yo los he usado para hacer una demo con un poco de "magia" en algunas conferencias.

Las cadenas de conexión permiten hacer mil cosas en una DMZ, especialmente con un sistema como Excel - donde sirven hasta para obtener nombres de máquinas o descubrir los servidores de Bases de Datos en una DMZ -. Para encontrar los ficheros de cadenas de conexión en los servidores yo suelo buscar los ficheros .DSN (Data Source Name) en los servidores Citrix, para intentar conectarme a alguna base de datos local o remota.

No se me había pasado buscar ficheros .DSN en Internet - no sé porque, pero siempre busqué UDL -, pero releyendo algunas páginas del libro de "Hacking con Buscadores", se me vino a la mente que seguro que acabarían apareciendo en Internet. Y así fue.

Figura 1: Buscando ficheros con extensión DSN en Google

Como se puede ver, los ficheros DSN son solo una cadena de texto donde se definen todos los parámetros de la conexión.

Figura 2: Fichero DSN publicado en Internet

En el caso de BING, la cosa es distinta, ya que no se puede buscar por extensión, así que hay que hacer uso de Filetype para obtener ficheros con esa cadena. 

Figura 3: Buscando cadenas de conexión en BING

Como ventaja al handicap de no poder buscar por extensión, tenemos que cuando se buscan cadenas de texto de cadenas de conexión, no importa si estos aparecen en ficheros .DSN, .UDL, o en un volcado ASP o PHP que se produjo por un fallo puntual del servidor.

Figura 4: Volcado ASP indexado en BING con datos de varias cadenas de conexión

Así que, si llegas a un server, no te olvides de buscar los DSN que te pueden facilitar el proceso de elevación de privilegios, o te pueden venir bien para pivotar a otros servidores de la DMZ.

Saludos Malignos!

DEF CON me gusta mogollÓN

La primera vez que fui a Defcon era la edición número 16, y llegué muerto de miedo. Estuve semanas enteras preparando la charla sobre Time-Based Blind SQL Injection & Marathon Tool, porque el lugar me daba todo el respeto que merece dicho evento.... y me lo pasé genial, y estuve arropado por un montón de amigos.

Al año siguiente en la Defcon 17 fui con mi amigo Palako, a hablar de Tactical Fingerprintng using Metadata, Hidden Info and Lost data, y a sacar a pasear la FOCA, en una charla que creo nos quedó como nunca. Recuerdo que no salí tan satisfecho de una charla nunca. Trabajar con Palako en aquella charla fue una pasada, y creo que en su memoria también estará ese buen recuerdo. En la mía, nunca se borrará el incidente por el que casi acabo en la cárcel.

En Defcon 18 repetí con Palako, después de haber pasado por la Yahoo! Security Week y volvimos a hablar de FOCA en este caso la versión 2 "The FOCA Strikes Back", donde fue genial ver que teníamos a la gente del año pasado y se acordaban de los chistes del anterior. A día de hoy, cuando Moxie Marlinspike me encuentra por cualquier conferencia del mundo, le oigo decir eso de "FOCA is working, FOCA is working...".

Este año, también nos animamos a impartir otra charla, en este caso la de Connection String Attacks, donde hablamos de Connection String Parameter Pollution y sacamos a pasear el CSSP Scanner. Creo que también nos quedó chula, aunque el comentario del final casi me cuesta un disgusto...


En Defcon 19, el año que ganamos el triplete [Eurocopa, Copa del Mundo y HackCup], primero hablé sobre DUST: Your RSS Feed Belongs to you, en un sitio donde no tenía todas conmigo de que el tono de la charla fuera a ser entendido.


Después, en esa misma edición de Defcon, acompañado por Juan Garrido "Silverhack", hablamos sobre Bosses Love Excel, Hackers Too, en una charla en la que Juan y yo trabajamos lo indecible. Puede que parezca que todo es muy sencillo, pero entender todas las políticas, las versiones, y afinar las demos nos llevó al trianero y a mí horas y horas y horas de trabajo, pero el resultado fue muy satisfactorio, y he de reconocer que después de ya varias charlas en Defcon, me sentí muy cómodo en el escenario en todo momento, aunque me pasé todo el tiempo trabajando.

Ahora, la charla de Owning Bad Guys {and mafia} with JavaScript Botnets que dimos en la Rooted ha sido seleccionada para la Defcon 20 (parece que ya es costumbre eso de presentar primero en RootedCON lo que luego haremos en Defcon), y la verdad es que estamos muy contentos. Creo que el espíritu de esa charla encaja mucho con el espíritu de Defcon [version No Lusers]

Actualización: Esta es la versión de la charla que impartí en Defcon XX


Y la versión final de la que impartí en DEFCON XXI.


Y claro, ya que vamos... habrá que volver a ganar la HackCUP, ¿no? ¿Quién se viene a la Defcon este año? ¿Quién quiere jugar en el FOCA Team? Amigos argentinos: Nico, Fran, Fede, Mariano, Eze, Hernán, Claudio, y compañía ... Fear the FOCA!

Saludos Malignos!

How to impress with FOCA, Connection Strings & Citrix

Me he permitido la osadía de tomarle prestado parte del título al paper que presentaron Alex Sotirov y Mark Dowd sobre cómo saltarse las protecciones de memoria en Windows Vista, para ilustrar la demo con la que quise terminar mi última charla en Troopers.

La gracia de la demostración final era que en esa conferencia había hablado hace dos años de Connection String Attacks, el año pasado de FOCA 2 y ese de Terminal Services y Citrix, y este ejemplo unía todo en una prueba bastante plástica. Este es el step by step.

Paso 1: EnFOCAndo la demo

La primer fase es algo bastante sencillo. Basta con lanzar FOCA sobre un dominio en el que entre los Juicy files aparezca un fichero de cadena de conexión de tipo UDL, como ya vimos en el artículo de Connection String Attacks.

Figura 1: Buscando un fichero UDL con password

Haciendo un poco de hacking con buscadores es posible encontrar fácilmente alguno con password, directamente, lo que nos lo pone todo mucho más sencillo.

Figura 2: La cadena de conexión en el fichero UDL. Copiamos la URL.

Paso 2: Buscando un EXCEL como plataforma base

La segunda parte consiste en buscar algún servidor en el que "tocando el piano" o haciendo jailbreak se pueda llegar a disponer de una aplicación EXCEL para realizar desde allí la demo. Así que se puede hacer algo de fingerprinting o encontrar los ficheros ICA con FOCA.

Figura 3: Un Excel en un servidor Citrix servido vía web

Paso 3: Encadenado el Excel a la base de datos

Una vez que tenemos la aplicación EXCEL en el servidor Citrix (o Terminal Services), el siguiente paso es crear una Conexión de Datos.

Figura 4: Añadir una conexión desde un documento EXCEL

Para hacerlo más chulo, bata con hacer uso del truco de "navegar sin navegador" y pegar la ruta copiada en el paso 1 del fichero UDL en el cuadro de diálogo de la creación de la conexión, concretamente en el nombre del fichero.

Figura 5: Pasándole la URL del fichero UDL al EXCEL

Una vez acabado tendremos la conexión creada.

Figura 6: Conexión entre Excel y la Base de Datos establecida

Paso 4: El truco final

Para terminar sólo hay que ir a las conexiones existentes para comprobar que estamos enlazamos y hacer doble clic sobre ella. Se selecciona la tabla que se desea volcar.

Figura 7: Selección de la tabla a volcar en Excel

Elegimos el formato de presentación:

Figura 8: Formato de la tabla a crear en Excel

Y EXCEL realizará el resto del trabajo volcando todos los datos en un bonito formato de hoja de cálculo.

Figura 9: Datos extraídos y bien formateados

[Applause]

Si todo ha ido bien, es el momento de pedir los aplausos al respetable, que seguro que agradece un buen truco de magia...

Figura 10: Magic happens...

Conclusiones

Esto es sólo una demo curiosa que permite, de forma cómoda, encadenar muchos trucos para explotar un fallo de seguridad. Lo cierto es que la gracia de este ataque está en que, como ya os publiqué en el artículo de Escaneando la red con Connection String y Excel, esto se puede hacer incluso con los servidores de la DMZ, lo que puede ser muy peligroso.

Saludos Malignos!