Mostrando entradas con la etiqueta MS SQL Server. Mostrar todas las entradas
Mostrando entradas con la etiqueta MS SQL Server. Mostrar todas las entradas

miércoles, junio 25, 2014

SQL Injection: Aplicar Mínima Superficie de Exposición en las Cadenas de Conexión a BBDD

Cuando me toca explicar la fortificación de aplicaciones web hay que hablar obligatoriamente del impacto que tienen los bus de SQL Injection y de cómo poder limitarlos aplicando las reglas de Mínimo Punto de Exposición y Minima Superficie de Exposición. Una de las areas donde se puede tener un buen resultado, es en la utilización del propio sistema de seguridad del motor de bases de datos que se esté utilizando, aprovechando un esquema múltiple de conexiones a bases de datos y permisos restringidos a cada uno de ellas. 

Bases de datos sin compartición de usuarios

Cuando se va a conectar una aplicación web a una base de datos, es necesario contar con al menos un usuario de la base de datos que tenga permisos en el SGBD. Con ese usuario, al menos, se hará la cadena de conexión para gestionar los datos que se almacenen en la base de datos que que allí se cree. Uno de los errores más comunes que se encuentran es que ese usuario al final se puede usar en varias bases de datos creadas dentro del mismo SGBD - algo muy común en entornos Microsoft SQL Server - o que tenga acceso a esquemas creados para otras aplicaciones - algo muy común en entornos Oracle Dabatabase -.

Figura 1: Mala gestión de conexiones a bases de datos en un SGBD

Esto lleva a que al final, si alguien es capaz de localizar un bug de SQL Injection en una aplicación web conectada a una base de datos, con el mismo usuario que la aplicación usa para conectarse a esa base de datos es capaz de conectarse a otras bases de datos y sacar datos de ella.

Figura 2: Bases de datos con usuarios aislados

Para evitar eso, cada base de datos de aplicación debe poder ser accedida única y exclusivamente por el/los usuarios que vayan a ser utilizados en la conexión de esa aplicación. Si alguien intenta acceder a esa base de datos desde otra cadena de conexión, deberá recibir un mensaje de error.

Figura 3: Error de conexión al intentar cambiar de base de datos con un bug de SQL Injection

Dentro de una aplicación web, conexiones distintas para cada rol

Supongamos que tenemos una aplicación web expuesta en Internet en la que los usuarios que allí se creen tienen tres roles. Vamos a suponer que estos tres roles son: Rol Administrador que puede leer, escribir todas las tablas que dan soporte a la aplicación, el Rol Editor, que pueden escribir y borrar registros en tres tablas, y el Rol Lector que solo puede leer datos de dos tablas.

A estos roles, hay que sumar que la propia aplicación web, en algún momento puede tener que realizar algunas acciones no dependientes de las acciones de los usuarios, por ejemplo la autenticación de las credenciales, las operaciones de mantenimiento, etcétera. Para ello, hablaremos del Rol de Aplicación.

Lo suyo es que, para dejar un entorno fortificado se creen dentro de la base de datos cuatro usuarios que representen a los cuatro roles con los que se va a conectar la aplicación web. Cada uno de esos usuarios de la base de datos tendrá asignados los privilegios sobre el sistema necesarios para el cumplimiento de su rol dentro de la aplicación web, así como los permisos sobre los objetos estrictos y nada más.

Figura 4: Tabla de roles y permisos

A partir de ese momento, la aplicación web no gestionará una única cadena de conexión, sino que gestionará 4 cadenas de conexión distintas para cada una de las acciones que quiera realizar. Por ejemplo, para hacer un proceso de login con un usuario, la aplicación web primero creará una conexión con el usuario del Aplicación, autenticará las credenciales que le introduzcan contra su tabla_usuarios, y una vez que se sepa el rol que deberá tener ese usuario dentro de la aplicación web, se cerrará la conexión con el Rol_Aplicación y se abrirá una nueva conexión con el usuario de la base de datos con el rol adecuado.

Figura 5: Esquema de cadenas de conexión múltiples desde la misma aplicación web a la misma base de datos

Esto lo que hace es que, si un usuario con el Rol_Lector encuentra un bug de SQL Injection dentro de la aplicación, el impacto que puede tener estará limitado. Por el contrario, lo habitual es que las aplicaciones web solo gestionen un único usuario de conexión con todos los permisos sobre todos los objetos de la base de datos, lo que lleva a que cualquier usuario de la aplicación web que encuentra un bug de SQL Injection acabe teniendo acceso a todos los objetos de la base de datos, ya  que el usuario que está utilizando la aplicación web en la conexión a la base de datos los tiene.

Saludos Malignos!

domingo, febrero 23, 2014

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 dicho 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!

miércoles, diciembre 26, 2012

Averiguar la versión de un SQL Server

Para este día de Navidad, Nelson Brito (@nbrito) tenía preparada una nueva versión de SQL Fingerprinting Next Generation, una herramienta de la que ya os había hablado aquí para hacer Fingerprinting a servidores SQL Server. Como yo también soy un enganchado a esto del hacking y las tecnologías, aproveché el día de Navidad para probar la herramienta, así que igual que hice en la anterior ocasión, escanee unos segmentos buscando servidores SQL Server con el puerto 1433 abierto en Internet y lancé la herramienta.

Figura 1: Buscando servidores SQL Server con el puerto 1433 abierto a Internet

Esta versión está escrita en Perl y según cuenta en la descripción, es capaz de reconocer más de 500 versiones distintas de SQL Server con su Service Pack y conjunto de parches de actualización instalados. Basta con invocarlo con el nombre del fichero en Perl y la dirección IP a realizar el proceso de fingerprinting para obtener una versión y un grado de porcentaje de certidumbre, tal y como se ve en la figura 2.

Figura 2: MS SQL Server 2008 R2 RTM descubierto con ESF.pl

Si se quiere conocer el nombre del servidor SQL Server en la red, hay que establecer una cadena de conexión y analizar la respuesta, tal y como ya vimos en "Cómo conocer el nombre de un servidor SQL Server con una cadena de conexión". En esta herramienta, basta con utilizar la opción -d  de debug, y analizar la respuesta obtenida. En la Figura 3 ZitrXXXXX7C1.

Figura 3: Modo debugging de la herramienta. Permite averiguar el nombre del servidor SQL Server

Tal vez hubiera sido más cómodo que el nombre del servidor saliera en la respuesta por defecto de la aplicación al hacer el proceso de fingerprinting, pero hay que reconocer que parece funcionar muy bien con diferentes versiones de SQL Server.

Figura 4: Servidor MS SQL Server 2008 SP3 descubierto con ESF.pl

Para descubrir los servidores SQL Server en una red, además de hacer el escaneo con nmap que os he puesto en este ejemplo, se puede utilizar un escaner IPv6 como Topera para descubrir qué equipos están respondiendo por ese puerto, o utilizar trucos como la creación de un DSN en una red local o herramientas de administración como MyLittleBackup. La herramienta merece tenerla en cuenta para analizar las versiones de SQL Server, así que tenla presente en tu próximo pentesting.

Saludos Malignos!

lunes, agosto 13, 2012

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!

jueves, junio 07, 2012

Explorando la DMZ de una red (3 de 3)

**************************************************************************************************
**************************************************************************************************

La herramienta de administración de Sonicwall CDP

Tras arrancar la aplicación instalada, la herramienta ya está configurada para conectarse al appliance de copias de seguridad, con lo que sólo se solicita una contraseña. Usando la password por defecto de estos dispositivos, como era de esperar se permite el acceso.

Figura 12: Herramienta de administración de SonicWall CDP

No sabía lo que allí me iba a encontrar, pero parece que está absolutamente todo el corazón de la empresa, ya que en este servidor se hace backup de Active Directory, las bases de datos MS SQL Server y las bases de datos de servidores de correo MS Exchange Server. Vamos, creo que los datos más valiosos de la infraestructura de la compañía.

Figura 13: Backups de Active Directory, MS SQL Server y MS Exchange Server

Tenerlos protegidos sólo con la contraseña por defecto es una autentica temeridad y si hubiera tenido delante al administrador le hubiera mordido una oreja por luser. La herramienta permite hacer restore de datos a cualquier sitio, y por lo tanto se podría acceder a todo. Sin embargo, esto no acaba aquí, ya que también se realizan copias de seguridad de carpetas compartidas, y desde la aplicación se pueden consultar todos los ficheros, y restaurarlos.

Figura 14: Buscando ficheros en el backup de datos

Todos los datos de una empresa sólo controlados por una contraseña por defecto es una autentica temeridad. Espero que todos vosotros hayáis cambiado las passwords por defecto de todos vuestros equipos de la red.

192.168.X.150: Otra impresora

Y también con la contraseña por defecto. Lo curioso es que con esta se puede acceder a ver qué usuarios han mandado a imprimir qué documentos, con lo cual se puede extraer un poco más de información. Lo cierto es que tras poder acceder al backup del Active Directory deja de tener importancia este resquicio de datos.

Figura 15: Otra impresora, con su password por defecto

Como curiosidad, quise comprobar a ver si tenía una shell que permitiera sacar algo de allí, pero lo cierto es que la consola msh que trae estaba bastante limitada.

Figura 16: La consola msh con password por defecto

Locahost: El servidor web público

Encontré alguna impresora más - sí, también con la password por defecto - pero ya era suficiente, así que revisé mi equipo para terminar, y como era de esperar, allí estaba el servidor web publicado en Internet con el acceso a los servicios Citrix.

Figura 17: El servidor web local con Citrix

Como estaba en ese equipo, miré a ver si podría haber metido una webshell en el servidor para poder acceder siempre al equipo. Allí estaba InetPub, y no estaba protegido, por lo que se podría meter un fichero con la webshell para perpetuar el acceso y control a la red.

Figura 18: El directorio InetPub y una rara aplicación llamada keygen

Conclusión

Tener un firewall no es una garantía de protección. Si estás publicando servicios en Internet audítalos. Si estos servicios están en una DMZ, audítala como si los servidores hubieran sido comprometidos. Si tienes dispositivos en tu red.... ¡cambia ahora mismo las passwords por defecto de todos ellos!

Saludos!

**************************************************************************************************
**************************************************************************************************

lunes, mayo 28, 2012

Webcasts gratuitos y recursos de MS SQL Server 2012

Esta misma tarde comienza una serie de Webcasts Gratuitos dedicados a SQL Server 2012, que impartirá Rubén Alonso (Punto Compartido). Estos webcasts se hacen a través de Internet, y son totalmente gratuitos, por lo que puedes asistir desde cualquier punto del mundo y participar en las sesiones. Los contenidos que se van a ver son los siguientes:


Estas formaciones se completarán con unos laboratorios presenciales que se impartirán la semana del 11 de Junio en Informática 64, a los que se ha puesto un precio reducido gracias a un acuerdo en la campaña de difusión conjunta que se va a hacer con Microsoft.

11 de junio: HOL-SQL58 MS SQL Server 2012 - Administración
11 y 12 de junio: HOL-SQL53 MS SQL Server 2012 - Servicios de Datos Maestros
12 de junio: HOL-SQL57 MS SQL Server 2012 - SQL PowerShell
13 de junio: HOL-SQL59 MS SQL Server 2012 - Optimización del rendimiento
13 y 14 de junio: HOL-SQL54 MS SQL Server 2012 - Servicios de Calidad de Datos
14 de junio: HOL-SQL55 MS SQL Server 2012 - Business Intelligent Semantic Model
15 de junio: HOL-SQL56 MS SQL Server 2012 - Informes con SQL Server Power View

Más información de todos los próximos eventos

Si quieres conocer más sobre estos temas, en el blog de Punto Compartido se ha publicado una serie dedicada a los Servicios de Datos Maestros en SQL Server 2012, a la instalación conjunta de SQL Server 2012 y SharePoint 2010, a las Novedades que ofrece SQL Server 2012 "Denali" y al Proyecto Crescent para la generación de informes. 

Por último, si quieres profundizar más en SQL Server 2012, puedes descargarte el Developer Training Kit y el eBook gratuito: Introducing MS SQL Server 2012 de Microsoft Press.

Saludos Malignos!

viernes, abril 20, 2012

La semana que viene eventos para todos... {y hoy}

Hoy, cuando estés leyendo este post, ya estaré en Barcelona, a punto de participar en el Talentum Tour en la Universidad Politécnica de Catalunya. O tal vez, si lo has leído tarde, esté viajando en AVE para llegar a mi charla en el evento AppFest de Madrid. Si se te ha pasado el día, lo mismo me pillas participando en el Curso de Peritaje Forense informático en Arganzuela

