Introducción a ataques de tipo inyección: Inyección SQL

Transcripción

1 Introducción a ataques de tipo inyección: Inyección SQL Jorge Peris Cortés - jorpecor@alumni.uv.es Asignatura: Redes Ingeniería Informática - Curso 2011/2012 Universidad de Valencia 1

2 Índice INTRODUCCIÓN... 3 DEFINICIÓN... 3 OBJETIVOS... 4 CONCEPTOS CLAVE... 5 EVALUACIÓN DE RIESGOS... 5 APLICACIONES UTILIZADAS... 6 EJEMPLO 1: ATAQUES A DVWA... 7 CONCLUSIÓN... 9 EJEMPLO 2: ATAQUES A MINI-APLICACIÓN CONCLUSIONES BIBLIOGRAFÍA

3 Introducción Con este documento, pretendemos hacer hincapié en cómo se encuentra actualmente la seguridad en aplicaciones web y el grado de dificultad (en algunos casos, de facilidad) con que un usuario puede explotar ciertas vulnerabilidades a la hora de atacar un sistema con información almacenada en una base de datos. Además, veremos cuáles son las técnicas básicas para poder llevar a cabo este cometido, por supuesto teniendo en cuenta que nuestros fines son puramente didácticos. Como organización de referencia hemos elegido a Open Web Application Security Project (OWASP) que es una comunidad abierta que busca mejorar la seguridad en las aplicaciones de software. Cada cierto tiempo, esta comunidad publica un documento donde, principalmente, se especifican los 10 vectores de ataque más utilizados sobre aplicaciones, este documento es el OWASP Top 10. El último publicado ha sido el OWASP Top , por lo que es un buen punto de partida. En él se especifica que los ataques de tipo inyección son los que más se producen. Por ello, hemos elegido centrarnos en un tipo en concreto, inyección SQL, que es un vector de ataque muy extendido y documentado, además de que su funcionamiento básico es sencillo de comprender. Definición Inyección SQL es una técnica de infiltración de código que permite realizar consultas a una base de datos. Se produce cuando un atacante es capaz de insertar una serie de sentencias SQL dentro de una consulta manipulando los datos de entrada dentro de una aplicación. En otras palabras, es un tipo de ataque que consiste en introducir código SQL desde el cliente en una aplicación a través de datos de entrada. Un ataque con éxito podría permitir, entre otras cosas: 1) Ejecutar acciones sobre una BD simulando ser root y, por tanto, poder ejecutar consultas del tipo: UPDATE/INSERT/SELECT/DELETE. A raíz de esto, aparecen dos vertientes de acciones posibles. Una de ellas sería, por ejemplo, realizar un DROP TABLE Clientes lo que implicaría una pérdida de datos (otro motivo por el que almacenar copias de seguridad). La otra sería acceder a la 3

4 información añadiendo un nuevo usuario con permisos de administrador, por ejemplo, INSERT INTO Administradores (id, nombre, pass) VALUES (, atacante, ), con lo que hubiésemos añadido un usuario no permitido en la tabla que contiene a todos los administradores. A partir de ahí, podríamos recabar información a nuestro antojo. El inconveniente de ello, es que hay que conocer de antemano las tablas con las que cuenta la BD, así como sus atributos, pero haciendo pruebas podrían obtenerse resultados satisfactorios. 2) Ejecutar comandos de llamada al SO. En este caso, el nivel de acciones dependerá de los privilegios vigentes de la máquina atacada. Desde esta perspectiva, podríamos realizar llamadas al sistema que apaguen la máquina sobre la que se ejecuta la BD, o conseguir información sobre la versión utilizada de BD, tipo de servidor sobre el que se ejecuta, lenguaje de programación utilizado, etc. Como ejemplos, podríamos llamar a algunas funciones interesantes: Lectura de fichero (permiso de lectura ON): load_file( Disco:\\RUTA\\ ) Versión actual del servidor: version() Actual usuario de la BD: system_user() Objetivos Al realizar ataques de tipo inyección SQL, el objetivo suele ser muy claro: obtener la mayor cantidad de información posible, intentando minimizar los rastros. Aunque ambos requisitos son importantes, podríamos decir que la recopilación de información es de mayor importancia que las huellas digitales que se hayan podido dejar durante el proceso del ataque. Esto es debido a que todo ataque requiere de una planificación previa, por lo que los posibles inconvenientes de dejar rastros se minimizarían durante esta fase. Sin embargo, todo dependerá de la relación entre el coste del ataque y el beneficio que obtendríamos si tuviésemos éxito, ya que si el coste es superior o igual al beneficio, ni tan siquiera se plantearía la opción de empezar a planificar un posible ataque. 4

