Si recuerdan, en la segunda y anterior parte de esta serie [ver primera entrada] acerca de ataques de Inyección SQL comenzamos a introducir las medidas de seguridad preventivas contra este tipo de amenazas, y dimos una serie de pautas básicas a seguir, como eran la utilización de funciones para la eliminación de carácteres de escape, el uso de consultas estáticas, o evitar el acceso a la base de datos con usuarios privilegiados. En esta tercera entrada, y antes de irme de vacaciones (sí, han leído bien), seguiré en esa línea, introduciendo herramientas para la realización de auditorías de código, que ayudan a evitar los problemas más comunes. Por supuesto, la habitual renuncia de responsabilidad “for educational purposes only” aplica.

Debe ser evidente, antes de pasar a las herramientas, que esto no pretende ser un listado exhaustivo, y que existen alternativas comerciales a todas ellas, pero pienso que las que les voy a indicar pueden ayudarles como punto de partida.

En primer lugar, destaca Sqlninja como detector de vulnerabilidades de Injección SQL en servidores basados en Microsoft SQL Server. Esta herramienta es capaz de lanzar diversos exploits que atacan directamente al gestor de base de datos demostrando el grado de seguridad y hasta qué punto puede quedar nuestro servicio comprometido. Es una herramienta muy completa y fácil de utilizar, y cuenta con menus que resultan bastante intuitivos.

Absinthe es otra aplicación de fácil manejo, y que cuenta con interfaz gráfica de usuario, que destaca por la sencillez y rapidez a la hora de parametrizar una auditoría. Admite auditorías sobre varios gestores de bases de datos, como pueden ser Postgres, MySQL, MS SQL, etc…

SQL Power Injector es otra aplicación completísima desarrollada con el lenguaje C# bajo la plataforma de desarrollo de .NET. La interfaz gráfica posibilita realizar una auditoría de forma rápida e intuitiva. Es válida para varios gestores de bases de datos.

Más que una aplicación, SQLIer puede considerarse un script que utiliza un ataque de tipo verdadero-falso para determinar usuario y contraseñas de las bases de datos. Es por tanto un script a nivel informativo, con el que se pueden determinar la fortaleza de las contraseñas utilizadas y el grado de defensa contra ataques de este tipo.

Por último, SQL Injection Pentesting TooL es otra utilidad con interfaz de usuario muy completa para la realización de auditorías. Aunque a diferencia de las anteriores en este caso no se dispone del código fuente de la aplicación, y únicamente se puede ejecutar bajo entornos Windows, su descarga es totalmente gratuita.

Como es habitual, desgraciadamente nada es perfecto y a pesar de las facilidades que estas herramientas introducen, será necesario auditar de forma manual todas las implicaciones que conlleva todo lo relacionado con la conexión, acceso y tratamiento de la base de datos. Por poner un ejemplo, en Java se deberían buscar todas las llamadas execute(), prepareStatement() y prepareCall(), y hacer una traza de las mismas. El uso combinado de estos dos tipos de auditorías, la realizada de forma manual y la automática a través de las aplicaciones mencionadas, nos ayudarán a filtrar todos aquellos “bugs” no tratados durante el proceso de codificación de la aplicación, obteniendo así una aplicación relativamente protegida frente a estos ataques de Inyección SQL.

Y de momento, esto es todo. Como suele decirse, to be continued…

Antes del pertinente, necesario, deseado y siempre corto descanso veraniego, recordarán que estuvimos hablando de ataques de Inyección SQL, utilizados al parecer en los ataques a la delegación de Microsoft en el Reino Unido el mes de junio y a la página Web de la ONU hace unas semanas.

Como les dijimos literalmente aquella vez, los ataques de inyección SQL se basan en explotar la interacción con el usuario ofrecida por aplicaciones Web (formularios de petición de datos, por ejemplo), para hacer llegar a la base de datos consultas SQL manipuladas. Y las principales herramientas utilizadas para ello son los caracteres que dentro de SQL sirven para declarar cadenas de texto: las comillas simples (‘) y los caracteres que introducen comentarios en el código (––), igual que en cualquier código fuente. Pues bien, los atacantes suelen aprovechar este tipo de caracteres para incrustar código aleatorio y conseguir validar cualquier sentencia manipulada. Vamos a ver un ejemplo:

Mientras que la sentencia anterior debería mostrar las características de un único usuario, al incrustar el atacante un operador “or” con una condición que siempre es cierta, consigue que la sentencia sea cierta para todos los usuarios, devolviendo la base de datos por tanto todos los datos de la tabla users.

