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