5 Conceptos clave En este punto, explicaremos qué necesitamos específicamente para poder explotar una consulta SQL. Nuestro principal objetivo es introducir de alguna manera - tendremos que ingeniárnoslas - alguna condición que se evalúe siempre a TRUE. Antes de empezar, conviene recordar dos conceptos básicos de lógica booleana, que resumen perfectamente qué entradas producen ciertas salidas. Tabla AND Tabla OR Los cuadrados de fondo AZUL representan las entradas que pondríamos en el formulario. Los cuadrados de fondo VERDE representan el resultado que obtendríamos al terminar. Evaluación de riesgos En este punto, es interesante explicar en qué medida repercuten las posibles acciones maliciosas de un ataque de inyección SQL sobre un supuesto entorno de trabajo. Mediremos 5 factores fundamentales, que pasamos a explicar: Explotabilidad: grado de facilidad para inyectar el código en la aplicación. No es lo mismo enviar datos mediante formulario que tener que cargar un fichero en un servidor. Predominio: grado de difusión de las técnicas que explotan una vulnerabilidad, es decir, cuanto mayor sea este factor, más fácil le resulta a un atacante encontrar información efectiva sobre un ataque. 5

6 Detección: mide el nivel de complejidad para encontrar qué causa produjo el ataque. En este caso, hay que mirar el código que contiene la lógica para encontrar por dónde ha podido filtrarse una entrada maliciosa. Impacto: medida de la repercusión que puede llegar a tener un conjunto de ataques, que puedan considerarse como los más dañinos. Aplicando las definiciones al caso que estamos analizando, obtenemos los siguientes resultados: Explotabilidad -> FÁCIL Basta con enviar texto plano que explote la sintaxis del intérprete objetivo. Predominio -> CONOCIDO Encontramos fácilmente cadenas típicas de ataque para inyección SQL. Muy documentado, incluyendo webs específicas que son vulnerables y que contienen tutoriales sobre cómo llevar a cabo algunos ataques. Detección -> MEDIO Es necesario acceder al código que contiene la lógica para poder encontrar las vulnerabilidades. Desde el lado del cliente, haciendo pruebas, es más complicado. No siempre es sencillo filtrar todas las entradas posibles. Impacto -> ALTO Un simple ataque puede causar pérdida o corrupción (total o parcial) de los datos. Podría verse afectado el sistema que haya por debajo de la BD (apagado de la máquina, denegación de acceso, eludir autentificaciones...). En resumen, podemos decir que los recursos de los que debemos disponer son reducidos, bastará con un equipo con una conexión a internet, conocimientos básicos sobre BBDD y algo de imaginación. Aplicaciones utilizadas A continuación, veremos un par de ejemplos sobre cómo explotar una aplicación web, incluyendo, tanto el código que corre en el servidor, como el código que inyectamos desde el cliente. La técnica de inyección que hemos visto la probaremos sobre las siguientes aplicaciones: 6

7 Aplicación web programada en PHP y MySQL, llamada Damn Vulnerable Web Application, de libre distribución. Pequeña (y absurda) aplicación web que he creado para la ocasión, también en PHP y MySQL. Antes de comenzar con los ejemplos, nos detendremos brevemente para explicar el funcionamiento más básico de la aplicación web DVWA. DWVA es una aplicación web basada en PHP y se apoya en una base de datos mediante MySQL. Para acceder a ella, sólo es necesario descargar su código fuente desde la página oficial y copiarlo en el repositorio deseado. Para acceder a ella, si tenemos un servidor funcionando sobre nuestro mismo equipo, podemos teclear la siguiente dirección en nuestro navegador preferido sabiendo que el usuario por defecto es admin y la contraseña password (muy segura). La aplicación está diseñada en dos marcos principales, el de la izquierda tiene varios botones que permiten seleccionar los diferentes tipos de webs vulnerables, así como botones adicionales para la configuración de la BD y del nivel de seguridad del código que se ejecuta en cada momento, y el de la derecha se limita a mostrar el contenido de la selección elegida. Nosotros nos centraremos únicamente en SQL Injection y sus 3 niveles de seguridad. Ejemplo 1: Ataques a DVWA 1) Ataque al nivel LOW: La página recibe una entrada por formulario, user_id, cuya consulta es: SELECT first_name, last_name FROM users WHERE user_id = $id Podemos observar, mirando el apartado de mostrar código, que no se filtra la entrada, lo que supone un fallo grave de seguridad. De este modo, como atacantes podemos escribir en la entrada de datos por formulario la siguiente cadena: ' OR '1'='1 Que, sustituyendo en la consulta original, quedaría de la siguiente forma: SELECT first_name, last_name FROM users WHERE user_id = ' OR '1'='1 7

8 De este modo, obtendremos un listado con todos los usuarios, tanto su nombre como su primer apellido, registrados en la base de datos. 2) Ataque al nivel MEDIUM: En este nivel de seguridad sí que se realiza un filtrado de la entrada, lo podemos ver haciendo clic de nuevo en mostrar código. La función que se utiliza es mysql_real_escape_string(string), cuya función básica es escapar una serie de cadenas frecuentemente utilizadas para inyectar código. Sin embargo, en ocasiones no es suficiente con filtrar las entradas con funciones de escape. En este caso en concreto, se puede explotar el hecho de que la consulta espera un número en el campo user_id, y a raíz de esto, atacar de una manera muy similar que al nivel anterior. Ahora, la entrada de datos por formulario quedaría del siguiente modo: 1 OR 1=1 Y, de nuevo, si sustituimos en la consulta original, obtendremos la consulta completa: SELECT first_name, last_name FROM users WHERE user_id = 1 OR 1=1 Cabe destacar, que se hace necesario un estricto control en el uso las comillas, ya que son la principal fuente de errores a la hora de practicar este tipo de ataques, con la tediosa característica de que son difíciles de detectar, pues los mensajes de error en SQL suelen ofrecer poca información, por ejemplo syntax error. 3) Ataque al nivel HIGH: Por último, veremos cómo nos es imposible atacar mientras este nivel de dificultad se halle activado, pues su principal punto defensivo es desechar todo aquello que no sea un número. En el nivel HIGH la entrada se filtra mediante el uso de 3 métodos: mysql_real_escape_string(string), que ya vimos en el punto anterior; stripslashes(string), que elimina las barras invertidas que encuentre en la cadena que se le pase como parámetro; y adicionalmente, se hace una comprobación de si la variable 8

9 $id es un número o no. Ante este filtrado, no podemos hacer nada, ya que necesitamos escribir alguna palabra de SQL para poder realizar una inyección efectiva. Por tanto, frente a esta situación, no es posible atacar. Conclusión Como hemos demostrado anteriormente, no siempre basta con filtrar. Por consiguiente, podemos confeccionar una metodología que pueda ayudar al programador a la hora de construir una buena defensa en su sistema que interactúe con BBDD: Filtrar entradas. Limitar número de caracteres. Conocer el problema y establecer rangos adecuados para los datos. Mostrar la información estrictamente imprescindible. Para terminar con este apartado, resumiremos, de un modo muy esquemático, los conceptos fundamentales necesarios para atacar una BD: Paciencia, tiempo y dedicación. Probar adecuadamente diferentes alternativas. Conocer lenguaje de manipulación de la BD. 9