Pero en cualquier caso te dejo la lista de eventos que tienes la semana que viene, para que te apuntes al que mejor te cuadre. Como siempre, os pongo [*] en los que yo voy a participar y [G] en aquellos que son gratuitos, para que tengas toda la información a primera vista.
20 Abril [Barcelona] Talentum Tour [*][G]
20 Abril [Madrid] The AppFest [*]
20 Abril [Online] Webcast Project Server 2010 [G]
21 Abril [Arganzuela] Curso Peritaje Forense Informático [*]
23 Abril [Bilbao] Talentum Tour [*][G]
23 Abril [Valencia] Cloud Ready [G]
24 Abril [Valencia] Talentum Tour [*][G]
24 Abril [Móstoles] HOL SQL Server 2012: PowerShell
24 Abril [Barcelona] Cloud Ready [G]
25 Abril [Zaragoza] Cloud Ready [*][G]
25 Abril [Madrid] Talentum Tour [*][G]
25 Abril [Móstoles] HOL SQL Server 2012: Tunning
26 Abril [Madrid] Cloud Ready [*][G]
27 Abril [Burgos] Cloud Ready [G]
Si vas a estar en alguno de los sitios en los que vamos a estar y quieres que te llevemos alguno de los libros de Informática 64, puedes pedírmelo. Si tengo un hueco en la maleta te lo llevo.

Saludos Malignos!

miércoles, abril 18, 2012

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!

martes, abril 10, 2012

Calendario de cursos y eventos en Abril: Save the date

Ya está bien de festejos y cachondeos, que hay que levantar el país. Así que a darle a la manivela que no se diga que aquí no nos ponemos la pilas con el trabajo. Desde Informática 64 vamos a estar participando en un buen número de actividades entre eventos y conferencias para que no te aburras en este lluvioso o caluroso Abril que tenemos.

14 de Abril: Vuelta a la Escuela Universitaria de Informática

Como muchos quizás ya sabréis, yo fui p0344 en la EUI-UPM, y el próximo sábado 14 de Abril volveré a dar una charla sobre la Seguridad Informática, esta vez como antiguo alumno. La charla es en sábado, es gratuita, y todo el mundo puede asistir. Sólo debes ponértelo en la agenda, y acordarte de venir a esa escuela entre el Valle del Kas y Santa Eugenia.

16 al 19 Abril: Análisis Forense de Dispositivos Móviles

Con nocturnidad y alevosía, ya que será en horario de 18:30 a 21:00 horas para que puedas venir fuera de tu jornada laboral, daremos en Informática 64 un curso de Análisis Forense de Dipositivos Móviles, donde durante 10 horas os enseñaremos a sacarle las tripas a los iPhone, los iPad, los Android y demás dispositivos itinerantes, para ponerte a encontrar fallos de seguridad tan divertidos como los DropBox, Facebook u otras. Además también podrás jugar con Oxygen Forensics, una de las mejores herramientas para análisis forense de este tipo.

19  y 20 de Abril: The App Fest

El día 20 de Abril con una charla titulada "Hacking, Ciberguerra y otras palabortas" participaré en la sesión de Futuro de The App Fest, que tendrá lugar en Madrid.

21 de Abril: Curso de Peritos Judiciales

Más sobre el tema del análisis forense. En este caso, como ya han publicado en Security By Default, estaré como ponente formando parte del Curso de Perito Informático Forense por la ANTPJI. Allí estaré junto a grandes especialistas de la materia, como el gran Pedrito Sánchez, y me llevaré de paseo la tierna Forensic FOCA.

23 al 27 de Abril: SQL Server 2012 para PROS

La semana del 23 de Abril toca ponerse las pilas en SQL Server 2012. Ya nos están pidiendo algún piloto para implantar en algún cliente, y hemos decidido hacer una semana de Hands On Lab dedicada íntegramente a este nuevo servidor. El calendario de esa semana está formado por 7, sí SIETE, Hands On Lab presenciales en las instalaciones de Informática 64 en los que podrás tocar todas las tecnologías que trae el nuevo servidor de BBDD "killer" de Microsoft.
HOL-SQL58 MS SQL Server 2012. Novedades en Administración
HOL-SQL53 MS SQL Server 2012. Gestión de Servicios de Datos Maestros
HOL-SQL57 MS SQL Server 2012. SQL PowerShell
HOL-SQL59 MS SQL Server 2012. Optimización del rendimiento
HOL-SQL54 MS SQL Server 2012. Servicios de Calidad de Datos
HOL-SQL55 MS SQL Server 2012. Business Intelligent Semantic Model
HOL-SQL56 MS SQL Server 2012. Reporting con SQL Server Power View
Y esto es [casi] todo en lo que estaremos metidos en Informática 64 durante este mes de Abril, que como veis no poco. Además, os tenemos preparada alguna FOCA-Sorpresa en forma de software nuevo que os vamos a poner disponible en breve... keep listening.

Saludos Malignos!

lunes, febrero 20, 2012

Encontrar los servidores SQL Server de la intranet con DSN

Para encontrar los roles de los servidores tenemos múltiples herramientas. Sin embargo, cuando estamos en una red conectados a través de un escritorio remoto por Citrix y con pocos privilegios, usar esas herramientas pueden estar más allá de nuestras posibilidades. 

En alguna ocasión me había quedado con el Excel preparado buscando el servidor SQL para intentar una conexión con autenticación integrada y volcar la base de datos. Hasta el momento, para encontrar el servidor había estado utilizando el Active Directory, tal y como os puse en el artículo de ataques con cadenas de conexión y Excel.

Sin embargo, cuando eso no ha funcionado y la red tiene un número de equipos grande, esa labor puede ser ardua y tediosa. Ese era el caso con alguna red como la que podéis ver en la imagen siguiente. ¿Dónde está el servidor SQL Server?

Figura 1: Equipos en la intranet. ¿Dónde está el SQL Server?

A priori, y así lo pensaba yo, esto tiene pinta de ser como buscar una aguja en un pajar, pero resulta que en los sistemas Windows ya hay un escáner de servidores SQL Server, y lo realiza automáticamente la herramienta de configuración de las Data Source Names. Basta con seleccionar un nuevo DSN de Sistema, elegir el driver de SQL Server, y automáticamente se pone a escanear la red en busca de los SQL Server que hay allí.

Figura 2: Servidores en la intranet con SQL Server

Por supuesto, también puedes poner servidores a mano, pero lo que nos interesa en este caso es que haga él la búsqueda por toda la red, y es una comodidad.

Saludos Malignos!

miércoles, febrero 15, 2012

Serialized SQL Injection, Errores ODBC y SFX

Tras publicar el artículo de Serialized SQL Injection y errores ODBC me asaltó la duda de si Dani "The Doctor" Kachakil habría resuelto este problema en su herramienta SFX. Aprovechando que estaba en un curso y quería contar el funcionamiento de las técnicas de Serialized SQL Injection sin tener que andar construyendo algún ataque de UNION tedioso, decidí probar qué tal iría la herramienta SFX en un entorno con errores ODBC como el que os puse el otro día.

Tras configurarla y dar a descargar las tablas, rápidamente se ve que no salen todas. De hecho, al mirar al descargar el tamaño y las filas de cada una se puede ver cómo no está comprobado este error.

Figura 1: Recepción parcial de las tablas de la Base de Datos

SFX tiene un control de tamaño de datos a la hora de la descargar, pero el límite de error en ODBC es demasiado pequeño y se obtienen datos parciales, como en este caso con el esquema de tablas de una base de datos master.

Figura 2: Recepción parcial de las tablas de un Base de Datos master

Sin embargo, la herramienta sigue siendo extramadamente útil cuando la tabla tiene pocos registros, como este caso con la tabla de usuarios.

Figura 3: Datos extraídos con SFX haciendo Serialized sobre errores ODBC

Y además, la posibilidad de lanzar consultas personalizadas deja en manos del auditor la posibilidad de extraer lo que se desee de forma cómoda.

Figura 4: Consulta personalizada

No obstante, a pesar de que se pueda utilzar, agarré el teléfono y marqué al número de mi viejo amigo Dani  Kachakil:
- "¿Dani?, soy Chema. ¿Sabes ya por qué te llamo?"
- "Me lo imagino, para liarme con algo".
- "Je,je. ¿Has leído lo que puse de Serialized con errores ODBC?"
- "Sí, Chema, pero ahora no tengo tiempo, estoy cubierto de "·$%$·$&".
- "Ya, ya, ya me imagino Dani, pero... saca el Visual Studio y arregla SFX".
- "Vaaale, pero primero tengo que acabar los Retos que tengo por delante de la Rooted y la Codegate, que si no RoMaNSoFt me castiga, y no sé a quién tengo más miedo... Me debo a los Int3Pids"
Así que vamos a darle algo de tiempo a Dani para que nos modifique SFX y que funcione correctamente en estos entornos, que es mucho más rápido que usar los errores ODBC campo a campo.