Como medida de seguridad, los distintos entornos de programación poseen ciertas funciones en las que se revisa estos tipos de entrada para evitar que lleguen a la base de datos. Por poner algunos ejemplos, en PHP por ejemplo existe la función mysql_real_escape_string para MySQL, en JAVA tenemos la función PreparedStatement, en Mono y C# de .NET se trata con las funciones SqlCommand (para Microsoft SQL Server) y OracleCommand (para gestores Oracle). De esta forma, si validamos tanto las entradas de primer orden como las de segundo, es decir, no sólo los posts, gets, cookies, sino también las que provienen de lectura de ficheros, bases de datos, etc… conseguimos filtrar instrucciones no deseadas, errores por tipos de datos, y manejo de tablas de la base de datos.

Como complemento de la seguridad en la aplicación, es recomendable generar las consultas de forma estática en la medida de lo posible, es decir, si predefinimos las consultas obligaremos al usuario de la aplicación únicamente a interactuar con los parámetros, por lo que no existe la posibilidad de que éste modifique las sentencias.

Hay muchas otras recomendaciones, como por ejemplo no acceder a la base de datos desde la aplicación con una cuenta de usuarios con privilegios de administrador, o hacer un uso restringido y controlado de los llamados “procedimientos almacenados”, pero de eso hablaremos en la tercera parte de esta serie.

Siendo éstos los tiempos de la Web 2.0, es muy habitual que una empresa ofrezca servicios a través de aplicaciones Web; éstas se convierten en la interfaz perfecta para que todo el mundo desde cualquier lugar acceda a información que muy probablemente se almacena en bases de datos. Esta entrada (y otras que le seguirán) viene a mostrar uno de los ataques más habituales hoy en día en este tipo de aplicaciones: el ataque de inyección SQL, por el que adquiere especial importancia el tratamiento de la información que fluye entre el aplicativo visible al usuario que la muestra (lo que podríamos llamar el frontend) y la base de datos que la almacena y gestiona (lo que vendría a ser el backend).

Dejando los detalles técnicos para más adelante, este ataque se basa en explotar la interacción con el usuario ofrecida por aplicaciones Web (formularios de petición de datos, por ejemplo) para hacer llegar a la base de datos consultas SQL manipuladas, que al no ser filtradas correctamente por el aplicativo web pueden tener efectos indeseados, como proporcionar información sobre el sistema, la estructura de la BD, o incluso acceso o borrado de los datos almacenados. Una variante muy interesante de este tipo de ataques es el “Blind SQL Injection“, o ataque a ciegas por inyección SQL, que aprovecha el resultado obtenido tras lanzar consultas que emiten páginas de error no tratadas por el desarrollador de la aplicación.

Se requiere de varias técnicas y algo de dedicación para poder filtrar este tipo de ataques. De nada sirve, por ejemplo, tener un servidor Web sirviendo páginas cifradas si el atacante puede insertar cualquier tipo de parámetros, lo que además invalidaría un sistema de detección de intrusos, puesto que no podría descifrar los accesos. Hay que tener en cuenta que el atacante intentará aprovechar cualquier información que le proporcione indicios de alguna vulnerabilidad, comenzando por algo tan simple como puede ser la versión de nuestro gestor de base de datos, el nombre de cada una de las tablas, usuarios por defecto,… y así sucesivamente, hasta conseguir en el peor de los casos usuarios con permisos de administración e incluso la ejecución a través de comandos en el propio sistema que soporta la base de datos.

Como en la mayoría de los casos, las tareas que hay que realizar orientadas a prevenir este tipo de ataques no suponen un gran esfuerzo en comparación con el trabajo que supondría restaurar la información de una base de datos que ha sido comprometida, así como la credibilidad de los usuarios al comprobar que se ha detectado un ataque culminado en una base de datos con información relevante, entre otros muchos factores negativos (¿… de cuándo dices que es la última copia …?). Como siempre, evitar el robo de información y el tratamiento no controlado ni permitido de ésta requiere una atención especial.

Sin extendernos más, y como cierre de esta introducción, la seguridad aplicada a la integridad y privacidad de los datos almacenados en las bases de datos no es trivial, pero podemos tener cierto grado de tranquilidad si aplicamos algunas recomendaciones para los distintos casos y métodos de ataque.

[Gráfico de Acunetix.com]