ANLISIS Y PERITAJE DE DISPOSITIVOS ELECTRNICOS

TRABAJO DE INTERCICLO: OWASP

Jos Luis Molina Len

Escuela de electrnica y telecomunicaciones,
Universidad de Cuenca.
jluis.molinal@ucuenca.ec
1. INTRODUCCIN
SEGURIDAD DE LA INFORMACIN
La seguridad de la informacin es el conjunto de medidas preventivas y reactivas de
las organizaciones y de los sistemas tecnolgicos que permiten resguardar y
proteger la informacin buscando mantener la confidencialidad, la disponibilidad e
integridad de la misma.
Para el hombre como individuo, la seguridad de la
informacin tiene un efecto significativo respecto a su privacidad, la que puede
cobrar distintas dimensiones dependiendo de la cultura del mismo. [1]
En la Seguridad Informtica se debe distinguir dos propsitos de proteccin, la
Seguridad
de
la
Informacin y la Proteccin de Datos. En la Seguridad de la Informacin el objetivo
de la proteccin son los datos mismos y trata de evitar su perdida y modificacin
non-autorizado. La proteccin debe garantizar en primer lugar la confidencialidad,
integridad y disponibilidad de los datos, sin embargo, existen ms requisitos como
por ejemplo la autenticidad entre otros. El motivo o el motor para implementar
medidas de proteccin, que responden a la Seguridad de la Informacin, es el
propio inters de la institucin o persona que maneja los datos, porque la prdida o
modificacin de los datos, le puede causar un dao (material o inmaterial).
Entonces en referencia al ejercicio con el banco, la prdida o la modificacin
errnea, sea causado intencionalmente o simplemente por negligencia humana, de
algn rcord de una cuenta bancaria, puede resultar en prdidas econmicas u
otras consecuencias negativas para la institucin.
En el caso de la Proteccin de Datos, el objetivo de la proteccin no son los datos en
s mismo, sino el contenido de la informacin sobre personas, para evitar el abuso
de esta. Esta vez, el motivo o el motor para la implementacin de medidas de
proteccin, por parte de la institucin o persona que maneja los datos, es la
obligacin jurdica o la simple tica personal, de evitar consecuencias negativas
para las personas de las cuales se trata la informacin.
OWASP (Open Web Application Security Project):
Organizacin internacional dedicada a mejorar la seguridad de las aplicaciones web.
provee de forma imparcial y practica informacin acerca de computadoras y
aplicaciones de internet. Los miembros del proyecto incluyen una variedad de
expertos de seguridad alrededor del mundo, quienes comparten sus conocimientos
de vulnerabilidades, amenazas, ataques y contramedidas. Como parte de esta
misin, OWASP patrocina numerosos proyectos relacionados con la seguridad. Uno
de los ms populares l es proyecto top 10. [1]
Top Ten OWASP:
Este proyecto publica una lista de lo que considera los 10 principales riegos de
seguridad actuales de aplicaciones web en todo el mundo, con mtodos eficaces

para hacer frente a estas vulnerabilidades. La lista describe cada vulnerabilidad,

provee ejemplos, y da sugerencias de cmo evitarlo. La versin ms reciente es la
de junio del 2013, actualizada de la lista del 2010. La lista de Top 10 2013 se basa
en datos de siete empresas de seguridad de aplicaciones, que abarcan ms de
500.000 vulnerabilidades a travs de cientos de organizaciones. OWASP prioriza el
top 10 en funcin de su prevalencia y su relacin explotabilidad, detectabilidad, y el
impacto. [2]
El OWASP Top 10 se enfoca en la identificacin de los riesgos ms serios para una
amplia gama de organizaciones. Para cada uno de estos riesgos, proporcionamos
informacin genrica sobre la probabilidad y el impacto tcnico a travs del
siguiente esquema de calificaciones, que est basado en Metodologa de Evaluacin
de Riesgos OWASP. [3]

Figura N 1. esquema de calificaciones.

El presente informe se basa en el OWASP Top 10 2013
A1 - Inyeccin
A2 - Prdida de autenticacin y gestin de sesiones.
A3 - Secuencia de comandos en sitios cruzados (XSS)
A4 - Referencia directa insegura a objetos
A5 - Configuracin de seguridad incorrecta.
A6 - Exposicin de datos sensibles.
A7 - Ausencia de control de acceso a las funciones
A8 - Falsificacin de peticiones en sitios cruzados (CSRF)
A9 - Uso de componentes con vulnerabilidades conocidas.
A10 - Redirecciones y reenvos no vlidos.
Los atacantes pueden potencialmente usar rutas diferentes a travs de la aplicacin
para hacer dao a un negocio u organizacin. Cada una de estas rutas representa
un riesgo que puede, o no, ser lo suficientemente grave como para justificar la
atencin.
A veces, estas rutas son triviales de encontrar y explotar, y a veces son muy
difciles. Del mismo modo, el dao que se causa puede ir de ninguna consecuencia,
o ponerlo fuera del negocio. Para determinar el riesgo en su organizacin, puede
evaluar la probabilidad asociada a cada agente de amenaza, vector de ataque, y la
debilidad en la seguridad, y combinarla con una estimacin del impacto tcnico y
de negocios para una organizacin. En conjunto, estos factores determinan el riesgo
global.

Figura N 2. Ataque a una aplicacin WEB.

2. FUNDAMENTOS DEL ATAQUE ESCOGIDO
A1- INYECCIN
Las fallas de inyeccin, tales como SQL, OS, y LDAP, ocurren cuando datos no
confiables son enviados a un intrprete como parte de un comando o consulta. Los
datos hostiles del atacante pueden engaar al interprete en ejecutar comandos no
intencionados o acceder datos no autorizados. [3]

Figura N 3. Inyeccin.
PREVENCIN:
Evitar una inyeccin requiere mantener los datos no confiables separados de los
comandos y consultas.
1. La opcin preferida es usar una API segura la cual evite el uso de intrpretes por
completo o provea una interface parametrizada. Sea cuidadoso con las APIs, como
los procedimientos almacenados, que son parametrizados, pero que an pueden
introducir inyecciones en el motor del interprete.
2. Si una API parametrizada no est disponible, debe codificar cuidadosamente los
caracteres especiales, usando la sintaxis de escape especfica del intrprete.
OWASP ESAPI provee muchas de estas rutinas de codificacin.
3. La validacin de entradas positiva o de "lista blanca" tambin se recomienda,
pero no es una defensa integral dado que muchas aplicaciones requieren caracteres
especiales en sus entradas. Si se requieren caracteres especiales, solo las

soluciones anteriores 1. y 2. haran su uso seguro. La ESAPI de OWASP =en una

librera extensible de rutinas de validacin positiva.
EJEMPLOS DE ESCENARIOS DE ATAQUES

Figura N 4. Ejemplos de escenarios de ataques.

3. CATEGORAS DEL ATAQUE (EN CASO DE QUE EXISTA)
INYECCIN:
Problemas que pueden permitir a un atacante intercalar comandos en los datos y
hacer que se interpreten por algn sistema al que alcancen los datos.
INYECCIN.HTML:
Fallas que puede permitir a un atacante inyectar HTML hacia una aplicacin y
modificar la apariencia del HTML generado por esta aplicacin. Por ejemplo, un
atacante pudiera inyectar una etiqueta IMG no deseada dentro de un libro de visitas
y ofender a otros usuarios.
INYECCIN.COMANDOS DE SO:
Fallas que pueden permitir a un atacante inyectar caracteres especiales y
comandos hacia la consola de comandos del sistema operativo y modificar los
comandos iniciales. El ataque pudiera intentar modificar la forma en que un
programa es invocado o pudiera intentar encadenar comandos adicionales.
INYECCIN.LDAP:
Fallas que pueden permitir a un atacante inyectar caracteres especiales y trminos
de bsqueda dentro de un servidor LDAP y modificar la consulta inicial.
INYECCIN.SQL:
Fallas que pueden permitir a un atacante inyectar caracteres especiales y
comandos hacia una base de datos SQL y modificar la consulta inicial. El ataque
pudiera intentar cambiar el significado de la consulta o pudiera intentar de
encadenar comandos adicionales.
INYECCIN.XSS:
Fallas que pueden permitir a un atacante enviar o ejecutar un script malicioso a
travs de una aplicacin Web. Los ataques de XSS almacenados guardan los scripts

en la aplicacin Web. Los ataques de XSS reflejados son rebotados de una

aplicacin Web en tiempo real y requieren que un usuario sea engaado a enviar
una llamada conteniendo el ataque. [4]
4. ANLISIS BIBLIOGRFICO DEL ATAQUE, DESCRIBIR CADA CATEGORA
EN CASO DE QUE SE REQUIERA
EN ESTE DOCUMENTO SE ANALIZA Y SE DESARROLLA EL ATAQUE SQL
INJECTION
Uno de los ataques comunes a sistemas WEB, es SQL INJECTION, que trata de
insertar
cadena
de texto con sentencias SQL, a la pgina vctima, y con esto comenzar a obtener
informacin de los sistemas con esta tcnica, segn el nivel de seguridad que este
implementado ser el impacto del ataque e informacin recolectada. Como se dijo
en el prrafo anterior, si la pgina no tiene las seguridades necesarias, el atacante
puede llegar a conseguir credenciales relevantes, adicional borrado de informacin,
como descubrir la estructura de base de datos como la informacin del servidor. [1]
SQL INJECTION
Un ataque de inyeccin SQL consiste en la insercin o inyeccin de una consulta
SQL a travs de los datos de entrada del cliente de la aplicacin. Una inyeccin SQL
xito exploit puede leer los datos sensibles de la base de datos, modificar datos de
bases de datos (Insertar / Actualizar / Eliminar), ejecutar operaciones de
administracin en la base de datos (tales como apagar el DBMS), recuperar el
contenido de un archivo determinado presente en el sistema de archivos DBMS y en
algunos casos emitir comandos al sistema operativo. Los ataques de inyeccin SQL
son un tipo de ataque de inyeccin, en el que comandos SQL se inyectan en la
entrada de datos de plano a fin de efectuar la ejecucin de comandos predefinidos
SQL.

Figura N 5. SQL INJECTION

Los ataques por inyeccin SQL permiten a los atacantes suplantar identidad, alterar
datos existentes, causar problemas de repudio, permite la revelacin de todos los
datos en el sistema, destruir los datos o si no volverlos inasequibles, y convertirse
en administradores del servidor de base de datos.
La inyeccin SQL es muy comn con aplicaciones PHP y ASP. Debido a la naturaleza
de las interfaces programticas, las aplicaciones J2EE y ASP.NET tienen menor
probabilidad de ser fcilmente atacadas por una inyeccin SQL.

La gravedad de una inyeccin SQL est limitada por la habilidad e imaginacin del
atacante, y en menor medida a las contramedidas, como por ejemplo las
conexiones con bajo privilegio al servidor de bases de datos, entre otras. En
general, se considera a la inyeccin SQL de alto impacto.
La inyeccin SQL se ha convertido en un problema comn con sitios web que
cuentan con base de datos. La falla es fcilmente detectada y fcilmente explotada,
y como tal, cualquier sitio o paquete de software con incluso una mnima base de
usuario es propenso a ser objeto de un intento de ataque de este tipo.
Esencialmente, el ataque es llevado a cabo mediante la colocacin de una meta
carcter en los datos de entrada para colocar comandos SQL en el plano de control,
el cual antes no exista.
Este error depende del hecho de que SQL no hace real distincin entre los planos de
datos
y
los
de control. Las principales consecuencias son: Confidencialidad: Dado que las bases
de
datos
SQL generalmente almacenan informacin sensible, la prdida de la confiabilidad es
un problema frecuente con las vulnerabilidades de inyeccin SQL.
Autenticacin: Si se utilizan consultas SQL pobres para chequear nombres de
usuarios u contraseas, puede ser posible conectarse a un sistema como otro
usuario sin conocimiento previo de la contrasea.
Autorizacin: Si la informacin de autorizacin es almacenada en una base de
datos SQL, puede ser posible cambiar esta informacin mediante la explotacin
exitosa de una vulnerabilidad por inyeccin SQL.
Integridad: As como puede ser posible leer informacin sensible, tambin es
posible realizar cambios o incluso borrar esta informacin mediante un ataque por
inyeccin SQL.
TIPOS DE SQL INJECTION
Los ataques realmente varan de unos a otros, pero nos sentimos ms se pueden
clasificar en dos categoras:
a) Datos Ex filtracin: Ex filtracin de datos a travs de la inyeccin de SQL es lo
que ha contribuido a algunas de las violaciones de datos ms grandes hasta la
fecha. Los atacantes encuentran una vulnerabilidad que les permite a la
lista de todas las tablas y volcar todas las cuentas de usuario, correos electrnicos y
contraseas.
b) Cdigo Inyeccin: No vemos esto muy a menudo, que a menudo se basan en
algunas
de
vulnerabilidad inicial pre-pruebas que nos bloqueamos automticamente a travs
de
nuestro
Sitio Web Firewall por lo que es mucho ms difcil de grabar y tentativa.
5. ANLISIS DE UNA APLICACIN DE ENTRENAMIENTO
INTRODUCCIN A DVWA
Damn Vulnerable Web App (DVWA) es un reconocido entorno de entrenamiento en
explotacin de seguridad web escrito en PHP y MySQL cuyo objetivo principal es
permitir a programadores y tcnicos estudiar e investigar sobre las diferentes
temticas involucradas en dicho campo en un entorno completamente legal. [6]

Gracias a su programacin deliberadamente vulnerable es posible realizar pruebas

sobre
los
diferentes tipos de ataques web que se pueden llevar a cabo en este tipo de
aplicacin, y ms concretamente sobre pginas web PHP.

Figura N 6. Portada de la aplicacin DVWA.

DVWA permite el anlisis del cdigo vulnerable a los siguientes ataques:
Brute Force.
Command Execution.
CSRF (Cross-Site Request Forgery).
File Inclusion (Local File Inclusion y Remote File Inclusion).
SQL Injection.
SQL Injection (Blind).
File Upload.
XSS reflected.
XSS stored.
Asimismo dispone de tres niveles de seguridad diferentes: low, medium y high
(bajo, medio y alto, respectivamente).

Figura N 7. Seleccin de los diferentes niveles de seguridad en DVWA.

Gracias a los diferentes niveles de seguridad se pueden apreciar las diferencias
entre cdigo seguro y bien estructurado, y cdigo vulnerable siguiendo malas
prcticas de programacin.

Figura N 8. DVWA permite comparar el cdigo de los diferentes niveles de

seguridad.
Este software se lo puede descargar de la pgina oficial: http://www.dvwa.co.uk/

Figura N 9. Descarga DVWA.

6. IDENTIFICACIN DE UNA APLICACIN WEB SUSCEPTIBLE AL ATAQUE
La mejor manera de averiguar si una aplicacin es vulnerable a una inyeccin es
verificar que en todo uso de intrpretes se separa la informacin no confiable del
comando o consulta. Para llamados SQL, esto significa usar variables
parametrizadas en todas las sentencias preparadas (prepared statements) y
procedimientos almacenados, evitando las consultas dinmicas. Verificar el cdigo
es una manera rpida y precisa para ver si la aplicacin usa intrpretes de manera
segura. Herramientas de anlisis de cdigo pueden ayudar al analista de seguridad
a ver como se utilizan los intrpretes y seguir el flujo de datos a travs de la
aplicacin. Los testadores pueden validar estos problemas al crear pruebas que
confirmen la vulnerabilidad. El anlisis dinmico automatizado, el cual ejercita la
aplicacin puede proveer una idea de si existe alguna inyeccin explotable. Los
analizadores automatizados no siempre pueden alcanzar a los intrpretes y se les
dificulta detectar si el ataque fue exitoso. Un manejo pobre de errores hace a las
inyecciones fciles de descubrir. [5]
7. DESCRIPCIN DE LOS PROCESOS REALIZADOS PARA EL ATAQUE
ESCOGIDO: CAPTURAS DE PANTALLA DEL ATAQUE ESCOGIDO Y
OBTENIDO DE LA APLICACIN
INSTALACIN DEL DVWA EN UBUNTU 14.04 [7]

Imagen N 10. Ingreso como root.

Damos permisos root en la terminal para poder instalar los aplicativos necesarios

Figura N 11. Instalacin y configuracin de mysql.

Instalamos el servidor de base de datos mysql y le asignamos una contrasea:
82644

Figura N 12. instalacin y configuracin de Apache

Instalamos apache2 web server, PHP5, PEAR, and the PHP5 MySQL modulo

Figura N 13. instalacin y configuracin de Apache

Nos ubicamos en la direccin /var/www/html que es el directorio de apache service
por defecto

Figura N 14. Descarga del DVWA.

Figura N 15. Descarga del DVWA.

Descarga finalizada del DVWA para su instalacin

Figura N 16. Descompresin del paquete DVWA en la ubicacin actual

Figura N 17. Configuracin

Eliminamos el paquete .zip y renombramos la carpeta del DVWA

Figura N 18. Configuracin. php

Configuramos el php. Reemplazamos la contrasea por nuestra contrasea de
mysql

Figura N 19. Edicin del archivo Apache php.ini

Figura N 20. Edicin del archivo Apache php.ini

allow_url_include = Of

Figura N 21. Edicin del archivo Apache php.ini

Reemplazamos allow_url_include = Of con: Of with On

Figura N 22. Asignacin de permisos.

Cambiamos los permisos de DVWA chmod -R 777 /var/www/html/dvwa

Figura N 23. Creacin de Una base de datos.

Creamos una base de datos en mysql con nombre dvwa

Figura N 24. Configuracin archivo apache.conf

Configuramos el archivo apache.conf y agregamos la lnea: ServerName localhost

Figura N 25. Iniciamos Apache.

Iniciamos Apache con: service apache2 start

Figura N 26. Ingresamos al DVWA mediante un explorador WEB.

Nos dirigimos a: http://localhost/dvwa/setup.php

Figura N 27. Elegimos la opcin: create/ Reset Database

Figura N 28. Ingreso al DVWA con usuario y contrasea.

Nos dirigimos a: http://localhost/dvwa/login.php e ingresamos con: username:
admin / password: password

Figura N 29. DVWA instalado en Ubuntu 14.04

PARTE PRCTICA: MYSQL INJECCTION [8]
NIVEL DE SEGURIDAD BAJA

Figura N 30. Eleccin del nivel de seguridad

Click en DVWA Security, en el menu izquierdo.
1. Select "low"
2. Click enviar (submit)

Figura N 31. SQL Injection Menu

seleccionamos SQL injecction en el menu.

Id, nombre,

Figura N 32. Inyeccin bsica:

1. ponemos "1" en el cuadro de texto
2. Click en enviar.
3. pgina web / cdigo: se debe imprimir ID, Nombre, Apellido en la
pantalla.

Figura N 33. Notas (FYI):

A continuacin, se muestra la instruccin de seleccin PHP que estaremos
explotando, $ especficamente ID.
$getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";

Figura N 34. True escenario.

Instrucciones:
Introducimos el texto %' or '0'='0 en el cuadro de texto de ID del usuario
damos click en enviar.
Notas (FYI):
En este escenario, mostramos en pantalla todos los registros que son falsos y todos
los registros que son verdaderos.
%' - Probablemente no ser igual a nada, y ser falsa.
'0'='0' - Es igual a true, porque siempre habr 0 igual a 0.
Declaracin de la base de datos:
mysql> SELECT first_name, last_name FROM users WHERE user_id = '%' or '0'='0';

Figura N 35. Mostrar la versin de la base de datos

Instrucciones:
Introducimos el texto %' or 0=0 union select null, version() # en el cuadro de
texto ID del usuario.
Click en enviar
Notas (FYI):
Se observa en la ltima lnea se muestra 5.5.53-0ubuntu0.14.04.1 en el lugar del
apellido.
Esta es la versin de la base de datos mysql.

Figura N 36. Mostrar el usuario de la base de datos

Instrucciones:
Introducimos el texto %' or 0=0 union select null, user() # en el cuadro de texto
ID del usuario.
Notas (FYI):
Se observa en la ltima lnea se muestra root@localhost en el lugar del apellido.
Este es el nombre del usuario de base de datos que ejecuta el cdigo detrs de la
escenas de PHP.

Figura N 37. Mostrar el nombre de la base de datos.

Instrucciones:
Introducimos el texto %' or 0=0 union select null, database() # en el cuadro de
texto ID del usuario.
Notas (FYI):
Se observa que en la ltima lnea se muestra dvwa en el lugar del apellido.
Este es el nombre de la base de datos.

Figura N 38. Mostrar todas las tablas en el esquema de informacin

(information_schema)
Instrucciones:
Introducimos el texto %' and 1=0 union select null, table_name from
information_schema.tables # en el cuadro de texto ID del usuario.
Click en enviar
Notas (FYI):
Se muestran todas las tablas de la base de datos del information_schema
information_schema: es la base de datos de informacin, el lugar que almacena
informacin sobre todas las otras bases de datos que mantiene el servidor MySQL

Figura N 39. Mostrar todas las tablas de usuario de information_schema

Instrucciones:
Introducimos el texto %' and 1=0 union select null, table_name from
information_schema.tables where table_name like 'user%'# en el cuadro de texto
ID del usuario.
Click en enviar
Notas (FYI):
Se muestran todas las tablas que comienzan con el prefijo "user" en la base de
datos de INFORMATION_SCHEMA.

Figura N 40. Mostrar todos los campos de las columnas en la tabla de usuario de
INFORMATION_SCHEMA
Instrucciones:
Introducimos el texto %' and 1=0 union select null, concat(table_name,0x0a,
column_name) from information_schema.columns where table_name = 'users' #
en el cuadro de texto ID del usuario.
Notas (FYI):
Se muestra todas las columnas en la tabla de usuarios.
Se observa que hay una columna user_id, nombre, apellido, usuario y contrasea.

Figura N 41. Mostrar todo el contenido del campo de columnas en la tabla de

usuario information_schema
Instrucciones:
Introducimos el texto %' and 1=0 union select null, concat(first_name,0x0a,
last_name,0x0a,user,0x0a,password) from users # en el cuadro de texto ID del
usuario.
Notas (FYI): Se ha mostrado con xito toda la informacin de autentificacin
necesaria en esta base de datos.
NIVEL DE SEGURIDAD MEDIA
Configuracin nivel de seguridad medio [9]

Figura N 42. Seleccin nivel de seguridad medio.

Figura N 43. Seleccin de mysql injecction

En el nivel de seguridad medio el cdigo difiere del anterior en que la ID es filtrada
con la funcin mysql_real_scape_string():

Imagen N 44. Nivel de seguridad medio

DVWA vuelve a mostrar la misma pgina que antes para escribir el ID de un usuario
de la base de datos, pero en esta ocasin restringidos los caracteres especiales, se
vuelve a usar la inyeccin de nivel low.
1' OR 1==1--' para ver si realmente este filtrado soluciona el problema, pero se
obtienen un mensaje de error de sintaxis.

Figura N 45. ingresando inyeccin de nivel bajo

Figura N 46. Mensaje de error obtenido

Se procede ahorra a inyectar 1 OR 1=1-- que no contiene comillas ni cualquier
carcter especial alguno, y que al igual que con la seguridad media, devuelve un
listado con los usuarios:

Figura N 47. Extraccin de los usuarios de la tabla users.

Incluso con la seguridad media (restriccin de caracteres especiales) se sigue
teniendo un gran nmero de posibilidades al hacer una consulta a la base de datos.
A continuacin se muestra un ejemplo en el que se anida una consulta original con

otra para obtener la contrasea de cada usuario: 1 UNION ALL SELECT first_name,
password from dvwa.users

Figura N 48. Extraccin de contraseas encriptadas de los usuarios.

Una vez obtenida la contrasea (encriptada con MD5), basta con dirigirse a algn
servicio como el que ofrece la pgina web http://md5.rednoize.com/ para obtener la
contrasea des encriptada.

Figura N 49. Pgina http://md5.rednoize.com para obtener la contrasea

desencriptada.

Se copia la contrasea encriptada y se pulsa en buscar.

Para este ejemplo se usa la contrasea 8d3533d75ae2c3966d7e0d4fcc69216b
del usuario Hack.

Figura N 49. Bsqueda de la contrasea desencriptada.

Figura N 50. Obtencin de la contrasea del usuario Hack.

Se obtiene que la contrasea del usuario Hack es: charley.

8. PRUEBAS EN LAS VARIAS APLICACIONES WEB

PRUEBAS
DE
SQL
INJECTION
http://www.mclibre.org [7]

EN

LA

PGINA

DE

INTERNET:

Figura N 51. Aplicacin de ejemplo.

Esta aplicacin tiene un men con tres opciones:
Borrar todo, para borrar y crear la tabla de usuarios, que contiene nicamente dos
campos (el nombre y la contrasea del usuario).
Aadir usuarios, para aadir nombres de usuario y sus contraseas en la tabla de
usuarios.
Entrar al sistema, que simula una pgina de entrada en una aplicacin web,
solicitando un nombre de usuario y su contrasea, comprobando si est en la tabla
de usuarios y respondiendo
el nombre de usuario y la contrasea son correctos.
el nombre de usuario es correcto, pero la contrasea no es correcta.
el nombre de usuario no es correcto.
Esta aplicacin es vulnerable a algunos ataques de inyeccin SQL porque los datos
enviados por el usuario se incluyen en las consultas a la base de datos sin ningn
tipo de tratamiento previo.

Figura N 52. Informacin de la aplicacin.

Figura N 53. licencia AGPL 3 o posterior

Inyeccin SQL 1 - Acceder a la aplicacin sin tener nombre de usuario ni
contrasea

Figura N 54. 1 Ingreso de usuario y contrasea. 2 Comprobacin de usuario y

contrasea. 3 consulta.
Este ltimo mensaje ("Error en la consulta") nos hace saber que no se tratan los
datos y que adems las consultas estn delimitadas por dobles comillas. Por qu?
Probablemente el cdigo de la aplicacin es algo similar a esto:

Figura N 55. Explicacin del error que se produce.

Ahora que sabemos que la consulta est delimitada por comillas dobles podemos
escribir unos datos que modificarn la consulta y harn que la aplicacin crea que
hemos introducido datos de un usuario registrado.

Figura N 56. Realizacin de la consulta a pesar de que la contrasea no es

correcta.
Esta consulta es correcta y, cuando se ejecuta, la base de datos devuelve el nmero
total de registros en la tabla, puesto que la condicin se cumple siempre, aunque el
nombre de usuario y la contrasea sean incorrectos, porque la condicin final OR
'1'='1' se cumple siempre.
Inyeccin SQL 2 - Averiguar el nombre de los campos
Los nombres de campos se pueden averiguar mediante prueba y error. La idea es
introducir datos que construyan consultas en las que aparezcan posibles nombres
de los campos. En caso de que las consultas den error significa que el nombre es
incorrecto, si no es as significa que hemos acertado el nombre de los campos.
vamos a probar si el nombre de uno de los campos es "usuario".
Podramos hacer algo parecido a lo visto en el punto anterior:

Figura N 57. Uso de posibles entradas para acceder a una consulta.

En SQL, los guiones son la marca de inicio de un comentario, de manera que la
comilla final no se toma en cuenta en la consulta.
En ambos casos hemos obtenido "Error en la consulta", por lo que sabemos que
ningn campo se llama "usuario".
Hacemos ahora un segundo intento, con el nombre "user"

Figura N 58. Obtencin del nombre de los campos.

Como hemos obtenido la respuesta "Nombre de usuario incorrecto", sabemos que
uno de los campos se llama "user".
Inyeccin SQL 3 - Averiguar los nombres de las tablas
Los nombres de las tablas se pueden averiguar mediante prueba y error. La idea es
introducir datos que construyan consultas en las que aparezcan posibles nombres
de las tablas. En caso de que las consultas den error significa que el nombre es
incorrecto, si no es as significa que hemos acertado el nombre de las tablas.
Por ejemplo, vamos a probar si el nombre de la tabla es "usuarios".
Podramos hacer algo parecido a lo visto en el punto anterior:

Figura N 59. Obtencin del nombre de una tabla.

Como hemos obtenido la respuesta "Nombre de usuario incorrecto", sabemos que
una de las tablas se llama "tabla".
Inyeccin SQL 4 - Averiguar el contenido de los registros
Una vez se conoce el nombre de la tabla de usuarios y los nombres de los campos
se puede intentar conocer valores concretos de un registro mediante prueba y error.
La idea es introducir datos que construyan consultas en las que aparezcan posibles
contenidos de los campos. En caso de que las consultas den error significa que el
contenido es incorrecto, si no es as significa que hemos acertado el contenido.
Por ejemplo, vamos a buscar nombres de usuarios.

Figura N 60. Averiguar el contenido de los registros

La respuesta de la aplicacin es "Nombre de usuario y contrasea correctos.", lo

que nos indica que hay un usuario cuyo nombre empieza por "a". Se podra ir
alargando la cadena letra a letra hasta encontrar el nombre del usuario.
Inyeccin SQL 5 - Aadir un nuevo usuario
La tcnica consiste en incluir una sentencia SQL que inserte un registro.

Figura N 61. Aadir un nuevo usuario.

Para comprobar si el ataque ha tenido xito, habra que probar a entrar como
usuario "hacker" con contrasea "hacker".
Obviamente para que el ataque tenga xito deberamos haber acertado la
estructura de la tabla, lo que podra exigir numerosas pruebas o ser demasiado
difcil. Otra va para conseguir los datos de un usuario sera averiguar el nombre de
algn usuario (mediante sentencias LIKE y algo de paciencia) e inyectar una
consulta que cambie su contrasea.
Inyeccin SQL 6 - Borrar una tabla

Figura N 62. Borrar una tabla.

La tcnica consiste en incluir una sentencia SQL que inserte un registro. Si el ataque
ha tenido xito, la aplicacin seguramente dejar de funcionar, puesto que ha
desaparecido una de las tablas.
9. IMPACTO: ANLISIS CON HECHOS REALES (SE PUEDE INVESTIGAR EN
NOTICIAS) DEL DAO PROVOCADO POR EL ATAQUE ESCOGIDO
ATAQUES DE SQL INJECTION CONTRA SONY. [7]
Las inyecciones SQL son actualmente el segundo tipo de amenaza de ms
importante (27 %) y atacan a los sitios web mediante la introduccin de
afirmaciones SQL en un formulario web para saturar la base de datos asociada.
CIBERATAQUE SQL INJECTION: SONY PICTURES
En Junio de 2012, la gran empresa cinematogrfica Sony Pictures Entertainment fue
objetivo de los ciber delincuentes. El grupo de hackers conocido como LulzSec se
atribuye el robo de datos personales de un milln de usuarios de Sony Pictures
Entertainment, la divisin de cine de Sony.
La tcnica empleada para perpetrar el ataque es la conocida como SQL injection,
mediante la cual lograron los datos de ms de 1.000.000 de usuarios, incluyendo
contraseas, direcciones de correo electrnico, direcciones postales y fechas de
nacimiento. Tambin han podido acceder a detalles de la administracin de Sony
Pictures, incluidas las contraseas, adems de 75.000 cdigos de la msica y 3,5
millones de cupones de la msica.
Los autores de la accin critican la seguridad de Sony, ya que han podido acceder a
sus bases de datos mediante una inyeccin simple de cdigo SQL.
Adems se da la caracterstica que Sony tena almacenado ms de 1.000.000 de
contraseas en texto plano, sin cifrar, con lo que el acceso a esta informacin se
facilit enormemente. LulzSec se jacta tambin de haber atacado con xito las
bases de datos de Sony BMG de Blgica y Holanda.