10 Ejemplo 2: Ataques a mini-aplicación Para este segundo ejemplo, hemos creado una aplicación muy sencilla, que se encarga de recoger una serie de datos por un formulario, contrastarlos con una BD y mostrar un mensaje por pantalla, que variará en función de los datos que haya introducido cada usuario. Veamos a continuación, cuáles son los módulos que forman el sistema. Contenido web - HTML Las 3 páginas web existentes en esta sencilla aplicación web están escritas en HTML, cuyo código se limita a llamar a otras webs y a procedimientos escritos en PHP. Cabe destacar que realizaremos los ataques siempre desde este lado de la aplicación, es decir, desde el lado del cliente. Programa en servidor - PHP Respecto al lado del servidor, tenemos 2 procedimientos independientes, que son llamados desde las páginas web correspondientes, es decir, las que ofrecen formularios a rellenar por un cliente, y realizan dos funciones muy concretas: Por un lado, tenemos el fichero login.php, que se encarga de consultar en la BD si el usuario y la contraseña son correctos y, de ser así, mostrar un mensaje de bienvenida con el nombre de usuario bien visible y la hora del sistema. 10

11 Por otro lado, tenemos el fichero registro.php, que se limita a ingresar un usuario nuevo en la BD, pidiendo un nombre y una contraseña. Base de datos - MySQL Para terminar, hemos elegido una BD como MySQL, junto con un administrador vía web PHPmyAdmin, dado que es un SGDB muy sencillo de utilizar e intuitivo, y para hacer este tipo de pruebas funciona perfectamente, ya que además, permite realizar consultas a la propia BD desde esta web de administración, con lo que podemos depurar los posibles fallos en las consultas y, cómo no, los ataques que realicemos posteriormente. Posibles ataques En este caso veremos cómo realizar 2 ataques muy sencillos a la BD, que nos van a permitir obtener un listado completo de todos los usuarios, sin tener siquiera un usuario registrado. Los ataques siempre se realizan desde la página web form_login.html. Como primer ejemplo de ataque, tanto en el campo usuario como en el de contraseña (ver explicación detallada en pág.6) introduciremos la cadena maliciosa: OR 1 = 1 Como segundo ejemplo, en el campo usuario introduciremos la cadena maliciosa: OR 1=1--_ Mucho cuidado con esta cadena, que lleva un espacio en blanco al final de la misma, que hemos resaltado en color gris e indicado con un guión bajo. La principal diferencia entre ambas cadenas es que en la segunda no es necesario rellenar más campos adicionales, pues el doble guión al final, implica comentar el resto de la sentencia SQL asociada. Por supuesto, para poder hacer estas afirmaciones, es necesario conocer la estructura de la consulta, si queremos obtener los resultados esperados. Por tanto, aunque no veremos aquí el código completo, sí que mostraremos a continuación cómo son las consultas SQL: 11

12 Recuperar datos: SELECT * FROM PruebaUsuarios WHERE nombre= $nom_form AND pass= $pass_form Introducir datos: INSERT INTO PruebaUsuarios(id,nombre,pass) VALUES (' ','{$_POST['usr']}','{$_POST['pass']}') Como hemos dicho anteriormente, veamos cómo quedan ambas cadenas maliciosas inyectadas en el código SQL, desde el formulario web: Utilizando el primer ejemplo de ataque: SELECT * FROM PruebaUsuarios WHERE nombre= OR 1 = 1 AND pass= OR 1 = Utilizando el segundo ejemplo de ataque: SELECT * FROM PruebaUsuarios WHERE nombre= OR 1=1-- AND pass= $pass_form Fijémonos en el espacio en blanco después del doble guión y en que la consulta SQL a partir de ese espacio en blanco, quedaría comentada. Conclusiones A lo largo de todo este documento, hemos visto cómo comprometer una BD con una cantidad muy reducida de recursos, conocimientos básicos de SQL y un poco de imaginación. Desde aquí, animo al lector a que haga sus propias comprobaciones en entornos controlados, ya que considero que es el mejor modo de aprender los entresijos de la aplicación de estas técnicas. 12

13 Bibliografía Información genérica acerca de inyección SQL o OWASP Top , The ten most critical Web Application Security risks. PHP y SQL Información específica de inyección SQL en varios entornos on_sql_sql_injection-t html 13