INYECCIN SQL.

WEB Y ESCRITORIO
INTRODUCCIN Y CONOCIMIENTOS PREVIOS Antes de comenzar a leer este texto sobre SQL Injection debo avisar de que para entenderlo correctamente es recomendable (no necesario) saber al menos unos conocimientos mnimos de SQL. No obstante en este texto se incluye una lista de comandos bsicos del lenguaje SQL Definicin de SQL(segn wikipedia): El Lenguaje de consulta estructurado (SQL Structured Query Language ) es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones sobre las mismas. Una de sus caractersticas es el manejo del lgebra y el clculo relacional permitiendo lanzar consultas con el fin de recuperar -de una forma sencilla- informacin de inters de una base de datos, as como tambin hacer cambios sobre la misma. Definicion de SQL Injection: El sql injection es un tipo de ataque a una base de datos en el cual, por la mala filtracin de las variables se puede inyectar un cdigo creado por el atacante al propio cdigo fuente de la base de datos. Listado de comandos bsicos en SQL: Grant Utilizado para otorgar privilegios Revoke Utilizado para eliminar privilegios Create Utilizado para crear nuevos elementos(tablas,idices) Drop Utilizado para eliminar elementos Alter Utilizado para alterar campos de las tablas Select Utilizado para consultar registros de una tabla y comprobar que satisfagan una condicin determinada Insert Utilizado para cargar lotes de datos en la base de datos Update Utilizado para cambiar valores de registros y campos Delete Elimina registros de una tabla de la base de datos

Lista de clausulas bsicas en SQL: From Selecciona la tabla sobre la cual se va a operar (o sobre sus registros) Especifica las condiciones que se deben cumplir los registros que se seleccionan Utilizado para separa registros en grupos Especifica las condiciones que cumple cada grupo Ordena registros selecionados

Where

Group by Having Order by

Antes de nada aclarar la razn de por qu estos ataques son tan peligrosos: pueden no solo sacar informacin de la base de datos (usuarios, contraseas, etc), sino tambin pueden borrar la base de datos, dejarla inservible o aplicarse a ataques DDOS entre otros. Introduccin al mtodo error y comprobacin de la vulnerabilidad del servidor Antes de nada destacar que esta informacin es puramente informativa y va enfocada al conocimiento, nunca a la realizacin de prcticas ilegales. Bien, empecemos a analizar la vulnerabilidad de nuestro objetivo, en cuanto a ataques SQL. Comencemos: lo primero que necesitamos es buscar algn indicio de que la web o el programa es vulnerable. Enfoquemos este apartado a sitios web. SQl Injection a pginas web. Imaginad que estis diseando una pgina web, es muy bonita, al cliente le gusta, se pone en marcha y a los 5 minutos es hackeada por algn indeseable que ha borrado la base de datos, sera un desastre. Es de recibo que, actualmente, los diseadores de pginas deben tener en mente un poco de seguridad informtica para que su pgina no resulte vulnerable, al menos en los casos tpicos. Es lo que se pretende con este manual: que el diseador tenga nociones de seguridad tpicas. Veamos primero si la web en cuestin tiene este tipo de sentencias en su url: "celebraciones.asp?ID=", "libros.php?view=", o cualquier otro tipo parecido. En

muchas ocasiones, introduciendo ah nuestro cdigo inyectado empieza el ataque , pero esto lo explicaremos ms adelante. Nota1: no siempre que tenga este tipo de sentencias es vulnerable Nota2: si ves ASP,ASPX,etc , piensa en que en un elevado tanto por ciento de los casos, la base de datos ser SQL. Nota3: Para comenzar el ataque, tambin podemos buscar formularios ligados a una consulta a una base de datos SQL. Si , con SQL injection podemos saltarnos algunos logueos pero el SQL Injection es mucho mas, como se explic al comienzo: podemos borrar una base de datos, cambiarle el nombre a las tablas o hacer mil maldades. Imaginad por ejemplo una pgina de venta de telfonos mviles, podemos hacer que la persona que se nos ocurra de la BD compre 1000 telfonos, por ejemplo.

2. Ataque blind SQL Injection. El BLIND SQL Injection se considera un ataque a ciegas, es decir, sin conocer nada sobre el server (Versin de SQL, nombre de las tablas, numero de tablas, etc, que deberemos saber para concluir el ataque y para saber defendernos.) 2.1-. Sacando el nmero de columnas de la BD Bien para sacar el numero de columnas de la base de datas (BD,DB), vamos a inyectar un cdigo que cause un conflicto al llegar a un numero de columna, el cual no se encuentra en la base de datos . Bien para esto vamos a utilizar la clausula order by. Este tipo de ataque se basa en ordenar columnas hasta llegar a la ultima. As al poner la siguiente, al no existir , nos devolver un error tipo: Unknown column numerodecolumna in order clause El error puede sufrir variaciones pero lo que nos interesa es que nos devuelva el unknown column y el nmero que es lo que nos indica que columna es la que no est definida(no existe). Este no es el nico mtodo para sacar el numero de columnas (si el que me parece ms fcil), pero hay varios si no les funciona con unos, estudien un poco de SQL y piensen como hacerlo es simple fjense de este mtodo y sabrn como sacar errores con otras clausulas. Pongo un ejemplo sencillo, para que se vea una parbola de lo anteriormente dicho.

2.2.- Sacando el nombre de la tabla. Imaginad una web con este tipo de enlace: http://www.soyunaweb.com/ soyunapagina.extension?id_pregunta=2 Es muy comn encontrar este tipo de enlaces en casi cualquier web y tambin es muy comn pensar que detrs de este enlace, existe una sentencia SQL que determina que mostraremos o el contenido de dicha pgina, por ejemplo. El formato de la sentencia SQL que podra estar detrs de ese enlace sera algo parecido a esto: SELECT * FROM pregunta WHERE id_pregunta= + parmetro Viendo el enlace, es lgico presuponer que la tabla se llame pregunta y el campo id_pregunta. Este podra ser un fallo de seguridad . Al disear Webs con ese tipo de enlaces, debemos intentar asegurarnos de que el nombre del parmetro no sea tan explicativo. Simplemente con haber puesto id_p se soluciona el problema, por ejemplo, acabndose as nuestro ataque de Blind SQL Injection. (Salvo utilizar la fuerza bruta, por supuesto). Hemos pensado que la sentencia SQL podra ser vlida, pero no sabemos a ciencia si lo es, tendremos que comprobarlo (podra ser tambin un simple cdigo escrito dentro de la pgina). Para comprobarlo, podemos hacer lo siguiente, poner una condicin que nos devuelva siempre cierto, a ver si lo que evala la condicin es un pedazo de cdigo o una sentencia SQL. Se nos ocurre probar con algo como esta sentencia: SELECT * FROM pregunta WHERE id_pregunta=2 AND 1=1 Que traducido a un enlace: http://www.soyunaweb.com/ soyunapagina.extension?id_pregunta=2 and 1=1 Si por defecto aparece la pagina de la pregunta 2, bingo, hemos acertado, es una sentencia SQL. A partir de aqu, tendramos que demorarnos en conseguir mas informacin (nombre de las tablas, por ejemplo). Yo aconsejo atacar a los servidores mas comunes, Access o SQL Server, por ejemplo, con sus tablas de sistema. Lo que nos indica otro fallo importante de seguridad: al disear, debemos prohibir la lectura a este tipo de tablas. Al intentar atacar, el atacante ver que o bien no existen o bien no tiene permiso para leerlas y esa va queda descartada.

Inyeccin SQL en aplicaciones de Escritorio. Imaginemos el siguiente escenario: tenemos una red local, con una aplicacin que accede a diferentes sitios de una intranet o de archivos de configuracin de un servidor o cualquier otra tarea que imaginemos. Supongamos que detrs de esa aplicacin hay una base de datos de Access, que controla todo el proceso de la identificacin del usuario sirviendo de apoyo a una aplicacin construida con Visual Studio 2008, en Visual Basic. Este ser nuestro escenario de ataque. Para este manual se ha construido un programa de ejemplo con un acceso por usuario y contrasea que constituye nuestra herramienta para el aprendizaje. La base de datos sobre la que se sustenta la aplicacin est creada en Access XP, una herramienta comn en el mundo de las Pymes. La inyeccin de SQL de una Web con un servidor SQL Server es ligeramente distinta a la de un programa de escritorio con base de datos Access: no tienes comandos para otorgar privilegios a los usuarios y el carcter de escape de una sentencia SQL es distinta tambin ( se ver mas adelante el significado de todo esto), por nombrar algunos ejemplos. Bien, imaginad que somos un usuario malicioso que ha quedado muy descontento con el gerente de la empresa TodoAdsl porque no le ha proporcionado un da de asuntos propios para ver el Madrid-Bara (por ejemplo). En el trabajo, tenemos un programa que funciona para insertar el Horario de los Trabajadores, las tareas que han realizado al cabo del da y en qu horario. Se nos ocurre, que, si podemos saltarnos la contrasea, podemos hacer grandes destrozos en la empresa. Vamos a trabajar, encendemos el ordenador y arrancamos el programa.

Tenemos esto:

Un simple formulario de entrada con un usuario y una contrasea, con la imagen de la persona elegida en el combobox de nombre de usuario a la derecha. (Se ha dejado el control pero se han omitido las imgenes, para que la BD no pese mas de lo necesario para el manual). Lo primero que se nos ocurre es poner un usuario y una contrasea al azar para saber que ocurre.