No ha sido el nico ataque a esta compaa, uno de los ms relevantes, que incluso
se tom como asunto de Estado por parte de la administracin Obama, tuvo lugar el
24 de noviembre de 2014, un grupo llamado Guardians of Peace o los GOP (por sus
siglas en ingls), logr hackear ordenadores de Sony, hacindose con un botn de
pelculas sin estrenar y correos. Se emplearon tcnicas deextorsin, segn
expertos, de la que se cree que el objetivo fue evitar la proyeccin de la pelcula
TheInterview. Tras las amenazas de los hackers, numerosas salas de cine se
negaron a estrenar la cinta,obligando a Sony a cancelar el estreno. Corea del Norte
podra estar detrs del ataque ciberntico que sufri Sony Pictures, segn The Wall
Street Journal. La primeras investigaciones del FBI apuntan al pas asitico como
uno de los sospechosos de filtrar pelculas y documentos de la compaa. Pero el
rgimen de Kim Jong-Un ni confirm ni desminti su participacin. Alcanz tanto a la
esfera de lo poltico como de lo econmico en EE UU, al provocar prdidas ante la
cancelacin del rodaje de pelculas.
As mismo se accedi a los estrenos de la compaa (cinco pelculas en total), como
nmeros de identificacin fiscal y partes mdicos de ms de 3.000 empleados y
correos electrnicos privados en los que se critica a algunos actores.
Sin embargo, el punto de inflexin lo ha puesto la pelcula The Interview, una
comedia de Sony sobre un complot para asesinar al lder de Corea del Norte, Kim
Jong-un. Se cree que esta cinta el motivo de las amenazas a Sony y de todas las
filtraciones.
El 24 de noviembre de 2014, un mensaje ilustrado apareci en las pantallas de los
empleados de Sony. Pareca inquietantemente similar al que apareci el ao pasado
en las computadoras de los bancos de Corea del Sur, un ataque que le fue atribuido
a Corea del Norte.
El ataque de hackers a la empresa Sony Pictures, que fren la exhibicin del film
The Interview, pudo haber sido perpetrado por un empleado despedido y no por el
gobierno de Corea del Norte como inform el FBI, aunque tambin pudieron ser
ambos factores combinados.
COMO EVITAR ESTOS ATAQUES
El principal problema de estos ataques es que si dejamos que el usuario del
programa introduzca libremente caracteres sin control ninguno (mediante
formularios, por ejemplo) puede llegar a aprovecharse de las comillas (simples y
dobles con las que declaramos cadenas de texto o strings).
Por ejemplo,se podra realizar una consulta SQL a la que le mandamos dos
parmetros(independientemente del lenguaje, ya que cualquier lenguaje que use
bases de datos SQL podra ser vctima de estos ataques), que mediante el lenguaje
que elijamos escribir tal cual le mandemos los parmetros.
Por lo tanto la solucin genrica sera evitar que se pudieran introducir caracteres
especiales (como comillas) sin haberlas transformado antes (por ejemplo, una
comilla doble: debera de transformarse en \ que as interpretar como texto la
comilla y no como el carcter que cierra o abre el una texto en la consulta, pero
segn el lenguaje se puede implementar de distintas formas y algunas son
automticas y ms optimizadas.
En .NET evitaremos la inyeccin en SQL Server (con C#) estableciendo el tipo de
parmetro como literal con SqlDbType.VarChar :

O tambin podramos usar AddWithValue de una forma ligeramente similar a la

anterior:

10.MTODOS DE MITIGACIN DEL ATAQUE:

DVWA hace uso en el nivel de seguridad high de algunas funciones PHP para filtrar la
informacin recibida desde el formulario: [9]

Figura N 63. Seguridad High.

Para evitar los ataques SQL Injection, PHP cuenta con la directiva magic_quotes_gpc que
automticamente restringe todas las comillas. Esta directiva puede ser habilitada desde el
fichero de configuracin de PHP (php.ini), aunque se recomienda no habilitar las comillas

mgicas deshabilitadas y, en su lugar, hacer un filtrado en tiempo de ejecucin y bajo demanda

o usar las funciones:

addcslashes() que restringe caracteres como \n, \r etc., convirtindolos en la misma

forma
que se hace en programacin C, mientras que los caracteres con cdigo ASCII inferior a
32 y superior a 126 son convertidos a representacin octal.
mysql_real_escape_string() que restringe los caracteres especiales.
stripslashes() que quita las barras de un string con comillas.

Existen ciertos principios a considerar para proteger aplicaciones de un SQL

Injection:

No
No
No
No

confiar en la entrada del usuario.

utilizar sentencias SQL construidas dinmicamente.
utilizar cuentas con privilegios administrativos.
proporcionar mayor informacin de la necesaria

Adicionalmente se recomienda el uso de la librera mysqli puesto que permite la

posibilidad
de
realizar conexiones seguras a la base de datos a travs de SSL y ofrece mucha ms
seguridad frente a la vulnerabilidad SQL Injection.

Figura N 64. Uso de la librera mysqli.

a. ENFOQUE: DESARROLLADOR DE UNA APLICACIN WEB.
a) Procedimientos almacenados: se puede crear funciones estticas de insercin,
eliminacin,
actualizacin y seleccin en la base de datos que accedan a las tablas de la base de
datos,
estas funciones tienen parmetros con tipos definidos que al momento de realizar
una sentencia SQL son tratadas en su totalidad como el tipo declarado evitando de
esta
forma
inyeccin
del cdigo SQL, pues sera procesado como cadena de texto parmetro y no como
parte
de
la sentencia.
b) En lo posible en las pginas web colocar en los input, cuadros de lista, para que
los
usuarios
solo puedan seleccionar datos predefinidos, s esto no es posible leer las variables
de acuerdo al tipo definido en la base de datos y enviar esto como un solo campo es
decir para campos tipo cadena se debe enviar entre comilla simple o doble segn el
lenguaje de base de datos, asegurando que si existiera dentro de una secuencia de
caracteres estos smbolos se realice el respectivo escape para que sea tomado
como parte de la cadena y no de la sentencia.

c) Mantener actualizado el servidor y/o contenedor WEB, muchos de los servidores