Saludos Malignos!

lunes, enero 23, 2012

Gira Up To Secure 2012: Tercera semana

Entramos ya en la tercera semana de la Gira Up To Secure 2012, en la que visitaremos las ciudades de Madrid, Valencia y Sevilla. Estamos muy agradecidos de la respuesta que está habiendo de asistencia, ya que se ha superado en un 25 % el número de registrados y asistentes en todas las ciudades, con lo que sabemos que cuesta conseguir una mañana libre en las ocupaciones actuales.

Como siempre, yo llevaré algunos libros a las ciudades, pero si no quieres quedarte sin el tuyo, como ya ha pasado en anteriores eventos, a mí no me importa si me pones un correo electrónico y me dices si quieres una camiseta de la FOCA, camiseta de No Lusers o cualquier libro, para que te lo reserve. Los eventos son:

- 24 de Enero: Gira Up To Secure 2012 en Valencia
- 25 de Enero: Gira Up To Secure 2012 en Madrid
- 26 de Enero: Gira Up To Secure 2012 en Sevilla

Al mismo tiempo, estaremos en Pamplona haciendo una semana de Hands On Lab dedicado a SQL Server 2012, gracias a la colaboración con EGA Informática - nuestro partner en Pamplona de siempre -, que impartirá Rubén Alonso, a los que puedes apuntarte, y también llevará encantado algún libro si nos lo pides antes de que salga de viaje.

- 23 al 27 de Enero: Hands On Lab SQL Server 2012 en Pamplona

Por último, esta semana terminaré impartiendo un Seminario Online de la FOCA 3 en Español al que puedes apuntarte todavía si quieres conseguir una versión PRO de la FOCA 3.

- 27 de Enero: Seminario Online de FOCA PRO 3

Saludos Malignos!

miércoles, enero 04, 2012

Averiguar el Nombre de un Servidor SQL Server con Excel, Cadenas de Conexión, y Autenticación Integrada NTLM

Cuando estuve escribiendo la última parte de Hacking Remote Applications: Escaneando la Red Interna con Excel, acababa diciendo que, al igual que en los ataques de Connection String Parameter Pollution podríamos robar el hash NTLM de sesión para intentar crackear la contraseña de la cuenta con la que corre el servicio de Terminal Services o Citrix. Sin embargo, no hice la prueba hasta ayer mismo, ya que sabía que iba a funcionar. La sorpresa es que cuando lo he hecho me he encontrado con algo que yo no sabía y que me ha dado para jugar un rato. Esta es la historia.

Cuando hicimos las pruebas iniciales de robo de hash NTLM de sesión usamos CAIN, ya que directamente trae un módulo que reconoce las cadenas de autenticación por TDS (Tabular Data Stream) de SQL Server y nos hacía la vida mucho más fácil.

Figura 1: Hash NTLM de Sesión en CAIN, robado con un Connection String Parameter Pollution Attack

Sin embargo, cuando lo hemos probado con un Excel en Citrix conectándolo con una cadena de conexión a un Rogue SQL Server en el que teníamos montado un Wireshark, hemos encontrado un pequeño detalle que no había contemplado al inicio: El nombre del equipo en el que corre... el servidor SQL que responde, tal y como se puede ver en la siguiente captura.

Figura 2: Hash y Nombre de equipo en una conexión con autenticación integrada desde Excel

Como se puede apreciar, aparece no solo la negociación NTLM de sesión, sino también el nombre del servidor con el que estamos negociando, pero es el nombre interno de la máquina en la red, y no el publicado. Esto es así siempre que se utiliza SMB, y parece que al usar Autenticación Integrada para conectarse a SQL Server también va implicito ese comportamiento, algo en lo que no había caído.

De hecho, cuando he ido a repasar la herramienta que publiqué - que ya no está disponible en su repositorio - sobre cómo hacer fingerprinting a servidores SQL Server, he visto que en ninguna de las pruebas que realicé apareció el nombre del equipo. 