Ponemos de contrasea la palabra contrasea y como usuario el que aparece en la imagen:

Al pulsar sobre el botn Entrar, aparece una ventana que se ha creado especficamente para que veais la sentencia SQL que el programa tiene detrs para controlar el acceso.

Obviamente, esta ventana no se muestra en ningn programa que precise de usuario y contrasea, sera un error de seguridad imperdonable. Podis ver la sentencia SQL, es muy sencilla. Tenemos una tabla TRABAJADOR, un campo clave personal que sera el campo donde se almacena la clave y un campo TRABAJADOR que sera el usuario. En este caso, el nombre de la tabla y el nombre del campo coinciden, pero no es lo habitual. Lo primero que debemos probar es a poner entradas extraas, como el usuario vaco o la contrasea vaca, a ver que ocurre. Probamos y nos sale la siguiente ventana:

En este caso, hemos errado: el programador ha sido lo suficientemente inteligente como para capar esos casos extraos y no dejar posibilidad al error. La siguiente treta ser intentar la Inyeccin de SQL. (Ya era hora). Ahora necesitamos saber como inyectar SQL en una base de datos Access. En este caso, tenemos ya que la sentencia SQL que realiza la consulta el del tipo:
"SELECT * FROM TRABAJADOR WHERE [clave personal]='" & pass & "' AND TRABAJADOR='" & usuario & "'"

Ahora hemos de pararnos a pensar durante un minuto. Cmo podemos insertar cdigo SQL en la sentencia de forma que podamos burlar el logueo?. Podemos probar con lo mas sencillo que se nos ocurre: introducir una condicin lgica que siempre sea verdadera. O sea: 1=1 Probamos esa sentencia en la contrasea, con cualquier usuario de la base de datos y tenemos esto:

De nuevo, nuestra suposicin era equivocada, no puede ser algo tan simple como eso, pero nos ha dejado una idea de cmo sacar la sentencia SQL en un caso normal (en el caso que nos ocupa, el programa, muy amablemente, se encarga de hacerlo por nosotros, pero repetimos que eso no sucede nunca): Si podemos introducir valores que den como resultado una sentencia SQL equivocada, entonces podramos saber la consulta que se realiza. Cul ha sido el error del programador en este caso?. Simplemente, no filtrar la entrada. Si tan slo hubiera aplicado un filtro para no permitir caracteres extraos, el

error nunca sucedera, y el malintencionado usuario (nosotros en este caso) se queda con un palmo de narices. No desesperemos. Probemos con otra cosa. La sentencia SQL que ejecuta la consulta es de este modo:
SELECT * FROM TRABAJADOR WHERE [clave personal]='" & pass & "' AND TRABAJADOR='" & usuario & "'"

Y si probamos a introducir una sentencia lgica siempre a cierto en el campo trabajador?. Probamos con esto: Pepe OR 'a'='a en el campo trabajador y esto otro contrasea en el campo contrasea. Esperanzados vamos a pulsar el botn de entrar.

Observamos la consulta y ya vemos que no funcionar: el programador ha filtrado los contenidos del campo usuario para permitir tan slo los usuarios que l ha elegido. Pulsamos Aceptar y nos encontramos con la ventana siguiente:

De nuevo hemos fracasado. Nos ponemos a pensar y se nos ocurre otra estrategia: probar a introducir una sentencia lgica que de cierto slo con que uno de los valores sea cierto. Sera algo as:
SELECT * FROM TRABAJADOR WHERE [clave personal]=

'loqueseteocurra' OR

'a'='a' AND TRABAJADOR='" & usuario & "'" Qu realiza esta sentencia?. Compara el valor de la clave con Or a=a y realiza un AND con el trabajador. Qu va a ocurrir?. Pues que OR a=a siempre devuelve cierto, sea cual sea el valor de la contrasea puesta!,

realizando un AND con el trabajador (que en este caso sirve cualquiera que pongamos y que el programador haya permitido). Nos vamos al programa y ponemos las siguientes valores: En contrasea: loqueseteocurra' OR 'a'='a En usuario: cualquiera que el combobox tenga almacenado. Pulsamos en entrar y tenemos esto como salida:

Bingo. Hemos dado con la sentencia correcta, el programa nos ha permitido insertarla y ahora, con todo el placer de nuestras malvolas mentes pulsamos en aceptar.

Y ya estaramos dentro del programa, podramos hacer lo que nos apeteciera con ese usuario, desde insertar horarios falsos, a nmeros de expedientes falsos, etc, etc..

El programa ya no realizar mas acciones, los botones insertar y sacar horario no hacen nada.

Espero que lo hayis disfrutado.

Manual creado por Ethiel para www.redeszone.net