martes, agosto 07, 2007

Protección contra las técnicas de Blind SQL Injection (IV de IV)

***************************************************************************************
Protección contra las técnicas de Blind SQL Injection (I de IV)
Protección contra las técnicas de Blind SQL Injection (II de IV)
Protección contra las técnicas de Blind SQL Injection (III de IV)
Protección contra las técnicas de Blind SQL Injection (IV de IV)
***************************************************************************************

Un ejemplo con Absinthe

Hablamos de esta herramienta el mes pasado, pero hoy vamos a hacer un ejemplo completo real. Para ello hemos buscado una url “controlada” en la que teníamos un parámetro id que recibía un valor numérico en este caso.

http://www.miwebserver.com/miprograma.asp?id=370

Hemos realizado una sencilla prueba de inyección con:

http://www.miwebserver.com/miprograma.asp?id=370 and 1=1
http://www.miwebserver.com/miprograma.asp?id=370 and 1=0


Con la primera inyección (and 1=1) hemos obtenido la misma página que sin inyección y con la segunda inyección (and 1=0) hemos obtenido una página diferente, con otros resultados. Suponemos, o sabemos, que es SQL Server, pero como las alternativas son pocas (MS SQL Server, Oracle, DB2, MySQL, etc…) podríamos incluso ir probando diferentes motores. Configuramos absinthe:

Paso 1:Configuración de la inyección a ciegas:

- Seleccionamos el motor de bases de datos. En este caso Microsoft SQL Server porque lo sé, pero si desconozco la versión puedo chequear el checkbutton de “Verify SQL Server Version”.
- En target URL ponemos la llamada al programa sin poner los parámetros, en este caso: www.miwebserver.com/miprograma.asp
- En el envío de parámetros seleccionamos por GET.
- En la parte de parámetros creamos un parámetro ID con valor por defecto 370 en el que marcaremos que es inyectable.
- Realizamos una prueba con Initialize Injection.


Imagen: Paso 1

Paso 2: Una vez configurado esto, la herramienta ya funciona sola, pasando a la pestaña de “DB Schema” podremos, en primer lugar averiguar el usuario, en segundo lugar, si el usuario tiene acceso al diccionario de datos, descubrir la estructura de tablas de la base de datos y por último consultando también al diccionario, descubrir los campos y tipos de datos de cada una de las columnas de las tablas. Una carencia de esta herramienta es la no posibilidad de descubrir los objetos por fuerza bruta, pero es perfecta en los entornos en los que el usuario tiene acceso al diccionario de datos. En la imagen se puede ver el usuario descubierto y las tablas que están siendo descubiertas.

Paso 2: Descubrimiento de usuario y tablas de la aplicación.

Para realizar este descubrimiento la aplicación va a generar por debajo un gran número de peticiones que funcionan como hemos explicado en el capítulo del mes pasado. En la siguiente imagen se puede ver una porción de las llamadas para descubrir los campos de las tablas.

Imagen: Petición para descubrir los nombres de los campos.

Como se puede apreciar en las peticiones, al parámetro vulnerable se le une con un AND una petición en la que se intenta ver si un determinado carácter es igual a un determinado valor ASCII. Como se ve se está consultando a syscolumns y se utilizan valores UNICODE para evitar el filtrado de comas o comillas.

Paso 3: Extracción de datos de tablas. Una vez descubierta la estructura completa de la base de datos el último paso a realizar es descargar la lista de datos de los campos, para ello, con seleccionar la tercera pestaña accederemos a la lista de los campos descubiertos y podremos descargarlos a un fichero XML.

Imagen 3: Extracción de datos.

Otras herramientas

El número de herramientas que realizan descubrimiento y explotación de vulnerabilidades Blind SQL Injection crece día a día, pero no me gustaría terminar el artículo sin citar algunas otras:

SQL Ninja, escrita en Perl y que realiza inyección basada en tiempos para motores Microsoft SQL Server (tienes la herramienta en la siguiente URL: http://sqlninja.sourceforge.net/ y más información en: Blind SQL Injection (III). SQL Ninja

SQLiBF

Herramienta publicada en el año 2006, desarrollada por DarkRaven, un consultor de seguridad afincado en Murcia, está pensada y adaptada para bases de datos genéricas, pero también para bases de datos específicas en las que realiza comprobaciones de inyección de comportamiento cero. A diferencia de otras realiza tests de comprobación para saber si un parámetro es vulnerable basados en número de líneas, número de palabras o palabra clave:

La herramienta tiene como curiosidad también la búsqueda de terminadores de expresiones con paréntesis para poder completar las inyecciones correctamente. La herramienta es Software Libre y está disponible en la siguiente URL:
http://www.open-labs.org

SQLiBF descubriendo por Blind SQL Injection el usuario de la aplicación

WebInspect

Esta herramienta se comercializa por la empresa SPI Dynamics desde el año 2005 y está mantenida bajo los estudios de Kevin Spett. Al ser una herramienta comercial no se dispone del código y solo se conoce su funcionamiento en base a las especificaciones del producto y a como es descrita en el documento “Blind SQL Injection. Are you web applications vulnerable?”. Funciona utilizando comprobaciones de error basadas en firmas, pero no se sabe si la aplicación utiliza la automatización basada en palabras clave. Lo que no aparece descrito en ningún apartado de las características es la utilización de automatismos basados en tiempo. Esta herramienta es una herramienta de carácter general en cuanto a seguridad de aplicaciones y está pensada para buscar todo tipo de vulnerabilidades. La información de la herramienta está disponible en la siguiente URL: WebInspect

Acunetix Web Vulnerability Scanner

Acunnetix es una herramienta de la que ya hablamos hace dos meses como una buena alternativa para la auditoría de aplicaciones web de forma automática. En la versión 4 de la herramienta se añadieron módulos para la detección de vulnerabilidades Blind SQL Injection y Blind XPath Injection (de estas últimas podríamos hablar algún día por esta sección). Esta herramienta una muy buena alternativa para realizar la comprobación de la seguridad de tu aplicación web, incluso para vulnerabilidades a ciegas.

Configuración módulo Blind SQL Injection/Blind XPath Injection para Acunetix Web Vulnerability Scanner 4

Protección contra Blind SQL Injection

Las protecciones para SQL Injection son las mismas que contra SQL Injection. Fácil ¿no? Como hacerlo, pues comprobando absolutamente todo. Hoy en día, en todos los documentos técnicos en los que se evalúa el desarrollo de aplicaciones seguras está disponible un amplio estudio sobre como desarrollar protegiendo los programas contra la inyección de código.

Michael Howard, uno de los padres del modelo SDL (Secure Development Lifecycle) utilizado por Microsoft en el desarrollo de sus últimas tecnologías y escritor del libro Writting Secure Code (2nd edition) dedica todo un tema a evitar la inyección de código y lo titula de forma muy personal:

“All Input Is Evil! Until proven otherwise”

Además, casi todos los fabricantes o responsables de lenguajes de programación de aplicaciones Web ofrecen “Mejores Prácticas” para el desarrollo seguro dando recomendaciones claras y concisas para evitar la inyección de código. Así que a comprobar todo.

Toda consulta que se vaya a lanzar contra la base de datos y cuyos parámetros vengan desde el usuario, no importa si en principio van a ser modificados o no por el usuario deben ser comprobados y realizar funciones de tratamiento para todos los casos posibles. Hay que prever que todos los parámetros pueden ser modificados y traer valores maliciosos. Se recomienda utilizar códigos que ejecuten consultas ya precompiladas para evitar que interactúe con los parámetros de los usuarios.

Así mismo, como se ha visto los atacantes intentan realizar ingeniera inversa y extraer información de las aplicaciones en base a los mensajes o tratamientos de error. Es importante que se controlen absolutamente todas las posibilidades que puedan generar error en cualquier procedimiento por parte del programador. Para cada acción de error se debe realizar un tratamiento seguro del mismo y evitar dar ninguna información útil a un posible atacante.

Es recomendable que los errores, tanto los errores de aplicación como los de servidor, se auditen pues puede representar un fallo en el funcionamiento normal del programa o un intento de ataque. Se puede afirmar que casi el 100 % de los atacantes a un sistema van a generar algún error en la aplicación.

Despedida

Este ha sido sido el último artículo sobre la serie de Blind SQL Injection. Seguiremos tocando este tema en otras ocasiones, pero por ahora toca pasar a otros temas nuevos....

12 comentarios:

Anónimo dijo...

Enhorabuena..

Entonces ya has terminado tu tesina...

Un abrazo.5|5()|>

Anónimo dijo...

La verdad, siempre me ha hecho gracia esto del SQL injection. Creía que lo único susceptible de este ataque era PHP, pero veo que también pasa lo mismo con ASP. (Bueno, aparte de lo que te permita el lenguaje, también hay que tener en cuenta la mala programación). He programado en java usando JDBC, y nunca me he preocupado por lo que puedan enviarme. Imagino que en .NET también se pueda programar igual. Si no, mal va...

Es más, si se es tan tonto (o si el lenguaje no permite otra cosa) como para programar concatenando cadenas al hacer los select a la BD, en lugar de pasar los datos por parámetro... Mal vamos. Ir a buscar seguridad en una solución así, es como buscar peras al olmo.

Anónimo dijo...

Que digo yo, más que cómo protegerse, estos artículos tratan cómo EXPLOTAR vulnerabilidades usando Blind SQL Injection, ¿no? Salvo el par de comentarios finales de este último artículo.

NetVicious dijo...

Ahí le has dado bastian, es lo que comenté yo en el post de la tercera parte.

Pensaba que en este último procedería a explicar las medidas de protección pero veo que no.

BlackTigerX dijo...

muy buena serie maligna

salu2

Anónimo dijo...

Según acabo de leer, el que quiera hacer pruebecitas de SQL Injection tiene miles y miles de webs para probar.

Menos mal que WP es opensource y libre y todo eso, si no tendría más agujeros... ¿o no?

Sorian dijo...

Ha estado de puta madre Chema. Qué pena, ya que le teníamos cariño a ver cada mañana un poquito de blind, ^^, pero bueno a ver con que nos sorprendes =:p

Por cierto, sigo flipando cada día más, mientras más alto es el edificio, más cañonazos se le puede dar.Lo que me doy cuenta es la falta de conciencia es directamente proporcional a la diversión del aprendizaje. jeje

Saludos !!

Gangrolf dijo...

A mi esto me ha llegado al alma:

Atsiv: utilidad gratuita que permite saltarse las defensas de Windows Vista

Si, en kriptópilos lo han publicado... Aquí está la URL:

http://www.kriptopolis.org/atsiv

Es genial, se diseña un sistema para que sólo puedas instalar lo que está probado que funciona y no jode al sistema, y ya han encotnrado la manera de instalar cualquier cosa. Luego se quejarán de que su sistema se caiga o no rinda. Y encima tienen los santos webs de decir que es una estrategia de microsoft para que quien quiera desarrollar para Vista tenga que pagar pasta. Mola eh? Diseño un vehículo que quiero que todo el mundo tenga, y me dedico a poner trabas para que vendan su combustible en las gasolineras.
De verdad que esa noticia me ha sonado a "he conseguido trucar una moto de 50 para que se ponga a 200"-> "la moto me ha explotado, y eso que decian que era la más seguria, malditos mentirosos, mira que no poder echar nitroglicerina al depósito... seguro que están compinchados con las petroleras"

Chema Alonso dijo...

@Gangrolf,

no te sulfures, lo que ha publicado el amigo de la ciudad de los krispis es una jilipollez como un piano. La herramienta usa un certificado de Microsoft para poder cargar drivers. Y cuando carga un driver legitimo, carga otro. ¿dónde está la magia? Se usa un certificado para ... saltarse el uso de certificados? Además, habla de dinero y no sabe de que va.

Por cierto, lo que no ha dicho, es que con una clave de registro la comprobación de firma de drivers en 64 bits se deshabilita, solo hay que usar google para mirarlo. En definitiva, lo único que sucede es que esta empresa se está jugando la renovación de su certificado para desarrollo de drivers. Así de sencillo. Ah, y no olvidemos, que tanto para cambiar la clave, como para instalar un driver hay que ser administrador, que en Windows Vista ya no es tan habitual.

Chema Alonso dijo...

@anónimo 1. Estoy en ello, estoy en ello. A ver si salen las cosas en plazo. Ya avisaré!. :P

@anónimo 2, buena reflexión.

@bastian, el conocer el peligro te hace buscar soluciones, ¿no?. ¿Como era eso que decía Socrates?

@BlacktigerX, gracias!

@Julio, WP ha pillado tanto cacho, que no se como sigue pillando. ¿Será el PHP? ¿Será el guaraná?

@Sorian, cuando me digo :"ya no me sorprende nada en esto de la seguridad" aparece otra cosa y me deja flipao. Yo creo que por eso engancha tanto.

Saludos veraniegos!

Anónimo dijo...

Si no digo que los artículos estén mal, pero lo que el título "vende" y lo que luego tratan los artículos son cosas distintas, ¿no crees?

[?] dijo...

Man esta bien ese programa pero lo malo es que no todas las blind sql son iguales es lo malo de los programas automatizados nunca tedan lo que buscas :
1=1
(ejecucion)

Este metodo es para saltanser los campos del login
1=120%login"cookie"

Solo editas tu cookie por los personas en (ID)="1" listo lo guardas y ya tienes tu login

Es cuestion de buscarle ya que
La blind sql blind (ID) blind(path)
etc...
SOLO SE VASAN EN LAS COOKIES

=D

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares