Estudio de la Seguridad en Sistemas Manejadores de Bases...
Transcript of Estudio de la Seguridad en Sistemas Manejadores de Bases...
INSTITUTO POLITECNICO NACIONAL
Unidad Profesional Interdiciplinaria de Ingenierıa y Ciencias
Sociales y Administrativas
Seccion de Estudios de Posgrado e Investigacion
“Estudio de la Seguridad en Sistemas
Manejadores de Bases de Datos y sus Ambientes”
Tesis para obtener el grado de Maestro en Ciencias en Informatica
PRESENTA
Rodolfo Adrian Lopez Torres
Director
Dr. Javier Garcıa Garcıa
Mexico D.F. Primavera de 2015
Resumen
Actualmente la informacion es un activo muy importante, las organizaciones publicas
y privadas, gobiernos y sociedad estan cada vez mas interesadas en proteger su informacion,
ya que un incidente sobre la misma puede afectar negativamente su privacidad, reputacion
o seguridad. El uso de Internet y dispositivos moviles ha propiciado el desarrollo de
aplicaciones en la nube y servicios Web desde los cuales los usuarios ejecutan diferentes
operaciones sobre los recursos del Sistema Manejador de Base de Datos con el que
interactua. En este escenario los datos estan cada vez mas expuestos a diferentes
amenazas y vectores de ataque, por lo que si no se incluyen controles de seguridad
adecuados en el diseno y desarrollo de estos sistemas, se pueden exponer diferentes
vulnerabilidades las cuales pueden ser explotadas por algun agente de amenaza.
Principalmente la capa aplicativa es un vector comun de ataque, ya que esta capa
por su naturaleza se encuentra expuesta a diferentes usuarios y sistemas, que utilizan
los diferentes puntos de entrada hacia el Sistema Manejador de Base de Datos para la
ejecucion de operaciones como consultas y modificacion de datos.
Es por ello que es muy importante analizar los controles de seguridad que se deben
implementar en las distintas capas de un sistema TI y las vulnerabilidades a las que
pueden estar expuestas dichas capas, con el fin de asegurar la integridad, confidencialidad
y disponibilidad de los datos que se resguardan, procesan y transmiten.
Abstract
Currently the information is a very important asset, public and private organizations,
governments and society are increasingly interested in protecting their information
since an incident on it can negatively affect their privacy, reputation or safety. The
use of Internet and mobile devices has led to the development of cloud applications
and Web services that are used by different users to perform operations on Database
Management System resources. In this scenario, the data is increasingly exposed to
different threats and attack vectors, so if security controls are not considered in the
design and development of these systems, these can be exposed to different vulnerabilities
that can be exploited by a threat agent.
Mainly the application layer is a common attack vector, since this layer is expose
to different users and systems, this layer also offer different points of entry to interact
with a Data Base Management System in order to execute operations like queries or
data modification.
That is why, it is very important to analyze the security controls that should be
implemented in the different layers of an IT system, and the vulnerabilities that can
affect these systems, in order to ensure the integrity, confidentiality and availability of
the data that is stored, processed and transmited.
Indice general
1. Introduccion 1
1.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Trabajos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Estructura del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6. Alcance y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Conceptos de seguridad de la informacion 10
2.1. Conceptos de seguridad de la informacion . . . . . . . . . . . . . . . . . 11
3. Enfoque ofensivo de seguridad 28
3.1. Vulnerabilidades en la capa aplicativa . . . . . . . . . . . . . . . . . . . 30
3.2. SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3. Mal manejo de sesiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4. Cross-Site Scripting - XSS . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5. Envıo de datos no cifrados . . . . . . . . . . . . . . . . . . . . . . . . . 43
4. Metodologıa para identificar vulnerabilidades contra ataques de SQL
Injection 47
i
INDICE GENERAL ii
4.0.1. Reconocimiento pasivo . . . . . . . . . . . . . . . . . . . . . . . 49
4.0.2. Identificar los modulos que interactuan con el SMBD . . . . . . 49
4.0.3. Reconocimiento activo . . . . . . . . . . . . . . . . . . . . . . . 56
4.0.4. Identificar los puntos de entrada vulnerables a SQL Injection . . 56
4.0.5. Inyeccion de operadores de modificacion de comportamiento . . 58
4.0.6. Inyeccion de operadores de correccion de sintaxis . . . . . . . . 64
4.0.7. Inyeccion de operadores de ofuscacion . . . . . . . . . . . . . . . 68
4.0.8. Perfilamiento del SMBD y estructura de la Base de Datos . . . 75
4.0.9. Ataque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.0.10. Extraccion de informacion . . . . . . . . . . . . . . . . . . . . . 77
4.0.11. Ganar acceso al SMBD, comprometer el sistema operativo y otros
sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5. Enfoque defensivo de seguridad 85
5.1. Uso de vistas parametrizadas y parametros de sesion para definir controles
de accesos en la base de datos . . . . . . . . . . . . . . . . . . . . . . . 86
5.1.1. Implementacion de vistas parametrizadas con parametros de sesion
basado en autenticacion . . . . . . . . . . . . . . . . . . . . . . 92
5.2. Controles mınimos de seguridad . . . . . . . . . . . . . . . . . . . . . . 95
5.2.1. Controles de seguridad en el SMBD . . . . . . . . . . . . . . . . 95
5.2.2. Controles de seguridad en la capa aplicativa . . . . . . . . . . . 96
5.2.3. Controles de seguridad en el servidor de aplicaciones o servidor
Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.2.4. Controles de seguridad en el sistema operativo . . . . . . . . . . 100
5.2.5. Polıticas de Password . . . . . . . . . . . . . . . . . . . . . . . . 101
5.2.6. Bitacoras de monitoreo . . . . . . . . . . . . . . . . . . . . . . . 102
Indice de figuras
1.1. Enfoque defensivo y enfoque ofensivo de seguridad . . . . . . . . . . . . 3
1.2. Arquitectura basica de 3 capas. . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Propiedades de seguridad en un SMBD . . . . . . . . . . . . . . . . . . 11
2.2. Relacion de los elementos de seguridad en un SMBD [5] . . . . . . . . . 13
2.3. Controles administrativos, tecnicos y fısicos [5] . . . . . . . . . . . . . . 16
2.4. Seguridad en profundidad . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5. Fases para la gestion de riesgos - Metodologıa Octave Allegro . . . . . . 19
2.6. Objetivos de cada fases para la gestion de riesgos . . . . . . . . . . . . 20
2.7. Metricas de impacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8. Identificacion de contenedores . . . . . . . . . . . . . . . . . . . . . . . 23
2.9. Analisis de vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . 24
2.10. Calculo del riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.11. Matriz de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1. Riesgos de seguridad en aplicaciones - OWASP . . . . . . . . . . . . . . 29
3.2. Causas que propician vulnerabilidades SQL Injection . . . . . . . . . . 33
3.3. Escenario del ataque de SQL Injection - OWASP . . . . . . . . . . . . 34
3.4. Escenario de vulnerabilidades en el manejo de sesiones . . . . . . . . . 36
3.5. Mal manejo de sesiones en una aplicacion Web . . . . . . . . . . . . . . 37
iv
INDICE DE FIGURAS v
3.6. modificacion de los parametros de sesion . . . . . . . . . . . . . . . . . 38
3.7. Acceso no autorizado a una aplicacion por vulnerabilidades en el manejo
de sesiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.8. Escenario del ataque de XSS . . . . . . . . . . . . . . . . . . . . . . . . 41
3.9. Inyeccion de script malicioso XSS almacenado . . . . . . . . . . . . . . 42
3.10. El navegador de la vıctima interpreta el codigo malicioso . . . . . . . . 43
3.11. Captura de trafico no cifrado . . . . . . . . . . . . . . . . . . . . . . . . 44
3.12. El atacante obtiene el nombre de la cuenta con la que esta accesando el
usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.13. El usuario crea un nuevo usuario en el SMBD . . . . . . . . . . . . . . 45
3.14. El atacante obtiene el usuario y password de acceso . . . . . . . . . . . 46
4.1. Panorama general de una metodologıa de explotacion SQL Injection . . 47
4.2. Pasos de una metodologıa de explotacion SQL Injection . . . . . . . . . 48
4.3. Uso de proxy para analizar el comportamiento logico de la aplicacion . 49
4.4. Ejecucion de operaciones al SMBD desde la aplicacion . . . . . . . . . 50
4.5. Estructura del metodo HTTP GET . . . . . . . . . . . . . . . . . . . . 51
4.6. Estructura del metodo HTTP POST . . . . . . . . . . . . . . . . . . . 52
4.7. Identificacion de parametros que envıan datos a traves de HTTP GET
y POST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.8. Ejemplo de tabla de estados para identificar los modulos que interactuan
con un SMBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.9. Escenarios general en un ataque de SQL Injection . . . . . . . . . . . . 56
4.10. Mutacion de Operadores de Inyeccion . . . . . . . . . . . . . . . . . . . 57
4.11. Ejemplo de inyeccion de operador OR . . . . . . . . . . . . . . . . . . . 60
4.12. Ejemplo de inyeccion de operador AND . . . . . . . . . . . . . . . . . . 61
INDICE DE FIGURAS vi
4.13. Ejemplo de mal manejo de errores . . . . . . . . . . . . . . . . . . . . . 63
4.14. Errores de sintaxis en la inyeccion de operadores de modificacion de
comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.15. Ejemplo de inyeccion del operador apostrofe para corregir errores de
sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.16. Ataque de SQL Injection con la tecnica de inyeccion de comentarios . . 67
4.17. Ambiente simple de base de datos[7] . . . . . . . . . . . . . . . . . . . 76
4.18. Ataque de SQL Injection para extraer metadatos del esquema . . . . . 77
4.19. Identificacion de numero de columnas con ORDER BY . . . . . . . . . 79
4.20. Tabla empleados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.21. Definicion de vista para el usuario A . . . . . . . . . . . . . . . . . . . 80
4.22. Definicion de vista para el usuario B . . . . . . . . . . . . . . . . . . . 81
4.23. Ataque de SQL Injection con la tecnica UNION Query . . . . . . . . . 83
4.24. Uso de la funcion LOAD DATA en MySQL para escalar privilegios . . 84
5.1. Usuario generico ejecutando acciones en la base de datos . . . . . . . . 87
5.2. Tabla empleados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3. Definicion de vista para el usuario A . . . . . . . . . . . . . . . . . . . 89
5.4. Definicion de vista para el usuario A . . . . . . . . . . . . . . . . . . . 89
5.5. Definicion de vista para el usuario B . . . . . . . . . . . . . . . . . . . 89
5.6. Definicion de vista para el usuario B . . . . . . . . . . . . . . . . . . . 90
5.7. Ataque de inyeccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.8. Vistas parametrizadas con parametros de sesion . . . . . . . . . . . . . 93
5.9. Vistas parametrizadas con parametros de sesion . . . . . . . . . . . . . 94
5.10. Definicion DDL de una vista parametrizada . . . . . . . . . . . . . . . 95
Capıtulo 1
Introduccion
Actualmente la informacion es un activo muy importante, las organizaciones publicas
y privadas, gobiernos y sociedad estan cada vez mas interesadas en proteger su informacion,
ya que un incidente sobre la misma puede afectar negativamente su privacidad, reputacion
o seguridad.
En este escenario los sistemas de informacion y en particular los Sistemas Manejadores
de Bases de Datos juegan un papel fundamental, ya que es en estos donde se resguardan
y procesan datos sensibles como datos personales o informacion financiera, estos datos
generalmente son utilizados por diferentes sistemas de informacion para ofrecer servicios
o ejecutar procesos crıticos.
Es por ello que es muy importante analizar los controles de seguridad que se deben
implementar en las distintas capas de un sistema TI para asegurar la integridad,
confidencialidad y disponibilidad de los datos que se resguardan, procesan y transmiten
a traves de los sistemas de informacion.
En particular esta investigacion se enfoca en los controles preventivos de seguridad
que se deben considerar en la administracion de un SMBD (Sistema Manejador de
Base de Datos) y sus ambientes, ası como analizar las vulnerabilidades que pueden ser
explotadas por algun agente de amenaza, ya sea de manera intencional o accidental,
1
CAPITULO 1. INTRODUCCION 2
afectando negativamente los recursos de un SMBD.
1.1. Planteamiento del problema
Para analizar este tema se definen dos enfoques, un enfoque defensivo que tiene
que ver con la implementacion de controles preventivos de seguridad en un SMBD y
en sus ambientes, y un enfoque ofensivo que analiza las diferentes vulnerabilidades y
falta de controles preventivos de seguridad en un SMBD y en sus ambientes, y que
pueden afectar negativamente los recursos de un SMBD (vistas, tablas, bases de datos,
procedimientos almacenados, etc.).
Consideramos como ambientes aquellas entidades logicas que interactuan con los
recursos de un SMBD, como son el Sistema Operativo donde reside o esta instalado el
SMBD, los protocolos de capa 7 del modelo OSI utilizados para administrar un SMBD
de forma remota, o las aplicaciones y servicios Web desde donde interactuan los usuarios
finales para realizar operaciones sobre los recursos de un SMBD.
Es importante analizar los controles preventivos de seguridad que se deben implementar
y las vulnerabilidades que pueden existir en los ambientes que interactuan con los
recursos de un SMBD, ya que una vulnerabilidad en alguno de estos ambientes externos
puede afectar negativamente los recursos de un SMBD. Como es el caso de la vulnerabilidad
de SQL Injection que es explotada en la capa aplicativa pero que afecta negativamente
a las bases de datos con las que interactua.
CAPITULO 1. INTRODUCCION 3
Figura 1.1: Enfoque defensivo y enfoque ofensivo de seguridad
Para analizar los dos tipos de enfoques planteados (enfoque defensivo y enfoque
ofensivo) se considera una arquitectura basica de 3 capas la cual consta de la capa de
presentacion, capa de aplicacion y capa de datos.
En la capa de presentacion se tiene un front-end o interfaz desde donde interactuan
los usuarios finales, esta interaccion generalmente se hace a traves de un navegador Web
por el cual se realizan peticiones a la capa aplicativa por medio del protocolo HTTP. Los
usuarios finales no conectan directamente con los recursos del SMBD, si no que lo hacen
a traves de la capa de aplicacion la cual incluye basicamente aplicaciones y servicios
Web. Desde la capa de presentacion los usuarios finales pueden generar consultas y
modificaciones a registros de una base de datos o ejecutar procesos sobre otros recursos
del SMBD.
En la capa de aplicacion o capa aplicativa se definen los servicios y aplicaciones Web
que interactuan con los recursos de un SMBD, para ello esta capa generalmente utiliza
un usuario generico con los permisos necesarios sobre los recursos del SMBD (Bases
de Datos, tablas, vistas, procedimientos almacenados, funciones, etc.) para ejecutar las
solicitudes provenientes de los usuarios finales desde la capa de presentacion, dichas
solicitudes se reciben a traves de metodos HTTP (GET, POST, DELETE, PUT). En
CAPITULO 1. INTRODUCCION 4
esta capa reside el codigo que se encarga de ejecutar decisiones logicas y evaluaciones
para enviar Queries y ejecutar procesos en el SMBD, y regresar una respuesta al usuario
final por medio del front-end o interfaz con la que el usuario final interactua.
En la capa de datos se tiene un SMBD generalmente de tipo relacional (Oracle,
MySQL, MSQL Server, Informix, PostgreSQL, etc.) donde residen los recursos del
SMBD que interactuan con la capa aplicativa.
Figura 1.2: Arquitectura basica de 3 capas.
CAPITULO 1. INTRODUCCION 5
En cada una de estas capas pueden existir vulnerabilidades que pueden afectar
los recursos que residen en un SMBD, por lo que se deben implementar controles
preventivos de seguridad que sean efectivos y que ayuden a minimizar los riesgos de
explotacion, o en su caso contener los impactos en la integridad, confidencialidad y
disponibilidad de los recursos de un SMBD en caso de un ataque exitoso.
Algunas de las vulnerabilidades mas comunes que se pueden encontrar son:
Vulnerabilidades de inyeccion en aplicaciones y servicios Web.
Configuraciones inseguras o por default.
Uso de protocolos inseguros que no cifran los datos enviados.
Metodos debiles de autenticacion y autorizacion.
Malware, virus o codigo malicioso.
Uso de password debiles.
Falta de proteccion de archivos y directorios de configuracion o con informacion
sensible.
1.2. Objetivo
El presente trabajo tiene los siguientes objetivos:
Analizar las vulnerabilidades mas comunes en la capa aplicativa, principalmente
la vulnerabilidad de SQL Injection (enfoque ofensivo).
Definir una metodologıa para identificar y explotar eficientemente las vulnerabilidades
de SQL Injection (enfoque ofensivo).
CAPITULO 1. INTRODUCCION 6
Analizar el uso de vistas y parametros de sesion en la capa aplicativa para reducir
los riesgos de explotacion de vulnerabilidades de SQL Injection, o en su caso a
contener los impactos sobre los recursos de un SMBD en caso de un ataque exitoso
(enfoque defensivo).
Definir los controles mınimos de seguridad que se deben implementar en un
SMBD, el sistema operativo donde reside el SMBD, y las aplicaciones con las
que interactua el SMBD (enfoque defensivo).
1.3. Justificacion
Debido a la dependencia que se tiene actualmente en los sistemas de informacion y a
la criticidad de los datos que se procesan en los mismos, se requiere de un estudio sobre
los controles preventivos de seguridad que se deben considerar en la implementacion
y administracion de un SMBD y sus ambientes con la finalidad de reducir los riesgos
de explotacion, o en su caso contener los impactos sobre la confidencialidad, integridad
y disponibilidad de los recursos de un SMBD ante un ataque exitoso, siendo la capa
aplicativa el vector mas comun de ataque.
Los incidentes de seguridad sobre los recursos de un SMBD se traducen en afectacion
a las personas, organizaciones y gobiernos que dependen de los sistemas de informacion
y de los datos que estos procesan para llevar a cabo sus actividades.
Un incidente sobre la confidencialidad de los recursos que residen en un SMBD
puede exponer informacion sensible a personas no autorizadas, esto puede afectar la
privacidad de las personas, ocasionar multas a empresas por incumplimiento a las leyes
y regulaciones sobre el manejo adecuado de la informacion, o exponer informacion
secreta de un gobierno afectando de esta manera la seguridad nacional de un paıs.
CAPITULO 1. INTRODUCCION 7
Un incidente sobre la integridad de los recursos que residen en un SMBD puede
afectar la veracidad de la informacion que es utilizada para la toma de decisiones, o la
ejecucion correcta de transacciones u operaciones criticas.
Un incidente sobre la disponibilidad de los recursos que residen en un SMBD pude
afectar la ejecucion de procesos crıticos que utilizan y dependen de dichos recursos como
entrada para completarse adecuadamente.
1.4. Trabajos relacionados
Dentro de los trabajos relacionados a esta investigacion se encuentran los siguientes:
En el articulo [3] se proponen tecnicas de inyeccion basadas en la mutacion de
operadores para evadir controles de seguridad que pueden tratar de impedir la
inyeccion exitosa de sentencias SQL desde la aplicacion de manera no autorizada,
dichas tecnicas se analizan desde un enfoque de “caja negra” donde no se tiene
conocimiento previo del sistema que se esta atacando.
En el articulo [10] se proponen tecnicas para identificar modulos de una aplicacion
Web con vulnerabilidades de SQL Injection, para ello se define una maquina finita
de estados donde cada modulo de la aplicacion representa un estado y el envıo
de parametros por los metodos HTTP GET/POST representan las funciones de
transicion.
En el articulo [9] se propone el uso de vistas parametrizadas para reducir los riesgos
de explotacion de vulnerabilidades de SQL Injection o a contener los impactos
sobre los recursos del SMBD en caso de un ataque exitoso.
CAPITULO 1. INTRODUCCION 8
1.5. Estructura del trabajo
El presente trabajo de investigacion tiene la siguiente estructura:
En el primer capıtulo se define el Planteamiento del Problema, Objetivo y Justificacion
de la investigacion.
En el segundo capıtulo se definen conceptos basicos de Seguridad de la Informacion
que son utilizados en temas posteriores para implementar controles preventivos de
seguridad y analizar las vulnerabilidades asociadas a un SMBD y sus ambientes.
En el tercer capıtulo, desde un enfoque ofensivo se analizan tecnicas de SQL
Injection en una aplicacion Web, y se propone una metodologıa para ejecutar
ataques de SQL Injection de manera efectiva.
En el cuarto capıtulo, desde un enfoque defensivo se definen los controles de
seguridad mınimos que se deben considerar en la administracion de un SMBD
con el fin de reducir los riesgos de explotacion, o en su caso contener los impactos
sobre recursos de un SMBD ante un ataque exitoso, principalmente se analiza
el uso de vistas parametrizadas y parametros de sesion en una aplicacion para
reducir los riesgos de explotacion de SQL Injection.
1.6. Alcance y limitaciones
Este trabajo de investigacion se enfoca principalmente en el ataque de SQL
Injection, ya que este ataque es el mas comun sobre aplicaciones Web y el que
mas hace dano a las Bases de Datos con las que interactua [2].
En el enfoque defensivo propuesto, se definen los controles mınimos de seguridad
que se deben implementar en un SMBD independientemente del producto o
CAPITULO 1. INTRODUCCION 9
version de SMBD que se este utilizando, y no se enfoca a una version o producto
de SMBD en particular.
Se deja para trabajos posteriores profundizar en las vulnerabilidades que pueden
existir en otros ambientes que interactuan con un SMBD, como son los servicios
Web (SOAP y REST) desde donde se ejecutan operaciones sobre los recursos
de un SMBD, el Sistema Operativo donde reside el SMBD y los protocolos de
capa 7 (modelo OSI) que son utilizados para administrar remotamente el SMBD,
ası como los controles preventivos de seguridad que se deben considerar en cada
una de estas capas para minimizar los riesgos de explotacion.
Capıtulo 2
Conceptos de seguridad de lainformacion
Para analizar los enfoques de seguridad planteados (Enfoque Ofensivo y Enfoque
Defensivo) es conveniente definir conceptos basicos de seguridad de la informacion,
ya que estos serviran como base para analizar temas posteriores. Debemos tener
en cuenta que al final lo que nos interesa proteger son los datos que se procesan,
resguardan o transmiten en sistemas de informacion y no los sistemas de informacion
en sı.
Es importante aclarar que la informacion puede existir en diferentes medios y
formas como documentos, medios electronicos, software, entre otros. Por lo que
el concepto de seguridad de la informacion no debe ser confundido con el de
seguridad informatica [4], en particular esta investigacion se enfoca en los datos
que residen, procesan o transmiten en un SMBD y en los ambientes con los
que interactua, y la definicion de los siguientes conceptos de seguridad de la
informacion se van orientar en este sentido.
10
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 11
2.1. Conceptos de seguridad de la informacion
� La Seguridad de la Informacion es el conjunto de controles preventivos de
seguridad que permiten asegurar y proteger la confidencialidad, integridad y
disponibilidad (CID) de los recursos de un SMBD.
� El principio de confidencialidad asegura que los recursos de un SMBD son
accesados solo por los usuarios autorizados.
� El principio de integridad asegura que los recursos de un SMBD son modificados
solo por usuarios autorizados, y que dichos usuarios solo pueden hacer modificaciones
o acciones autorizadas sobre dichos recursos.
� El principio de disponibilidad asegura que los recursos de un SMBD estan
disponibles a los usuarios autorizados cuando estos son requeridos.
� Un usuario es cualquier entidad logica (programa, usuario final, proceso,
sistema) que interactua con un sistema.
Figura 2.1: Propiedades de seguridad en un SMBD
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 12
� Una vulnerabilidad es una debilidad inherente o la falta de controles de
seguridad en el SMBD o en sus ambientes, y que pueden ser explotadas por
una amenaza afectando negativamente alguna de las tres propiedades basicas
de seguridad de la informacion (CID). Las vulnerabilidades asociadas a un
SMBD y sus ambientes son evaluadas de acuerdo al grado en que dichas
vulnerabilidades pueden impactar alguna de las propiedades de seguridad
(CID), en caso de que estas sean explotadas por algun agente de amenaza
ya sea de manera intencional o accidental.
� Una amenaza es un agente interno o externo que puede aprovechar alguna
vulnerabilidad o la falta de controles de seguridad en un SMBD o en sus
ambientes, la explotacion de una vulnerabilidad puede ser de manera intencional
o accidental y el resultado es una afectacion o impacto negativo a los recursos
que residen en un SMBD. Los agentes de amenaza mas comunes son:
◦ Usuarios o administradores de la Base de Datos
◦ Empleados disgustados en una organizacion
◦ Hackers o atacantes externos
� Un riesgo es la probabilidad de que un agente de amenaza explote alguna
vulnerabilidad o aproveche la falta de controles de seguridad en un SMBD o
en alguno de sus ambientes y el impacto que dicha explotacion puede causar
sobre los recursos de un SMBD.
� Los controles de seguridad que se implementan en un SMBD y en sus ambientes
ayudan a mitigar los riesgos de explotacion de vulnerabilidades, reduciendo la
probabilidad de que una amenaza explote alguna vulnerabilidad o aproveche
la falta de controles de seguridad. Los controles de seguridad tambien ayudan
a contener los impactos en la confidencialidad, integridad y disponibilidad
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 13
de los recursos de un SMBD en caso de un ataque exitoso. Los controles de
seguridad se evaluan de acuerdo al grado que dichos controles protegen y
aseguran las tres propiedades de seguridad en un SMBD (CID).
Figura 2.2: Relacion de los elementos de seguridad en un SMBD [5]
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 14
� Existen tres tipos de controles de seguridad, estos son: controles administrativos,
controles tecnicos (tambien llamados controles logicos) y controles fısicos.
Los controles administrativos incluyen el desarrollo e implementacion de
polıticas, estandares, procedimientos y guıas de seguridad.
Los controles tecnicos tienen que ver con la implementacion de controles
de seguridad en hardware y software, ejemplo de controles tecnicos son la
implementacion de antivirus, definicion de reglas de acceso en un firewall, o
definicion de polıticas robustas de password en una aplicacion.
Los controles fısicos se refieren a la proteccion de las instalaciones fısicas
donde residen los sistemas de informacion para asegurar que solo personal
autorizado tenga acceso fısico a los mismos y que las instalaciones cuentan
con condiciones seguras para el correcto funcionamiento de los sistemas
de informacion, ejemplo de controles fısicos pueden ser un guardia que se
encuentra en la entrada de un centro de datos, camaras de seguridad, o
controles ambientales y de temperatura en un centro de datos.
� Los controles administrativos, tecnicos y fısicos de seguridad se dividen en las
siguientes categorıas: controles preventivos, controles detectivos y controles
correctivos.
Los controles preventivos son aquellos que ayudan a evitar que ocurra un
evento no deseado, ejemplos de controles preventivos son el uso de password
robustos en una aplicacion, para prevenir accesos no autorizados.
Los controles detectivos son aquellos que identifican la ejecucion de un incidente
de seguridad o de un evento no deseado, un ejemplo puede ser el uso de
un IDS (Intrusion Detection System) para detectar actividades anomalas o
violaciones a las polıticas de seguridad en una red de datos.
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 15
Los controles correctivos son aquellos que se utilizan para recuperar el estado
original o normal de un sistema despues de un incidente de seguridad o un
evento no deseado, un ejemplo de este control es el plan de continuidad de
negocio de una organizacion para recuperar la operacion de procesos crıticos
despues de un incidente de seguridad.
� Un control de accesos basicamente consiste en tres procesos que son: identificacion,
autenticacion y autorizacion.
El proceso de identificacion consiste en asignar una identidad a los usuarios
que acceden a un sistema de informacion, de esta manera dichos usuarios
pueden ser identificados de manera unica, por lo que las acciones que realicen
dichos usuarios en el sistema de informacion son asociadas a los mismos,
comunmente la asignacion de esta identidad se da por una cuenta de usuario
o ID de acceso al sistema.
El proceso de autenticacion consiste en que dichos usuarios demuestran su
identidad. Un usuario puede demostrar su identidad de tres formas: algo
que es usuario es (ejemplo: accesos biometricos), algo que el usuario tiene
(ejemplo: tokens de acceso, tarjetas de identidad) o algo que el usuario
conoce (ejemplo: password de acceso). La forma mas comun de demostrar
la identidad de un usuario es por medio de passwords de acceso (algo que el
usuario conoce).
Se pueden combinar varias formas para demostrar la identidad de un usuario,
lo cual se conoce como doble factor de autenticacion.
El proceso de autorizacion consiste en asegurar que los usuarios una vez
identificados y autenticados puedan acceder solo los recursos del sistema
sobre los que tienen permisos.
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 16
Figura 2.3: Controles administrativos, tecnicos y fısicos [5]
� El Principio de mınimos privilegios (least privilege) consiste en asegurar que
los usuarios solo tengan los permisos mınimos necesarios para realizar sus
funciones.
� El concepto de Seguridad en Profundidad (Defense in depth) tiene que ver
con la implementacion de diferentes controles de seguridad en distintas capas
de un sistema de informacion para proteger los datos de amenazas, estas
capas tienen la finalidad de proveer redundancia en caso de que un control
de seguridad falle o sea vulnerado.
Cada una de las capas considera controles fısicos, controles administrativos,
y controles tecnicos o logicos, que en su conjunto presentan una serie de
capas de seguridad para proteger la informacion.
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 17
Este concepto tiene sus orıgenes en el area militar donde se buscaba retardar
o estorbar el avance de un atacante, con el fin de ganar tiempo y dar respuesta
a los incidentes de manera oportuna. La idea es implementar diferentes capas
de seguridad para proteger la informacion.
Figura 2.4: Seguridad en profundidad
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 18
� La gestion de riegos es un proceso donde se analiza y cuantifica la probabilidad
de que una vulnerabilidad sea explotada por algun agente de amenaza, ya
sea de manera accidental o intencional, y el impacto que dicha explotacion
puede ocasionar sobre la confidencialidad, disponibilidad o integridad de los
recursos de un SMBD.
Dichos impactos sobre los recursos de un SMBD pueden ocasionar perdidas
monetarias, mala reputacion de una organizacion, afectacion a la privacidad
de las personas, multas o demandas por incumplimiento a las regulaciones
sobre la proteccion de datos personales.
El resultado del proceso de analisis de riesgos muestra el costo-beneficio de la
implementacion de controles de seguridad contra el costo del impacto debido
a la afectacion en los datos en caso de que una vulnerabilidad sea explotada.
Existen dos tipos de analisis de riesgos, estos son: analisis de riegos cuantitativo
y analisis de riesgos cualitativo.
Un proceso de gestion de riesgos cualitativo consta basicamente de las siguientes
etapas [6]:
◦ Establecimiento de metricas de riesgo
◦ Perfil de activos
◦ Identificacion de amenazas
◦ Identificacion y mitigacion de riesgos
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 19
Figura 2.5: Fases para la gestion de riesgos - Metodologıa Octave Allegro
En el establecimiento de las metricas de riesgo se deben involucrar a las
diferentes areas de la organizacion para definir un conjunto de metricas
cualitativas contra las cuales se evaluaran los riesgos en la organizacion y
establecer las areas de impacto mas significativas en la organizacion. La
definicion adecuada de este conjunto de metricas de riesgo asegura que las
decisiones acerca de como mitigar dichos riesgos sea consistente.
Ejemplos de areas de impacto son:
◦ Reputacion
◦ Confianza del cliente
◦ Finanzas
◦ Productividad
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 20
Figura 2.6: Objetivos de cada fases para la gestion de riesgos
◦ Seguridad y salud
◦ Multas y sanciones legales
◦ Imagen de la marca
Para identificar las metricas de impacto que se utilizaran para evaluar los
riesgos, se pueden utilizar las siguientes preguntas:
◦ ¿Que servicios, procesos o informacion son los mas relevantes dentro de
la organizacion?
◦ ¿Que servicios, procesos o informacion, si se vieran afectados, tambien
afectarıan a la mision y objetivos de la organizacion?
Para cada servicio, proceso e informacion identificados en los puntos anteriores,
se deben definir las situaciones o condiciones que podrıan ocasionar un
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 21
impacto, clasificando dichos impactos como alto(3), medio(2) y bajo(1).
Figura 2.7: Metricas de impacto
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 22
Una vez que se han definido las metricas de impacto, se deben identificar los
activos de informacion que estan relacionados con dichas areas de impacto
y sus contenedores. Un contendedor es donde reside, transmite o procesan
los servicios o informacion (ejemplo: hardware, software, servidores, redes,
lugares fısicos como cajones, documentos, o personas) y que se pueden convertir
en puntos vulnerables que podrıan negativamente a la organizacion.
Se debe asegurar de que la descripcion de los activos de informacion sea
clara y concisa, y que los requerimientos de seguridad para dichos activos
sean definidos adecuadamente.
Para cada activo de informacion identificado se debe incluir al menos:
◦ Nombre del activo de informacion
◦ Razon de la seleccion (¿Por que este activo es importante para la organizacion?)
◦ Descripcion (¿Cual es la descripcion del activo de informacion?)
◦ Dueno(s) (¿A quien pertenece el activo de informacion?, ¿Quien es responsable
por este activo de informacion?, ¿Quien es dueno de los procesos donde
este activo de informacion es usado?, ¿Quien es el responsable por asignar
valor (monetario u otro) a este activo de informacion?, ¿Quien seria mas
impactado si este activo de informacion es comprometido?, ¿Existen
diferentes duenos para los distintos elementos que componen este activo
de informacion?)
◦ Requerimientos de seguridad (integridad, confidencialidad, disponibilidad,
otro)
◦ Requisito de seguridad mas importante (¿Cual es el requisito de seguridad
mas importante para
◦ Descripcion de los contenedores (tecnologico/fısico/humano/interno/externo)
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 23
del activo de informacion
Figura 2.8: Identificacion de contenedores
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 24
En la identificacion de vulnerabilidades se obtiene informacion de los contenedores,
como: arquitecturas, tecnologıas, versiones, listas de usuarios, flujos de informacion,
etc., y se identifican vulnerabilidades tecnicas, de procesos o en el personal
(capacitacion o concientizacion) basados en escenarios de riesgos donde se
consideran diferentes actores, motivos y medios que pueden ser utilizados
para explotar alguna vulnerabilidad.
La finalidad de esta fase es identificar vulnerabilidades tecnicas, de procesos
o en el personal (capacitacion o concientizacion) que podrıan exponer la
informacion o causar que los procesos identificados sean afectados.
Figura 2.9: Analisis de vulnerabilidades
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 25
Para la identificacion, analisis y tratamiento de riesgos se debe medir el
impacto a la organizacion si una vulnerabilidad es explotada, y las consecuencias
que dicha explotacion puede causar a la organizacion de acuerdo a las metricas
de impacto definidas previamente.
La forma calcular el riesgo es la siguiente:
Riesgo = Impacto * probabilidad
Este calculo se debe realizar para cada vulnerabilidad identificada. Con los
valores obtenidos se obtiene una matriz de riesgos, que califica el riesgo de
cada vulnerabilidad con la finalidad de identificar los riesgos mas crıticos y
los que se debe dar prioridad para su tratamiento.
Figura 2.10: Calculo del riesgo
CAPITULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACION 27
Con los resultados del analisis de riesgos, la organizacion debe decidir como
dara tratamiento al riesgo, teniendo las siguientes opciones:
◦ Aceptar el riesgo
◦ Mitigar el riesgo
◦ Transferir el riesgo
Capıtulo 3
Enfoque ofensivo de seguridad
Actualmente los sistemas de informacion son fundamentales para el desarrollo
de las actividades cotidianas de las personas y organizaciones, el uso de
Internet y dispositivos moviles ha propiciado el desarrollo de aplicaciones
en la nube y servicios Web desde los cuales los usuarios ejecutan diferentes
operaciones sobre los recursos del SMBD con el que interactua.
En este escenario los datos estan cada vez mas expuestos a diferentes amenazas
y vectores de ataque, por lo que si no se incluyen controles de seguridad
adecuados en el diseno y desarrollo de estos sistemas, se pueden exponer
diferentes vulnerabilidades las cuales pueden ser explotadas por algun agente
de amenaza.
Principalmente la capa aplicativa es un vector comun de ataque, ya que esta
capa por su naturaleza se encuentra expuesta a diferentes usuarios y sistemas,
que utilizan los diferentes puntos de entrada hacia el SMBD para la ejecucion
de operaciones como consultas y modificacion de registros sobre bases de
datos. Si estos puntos de entrada no son validados adecuadamente pueden
permitir la inclusion de codigo o sentencias maliciosas para manipular la
ejecucion logica de la aplicacion y el envıo de sentencias al SMBD de manera
28
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 29
no autorizada, afectando la integridad, disponibilidad y confidencialidad de
los recursos del SMBD con el que interactua.
En este capıtulo se analiza principalmente la vulnerabilidad de SQL Injection,
desde un enfoque de “caja negra”, donde no se tiene conocimiento previo de
la arquitectura e infraestructura del sistema que es atacado.
Para esta investigacion, la identificacion y explotacion de vulnerabilidades
no es el fin, si no el medio para implementar controles efectivos de seguridad
que ayuden a minimizar los riesgos de explotacion.
Los atacantes pueden potencialmente usar rutas diferentes a traves de la
aplicacion para hacer dano a una organizacion. Cada una de estas rutas
representa un riesgo que puede, o no, ser lo suficientemente grave como
para justificar su atencion. A veces estas rutas son triviales de encontrar
y explotar, y otras veces requieren de un conocimiento tecnico avanzado
para poder explotar dichas vulnerabilidades.
Figura 3.1: Riesgos de seguridad en aplicaciones - OWASP
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 30
3.1. Vulnerabilidades en la capa aplicativa
Actualmente el uso de Internet es esencial para la operacion de los sistemas
de informacion, aunado al aumento en el uso de de plataformas en la nube
y dispositivos moviles con gran capacidad de procesamiento para acceder y
manipular Bases de Datos a traves de aplicaciones y servicios Web como
SOAP o REST, hacen de esta capa un vector comun de ataque hacıa los
recursos del SMBD.
En este escenario los controles perimetrales se vuelven insuficientes para
proteger adecuadamente las Bases de Datos, ya que la capa aplicativa por su
naturaleza expone puntos de entrada a diferentes usuarios y sistemas para
interactuar con los recursos del SMBD. Estos puntos de entrada pueden
aceptar datos de diferentes fuentes como formularios Web, cookies o webservices,
dichos datos son procesados por la aplicacion para ejecutar procesos u operaciones
sobre los recursos del SMBD.
De acuerdo a estadısticas elaboradas por Gartner, el 75 % de los ataques
ocurren en la capa aplicativa [1], por lo que es importante analizar los
controles preventivos de seguridad que se deben implementar y las vulnerabilidades
a las que puede estar expuesta dicha capa.
Por otro lado los desarrolladores generalmente se enfocan mas en la funcionalidad
y operacion de la aplicacion y dejan a un lado los requerimientos de seguridad
en el ciclo del desarrollo del software, por lo que es comun encontrar aplicaciones
en ambientes productivos con vulnerabilidades que pueden comprometer los
recursos del SMBD u otros sistemas a los que se conecta.
La implementacion de controles de seguridad en ambientes productivos es
mas costosa en tiempo y recursos, por lo que es importante considerar los
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 31
requerimientos de seguridad desde las fases iniciales del ciclo de desarrollo
del software para poder detectar vulnerabilidades potenciales en el diseno
del sistema, con la finalidad de corregir dichos huecos de seguridad antes de
su implementacion en ambientes de produccion.
Las vulnerabilidades mas comunes en la capa aplicativa segun la fundacion
OWASP (Open Web Application Security Project) son:
◦ Vulnerabilidades de inyeccion.
◦ Perdida de autenticacion y gestion de sesiones.
◦ Ejecucion de scripts maliciosos (Cross-Site Scripting - XSS).
◦ Referencia directa insegura a objetos.
◦ Configuraciones de seguridad incorrectas.
◦ Exposicion de datos sensibles.
◦ Ausencia de control de acceso a las funciones.
◦ Falsificacion de peticiones (Cross-Site Request Forgery - CSRF).
◦ Uso de componentes con vulnerabilidades conocidas.
◦ Redirecciones y reenvıos no validados.
Aunque existen diferentes frameworks de desarrollo (spring, .net, ruby on
rails, django, web2py, etc.) con funcionalidades de seguridad propias para
reducir los riesgos de explotacion de vulnerabilidades comunes, si el framework
utilizado no es implementado adecuadamente, es posible que un atacante
explote vulnerabilidades en la aplicacion exitosamente, por lo que no basta
con implementar algun framework de desarrollo, si no que es necesario incluir
los requerimientos de seguridad en todo el ciclo de vida de desarrollo del
software y analizar la arquitectura del sistema para asegurar que se estan
implementado controles adecuados de seguridad que no afecten la operacion
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 32
del sistema, pero que si ayuden a minimizar los riesgos de explotacion de
manera efectiva.
Las vulnerabilidades de inyeccion son las mas comunes en la capa aplicativa,
los atacantes pueden aprovechar esta vulnerabilidad para extraer informacion
de manera no autorizada o ejecutar codigo malicioso, ya que esta vulnerabilidad
permite enviar sentencias SQL (SQL Injection), comandos para manipular
la ejecucion logica de procesos en el sistema operativo, o evadir metodos de
autenticacion de manera no autorizada.
3.2. SQL Injection
Dentro de las vulnerabilidades de inyeccion, el ataque de SQL Injection es
que mas hace dano a las bases de datos con las que interactua la aplicacion,
ya que esta vulnerabilidad permite a un atacante manipular el envıo de
sentencias SQL a la base de datos y ejecutar procesos sobre los recursos del
SMBD de manera no autorizada.
SQL Injection ocurre principalmente por las siguientes causas:
◦ Se utilizan Queries dinamicos para ejecutar sentencias SQL en la base
de datos desde la aplicacion.
◦ No se utilizan usuarios especıficos con los privilegios mınimos necesarios
para conectar a la base de datos desde la aplicacion.
◦ No se sanitizan o filtran los datos de entrada enviados desde la aplicacion
a la base de datos para construir sentencias SQL y asegurar que los datos
sean del tipo y tamano esperado.
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 33
Figura 3.2: Causas que propician vulnerabilidades SQL Injection
Aunque el ataque de SQL Injection generalmente se ejecuta sobre la capa
aplicativa y no directamente sobre el SMBD, se deben implementar controles
de seguridad en cada una de las capas con el fin de minimizar los riesgos de
explotacion o contener el impacto sobre los recursos del SMBD en caso de
un ataque exitoso de SQL Injection.
SQL es el lenguaje estandar para manipular datos en diferentes SMBD
relacionales como Microsoft SQL Server, Oracle, MySQL, Sybase, Informix,
etc., por lo que cualquier proceso desde la aplicacion que construya sentencias
de SQL puede ser potencialmente vulnerable a SQL Injection si no se implementan
los controles de seguridad adecuados para reducir los riegos de explotacion.
Esta vulnerabilidad se agrava cuando el usuario utilizado para conectar a la
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 34
base de datos desde la aplicacion cuenta con privilegios de administracion,
ya que cuando esto ocurre es posible inyectar comandos o sentencias para
acceder o manipular otros recursos del sistema de manera no autorizada,
como es el caso de Microsoft SQL Server que cuenta con la funcion xp cmdshell,
la cual puede ser utilizada por un atacante para ejecutar comandos en el
Sistema Operativo donde reside el SMBD, con la posibilidad de comprometer
el sistema operativo o “pivotear” a otros sistemas.
El escenario general de la vulnerabilidad de SQL Injection es el siguiente:
Figura 3.3: Escenario del ataque de SQL Injection - OWASP
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 35
3.3. Mal manejo de sesiones
El manejo seguro de sesiones en una aplicacion se refiere a proteger adecuadamente
los parametros de sesion de un usuario, de tal manera que estos no puedan ser
robados, alterados o falsificados por un atacante, lo cual le permitirıa robar
la identidad de otro usuario y acceder a la aplicacion con dicha identidad de
manera no autorizada.
La forma mas comun de autenticar a una aplicacion Web es por medio de
passwords de acceso, por lo que el manejo y administracion de los password
debe ser adecuado y seguro, considerando al menos que estos no se resguarden
o se envıen en texto claro o de una forma que queden expuestos en el proceso
de autenticacion.
Las vulnerabilidades en el manejo de sesiones y en el proceso de autenticacion
se puede dar por las siguientes causas:
◦ Los IDs de sesion o password de acceso se exponen en la URL, es decir,
se envıan los parametros por medio del metodo HTTP GET, por lo que
estos datos pueden ser capturados y modificados por un atacante.
◦ Los IDs de sesion no se generan con un algoritmo robusto que asegure
IDs aleatorios, por lo que un atacante puede falsificar los IDs de sesion
y robar la identidad de un usuario valido.
◦ Las sesiones no expiran por tiempo de inactividad.
◦ No se destruyen e invalidan los parametros de sesion despues del cierre
de sesion de la aplicacion.
◦ Los parametros de sesion y password de acceso se envıan en canales no
cifrados.
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 36
◦ Los password se resguardan en texto claro.
◦ No hay polıticas robustas de password en la aplicacion, se permite el uso
de password debiles y estos no expiran por inactividad.
Figura 3.4: Escenario de vulnerabilidades en el manejo de sesiones
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 37
Para ejemplificar esta vulnerabilidad, supongamos que tenemos una aplicacion
Web que genera un ID de sesion por cada usuario que se autentica a la
aplicacion, este ID de sesion es utilizado para permitir acceso a diferentes
funcionalidades en la aplicacion.
Figura 3.5: Mal manejo de sesiones en una aplicacion Web
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 38
Esta aplicacion tiene la vulnerabilidad de que los IDs de sesion no se generan
con un algoritmo robusto que asegure que el ID de sesion se genera de manera
no predecible. En este caso se puede observar que el algoritmo utilizado para
generar el ID de sesion se genera con un algoritmo simple de transposicion
de letras, donde cada letra es reemplazada por su sucesor, ejemplo:
"a" por "b"
"f por "g"
Y el nombre del usuario es invertido, en este caso el nombre del usuario es
webgoat, si se invierte, el resultado es taogbew, despues sustituyendo cada
letra por su sucesor tenemos ubphcfx. Por lo que en este caso el algoritmo
utilizado es debil y puede ser vulnerado para lograr acceso a la aplicacion.
Figura 3.6: modificacion de los parametros de sesion
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 39
Algunas veces se utilizan mecanismos debiles para manejar las sesiones o
implementan algoritmos propios los cuales pueden tener vulnerabilidades
que pueden ser aprovechadas por un atacante para acceder de manera no
autorizada a la aplicacion.
En este ejemplo, un atacante puede acceder a la aplicacion sin proporcionar
un password valido de acceso, inyectando un ID de sesion valido, puede
ingresar a la aplicacion de manera no autorizada.
Figura 3.7: Acceso no autorizado a una aplicacion por vulnerabilidades en el manejo desesiones
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 40
3.4. Cross-Site Scripting - XSS
Esta vulnerabilidad ocurre cuando una aplicacion, en una pagina enviada a
un navegador incluye datos suministrados por un usuario sin ser validados o
codificados apropiadamente, por lo que un atacante puede ejecutar secuencias
de comandos en el navegador de la vıctima para secuestrar las sesiones de
usuario, alterar la apariencia del sitio Web, insertar codigo hostil, redirigir
usuarios, secuestrar el navegador de la vıctima utilizando malware, etc.
Existe tres tipos de fallas conocidas XSS:
◦ XSS Almacenado: en este tipo de vulnerabilidad es posible almacenar
scripts maliciosos en la aplicacion, por lo que cada vez que un usuario
ingrese al modulo vulnerado, el script malicioso se ejecuta automaticamente.
◦ XSS Reflejado: en este tipo de vulnerabilidad el script malicioso se
adjunta en algun parametro utilizado por la aplicacion y que es interpretado
por el navegador Web de la vıctima cuando dicho parametro es interpretado.
◦ XSS Basado en DOM.
El escenario de la vulnerabilidad de XSS es la siguiente:
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 41
Figura 3.8: Escenario del ataque de XSS
En el siguiente ejemplo se tiene una aplicacion vulnerable a XSS almacenado,
la aplicacion tiene un modulo de visitas donde los usuarios de la aplicacion
ingresan y dejan sus comentarios sobre el sitio, debido a que este modulo
no valida adecuadamente los datos ingresados por los usuarios, es posible
ingresar scripts maliciosos que son almacenados por el servidor.
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 42
Figura 3.9: Inyeccion de script malicioso XSS almacenado
Cuando un usuario entra a la aplicacion, el script malicioso es interpretado
por el navegador del usuario. Para evitar este tipo de ataques la aplicacion
debe validar que los datos de entrada sean del tipo y tamano esperado por
la aplicacion.
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 43
Figura 3.10: El navegador de la vıctima interpreta el codigo malicioso
3.5. Envıo de datos no cifrados
El SMBD se debe instalar en lo posible en un servidor dedicado, ya que
de esta manera se pueden habilitar solo los servicios requeridos para el
funcionamiento del SMBD.
Si el SMBD convive con otras aplicaciones o servicios vulnerables, estos
podrıan poner en riesgo el SMBD si dichos servicios o aplicaciones son
comprometidos.
Cada servicio o protocolo habilitado si no es configurado adecuadamente
puede representar un riesgo para la informacion, por ejemplo, si el Sistema
Operativo donde reside el SMBD se va administrar remotamente y se habilita
el protocolo Telnet para ello, un atacante podrıa hacer sniffing en la red y
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 44
obtener informacion sensible como passwords de acceso al SMBD, en su lugar
se debe implementar un protocolo seguro de comunicacion (ejemplo: ssh) que
cifre los datos enviados desde el cliente al servidor donde reside el SMBD
para que en caso de que estos datos sean interceptados por un atacante en
la red, este no pueda obtener informacion sensible.
En un ejemplo donde se tiene un servidor MySQL en la IP 192.168.56.101
con el puerto default de MySQL 3306 habilitado para permitir conexiones
remotas sin utilizar un protocolo seguro de comunicacion que cifre los datos
enviados desde el cliente al servidor donde reside el SMBD, un atacante que
se encuentre en el mismo segmento LAN puede capturar el trafico no cifrado
en la red y obtener informacion sensible como passwords de acceso, comando
ejecutados, datos de tarjeta de credito, informacion financiera u otro tipo de
informacion sensible.
Figura 3.11: Captura de trafico no cifrado
Si un usuario inicia una sesion al servidor MySQL 192.168.56.101 desde el
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 45
cliente 192.168.56.102 sin utilizar un protocolo seguro de comunicacion que
cifre los datos enviados al servidor MySQL, un atacante que se encuentra
en el mismo segmento LAN puede ejecutar un ataque de sniffing en la red
obteniendo el nombre de la cuenta con el que dicho usuario esta accesando,
con esta informacion el atacante posteriormente podrıa ejecutar un ataque
de fuerza bruta o diccionario para tratar de acceder al SMBD de forma no
autorizada.
Figura 3.12: El atacante obtiene el nombre de la cuenta con la que esta accesando elusuario
Posteriormente el usuario ejecuta el comando CREATE USER para crear un
nuevo usuario con privilegios sobre las bases de datos que residen en MySQL.
Figura 3.13: El usuario crea un nuevo usuario en el SMBD
El atacante obtiene los comandos enviados los cuales incluyen el usuario y
password de acceso al SMBD, debido a que el usuario no utilizo protocolos
seguros de comunicacion que cifren los datos enviados desde el cliente al
servidor MySQL, de esta manera el atacante logra capturar la creacion de
CAPITULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 46
un usuario obteniendo el usuario y password de acceso al SMBD.
Figura 3.14: El atacante obtiene el usuario y password de acceso
Capıtulo 4
Metodologıa para identificarvulnerabilidades contra ataquesde SQL Injection
Existen diferentes controles de seguridad para tratar de mitigar un ataque de
SQL Injection, tambien en aplicaciones grandes es difıcil detectar puntos de
entrada vulnerables a inyeccion, aun con el uso de herramientas automatizadas
para escanear y detectar este tipo de vulnerabilidades se pueden obtener
falsos positivos, por lo que se requiere de una metodologıa adecuada para
ejecutar un ataque exitoso de SQL Injection, ya que de lo contrario se
pueden desperdiciar recursos para tratar de lograr una inyeccion exitosa en
la aplicacion.
Para identificar vulnerabilidades de inyeccion eficientemente se propone la
siguiente metodologıa:
Figura 4.1: Panorama general de una metodologıa de explotacion SQL Injection
47
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION48
Figura 4.2: Pasos de una metodologıa de explotacion SQL Injection
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION49
4.0.1. Reconocimiento pasivo
En el reconocimiento pasivo se ejecutan operaciones normales sobre la aplicacion
con la finalidad de entender el comportamiento de la aplicacion, este entendimiento
de la aplicacion es util para identificar los modulos que tienen una interaccion
sobre algun recurso del SMBD.
Este tipo de reconocimiento no es intrusivo y no se espera que la aplicacion
responda de manera inesperada o que genere algun tipo de alarma que
informe sobre las actividades que esta ejecutando el atacante.
4.0.2. Identificar los modulos que interactuan con el
SMBD
Debido a que el enfoque de ataque propuesto para esta investigacion es de
caja negra, no se tiene acceso al codigo de la aplicacion que se esta atacando
u otro tipo de informacion que nos ayude a perfilar y obtener detalle de
la arquitectura del sistema, por lo que para identificar los modulos que
interactuan con algun recurso del SMBD se pueden utilizar herramientas
proxy que nos permiten analizar la comunicacion entre un cliente y una
aplicacion Web.
Figura 4.3: Uso de proxy para analizar el comportamiento logico de la aplicacion
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION50
En una arquitectura basica de tres capas, la logica de la aplicacion se encuentra
en la capa aplicativa, en esta capa se encuentra el codigo que interactua y
envıa operaciones al SMBD. Un usuario final generalmente interactua con la
capa aplicativa a traves de un navegador Web, desde donde envıa datos a la
aplicacion a traves de metodos HTTP GET/POST. La capa aplicativa recibe
estos datos de entrada por medio de parametros o variables, y los utiliza
posteriormente para enviar instrucciones al SMBD. Por ejemplo, un usuario
puede realizar la busqueda de registros hacia una Base de Datos a traves
de un formulario Web de busqueda, los datos recibidos por la aplicacion son
utilizados para armar una sentencia SQL que es enviada al SMBD para su
ejecucion, la capa aplicativa tambien se encarga de regresar una respuesta al
usuario final.
Figura 4.4: Ejecucion de operaciones al SMBD desde la aplicacion
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION51
Generalmente el metodo HTTP GET es el metodo mas simple para obtener
recursos de un servidor, dichos recursos pueden ser paginas HTML, imagenes
JPEG u otro tipo de archivos, por el contrario con el metodo POST no solo
se pueden obtener recursos de un servidor, si no tambien se puede enviar
datos al servidor para ser procesados.
Otra diferencia entre el metodo GET y POST, es que el primero expone los
parametros y los datos enviados al servidor en la URL o recurso solicitado,
por lo que en caso de enviar datos sensibles, estos pueden ser interceptados y
modificados facilmente por un atacante para ejecutar inyecciones con dichos
parametros.
Figura 4.5: Estructura del metodo HTTP GET
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION52
Figura 4.6: Estructura del metodo HTTP POST
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION53
La identificacion de los parametros utilizados por la aplicacion para ejecutar
operaciones en el SMBD por medio de los metodos HTTP GET/POST es
muy importante ya que estos parametros son utilizados para ejecutar ataques
de SQL Injection modificando los datos enviados a traves de los mismos. En
este ejemplo se puede observar que la aplicacion envıa el parametro “id” por
el metodo HTTP GET.
Figura 4.7: Identificacion de parametros que envıan datos a traves de HTTP GET yPOST
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION54
Para identificar los modulos que interactuan con un SMBD se define una
maquina finita no determinista de estados donde cada modulo representa
un estado y el envıo de parametros a traves de los metodos GET o POST
representan las funciones de transicion.
Para identificar los modulos que interactuan con algun recurso del SMBD
utilizaremos los siguientes estados:
◦ Estado c: modulo que devuelve el resultado de una consulta.
◦ Estado a: modulo de autenticacion. Ejemplo: modulo que solicita un
usuario/password de acceso.
◦ Estado s: modulo que se utiliza para subir archivos a la aplicacion.
◦ Estado m: modulo para generar o modificar un registro desde la aplicacion.
Ejemplo: modulo que permite la entrada de comentarios en un blog o
pagina de visitas.
◦ Estado sqli: modulo vulnerable a ataques de SQL Injection.
A = Q, q 0, F,∑
, δ
Q = c, a, s, m, sqli
q0 = modulo desde donde se inicia la revision de la aplicacion.
∑= metodos HTTP POST y GET.
δ = Q×∑→ P (Q)
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION55
Despues de realizar el envıo de parametros a traves de los metodos HTTP GET o
POST, se identifican aquellos modulos que llegan a algun estado c, a, s, o m. Estos
modulos son los que se considera tienen interaccion con algun recurso del SMBD, y seran
validados posteriormente con tecnicas de inyeccion para identificar vulnerabilidades de
SQL Injection (estado sqli) en los mismos.
Figura 4.8: Ejemplo de tabla de estados para identificar los modulos que interactuancon un SMBD
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION56
4.0.3. Reconocimiento activo
En el reconocimiento activo se ejecutan actividades mas intrusivas sobre la aplicacion
para observar su comportamiento al tratar de enviar datos mal formados a la misma.
En esta etapa un atacante ejecuta validaciones mas agresivas sobre los modulos de la
aplicacion con la finalidad de perfilar el sistema y preparar un ataque mas dirigido sobre
la aplicacion, y como consecuencia afectar alguno de los recursos del SMBD de manera
no autorizada.
4.0.4. Identificar los puntos de entrada vulnerables a SQL Injection
Dependiendo de los controles de seguridad que se encuentren implementados en la
aplicacion que se esta atacando, se deben utilizar tecnicas avanzadas de inyeccion con
la finalidad de disminuir el numero de falsos positivos y evadir posibles controles de
seguridad como firewall de aplicaciones (WAF) o IDSs (Intrusion Detection System)
que pueden impedir la explotacion exitosa de un ataque de SQL Injection, en este
escenario se debe considerar que la sentencia inyectada muchas veces debe pasar por
diferentes servidores y controles de seguridad, antes de lograr una inyeccion exitosa a
la Base de Datos.
Figura 4.9: Escenarios general en un ataque de SQL Injection
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION57
Dependiendo del estado al que se haya llegado en la aplicacion (c, a, s, m) se deben
elegir los operadores adecuados para lograr una inyeccion exitosa. De acuerdo a la
metodologıa propuesta se definen los siguientes operadores de inyeccion.
Figura 4.10: Mutacion de Operadores de Inyeccion
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION58
Cada uno de estos operadores se pueden combinar de tal manera que se logre ejecutar
una sentencia SQL exitosamente de manera no autorizada. En particular los operadores
de ofuscacion se deben utilizar para evadir posibles controles de seguridad en la aplicacion
como firewalls o IDS.
4.0.5. Inyeccion de operadores de modificacion de comportamiento
Este tipo de operadores se utilizan para alterar o modificar el comportamiento normal
de la aplicacion con el fin de provocar un evento inesperado en la aplicacion que lleve a
la exposicion de informacion sensible como errores de sintaxis SQL, informacion tecnica
de la infraestructura o alterar la ejecucion logica de la aplicacion.
Inyeccion del operador OR
Definicion: Anade “OR x=x” a una clausula WHERE de una sentencia SQL donde
“x” es un numero o caracter aleatorio entre apostrofes o comillas.
Comunmente las sentencias SELECT y UPDATE utilizan la clausula WHERE para
restringir los registros que se van a consultar o actualizar en una Base de Datos, un
ejemplo de un sentencia SELECT basica es la siguiente:
SELECT [nombre_columna]
FROM [nombre_tabla]
WHERE [condicion]
En una aplicacion vulnerable, la condicion WHERE puede ser inyectada para alterar su
ejecucion normal, debido a que los datos de entrada de la aplicacion no son validados
adecuadamente para asegurar que estos sean del tipo y tamano esperado. Comunmente
los datos enviados son utilizados para crear Queries dinamicos hacia la Base de Datos,
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION59
por lo que si dichos datos son inyectados con una condicion “OR”, es posible alterar la
ejecucion de Queries desde la aplicacion de manera no autorizada.
$id = $_GET[’id ’];
$getid = "SELECT first_name , last_name
FROM users
WHERE user_id = ’$id ’";
En este ejemplo la aplicacion recibe el parametro “id” por medio del metodo HTTP
GET, el dato enviado por este parametro no es validado adecuadamente por lo que
se puede inyectar un operador “OR” para alterar la clausula WHERE de manera no
autorizada.
SELECT first_name , last_name
FROM users
WHERE user_id =1 OR 1=1;
En este ejemplo la inyeccion del operador “OR” ocasiona que la condicion WHERE
siempre sea verdadera, de esta manera un atacante puede extraer o modificar registros
en la Base de Datos de manera no autorizada.
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION60
Figura 4.11: Ejemplo de inyeccion de operador OR
Inyeccion del operador AND
Definicion: Anade “AND x=y” a una clausula WHERE de una sentencia SQL donde
“x” y “y” son numeros o caracteres aleatorios entre apostrofes o comillas, y “x” es
diferente a “y”.
Al igual que el operador OR, la inyeccion de un operador AND se hace comunmente
despues de la clausula WHERE con la finalidad de alterar la ejecucion logica de la
aplicacion, cualquier comportamiento anormal en la aplicacion despues de la inyeccion
del operador “AND” puede exponer vulnerabilidades de SQL Injection.
SELECT first_name , last_name
FROM users
WHERE user_id =1 AND 1=2;
En este caso el resultado de la consulta no arroja ningun tipo de informacion, debido
a que se inyecta una condicion falsa, de esta manera se confirma que la aplicacion
tiene vulnerabilidades de sql Injection, ya que la sentencia de comparacion inyectada
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION61
es procesada por el SMBD.
Figura 4.12: Ejemplo de inyeccion de operador AND
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION62
Inyeccion de sentencias adicionales
Definicion: Anade “;” seguido de una sentencia SQL adicional. El query resultante
tiene la forma;
sentencia_sql1; sentencia_sql2
Donde “sentencia sql1” es la sentencia original enviada por la aplicacion y “sentencia sql2”
es una sentencia SQL adicional.
Comunmente el operador “;” se utiliza para terminar una sentencia SQL, al inyectar
un operador “;”, nos permite terminar la sentencia SQL original enviada e incluir una
nueva sentencia que sera ejecutada por el SMBD.
Debido a que el objetivo de inyeccion de estos operadores es alterar el comportamiento
logico de la aplicacion, no se espera que con estas primeras inyecciones se logre la
extraccion de informacion o la ejecucion de operaciones sobre los recursos del SMBD
de manera no autorizada, muchas veces la aplicacion no sabe manejar correctamente
este tipo de eventos provocando mensajes de error que exponen informacion sensible,
como errores de sintaxis SQL o informacion tecnica de la infraestructura que informan
sobre la version de SMBD utilizado, esta informacion es muy valiosa para un atacante
ya que es utilizada para perfilar el sistema y ejecutar un ataque mas elaborado y
dirigido aprovechando las funcionalidades que el propio SMBD ofrece pero que pueden
ser utilizadas de manera no autorizada.
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION63
Figura 4.13: Ejemplo de mal manejo de errores
Dependiendo de las funcionalidades del SMBD y de los permisos que tenga el usuario
utilizado para conectar desde la aplicacion Web a la Base de Datos, se pueden inyectar
diferentes sentencias adicionales con el fin de ejecutar procesos en el SMBD.
Por ejemplo, un ataque de este tipo contra un SMBD Microsoft SQL Server, el cual
tiene la funcion xp cmdshell(string) que permite ejecutar comandos a nivel de sistema
operativo, puede en algunos casos permitir la creacion de usuarios en el sistema operativo
donde reside el SMBD, de esta manera un atacante obtiene mas visibilidad del sistema
que esta atacando con la posibilidad de comprometer otras aplicaciones, bases de datos
o sistemas. Otra funcion que se puede utilizar en esta tecnica de inyeccion contra un
SMBD Microsoft SQL Server es en la funcion sp execwebtask (sql,location), la cual
permite almacenar el resultado de la ejecucion de un Query en un directorio del servidor
donde reside el SMBD u otro servidor al que tenga conexion. Por lo que si estas funciones
no estan restringidas solo a los usuarios autorizados, y no se implementan controles para
evitar la inyeccion de sentencias adicionales a un SMBD desde la capa aplicativa, estas
pueden ser aprovechadas por un atacante para ejecutar procesos en el SMBD de manera
no autorizada y en algunos casos comprometer otros sistemas.
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION64
sentencia_sql1; EXEC sp_addlogin ’user ’, ’pass ’; #
4.0.6. Inyeccion de operadores de correccion de sintaxis
Muchas veces en el proceso de inyeccion se producen errores de sintaxis antes de lograr la
ejecucion exitosa de una sentencia SQL, esto se debe a que en un enfoque de caja negra
se desconoce la estructura de la base de datos que se esta atacando, para estos casos el
uso de los operadores de correccion de sintaxis nos ayudaran estructurar correctamente
una sentencia SQL, con la finalidad de lograr una inyeccion exitosa desde la aplicacion
de manera no autorizada.
Definicion: Anade alguno de los siguientes operadores al final de la sentencia inyectada.
parentesis: )
comentarios: --
comentarios: #
apostrofe: ’
comillas: ‘‘
Condicion: Antes de utilizar operadores de correccion de sintaxis se requiere que un
operador de modificacion de comportamiento haya sido inyectado previamente.
Los operadores de modificacion de comportamiento pueden causar que la aplicacion
envıe una sentencia SQL al SMBD con errores de sintaxis, si la aplicacion no maneja
correctamente este tipo de eventos, puede exponer informacion sensible como errores de
sintaxis SQL, informacion tecnica de la infraestructura que soporta el SMBD, version
del Sistema Operativo donde esta instalado el SMBD, o la version del servidor Web
donde reside la aplicacion, esta informacion es muy util para un atacante, ya que dicha
informacion permite perfilar el sistema que se esta atacando con la finalidad de ejecutar
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION65
un ataque mas elaborado sobre la aplicacion.
Figura 4.14: Errores de sintaxis en la inyeccion de operadores de modificacion decomportamiento
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION66
Por ejemplo, en un modulo de busqueda basico que recibe datos de tipo cadena, se
debe incluir el uso del operador apostrofe para delimitar adecuadamente los datos que
se estan enviado al SMBD desde la aplicacion y corregir posibles errores de sintaxis.
Figura 4.15: Ejemplo de inyeccion del operador apostrofe para corregir errores desintaxis
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION67
La inyeccion de comentarios es muy util para un atacante, ya que de esta manera puede
truncar las sentencias SQL enviadas desde la aplicacion a la base de datos. En el caso
de sentencias que tienen la clausula WHERE, con esta tecnica de inyeccion se pueden
eliminar condiciones o validaciones sobre los datos de entrada
Supongamos que tenemos una aplicacion que se basa en una autenticacion local para
permitir el acceso a la misma de la forma:
SELECT *
FROM users
WHERE usuario=’juan ’ AND clave=’patito01 ’
Con esta tecnica de inyeccion un atacante puede comentar la validacion sobre el parametro
clave para evitar errores de sintaxis que se originen en la ejecucion del Query y lograr
acceso no autorizado a la aplicacion invalidando la validacion sobre el parametro clave.
SELECT *
FROM users
WHERE usuario=’juan ’ -- AND clave=’patito01 ’
Figura 4.16: Ataque de SQL Injection con la tecnica de inyeccion de comentarios
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION68
4.0.7. Inyeccion de operadores de ofuscacion
En una aplicacion donde existen controles de seguridad como funciones de sanitizacion
en los datos de entrada, firewall de aplicaciones o IDS/IPS, los datos de entrada
son validados antes de ser procesados por la aplicacion, por lo que se deben utilizar
operadores de ofuscacion para evadir dichos controles de seguridad.
Comunmente los datos de entrada que son filtrados por estos controles son:
◦ Palabras reservadas SQL como SELECT, INSERT, FROM, etc.
◦ Caracteres especiales como ’, ;, #, etc.
◦ Espacios en blanco
Las tecnicas de ofuscacion nos permiten ingresar datos codificados para que los controles
de seguridad que validan los datos de entrada en la aplicacion no detecten el ingreso de
caracteres anomalos.
La inyeccion de cada uno de estos operadores muchas veces depende de la version de
SMBD utilizado, por lo que es importante haber realizado un reconocimiento pasivo
previo para poder aplicar la codificacion correcta para evadir los controles de seguridad
existentes y enviar sentencias de inyeccion mas especificas de acuerdo al SMBD utilizado.
Tambien cada SMBD tiene funcionalidades propias que pueden ser aprovechadas para
evadir controles de filtrado sobre los datos de entrada. Por ejemplo en el caso de Oracle,
que cuenta con la funcion CHAR para representar caracteres en base a su codigo ASCII
se puede inyectar una sentencia SELECT de la siguiente manera:
CHAR (83)+CHAR (69)+CHAR (76)+CHAR (69)+CHAR (67)+CHAR (84)
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION69
Codificacion de espacios en blanco
Esta tecnica de inyeccion se refiere a reemplazar los espacios en blanco con algunos de
los siguientes caracteres:
SqlCommand +
SqlCommand /**/
HTML Entity (decimal)  
HTML Entity (hex)  
UTF -8 (hex) 0x20 (20)
UTF -8 (binary) 00100000
UTF -16 (hex) 0x0020 (0020)
UTF -16 (decimal) 32
UTF -32 (hex) 0x00000020 (0020)
UTF -32 (decimal) 32
C/C++/ Java source code "\u0020"
Python source code u"\ u0020"
En un ejemplo donde se inyecta un operador OR seguido de una comparacion que
resulta verdadera se obtiene la siguiente forma:
Inyeccion original:
1 OR 1=1
Inyeccion con operadores de ofuscacion:
1+OR+1=1
Se obtiene un inyeccion de la siguiente forma:
SELECT *
FROM table
WHERE id=1+OR+1=1
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION70
Codificacion de datos entre apostrofes o comillas
Los caracteres de apostrofes y comillas son generalmente filtrados o escapados por
controles de seguridad que validan los datos de entrada.
Para evadir dichos controles de seguridad se pueden codificar dichos caracteres representandolos
de forma binaria, hexagecimal o con caracteres UNICODE.
Ejemplo de representacion binaria:
El caracter ’a’ se reemplaza por ’1100001’
Ejemplo de representacion hexadecimal:
El caracter a se reemplaza por x61
En un ejemplo donde se inyecta un operador OR seguido de una comparacion que
resulta verdadera se obtiene la siguiente forma:
Inyeccion original:
1 OR ’a’=’a’
Inyeccion con operadores de ofuscacion:
1 OR ’a’= x61ax61
Se obtiene un inyeccion de la siguiente forma:
SELECT *
FROM table
WHERE id=1 OR ’a’= x61ax61
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION71
Codificacion de caracteres con entidades HTML
La codificacion de caracteres con HTML se puede hacer de dos formas, por medio de
referencia numerica de caracteres o referencia a entidades de caracteres.
Las referencias numericas de caracteres especifican la posicion del codigo de un caracter
en el conjunto de caracteres del documento.
Las referencias numericas de caracteres pueden tener dos formas:
"&\#D;"
Donde D es un numero decimal, se refiere al caracter de ISO 10646 con el numero
decimal D.
"&\#xH;"
"&\#XH;"
Donde H es un numero hexadecimal, se refiere al caracter de ISO 10646 con el numero
hexadecimal H. Para los numeros hexadecimales de referencias de caracteres numericas
no se distingue entre mayusculas y minusculas.
Para tener una manera mas intuitiva de referirse a caracteres del conjunto de caracteres
del documento, HTML ofrece un conjunto de referencias a entidades de caracteres. Las
referencias a entidades de caracteres utilizan nombres simbolicos para no tener que
recordar posiciones de codigo.
Ejemplo de representacion del signo ”menor que“:
"<"
Ejemplo de representacion del signo ”mayor que“:
">"
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION72
Ejemplo de representacion del signo & :
"&"
Ejemplo de representacion del signo ’:
"""
En un ejemplo donde se inyecta un operador OR seguido de una comparacion que
resulta verdadera se obtiene la siguiente forma:
Inyeccion original:
1 OR ’a’=’a’
Inyeccion con operadores de ofuscacion:
1 OR "a"= "a"
Se obtiene un inyeccion de la siguiente forma:
SELECT *
FROM table
WHERE id=1 OR "a"= "a"
Codificacion con notacion hexagecimal
La inyeccion de caracteres se puede hacer codificando dichos caracteres con notacion
hexadecimal.
Representacion con notacion hexagecimal:
%HH
Donde HH es el valor hexadecimal del caracter inyectado.
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION73
En un ejemplo donde se inyecta un operador OR seguido de una validacion verdadera
se obtiene la siguiente forma:
1 OR a=a
Inyeccion con operadores de ofuscacion:
1 OR %20a=a
Se obtiene un inyeccion de la siguiente forma:
SELECT *
FROM table
WHERE id=1OR %20a=a
Codificacion utilizando expresiones booleanas
La inyeccion de expresiones booleanas permite alterar el resultado de las validaciones
realizadas con la clausula WHERE. Inyectando diferentes tipos de expresiones booleanas
se pueden evadir los controles de seguridad, ya que es comun que los controles de
seguridad que hacen validacion sobre los datos de entrada filtren o escapen la inyeccion
de condiciones comunes por medio de listas blancas o negras.
En un ejemplo donde se inyecta un operador OR seguido de una comparacion que
resulta verdadera se obtiene la siguiente forma:
Inyeccion original:
1 OR 1=1
Inyeccion con operadores de ofuscacion:
1 OR not false =!!1
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION74
Se obtiene un inyeccion de la siguiente forma:
SELECT * FROM table WHERE id=1 OR not false =!!1
Codificacion con caracteres aleatorios
La finalidad de este tipo de codificacion es utilizar expresiones equivalentes que son
interpretas por la aplicacion, por ejemplo se pueden escoger caracteres aleatorios inyectando
”SelEcT“ en lugar de ”SELECT“.
Para los SMBD que no son sensitivos, esto representarıa la misma expresion. Tambien
para un controles que validan los datos de entrada en base a listas negras o blancas,
este tipo de expresion puede ser considerado como valido.
Para inyectar caracteres aleatorios se puede:
◦ Utilizar mayusculas/minusculas
◦ Incluir comentarios
◦ Codificar con alguna representacion como binario, hexadecimal, UNICODE,
etc.
En un ejemplo donde se inyecta un operador OR seguido de una comparacion que
resulta verdadera se obtiene la siguiente forma:
Inyeccion original:
1 OR ’a’=’a’
Inyeccion con operadores de ofuscacion:
1 || "a"= "a"
Se obtiene un inyeccion de la siguiente forma:
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION75
SeLeCT *
froM table
WheRE id=1 || "a"= "a"
4.0.8. Perfilamiento del SMBD y estructura de la Base de
Datos
Conocer el tipo de producto o version de SMBD utilizado es importante, ya que cada
SMBD tiene funcionalidades propias que pueden ser utilizadas por un atacante para
comprometer otros recursos del SMBD o sistemas. Por ejemplo, MSQL Server cuenta
con la funcion ”EXEC xp cmdshell“ que permite ejecutar comandos en el sistema
operativo donde reside el SMBD, en este escenario si un atacante gana acceso al
sistema operativo obtiene mas visibilidad del sistema atacado o puede ”pivotear“ a
otros sistemas. Perfilar el SMBD utilizado tambien ayuda a inyectar sentencias mas
especificas y aprovechar las caracterısticas propias del SMBD de manera no autorizada.
Un SMBD es un software que permite crear y administrar bases de datos, de esta
manera se facilitan los procesos de definir, construir, manipular y compartir bases de
datos entre distintos usuarios y aplicaciones[8].
La definicion de una base de datos consiste basicamente en la especificacion de los tipos
de datos, estructuras y restricciones sobre los datos que residen en una base de datos.
Estas especificaciones se almacenan en un catalogo o diccionario de datos en el SMBD,
este catalogo o diccionario tambien es llamado meta-datos.
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION76
Figura 4.17: Ambiente simple de base de datos[7]
Cada SMBD tiene una estructura propia en su esquema o diccionario de datos, estos
tambien proporcionan informacion valiosa para ejecutar un ataque mas efectivo, inyectando
queries hacia estos diccionarios o utilizando funciones especificas para obtener nombres
de otras bases de datos, nombres de tablas, usuarios utilizados por la aplicacion para
conectar a la base de datos, entre otros datos.
En este ejemplo se explota un SMBD MySQL inyectando las funciones ”user()“ y
”database()“ las cuales informan sobre el nombre de la base de datos y el usuario
que utiliza la aplicacion para interactuar con el SMBD.
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION77
Figura 4.18: Ataque de SQL Injection para extraer metadatos del esquema
4.0.9. Ataque
Las aplicaciones Web son un vector comun de ataque hacia los SMBD, ya que estas
exponen diferentes puntos de entrada hacia los recursos de un SMBD, principalmente
las bases de datos para ejecutar diferentes operaciones como la consulta de informacion,
o modificacion de registros de una base de datos.
Ademas de los datos que se resguardan en estos sistemas, los SMBD ofrecen diferentes
funcionalidades para interactuar con el sistema operativo donde este reside u otros
sistemas a los que se conecta. Por lo que una vez que se han encontrado vulnerabilidades
de inyeccion, uno de los objetivos principales para un atacante ademas de la extraccion
de informacion de manera no autorizada, es comprometer otros sistemas.
4.0.10. Extraccion de informacion
Ademas de la importancia que tienen los datos para las personas y organizaciones,
actualmente tambien existen legislaciones y regulaciones en diferentes paıses exigen la
proteccion adecuada de los datos, es por ello que es importante identificar las vulnerabilidades
de SQL Injection que pueden propiciar la extraccion de informacion, con la finalidad
de implementar controles de seguridad adecuados.
Una vez que el atacante a identificado puntos vulnerables a inyeccion y conoce el sistema
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION78
que esta atacando por medio del perfilamiento del sistema, le resta elegir que tipo de
informacion que quiere obtener, el acceso a dicha informacion tambien depende de los
privilegios que tiene el usuario que conecta desde la aplicacion a la base de datos, sin
embargo es comun encontrar usuarios privilegiados para realizar estas conexiones en
ambientes de produccion.
Una tecnica que se puede utilizar para extraer informacion es el uso de la sentencia
UNION la cual permite unir el resultado de la ejecucion de dos Queries.
SELECT col1 ,col2 ,col3
FROM table1
UNION SELECT col4 ,col5 ,col6
FROM table2
Las restricciones sobre el uso de UNION es que los Queries deben tener el mismo numero
de columnas y las columnas deben de ser del mismo tipo.
En el caso de inyeccion de Queries con la sentencia UNION, un atacante tratara de
descubrir el numero de columnas utilizadas en el Query enviado desde la capa aplicativa
a la capa de datos. Para ello comunmente se envıan caracteres mal formados a la
aplicacion, o caracteres que no son del tipo y tamano esperado por la base de datos
esperando que esta responda de manera inesperada y arroje errores con informacion
tecnica a la capa aplicativa, estos errores pueden incluir informacion de la base de datos
que pueden permitir descubrir la estructura del Query con la finalidad de inyectar una
sentencia UNION de manera exitosa y acceder a los datos de manera no autorizada. Otra
tecnica muy comun es inyectar la clausula ”ORDER BY“ esperando que la aplicacion
responda con un error de sintaxis cuando se trata de ordenar la consulta con una
columna que no existe.
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION79
Figura 4.19: Identificacion de numero de columnas con ORDER BY
Para ejemplificar esta tecnica de inyeccion, vamos a considerar una tabla que contiene
registros de los empleados de una empresa con las columnas: nivel, departamento y
salario de los empleados. Es una tabla simple donde no se consideran relaciones con
otras tablas, debido a que la finalidad es ejemplificar la tecnica de inyeccion UNION
Queries.
Figura 4.20: Tabla empleados
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION80
Supongamos que tenemos una aplicacion Web que interactua con esta tabla y permite
acceso a dos tipos de usuarios, un tipo de usuario A que debe tener acceso solo a los
registros de los empleados que corresponden al departamento de operaciones y nivel
1a, y Un usuario B que solo debe tener acceso a la informacion del departamento de
direccion y nivel 2b.
Para restringir el acceso a registros de la Base de Datos en base a la polıtica definida,
se crean dos vistas, una para cada usuario de la siguiente manera.
Figura 4.21: Definicion de vista para el usuario A
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION81
Figura 4.22: Definicion de vista para el usuario B
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION82
Aunque utilizando este tipo de vistas tradicionales se puede restringir el acceso solo
a ciertos registros de una tabla, sigue existiendo el problema de que la ejecucion del
Query sobre la vista se realiza desde la capa aplicativa utilizando un usuario generico
que tiene acceso a todos los registros de la tabla base y otros recursos de SMBD, por lo
que en caso de un ataque de inyeccion con la tecnica UNION Query, se pueden acceder
a otros registros que no estan definidos en la vista de forma no autorizada.
Una vista (view) se puede definir como una tabla virtual que es definida a partir de otras
tablas, estas otras tablas se llaman tablas base o tambien pueden ser vistas definidas
previamente. Una vista no necesariamente existe fısicamente en la base de datos, si no
que esta es considerada una tabla virtual, a diferencia de las tablas base que siempre
existen fısicamente en la base de datos. Por consecuencia esto limita las operaciones
que se pueden ejecutar sobre una vista, pero esto no aplica a limitaciones en el uso de
consultas sobre las vistas, esto nos permite restringir los registros y columnas a las que
puede acceder un usuario.
En este escenario un atacante podrıa inyectar la siguiente sentencia para obtener acceso
a otros registros de manera no autorizada.
’ UNION SELECT *
FROM dep_direccion;
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION83
Figura 4.23: Ataque de SQL Injection con la tecnica UNION Query
4.0.11. Ganar acceso al SMBD, comprometer el sistema operativo
y otros sistemas
Los SMBD actualmente ofrecen diferentes funcionalidades que permiten ejecutar tareas
de administracion sobre el SMBD, como la asignacion de permisos o creacion de usuarios,
si estas funciones no son protegidas para que solo los usuarios autorizados puedan
utilizarlas o se utilizan usuarios privilegiados en la aplicacion para realizar consultas,
un atacante puede por medio de estas funciones ganar acceso a otros recursos del SMBD
u otros sistemas.
Una vez que se han detectado vulnerabilidades de inyeccion, la explotacion de estas
funciones de manera no autorizada dependen practicamente de los permisos que puede
tener el usuario utilizado para conectar desde la aplicacion.
Cada SMBD tiene funcionalidades propias, muchas de estas funcionalidades pueden
representar un riesgo a los recursos del SMBD en caso de que dichas funciones no sean
configuradas adecuadamente.
A continuacion se muestran algunas de las funciones que pueden permitir escalar
privilegios en el SMBD o vulnerar otros sistemas.
CAPITULO 4. METODOLOGIA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQUES DE SQL INJECTION84
LOAD DATA INFILE - MySQL
La funcion LOAD DATA de MySQL permite cargar archivos que se encuentran en el
servidor o pueden ser cargados desde el cliente que se esta conectando al servidor. De
esta manera un atacante puede tener acceso a los archivos del servidor donde reside el
SMBD.
Es comun que cuando un atacante vulnera un sistema inserte una puerta trasera (”back
door“) que le permita volver acceder el sistema, por lo que con esta funcionalidad un
atacante puede insertar codigo malicioso a la aplicacion para acceder a la misma de
manera no autorizada.
En este ejemplo un atacante puede tener acceso de lectura a archivos que residen en el
sistema operativo, y acceder a informacion sensible inyectando un UNION Query, con
la posibilidad de escalar privilegio o acceder a otros recursos del sistema de manera no
autorizada.
ID: ’ UNION SELECT 1,
load_file(’C:/Users/Administrator/Documents/notas.txt ’) #
Figura 4.24: Uso de la funcion LOAD DATA en MySQL para escalar privilegios
Capıtulo 5
Enfoque defensivo de seguridad
Se deben considerar controles de seguridad en cada una de las capas del sistema
(aplicacion, sistema operativo, red, servidor web/aplicaciones, etc.) tomando en cuenta
el concepto de seguridad en profundidad, con la finalidad de asegurar que existen
controles de seguridad adecuados que ayuden a minimizar los riesgos de explotacion
de vulnerabilidades.
Principalmente la capa aplicativa es un vector comun de ataque hacia los recursos de
un SMBD, ya que esta capa esta expuesta a diferentes usuarios que ejecutan procesos
sobre los recursos del SMBD desde servicios o aplicaciones Web.
Por otro lado, cada producto y version de SMBD tienen funcionalidades propias de
seguridad que pueden ser utilizadas para implementar controles de seguridad, sin embargo,
se deben considerar controles de seguridad en cada capa del sistema para asegurar una
proteccion adecuada del sistema, principalmente del SMBD.
En este capıtulo se analiza principalmente el uso de vistas parametrizadas y parametros
de sesion para restringir el acceso a los datos desde la capa aplicativa, y se definen
de manera general controles mınimos seguridad que se deben considerar en la capa
aplicativa, sistema operativo y red, para disminuir los riegos de explotacion que pueden
afectar alguno de los recursos de un SMBD.
85
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 86
5.1. Uso de vistas parametrizadas y parametros de
sesion para definir controles de accesos en la
base de datos
Comunmente los usuarios finales no conectan directamente a los recursos del SMBD, si
no que lo hacen a traves de la capa de aplicacion la cual incluye basicamente aplicaciones
y servicios Web. Desde la capa de presentacion los usuarios finales pueden generar
consultas y modificaciones a registros de una base de datos o ejecutar procesos sobre
otros recursos del SMBD.
En la capa de aplicacion o capa aplicativa se definen los servicios y aplicaciones Web
que interactuan con los recursos de un SMBD, para ello esta capa generalmente utiliza
un usuario generico con los permisos necesarios sobre los recursos del SMBD (Bases
de Datos, tablas, vistas, procedimientos almacenados, funciones, etc.) para ejecutar las
solicitudes provenientes de los usuarios finales desde la capa de presentacion, dichas
solicitudes se reciben a traves de metodos HTTP (GET, POST, DELETE, PUT). En
esta capa reside el codigo que se encarga de ejecutar decisiones logicas y evaluaciones
para enviar Queries y ejecutar procesos en el SMBD, y regresar una respuesta al usuario
final por medio del front-end o interfaz con la que el usuario final interactua.
De esta manera la identidad del usuario final que esta accesando la aplicacion no esta
definida o no es reconocida por la base de datos, por lo que no es posible asignar
permisos especıficos a cada usuario que accede desde la aplicacion Web a la base de
datos, ya que todas las acciones que se realizan en la base de datos se hacen a traves
del usuario generico utilizado por la aplicacion Web.
Las implicaciones de este escenario es que no es posible definir controles de acceso a los
usuarios finales que estan accesando la base de datos. El SMBD no puede diferenciar
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 87
el usuario final que esta accesando a la base de datos y de esta manera el principio
de mınimos privilegios (least privilege) es violado, esta situacion puede resultar en una
escalacion de privilegios horizontal y vertical si se ejecuta con exito un ataque de SQL
Injection.
Figura 5.1: Usuario generico ejecutando acciones en la base de datos
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 88
El uso de vistas parametrizadas y parametros de sesion definen una identidad al usuario
final que accede desde una aplicacion Web a la base de datos, y de esta manera permite
definir controles de acceso granulares que restringen el acceso a los datos en base a la
identidad asignada.
Con este metodo, dicha identidad es generada dinamicamente al usuario que accede
desde una aplicacion Web a la base de datos. Una de las condiciones basicas al utilizar
este metodo es que los parametros de sesion utilizados en la capa aplicativa para asignar
una identidad a los usuarios, no sean alterados o manipulados, este parametro tambien
debe ser generado de forma aleatoria e impredecible.
El uso de vistas tradicionales no es apropiado para manejar un control de accesos a
bases de datos expuestas a traves de aplicaciones Web. Una vista (view) se puede definir
como una tabla virtual que es definida a partir de otras tablas, estas otras tablas se
llaman tablas base, o tambien pueden ser vistas definidas previamente. Una vista no
necesariamente existe fısicamente en la base de datos, si no que esta es considerada una
tabla virtual, a diferencia de las tablas base que siempre existen fısicamente en la base
de datos. Por consecuencia esto limita las operaciones que se pueden ejecutar sobre una
vista, pero esto no aplica a limitaciones en el uso de consultas sobre las vistas, esto nos
permite restringir los registros y columnas a las que puede acceder un usuario.
Para ejemplificar el concepto de vistas, vamos a considerar una tabla que contiene
registros de los empleados de una empresa con las columnas: nivel, departamento y
salario de los empleados.
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 89
Figura 5.2: Tabla empleados
Supongamos que tenemos una aplicacion Web que interactua con esta tabla y permite
acceso a dos tipos de usuarios, un tipo de usuario A que debe tener acceso solo a los
registros de los empleados que corresponden al departamento de operaciones y nivel
1a, y Un usuario B que solo debe tener acceso a la informacion del departamento de
direccion y nivel 2b, para restringir el acceso a registros en base a esta polıticas se
definen dos vistas, una para cada usuario de la siguiente manera.
Figura 5.3: Definicion de vista para el usuario A
Figura 5.4: Definicion de vista para el usuario A
Figura 5.5: Definicion de vista para el usuario B
Aunque utilizando este tipo de vistas tradicionales se puede restringir el acceso solo
a ciertos registros de una tabla, sigue existiendo el problema de que la ejecucion de
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 90
Figura 5.6: Definicion de vista para el usuario B
dicha vista se realiza por medio de un usuario generico utilizado desde la aplicacion
que tiene acceso a todos los registros de la tabla base, por lo que en caso de un ataque
de inyeccion se pueden acceder a otros registros que no estan definidos en la vista de
forma no autorizada.
Un atacante podrıa inyectar la siguiente sentencia para obtener acceso a otros registros
de manera no autorizada.
UNION SELECT * FROM dep_direccion
Figura 5.7: Ataque de inyeccion
Con este ejemplo podemos ver que el uso de vistas tradicionales no es adecuado para
definir un control de accesos adecuado sobre los registros de una base de datos, por
lo que se requiere el uso de vistas parametrizadas y parametros de sesion para poder
restringir el acceso a los datos por medio de una asignacion de identidad dinamica a los
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 91
usuarios finales.
El metodo de vistas parametrizadas y parametros de sesion se puede implementar
de dos manera, la primer tecnica es basada en un parametro de sesion generado por
una aplicacion Web al momento de que el usuario final se autentica exitosamente en
dicha aplicacion Web, y la segunda tecnica es aplicada a aplicaciones que no requieren
autenticacion para ser accesadas.
Para diferenciar estas dos tecnicas, vamos a considerar dos tipos de aplicaciones Web, la
primera tiene que ver con aplicaciones Web que requieren autenticacion, la mayorıa de
los procesos de autenticacion requieren de un usuario y password para poder acceder la
aplicacion, en este escenario el parametro de identificacion utilizado sera el mismo que
utiliza la aplicacion, en este caso es la cuenta de usuario con la que se esta accesando,
la segunda tiene que ver con aplicaciones que no requieren autenticacion a los usuarios,
en este escenario se requiere definir un parametro aleatorio de sesion en la aplicacion
Web para poder definir los accesos en la base de datos.
En el primer caso donde se tiene una aplicacion que requiere autenticacion se define un
parametro de sesion generada por la aplicacion para manejar la identidad del usuario
al momento que una autenticacion es exitosa, este parametro de sesion es generado de
manera aleatoria dinamicamente por por la aplicacion, de esta manera se reduce el riesgo
de poder modificar dicho parametro, reduciendo ası tambien el riesgo de explotacion de
SQL Injection, ya que el atacante requiere obtener el parametro generado para inyectar
sentencias de SQL de manera no autorizada.
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 92
5.1.1. Implementacion de vistas parametrizadas con parametros
de sesion basado en autenticacion
Este metodo consiste en generar una variable de sesion de manera dinamica y no
predecible a nivel de la aplicacion en el proceso de autenticacion, esta variable de
sesion es posteriormente enviada en cada ejecucion de sentencias SQL hacia la base
de datos, de esta manera se puede identificar al usuario que esta tratando de acceder
a la aplicacion con el fin de restringir el acceso a los datos. Para aplicar este metodo
se asume que la base da datos tambien tiene una tabla llamada usuarios activos que
contiene registros temporales con los parametros de sesion generados por la aplicacion.
Este metodo funciona de la siguiente manera:
◦ Un usuario se autentica en la aplicacion Web que interactua con la base
de datos que se quiere acceder. Tıpicamente las aplicaciones maneja
usuario y password como metodo de autenticacion.
◦ La aplicacion verifica la identidad del usuario y envıa una variable aleatoria
a la base de datos que sera utilizada para manejar las sesiones con la
base de datos.
◦ La base de datos resguarda la variable aleatoria temporalmente, mientras
dura la sesion del usuario en la aplicacion, este parametro de sesion es
enviado por la aplicacion siempre que se ejecuta una sentencia SQL sobre
la base de datos.
◦ Para cada sentencia ejecutada desde la aplicacion a la base de datos,
se envıa tambien el parametro de sesion generado por la aplicacion a la
base de datos.
◦ Todas las variables de sesion generadas se eliminan de la base de datos
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 93
cuando el usuario termina o se desconecta de la aplicacion.
Figura 5.8: Vistas parametrizadas con parametros de sesion
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 94
Para ejemplificar este metodo vamos a definir la tabla de “usuarios activos” la cual
contiene los registros de los parametros de sesion generados por la aplicacion cuando
un usuario se autentica correctamente, la aplicacion consulta la tabla “autenticacion” la
cual contiene los usuarios y passwords validos para verificar la identidad de los usuarios
que acceden.
Figura 5.9: Vistas parametrizadas con parametros de sesion
De esta manera se verifica la identidad de los usuarios finales que ejecutan procesos
sobre el SMBD, reduciendo ası el riesgo de explotacion de ataques de de SQL Injection,
ya que la vista ejecutada solo devuelve la informacion que corresponde al usuario que
esta ejecutando la sentencia, ademas de que el usuario final debe enviar el parametro
de sesion asignado por la aplicacion para poder ejecutar algun proceso o consulta en
una base de datos.
Tambien aunque un ataque de SQL Injection se ejecute exitosamente contra la aplicacion,
este tendra un impacto menor ya que los registros que puede comprometer el atacante
corresponderan a aquellos que estan asignados a su identidad por medio de los parametros
de sesion generados por la aplicacion.
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 95
Figura 5.10: Definicion DDL de una vista parametrizada
5.2. Controles mınimos de seguridad
5.2.1. Controles de seguridad en el SMBD
◦ Se debe instalar la ultima version estable del Sistema Manejador de Base
de Datos (SMBD) que no afecte la operacion del sistema
◦ El SMBD utilizado debe tener instalados los ultimos parches de seguridad
estables que no afecten la operacion del sistema.
◦ Se deben remover o deshabilitar todos los recursos, componentes, herramientas
y servicios que no son requeridos para la operacion del sistema.
◦ Las base de datos se debe montar en una particion o equipo diferente al
de la aplicacion y sistema operativo.
◦ Se deben asignar solo los recursos requeridos (espacio, memoria, etc.) a
cada usuario para realizar sus funciones. Las cuentas de usuario deben
tener asignada una cuota para trabajo y no ocupar espacio dedicado al
funcionamiento interno de la base de datos.
◦ Se debe restringir el acceso y establecer controles de seguridad sobre
archivos y directorios crıticos del SMBD (ejemplo: archivos que contengan
detalles de configuracion, passwords, diccionario de datos, metadatos),
tablas y recursos de la base de datos, ejecucion de comandos, funciones,
procedures, ejecucion de tareas sensitivas de administracion, ejecucion
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 96
de tareas programadas y procesos, solo a los hosts y usuarios autorizados.
◦ Todas las consultas a los datos se deben hacer en lo posible por medio
de vistas, store procedures o queries parametrizados, evitando el uso de
queries dinamicos, e implementar mecanismos para validar que todos los
datos de entrada sean del tipo y tamano esperado.
◦ El usuario utilizado para levantar la Base de datos no debe tener privilegios
de administracion.
◦ Se debe limitar el numero de conexiones por usuario y sesiones concurrentes.
◦ Los password se deben almacenarse de forma cifrada.
5.2.2. Controles de seguridad en la capa aplicativa
◦ No se deben utilizar cuentas privilegiadas de sistema operativo para
ejecutar procesos o tareas en la aplicacion.
◦ No se deben utilizar cuentas privilegiadas de base de datos para conectar
a bases de datos desde la aplicacion o ejecutar procesos en las mismas,
en su lugar se deben definir cuentas especıficas para la conexion a las
bases de datos con los privilegios mınimos necesarios para realizar sus
funciones.
◦ Deben existir mecanismos robustos de autenticacion y autorizacion que
permitan el acceso y uso de recursos del sistema funciones (ejemplo:
URLs, vistas, archivos, modulos de la aplicacion, menus, opciones en la
aplicacion, etc.) solo a usuarios y hosts autorizados.
◦ Los parametros o variables utilizadas para autenticar o autorizar el uso
de recursos a los usuarios o hosts validos, se deben proteger de tal manera
que estos no puedan ser modificados o alterados.
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 97
◦ No se debe exponer en texto claro passwords de acceso en el proceso de
autenticacion y autorizacion.
◦ Se deben utilizar mensajes genericos que no informen sobre la existencia
de usuarios validos cuando se proporcionan usuarios o passwords incorrectos
o inexistentes en el proceso de autenticacion.
◦ La desconexion de la aplicacion o servicio debe limpiar todos los estados
de sesion y remover o invalidar cualquier cookie residual.
◦ No se deben utilizar cookies persistentes para guardar datos sensibles.
◦ Las cookies deben ser creadas con HttpOnly y Secure.
◦ Se debe configurar la expiracion de sesiones por inactividad despues de
30 minutos.
◦ La funcion de logout o cierre de sesion debe finalizar correctamente la
sesion no permitiendo ingresar nuevamente a la aplicacion despues de
ejecutada dicha funcion.
◦ Se deben eliminar o destruir los IDs o parametros de sesion en la funcion
de logout o cierre de sesion, para que estos no puedan ser reutilizados.
◦ Se deben validar que todos los datos de entrada sean del tamano y
tipo esperado, restringiendo el envıo de cadenas de datos muy largas,
caracteres especiales, comandos de sistema operativo, codigo HTML/jsp,/php
u otro, sentencias SQL o cualquier caracter o cadena que pueda ser
interpretada como comando por la aplicacion, base de datos, sistema
operativo, servidores web o servidores de aplicaciones.
◦ En los modulos que permiten a los usuarios cargar archivos, se debe
restringir el tipo de archivo permitido, evitando subir archivos con extension
.html, .jsp, .js, .exe u otra extension que pueda ser interpretada o ejecutada
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 98
por el servidor web, servidor de aplicaciones, sistema operativo, aplicacion
y base de datos.
◦ En los modulos que permiten a los usuarios la carga de archivos, se debe
restringir el tamano de los archivos que los usuarios pueden cargar.
◦ Se debe configurar la aplicacion para que envie errores genericos ante un
evento inesperado, evitando mostrar parametros e informacion tecnica
del sistema como versiones de servidores web y de aplicaciones, versiones
de sistema operativo, nombres de variables, sintaxis SQL, nombre de
tablas de la BD a la que se conecta, stack traces, u otro tipo de informacion
tecnica o de configuracion.
◦ Se debe inhibir la visualizacion del codigo de programacion de la aplicacion
deshabilitando el boton derecho del mouse para diferentes navegadores
y proteger archivos con codigo fuente o codigo de programacion que
contenga datos sensibles (configuraciones de conexion a bases de datos,
usuarios y passwords de acceso, etc).
◦ No se debe enviar informacion sensitiva.
◦ Se debe restringir el consumo de los metodos y servicios expuestos por el
Web Service o API solo a los usuarios y host autorizados, implementando
al menos mecanismos de autenticacion como usuario/password y restriccion
por IP, para asegurar que solo los host y usuarios autorizados pueden
consumir los metodos expuestos.
◦ Se debe cifrar la informacion sensible utilizada o enviada a traves de
Web Services o APIs.
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 99
5.2.3. Controles de seguridad en el servidor de aplicaciones o
servidor Web
◦ Se debe instalar la ultima version estable que no afecte la operacion del
sistema.
◦ Se deben instalar los ultimos parches de seguridad disponibles que no
afecten la operacion del sistema.
◦ El servidor web o servidor de aplicaciones se debe instalar en una particion
diferente a la del sistema operativo y base de datos.
◦ o se deben instalar ambientes de pruebas con ambientes de produccion
en una misma instancia del servidor de aplicaciones o servidor web.
◦ Se deben deshabilitar o remover todos los archivos, directorios, modulos,
scripts, documentacion, ejemplos, aplicaciones, servicios y funcionalidades
por default y que no son requeridos por la operacion del sistema.
◦ Se debe restringir el listado transversal de directorio o deshabilitar la
opcion para listar los directorios del servidor web o servidor de aplicaciones
desde el cliente web o navegadores web.
◦ Se deben habilitar solo los metodos HTTP (ejemplo: GET, POST, etc.)
necesarios para la operacion.
◦ Se debe restringir el envıo de informacion tecnica de la infraestructura
en los response headers del servidor.
◦ Se debe de modificar el nombre default de los directorios de instalacion.
◦ El usuario utilizado para levantar el servidor web o servidor de aplicaciones
debe tener los permisos mınimos necesarios para realizar sus funciones
y no tener privilegios de administracion sobre el sistema operativo.
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 100
◦ Se deben proteger los archivos y directorios que contienen informacion
sensible.
◦ Se debe restringir el acceso a los recursos para levantar, detener, cambiar
la configuracion o ejecutar procesos o scripts en el servidor solo a los
usuarios y hosts autorizados.
5.2.4. Controles de seguridad en el sistema operativo
◦ Se debe instalar la ultima version estable que no afecte la operacion del
sistema.
◦ Se deben instalar los ultimos parches de seguridad estables que no afecten
la operacion del sistema.
◦ Se deben deshabilitar o detener todos los servicios, puertos, utilerıas,
compiladores, protocolos, aplicaciones y herramientas que no son requeridos
para la operacion.
◦ No se deben habilitar protocolos o servicios con vulnerabilidades conocidas
como ftp, telnet, rlogin, o protocolos que transmiten informacion en
texto claro.
◦ El super usuario de Sistema Operativo (ejemplo: root, Administrator,
SYSTEM, etc.) debe ser usado para tareas de administracion, operacion
y mantenimiento exclusivas del Sistema Operativo sin excepcion.
◦ El sistema operativo debe permitir establecer un tiempo de inactividad
para todos los usuarios de operacion y administracion.
◦ El sistema operativo debe contener solo las configuraciones mınimas de
red para su correcta operacion, todas aquellas opciones que impliquen
un riesgo para la plataforma deben ser deshabilitadas.
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 101
◦ El sistema operativo debe contener la configuracion necesaria para la
proteccion del stack de memoria de acuerdo a la version que se trate.
5.2.5. Polıticas de Password
Se deben implementar las siguientes polıticas de password en el sistema:
◦ El password debe tener una longitud mınima de 8 caracteres y debe de
contener al menos un caracter alfabetico y un caracter numerico.
◦ El password debe de modificarse en el primer acceso de una cuenta de
usuario nueva o cuando se restablezca el password.
◦ El password debe expirar automaticamente al menos cada 60 dıas.
◦ El password debe tener restriccion programable de rehuso, cada vez que
se cambie el password este debe ser diferente a los 5 previos.
◦ El password debe de ser distinto a la cuenta de usuario y a palabras
comunes.
◦ Se debe de bloquear la cuenta de usuario despues de 5 intentos fallidos
de autenticacion.
◦ Se deben inhabilitar o dar de baja las cuentas de acceso que no hayan
sido utilizadas en un periodo mayor o igual de 60 dıas.
◦ Los password se deben almacenar de forma segura y cifrados.
◦ Se deben modificar los password por default de los usuarios requeridos
por el sistema.
CAPITULO 5. ENFOQUE DEFENSIVO DE SEGURIDAD 102
5.2.6. Bitacoras de monitoreo
Se deben habilitar logs o bitacoras de auditorıa que registren al menos los siguientes
eventos:
◦ Intentos fallidos y exitosos de autenticacion.
◦ Intentos fallidos y exitosos de acceso, creacion o modificacion a archivos/directorios
sensitivos o recursos del sistema (ejemplo: archivos de configuracion,
logs, archivos de passwords, objetos del kernel, etc).
◦ Intentos fallidos y exitosos de conexion a los servicios, protocolos, puertos
habilitados, APIs/Web Services o metodos.
◦ Altas, bajas y cambios de usuarios y grupos.
◦ Cambios de password.
◦ Ejecucion de comandos crıticos, para levantar o parar procesos o tareas
de administracion o configuracion, y tareas automaticas o programadas.
◦ Escalacion de privilegios.
◦ Conexiones TCP entrantes.
◦ Registro de eventos del software (Caıdas, Actualizaciones, Warnings,
emergencias, alertas, errores crıticos, advertencias, notificaciones, etc).
◦ Cambios de configuracion.
Capıtulo 6
Conclusiones
En el presente trabajo de investigacion se han analizado las vulnerabilidades mas
comunes que pueden afectar a un SMBD (enfoque ofensivo) y los controles mınimos
de seguridad que se deben considerar en la administracion de un SMBD (enfoque
defensivo), desde el enfoque ofensivo de seguridad se ha puesto especial atencion a
la vulnerabilidad de SQL Injection, ya que esta es la vulnerabilidad mas comun que se
encuentra en la capa aplicativa y que mas hace dano a los recursos del SMBD con los
que interactua.
En base a los artıculos de investigacion [3] y [10] se definio una metodologıa para
realizar ataques de SQL Injection de manera efectiva, con la finalidad de detectar este
tipo de vulnerabilidad e implementar controles de seguridad adecuados para minimizar
los riesgos de explotacion.
Dentro de los controles de seguridad analizados, en base al articulo [9] se hizo uso de
vistas parametrizadas y parametros de sesion para reducir los riesgos de explotacion
ante ataques de SQL Injection, y disminuir el impacto sobre los recursos de un SMBD
en caso de un ataque exitoso.
Tambien se han definido los controles mınimos de seguridad que se deben considerar
en la administracion de un SMBD tomando como base el concepto de seguridad en
103
CAPITULO 6. CONCLUSIONES 104
profundidad, ya que de esta manera se consideran no solo las vulnerabilidades y controles
de seguridad nativos en un SMBD, si no tambien aquellos que tienen que ver con los
ambientes con los que interactua.
El presente trabajo de investigacion servira como guıa a aquellas personas que esten
interesadas en robustecer la seguridad de los Sistemas Manejadores de Bases de Datos
que administra, ası como evaluar la efectividad de los controles implementados.
Bibliografıa
[1] Gartner now is the time for security at the application level.
http://www.sigist.org.il/\_Uploads/dbsAttachedFiles/
GartnerNowIsTheTimeForSecurity.pdf. Accessed: 2014-08-20.
[2] OWASP Foundation top 10 2013-top 10. https://www.owasp.org/
index.php/Top_10_2013-Top_10. Accessed: 2014-08-20.
[3] Dennis Appelt, Cu Duy Nguyen, Lionel C. Briand, and Nadia
Alshahwan. Automated testing for sql injection vulnerabilities: An input
mutation approach. In Proceedings of the 2014 International Symposium
on Software Testing and Analysis, ISSTA 2014, pages 259–269, New
York, NY, USA, 2014. ACM.
[4] Alvaro (2007). Enciclopedia de la Seguridad Informatica. Gomez Vieites.
Seguridad de la informacion. SIGKDD Explor. Newsl., 11(1):10–18,
2009.
[5] Shon Harris. Information security and risk management. In CISSP
Exam Guide, 2011.
[6] Richard A. Caralli. James F. Stevens. Lisa R. Young. William R.
Introducing octave allegro: Improving the information security risk.
assessment process. In Introducing OCTAVE Allegro: Improving the
Information Security Risk. Assessment Process, 2007.
105
BIBLIOGRAFIA 106
[7] Shamkant B. Navathe Ramez Elmasri. Databases and database users.
In Fundamentals of Database Systems, page 7, 2011.
[8] Shamkant B. Navathe Ramez Elmasri. Fundamentals of Database
Systems. Pearson, USA, 2011.
[9] Alex Roichman and Ehud Gudes. Fine-grained access control to web
databases. In Proceedings of the 12th ACM Symposium on Access
Control Models and Technologies, SACMAT ’07, pages 31–40, New York,
NY, USA, 2007. ACM.
[10] Julian Thome, Alessandra Gorla, and Andreas Zeller. Search-based
security testing of web applications. In Proceedings of the 7th
International Workshop on Search-Based Software Testing, SBST 2014,
pages 5–14, New York, NY, USA, 2014. ACM.