WEB Apache, Tomcat, Jboss, GlashFish, IIS actualmente tienen mdulos que se
encargan de prevenir diferentes tipos de ataques.
d) Cuando aparecen nuevos tipos de ataques los proveedores actualizan sus
sistemas para ofrecer proteccin a la aplicacin Web, por lo que es aconsejable
mantener siempre actualizado los servidores de aplicacin.
e) Los mensajes de error deben indicar el error en detalle general es decir sin
mostrar informacin relevante que puede ser usada por el atacante para vulnerar el
sitio WEB.
f) Verificar los textos introducidos con un diccionario de cadenas usadas en ataques
SQL INJECTION de esta forma si el atacante ingresa 1=1 y esta cadena est en el
diccionario se enviar un mensaje de error al ejecutar la transaccin
g) Sentencias preparadas, la mayora de lenguaje de programacin permite el uso
de
sentencias
preparadas en donde se crea la sentencia con parmetros de ingreso y luego se
asigna valor a estos parmetros, le interprete del lenguaje entiende que todos los
caracteres que contienen el parmetro debe ser tratado como uno solo, y coloca
automticamente los caracteres de escape.
h) Realizar en la etapa de pruebas del software, pruebas de seguridad SQL
INJECTION, de esta forma se asegura que la pgina o sitio WEB, no sea vulnerable
por cualquier atacante.

b. ENFOQUE: USUARIOS DE UNA APLICACIN WEB.

a) Firewall WEB, este software se instala entre el servidor WEB y el usuario, este
tipo
de
software
tiene reglas de validacin que proveen ataques de seguridad de diferente tipo entre
ellas
SQL
INJECTION, lo importante de este tipo de implementacin es que constantemente
los proveedores de estas soluciones actualizan sus reglas para nuevos tipos de
ataques.
b) Evitar usar variables en la URL, en lo posible se debe usar variables dentro de la
pgina URL, o en cookies haciendo que sea un poco ms laborioso para el atacante
encontrar la variable e inyectar cdigo.
SOLUCIONES INFORMTICAS FRENTE A ATAQUES DE SQL INJECTION [3]
Kona Site Defender es una solucin verstil de defensa que ofrece proteccin contra
los ataques distribuidos de denegacin del servicio (DDoS), as como contra los
ataques dirigidos a aplicaciones web,incluidas las inyecciones SQL y los ataques a
filtros de scripts de sitios. Kona Site Defender integra sofisticados controles de nivel
de aplicacin, incluido un conjunto de normas de firewall de aplicaciones web de
configuracin personalizada predefinidas que permiten realizar una inspeccin
profunda de paquetes de solicitud o respuesta HTTP/S y anlisis de carga, con el fin
de identificar y ofrecer proteccin contra ataques tales como las inyecciones SQL,
ataques a filtros de scripts de sitios, etc.

Kona Site Defender combina proteccin automatizada contra ataques distribuidos

de denegacin de servicio (DDoS) con un firewall de aplicaciones web (WAF) muy
preciso y escalable que protege sitios web contra una amplia gama de amenazas
online, incluidos ataques DDoS en los niveles de red y aplicacin, inyecciones SQL y
filtros de scripts de sitios (XSS), sin hacer concesiones en trminos de experiencia
del usuario. Kona Site Defender es capaz de detener ataques de gran alcance y
aprovecha la visibilidad de Akamai sobre el trfico web global para ayudar a las
empresas a adoptar medidas frente a las amenazas ms recientes.
11.CONCLUSIONES:
Un ataque por SQL inyeccin permite al atacante obtener la informacin de distinto
tipo desde las pginas WEB de sus bases de datos y acceso a la misma con el fin
de: modificar los datos, obtener informacin confidencial, emitir comandos al SO,
suplantacin de identidad, etc. Cuya gravedad y alcance est limitada por la
habilidad del atacante. La Inyeccin se ha convertido en uno de los principales
problemas de los sitios web que cuentan con base de datos, en donde cualquier
error de programacin, descuidos del desarrollador, malas validaciones, uso de
libreras estndar, entre otras; puede llevar a brindar al atacante control de:
Autenticacin, Autorizacin e Integridad de los datos.
12.REFERENCIAS

[1] L. P. G. V. C. Giovanny Chicaiza 1, INYECCIN DE SQL, CASO DE ESTUDIO

OWASP, Universidad de las Fuerzas Armadas ESPE, Sangolqu, Ecuador.
[2] www.ibm.com,
[En
lnea].
Available:
https://www.ibm.com/developerworks/library/se-owasptop10/.
[3] http://searchsoftwarequality.techtarget.com,
[En
lnea].
Available:
http://searchsoftwarequality.techtarget.com/definition/OWASP-Top-Ten.
[4] O. T. O. W. A. S. Project, OWASP Top 10 - 2013 Los dies riesgos ms criticos en
aplicaciones Web, Creative Commons (CC) Attribution Share-Alike., 2013.
[5] OWASP, OWASP: Lista de Verificacin para Intrusin en Aplicaciones Web
Versin 1.1.17, 14 de Julio de 2004.
[6] D. V. W. A. (DVWA), INTRODUCCIN A DVWA, http://www.dvwa.co.uk/.
[7] linuxsecurityblog.com, https://linuxsecurityblog.com, 2016. [En lnea].
Available: https://linuxsecurityblog.com/2016/01/28/install-dvwa-on-ubuntu/.
[8] C. (CSS), www.computersecuritystudent.com, [En lnea]. Available:
http://www.computersecuritystudent.com/SECURITY_TOOLS/DVWA/DVWAv107/l
esson6/.
[9] F. J. P. S. Javier Waisen Restoy, WEB VULNERABLE DVWA, Mster en
Administracin, Comunicaciones y Seguridad Informtica, Universidad de
Almera.
[10 http://www.mclibre.org,
http://www.mclibre.org,
[En
lnea].
Available:
]
http://www.mclibre.org/consultar/php/lecciones/php_db_inyeccion_sql.html.
[11 http://www.eoi.es,
[En
lnea].
Available:
]
http://www.eoi.es/blogs/ciberseguridad/2016/04/18/ 597/ .