Figura 3: Fingerprinting SQL con esf

Sin embargo, probándolo con diferentes versiones hemos podido comprobar que siempre es posible acceder al nombre del equipo. Así que, basta con abrir tu Excel en local, hacer una cadena de conexión a un servidor SQL Server y, no importa si Wireshark trae el parseador para ese paquete o no, al final siempre se obtiene el nombre de la máquina. Y luego para celebrarlo, con el mismo Excel, te juegas un Missile Command o un Tower Defense

Figura 4: Nombre de equipo en un paquete de autenticación integrada TDS 
Resumiendo:
1) Busca un servidor SQL Server: Puedes hacerlo por Robtex, por Shodan, o utilizando un scan nmap por el puerto 1433.

2) Abre tu Wireshark y ponte a sniffar tráfico en tu máquina


3) Abre tu Excel y crea una cadena de conexión contra el servidor con autenticación integrada.

Nota: Recuerda que irá tu hash NTLM sesión, así que no uses una cuenta de importancia.
Como única solución, a parte de cancelar el inicio de sesión integrada en SQL Server, sería poner en los firewalls un filtrado de este tipo de paquetes, para evitar la fuga de información y, por supuesto, usar VPNs para conectarse al servidor SQL Server sería lo más que deseable, en caso de que tenga que estar expuesto externamente.

Saludos Malignos!

viernes, diciembre 16, 2011

Hacking Remote Applications: Escaneando la red con Connection Strings en Excel (II de III)

**************************************************************************************************
- Escaneando la red con Connection Strings en Excel (III de III)
Autores: Juan Garrido "Silverhack" & Chema Alonso
**************************************************************************************************

En la parte anterior de este artículo vimos como podíamos intentar conectar la aplicación Excel a un servidor interno de base de datos que se encontrara detrás del firewall utilizando las credenciales de la sesión Terminal Services o Citrix. Sin embargo, aunque ese servidor interno no exista aún se pueden hacer otras muchas cosas con las cadenas de conexión, como vamos a ver ahora.

Conexión al ficheros del sistema.

Una de las características que molan de las cadenas de conexión es que se pueden conectar a casi cualquier cosa. Así, en las técnicas de Remote File Downloading las utilizamos para poder acceder a ficheros del sistema operativo por medio de ataques de SQL Injection que las cargaban como "Fuentes infrecuentes". Esto lo vamos poder seguir realizando con un Excel en un servidor Citrix o Terminal Services, accediendo no solo a ficheros locales sino remotos en red local.

Para ello, se debe seleccionar la opción de crear una conexión ODBC de usuario y construirla en el perfil de usuario, en este ejemplo con Excel 2010. Como se puede ver hay posibilidad de conectarse a ficheros csv, txt, Excel, Access, dBASE o FoxPro, entre otros.

Figura 5: Drives para fichero en conexiones OLEDB

Para hacer esta conexión hay que generar un fichero de conexión a nivel de usuario que se tiene que guardar en el sistema, así que la mejor opción es usar los directorios para archivos temporales.

Figura 6: Construcción de la conexión a nivel de usuario

Una vez terminada la conexión se puede cargar cualquier archivo vía la cadena de conexión al sistema.

Figura 7: El fichero se toma como una tabla de 1 sólo campo en el que cada línea es una fila


Por supuesto, todo esto un poco extremo, y solo debería usarse cuando la opción Abrir estuviera totalmente capada o cuando no se pudiera acceder a la ruta por , pero, como puede verse.... funciona.

Figura 8: El fichero leído vía cadena de conexión en Excel

Conexión al Active Directory

Usando las cadenas de conexión también es posible acceder al servicio de Active Directory de la organización para hacer las consultas pertinentes desde Excel, ya que, por supuesto, este es una base de datos con información útil y necesaria.

Figura 9: Objeto de conexión para Microsoft Directory Services

Así, por ejemplo, si hubiéramos sido capaces de descubrir qué equipo tiene el servicio de Active Directory en la organización, podríamos crear una conexión contra él, haciendo uso de la credencial del usuario del sistema operativo, para después lanzar consultas LDAP.

Figura 10: Cadena de conexión a un servicio de directorio

**************************************************************************************************
**************************************************************************************************

Entradas populares