Estudio de la Seguridad en Sistemas Manejadores de Bases ...148.204.210.201/tesis/1429632192172tesisrodolfol.pdf · aplicaciones en la nube y servicios Web desde los cuales los usuarios

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

ii

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 GENERAL iii

6. Conclusiones 103

Bibliografıa 105

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.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.


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


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.


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).


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.


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.


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


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


� 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


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]


� 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.


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.


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.


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


� 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


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


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


impacto, clasificando dichos impactos como alto(3), medio(2) y bajo(1).

Figura 2.7: Metricas de impacto


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)


del activo de informacion

Figura 2.8: Identificacion de contenedores


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


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


Figura 2.11: Matriz de riesgos


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


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


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


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.


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


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


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.


◦ 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


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


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


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


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:


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.


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.


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


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


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


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


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


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


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


Figura 4.6: Estructura del metodo HTTP POST


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


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)


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


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


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


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,


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.


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


es procesada por el SMBD.

Figura 4.12: Ejemplo de inyeccion de operador AND


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.


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.


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


un ataque mas elaborado sobre la aplicacion.

Figura 4.14: Errores de sintaxis en la inyeccion de operadores de modificacion decomportamiento


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


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


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)


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


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



Inyeccion original:

1 OR ’a’=’a’


1 OR ’a’= x61ax61


SELECT *

FROM table

WHERE id=1 OR ’a’= x61ax61


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“:

">"


Ejemplo de representacion del signo & :

"&"

Ejemplo de representacion del signo ’:

"""



Inyeccion original:

1 OR ’a’=’a’


1 OR "a"= "a"


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.


En un ejemplo donde se inyecta un operador OR seguido de una validacion verdadera

se obtiene la siguiente forma:

1 OR a=a


1 OR %20a=a


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.



Inyeccion original:

1 OR 1=1


1 OR not false =!!1



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.



Inyeccion original:

1 OR ’a’=’a’


1 || "a"= "a"



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.


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.


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


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.


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


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


Figura 4.22: 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 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;


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.


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


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


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.


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.




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



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


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.


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


cuando el usuario termina o se desconecta de la aplicacion.

Figura 5.8: Vistas parametrizadas con parametros de sesion


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.


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


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.


◦ 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


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.


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.


◦ 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.


◦ 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.


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.