Estudio de la Seguridad en Sistemas Manejadores de Bases de Datos y sus Ambientes

Transcripción

1 INSTITUTO POLITÉCNICO NACIONAL Unidad Profesional Interdiciplinaria de Ingeniería y Ciencias Sociales y Administrativas Sección de Estudios de Posgrado e Investigación Estudio de la Seguridad en Sistemas Manejadores de Bases de Datos y sus Ambientes Tesis para obtener el grado de Maestro en Ciencias en Informática PRESENTA Rodolfo Adrian López Torres Director Dr. Javier García García México D.F. Primavera de 2015

2

3 ii

4 Resumen Actualmente la información es un activo muy importante, las organizaciones publicas y privadas, gobiernos y sociedad están cada vez más interesadas en proteger su información, ya que un incidente sobre la misma puede afectar negativamente su privacidad, reputación o seguridad. El uso de Internet y dispositivos móviles 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 interactúa. En este escenario los datos están cada vez más expuestos a diferentes amenazas y vectores de ataque, por lo que si no se incluyen controles de seguridad adecuados en el diseño y desarrollo de estos sistemas, se pueden exponer diferentes vulnerabilidades las cuales pueden ser explotadas por algún agente de amenaza. Principalmente la capa aplicativa es un vector común 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 ejecución de operaciones como consultas y modificación 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.

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

6 Índice general 1. Introducción Planteamiento del problema Objetivo Justificación Trabajos relacionados Estructura del trabajo Alcance y limitaciones Conceptos de seguridad de la información Conceptos de seguridad de la información Enfoque ofensivo de seguridad Vulnerabilidades en la capa aplicativa SQL Injection Mal manejo de sesiones Cross-Site Scripting - XSS Envío de datos no cifrados Metodología para identificar vulnerabilidades contra ataques de SQL Injection 47 i

7 ÍNDICE GENERAL ii Reconocimiento pasivo Identificar los módulos que interactúan con el SMBD Reconocimiento activo Identificar los puntos de entrada vulnerables a SQL Injection Inyección de operadores de modificación de comportamiento Inyección de operadores de corrección de sintaxis Inyección de operadores de ofuscación Perfilamiento del SMBD y estructura de la Base de Datos Ataque Extracción de información Ganar acceso al SMBD, comprometer el sistema operativo y otros sistemas Enfoque defensivo de seguridad Uso de vistas parametrizadas y parámetros de sesión para definir controles de accesos en la base de datos Implementación de vistas parametrizadas con parámetros de sesión basado en autenticación Controles mínimos de seguridad Controles de seguridad en el SMBD Controles de seguridad en la capa aplicativa Controles de seguridad en el servidor de aplicaciones o servidor Web Controles de seguridad en el sistema operativo Políticas de Password Bitácoras de monitoreo

8 ÍNDICE GENERAL iii 6. Conclusiones 103 Bibliografía 105

9 Índice de figuras 1.1. Enfoque defensivo y enfoque ofensivo de seguridad Arquitectura básica de 3 capas Propiedades de seguridad en un SMBD Relación de los elementos de seguridad en un SMBD [5] Controles administrativos, técnicos y físicos [5] Seguridad en profundidad Fases para la gestión de riesgos - Metodología Octave Allegro Objetivos de cada fases para la gestión de riesgos Métricas de impacto Identificación de contenedores Análisis de vulnerabilidades Calculo del riesgo Matriz de riesgos Riesgos de seguridad en aplicaciones - OWASP Causas que propician vulnerabilidades SQL Injection Escenario del ataque de SQL Injection - OWASP Escenario de vulnerabilidades en el manejo de sesiones Mal manejo de sesiones en una aplicación Web iv

10 ÍNDICE DE FIGURAS v 3.6. modificación de los parámetros de sesión Acceso no autorizado a una aplicación por vulnerabilidades en el manejo de sesiones Escenario del ataque de XSS Inyección de script malicioso XSS almacenado El navegador de la víctima interpreta el código malicioso Captura de trafico no cifrado El atacante obtiene el nombre de la cuenta con la que esta accesando el usuario El usuario crea un nuevo usuario en el SMBD El atacante obtiene el usuario y password de acceso Panorama general de una metodología de explotación SQL Injection Pasos de una metodología de explotación SQL Injection Uso de proxy para analizar el comportamiento lógico de la aplicación Ejecución de operaciones al SMBD desde la aplicación Estructura del método HTTP GET Estructura del método HTTP POST Identificación de parámetros que envían datos a través de HTTP GET y POST Ejemplo de tabla de estados para identificar los módulos que interactúan con un SMBD Escenarios general en un ataque de SQL Injection Mutación de Operadores de Inyección Ejemplo de inyección de operador OR Ejemplo de inyección de operador AND

11 ÍNDICE DE FIGURAS vi Ejemplo de mal manejo de errores Errores de sintaxis en la inyección de operadores de modificación de comportamiento Ejemplo de inyección del operador apostrofe para corregir errores de sintaxis Ataque de SQL Injection con la técnica de inyección de comentarios Ambiente simple de base de datos[7] Ataque de SQL Injection para extraer metadatos del esquema Identificación de numero de columnas con ORDER BY Tabla empleados Definición de vista para el usuario A Definición de vista para el usuario B Ataque de SQL Injection con la técnica UNION Query Uso de la función LOAD DATA en MySQL para escalar privilegios Usuario genérico ejecutando acciones en la base de datos Tabla empleados Definición de vista para el usuario A Definición de vista para el usuario A Definición de vista para el usuario B Definición de vista para el usuario B Ataque de inyección Vistas parametrizadas con parámetros de sesión Vistas parametrizadas con parámetros de sesión Definición DDL de una vista parametrizada

12 Capítulo 1 Introducción Actualmente la información es un activo muy importante, las organizaciones publicas y privadas, gobiernos y sociedad están cada vez más interesadas en proteger su información, ya que un incidente sobre la misma puede afectar negativamente su privacidad, reputación o seguridad. En este escenario los sistemas de información 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 información financiera, estos datos generalmente son utilizados por diferentes sistemas de información 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 través de los sistemas de información. En particular esta investigación se enfoca en los controles preventivos de seguridad que se deben considerar en la administración de un SMBD (Sistema Manejador de Base de Datos) y sus ambientes, así como analizar las vulnerabilidades que pueden ser explotadas por algún agente de amenaza, ya sea de manera intencional o accidental, 1

13 CAPÍTULO 1. INTRODUCCIÓN 2 afectando negativamente los recursos de un SMBD Planteamiento del problema Para analizar este tema se definen dos enfoques, un enfoque defensivo que tiene que ver con la implementación 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 lógicas que interactúan 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, ó las aplicaciones y servicios Web desde donde interactúan 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 interactúan 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 interactúa.

14 CAPÍTULO 1. INTRODUCCIÓN 3 Figura 1.1: Enfoque defensivo y enfoque ofensivo de seguridad Para analizar los dos tipos de enfoques planteados (enfoque defensivo y enfoque ofensivo) se considera una arquitectura básica de 3 capas la cual consta de la capa de presentación, capa de aplicación y capa de datos. En la capa de presentación se tiene un front-end o interfaz desde donde interactúan los usuarios finales, esta interacción generalmente se hace a través 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 través de la capa de aplicación la cual incluye básicamente aplicaciones y servicios Web. Desde la capa de presentación 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 aplicación o capa aplicativa se definen los servicios y aplicaciones Web que interactúan con los recursos de un SMBD, para ello esta capa generalmente utiliza un usuario genérico 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 presentación, dichas solicitudes se reciben a través de métodos HTTP (GET, POST, DELETE, PUT). En

15 CAPÍTULO 1. INTRODUCCIÓN 4 esta capa reside el código que se encarga de ejecutar decisiones lógicas 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 interactúa. 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 interactúan con la capa aplicativa. Figura 1.2: Arquitectura básica de 3 capas.

16 CAPÍTULO 1. INTRODUCCIÓN 5 En cada una de estas capas pueden existir vulnerabilidades que pueden afectar los recursos que residen en un SMBD, por lo que se deben implementar controles preventivos de seguridad que sean efectivos y que ayuden a minimizar los riesgos de explotación, 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 más comunes que se pueden encontrar son: Vulnerabilidades de inyección en aplicaciones y servicios Web. Configuraciones inseguras o por default. Uso de protocolos inseguros que no cifran los datos enviados. Métodos débiles de autenticación y autorización. Malware, virus o código malicioso. Uso de password débiles. Falta de protección de archivos y directorios de configuración ó con información sensible Objetivo El presente trabajo tiene los siguientes objetivos: Analizar las vulnerabilidades más 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).

17 CAPÍTULO 1. INTRODUCCIÓN 6 Analizar el uso de vistas y parámetros de sesión en la capa aplicativa para reducir los riesgos de explotación 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 interactúa el SMBD (enfoque defensivo) Justificación Debido a la dependencia que se tiene actualmente en los sistemas de información 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 implementación y administración de un SMBD y sus ambientes con la finalidad de reducir los riesgos de explotación, 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 más común de ataque. Los incidentes de seguridad sobre los recursos de un SMBD se traducen en afectación a las personas, organizaciones y gobiernos que dependen de los sistemas de información 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 información 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 información, o exponer información secreta de un gobierno afectando de esta manera la seguridad nacional de un país.

18 CAPÍTULO 1. INTRODUCCIÓN 7 Un incidente sobre la integridad de los recursos que residen en un SMBD puede afectar la veracidad de la información que es utilizada para la toma de decisiones, o la ejecución correcta de transacciones u operaciones criticas. Un incidente sobre la disponibilidad de los recursos que residen en un SMBD pude afectar la ejecución de procesos críticos que utilizan y dependen de dichos recursos como entrada para completarse adecuadamente Trabajos relacionados Dentro de los trabajos relacionados a esta investigación se encuentran los siguientes: En el articulo [3] se proponen técnicas de inyección basadas en la mutación de operadores para evadir controles de seguridad que pueden tratar de impedir la inyección exitosa de sentencias SQL desde la aplicación de manera no autorizada, dichas técnicas 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 técnicas para identificar módulos de una aplicación Web con vulnerabilidades de SQL Injection, para ello se define una maquina finita de estados donde cada módulo de la aplicación representa un estado y el envío de parámetros por los métodos HTTP GET/POST representan las funciones de transición. En el articulo [9] se propone el uso de vistas parametrizadas para reducir los riesgos de explotación de vulnerabilidades de SQL Injection o a contener los impactos sobre los recursos del SMBD en caso de un ataque exitoso.

19 CAPÍTULO 1. INTRODUCCIÓN Estructura del trabajo El presente trabajo de investigación tiene la siguiente estructura: En el primer capítulo se define el Planteamiento del Problema, Objetivo y Justificación de la investigación. En el segundo capítulo se definen conceptos básicos de Seguridad de la Información 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 técnicas de SQL Injection en una aplicación 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 administración de un SMBD con el fin de reducir los riesgos de explotación, 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 parámetros de sesión en una aplicación para reducir los riesgos de explotación de SQL Injection Alcance y limitaciones Este trabajo de investigación se enfoca principalmente en el ataque de SQL Injection, ya que este ataque es el más común sobre aplicaciones Web y el que más hace daño a las Bases de Datos con las que interactúa [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

20 CAPÍTULO 1. INTRODUCCIÓN 9 versión de SMBD que se este utilizando, y no se enfoca a una versión o producto de SMBD en particular. Se deja para trabajos posteriores profundizar en las vulnerabilidades que pueden existir en otros ambientes que interactúan 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 explotación.

21 Capítulo 2 Conceptos de seguridad de la información Para analizar los enfoques de seguridad planteados (Enfoque Ofensivo y Enfoque Defensivo) es conveniente definir conceptos básicos de seguridad de la información, ya que estos servirán 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 información y no los sistemas de información en sí. Es importante aclarar que la información puede existir en diferentes medios y formas como documentos, medios electrónicos, software, entre otros. Por lo que el concepto de seguridad de la información no debe ser confundido con el de seguridad informática [4], en particular esta investigación se enfoca en los datos que residen, procesan o transmiten en un SMBD y en los ambientes con los que interactúa, y la definición de los siguientes conceptos de seguridad de la información se van orientar en este sentido. 10

22 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN Conceptos de seguridad de la información ˆ La Seguridad de la Información 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 están disponibles a los usuarios autorizados cuando estos son requeridos. ˆ Un usuario es cualquier entidad lógica (programa, usuario final, proceso, sistema) que interactúa con un sistema. Figura 2.1: Propiedades de seguridad en un SMBD

23 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 12 ˆ Una vulnerabilidad es una debilidad inherente o la falta de controles de seguridad en el SMBD o en sus ambientes, y que pueden ser explotadas por una amenaza afectando negativamente alguna de las tres propiedades básicas de seguridad de la información (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 algún 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 explotación de una vulnerabilidad puede ser de manera intencional o accidental y el resultado es una afectación o impacto negativo a los recursos que residen en un SMBD. Los agentes de amenaza más comunes son: Usuarios o administradores de la Base de Datos Empleados disgustados en una organización 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 explotación 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 explotación de vulnerabilidades, reduciendo la probabilidad de que una amenaza explote alguna vulnerabilidad o aproveche la falta de controles de seguridad. Los controles de seguridad también ayudan a contener los impactos en la confidencialidad, integridad y disponibilidad

24 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 13 de los recursos de un SMBD en caso de un ataque exitoso. Los controles de seguridad se evalúan de acuerdo al grado que dichos controles protegen y aseguran las tres propiedades de seguridad en un SMBD (CID). Figura 2.2: Relación de los elementos de seguridad en un SMBD [5]

25 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 14 ˆ Existen tres tipos de controles de seguridad, estos son: controles administrativos, controles técnicos (también llamados controles lógicos) y controles físicos. Los controles administrativos incluyen el desarrollo e implementación de políticas, estándares, procedimientos y guías de seguridad. Los controles técnicos tienen que ver con la implementación de controles de seguridad en hardware y software, ejemplo de controles técnicos son la implementación de antivirus, definición de reglas de acceso en un firewall, o definición de políticas robustas de password en una aplicación. Los controles físicos se refieren a la protección de las instalaciones físicas donde residen los sistemas de información 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 información, ejemplo de controles físicos pueden ser un guardia que se encuentra en la entrada de un centro de datos, cámaras de seguridad, o controles ambientales y de temperatura en un centro de datos. ˆ Los controles administrativos, técnicos 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 aplicación, para prevenir accesos no autorizados. Los controles detectivos son aquellos que identifican la ejecución 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 anómalas o violaciones a las políticas de seguridad en una red de datos.

26 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 15 Los controles correctivos son aquellos que se utilizan para recuperar el estado original o normal de un sistema después de un incidente de seguridad o un evento no deseado, un ejemplo de este control es el plan de continuidad de negocio de una organización para recuperar la operación de procesos críticos después de un incidente de seguridad. ˆ Un control de accesos básicamente consiste en tres procesos que son: identificación, autenticación y autorización. El proceso de identificación consiste en asignar una identidad a los usuarios que acceden a un sistema de información, de esta manera dichos usuarios pueden ser identificados de manera única, por lo que las acciones que realicen dichos usuarios en el sistema de información son asociadas a los mismos, comúnmente la asignación de esta identidad se da por una cuenta de usuario o ID de acceso al sistema. El proceso de autenticación consiste en que dichos usuarios demuestran su identidad. Un usuario puede demostrar su identidad de tres formas: algo que es usuario es (ejemplo: accesos biométricos), algo que el usuario tiene (ejemplo: tokens de acceso, tarjetas de identidad) o algo que el usuario conoce (ejemplo: password de acceso). La forma más común 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 autenticación. El proceso de autorización consiste en asegurar que los usuarios una vez identificados y autenticados puedan acceder solo los recursos del sistema sobre los que tienen permisos.

27 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 16 Figura 2.3: Controles administrativos, técnicos 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 implementación de diferentes controles de seguridad en distintas capas de un sistema de información 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 técnicos o lógicos, que en su conjunto presentan una serie de capas de seguridad para proteger la información.

28 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 17 Este concepto tiene sus orígenes en el área 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 información. Figura 2.4: Seguridad en profundidad

29 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 18 ˆ La gestión de riegos es un proceso donde se analiza y cuantifica la probabilidad de que una vulnerabilidad sea explotada por algún agente de amenaza, ya sea de manera accidental o intencional, y el impacto que dicha explotación 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 reputación de una organización, afectación a la privacidad de las personas, multas o demandas por incumplimiento a las regulaciones sobre la protección de datos personales. El resultado del proceso de análisis de riesgos muestra el costo-beneficio de la implementación de controles de seguridad contra el costo del impacto debido a la afectación en los datos en caso de que una vulnerabilidad sea explotada. Existen dos tipos de análisis de riesgos, estos son: análisis de riegos cuantitativo y análisis de riesgos cualitativo. Un proceso de gestión de riesgos cualitativo consta básicamente de las siguientes etapas [6]: Establecimiento de métricas de riesgo Perfil de activos Identificación de amenazas Identificación y mitigación de riesgos

30 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 19 Figura 2.5: Fases para la gestión de riesgos - Metodología Octave Allegro En el establecimiento de las métricas de riesgo se deben involucrar a las diferentes áreas de la organización para definir un conjunto de métricas cualitativas contra las cuales se evaluaran los riesgos en la organización y establecer las áreas de impacto mas significativas en la organización. La definición adecuada de este conjunto de métricas de riesgo asegura que las decisiones acerca de como mitigar dichos riesgos sea consistente. Ejemplos de áreas de impacto son: Reputación Confianza del cliente Finanzas Productividad

31 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 20 Figura 2.6: Objetivos de cada fases para la gestión de riesgos Seguridad y salud Multas y sanciones legales Imagen de la marca Para identificar las métricas de impacto que se utilizarán para evaluar los riesgos, se pueden utilizar las siguientes preguntas: Qué servicios, procesos ó información son los mas relevantes dentro de la organización? Qué servicios, procesos ó información, si se vieran afectados, también afectarían a la misión y objetivos de la organización? Para cada servicio, proceso e información identificados en los puntos anteriores, se deben definir las situaciones o condiciones que podrían ocasionar un

32 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 21 impacto, clasificando dichos impactos como alto(3), medio(2) y bajo(1). Figura 2.7: Métricas de impacto

33 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 22 Una vez que se han definido las métricas de impacto, se deben identificar los activos de información que están relacionados con dichas áreas de impacto y sus contenedores. Un contendedor es donde reside, transmite o procesan los servicios o información (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 organización. Se debe asegurar de que la descripción de los activos de información sea clara y concisa, y que los requerimientos de seguridad para dichos activos sean definidos adecuadamente. Para cada activo de información identificado se debe incluir al menos: Nombre del activo de información Razón de la selección ( Por qué este activo es importante para la organización?) Descripción ( Cuál es la descripción del activo de información?) Dueño(s) ( A quién pertenece el activo de información?, Quién es responsable por este activo de información?, Quién es dueño de los procesos donde este activo de información es usado?, Quién es el responsable por asignar valor (monetario u otro) a este activo de información?, Quien seria mas impactado si este activo de información es comprometido?, Existen diferentes dueños para los distintos elementos que componen este activo de información?) Requerimientos de seguridad (integridad, confidencialidad, disponibilidad, otro) Requisito de seguridad mas importante ( Cuál es el requisito de seguridad mas importante para Descripción de los contenedores (tecnológico/físico/humano/interno/externo)

34 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 23 del activo de información Figura 2.8: Identificación de contenedores

35 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 24 En la identificación de vulnerabilidades se obtiene información de los contenedores, como: arquitecturas, tecnologías, versiones, listas de usuarios, flujos de información, etc., y se identifican vulnerabilidades técnicas, de procesos o en el personal (capacitación o concientización) 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 técnicas, de procesos o en el personal (capacitación o concientización) que podrían exponer la información o causar que los procesos identificados sean afectados. Figura 2.9: Análisis de vulnerabilidades

36 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 25 Para la identificación, análisis y tratamiento de riesgos se debe medir el impacto a la organización si una vulnerabilidad es explotada, y las consecuencias que dicha explotación puede causar a la organización de acuerdo a las métricas 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

37 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 26 Figura 2.11: Matriz de riesgos

38 CAPÍTULO 2. CONCEPTOS DE SEGURIDAD DE LA INFORMACIÓN 27 Con los resultados del análisis de riesgos, la organización debe decidir como dará tratamiento al riesgo, teniendo las siguientes opciones: Aceptar el riesgo Mitigar el riesgo Transferir el riesgo

39 Capítulo 3 Enfoque ofensivo de seguridad Actualmente los sistemas de información son fundamentales para el desarrollo de las actividades cotidianas de las personas y organizaciones, el uso de Internet y dispositivos móviles 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 interactúa. En este escenario los datos están cada vez más expuestos a diferentes amenazas y vectores de ataque, por lo que si no se incluyen controles de seguridad adecuados en el diseño y desarrollo de estos sistemas, se pueden exponer diferentes vulnerabilidades las cuales pueden ser explotadas por algún agente de amenaza. Principalmente la capa aplicativa es un vector común 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 ejecución de operaciones como consultas y modificación de registros sobre bases de datos. Si estos puntos de entrada no son validados adecuadamente pueden permitir la inclusión de código o sentencias maliciosas para manipular la ejecución lógica de la aplicación y el envío de sentencias al SMBD de manera 28

40 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 29 no autorizada, afectando la integridad, disponibilidad y confidencialidad de los recursos del SMBD con el que interactúa. 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 investigación, la identificación y explotación de vulnerabilidades no es el fin, si no el medio para implementar controles efectivos de seguridad que ayuden a minimizar los riesgos de explotación. Los atacantes pueden potencialmente usar rutas diferentes a través de la aplicación para hacer daño a una organización. Cada una de estas rutas representa un riesgo que puede, o no, ser lo suficientemente grave como para justificar su atención. A veces estas rutas son triviales de encontrar y explotar, y otras veces requieren de un conocimiento técnico avanzado para poder explotar dichas vulnerabilidades. Figura 3.1: Riesgos de seguridad en aplicaciones - OWASP

41 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD Vulnerabilidades en la capa aplicativa Actualmente el uso de Internet es esencial para la operación de los sistemas de información, aunado al aumento en el uso de de plataformas en la nube y dispositivos móviles con gran capacidad de procesamiento para acceder y manipular Bases de Datos a través de aplicaciones y servicios Web como SOAP o REST, hacen de esta capa un vector común 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 aplicación 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 más en la funcionalidad y operación de la aplicación y dejan a un lado los requerimientos de seguridad en el ciclo del desarrollo del software, por lo que es común encontrar aplicaciones en ambientes productivos con vulnerabilidades que pueden comprometer los recursos del SMBD u otros sistemas a los que se conecta. La implementación de controles de seguridad en ambientes productivos es más costosa en tiempo y recursos, por lo que es importante considerar los

42 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 31 requerimientos de seguridad desde las fases iniciales del ciclo de desarrollo del software para poder detectar vulnerabilidades potenciales en el diseño del sistema, con la finalidad de corregir dichos huecos de seguridad antes de su implementación en ambientes de producción. Las vulnerabilidades más comunes en la capa aplicativa según la fundación OWASP (Open Web Application Security Project) son: Vulnerabilidades de inyección. Pérdida de autenticación y gestión de sesiones. Ejecución de scripts maliciosos (Cross-Site Scripting - XSS). Referencia directa insegura a objetos. Configuraciones de seguridad incorrectas. Exposición de datos sensibles. Ausencia de control de acceso a las funciones. Falsificación 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 explotación de vulnerabilidades comunes, si el framework utilizado no es implementado adecuadamente, es posible que un atacante explote vulnerabilidades en la aplicación exitosamente, por lo que no basta con implementar algún 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 están implementado controles adecuados de seguridad que no afecten la operación

43 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 32 del sistema, pero que si ayuden a minimizar los riesgos de explotación de manera efectiva. Las vulnerabilidades de inyección son las más comunes en la capa aplicativa, los atacantes pueden aprovechar esta vulnerabilidad para extraer información de manera no autorizada o ejecutar código malicioso, ya que esta vulnerabilidad permite enviar sentencias SQL (SQL Injection), comandos para manipular la ejecución lógica de procesos en el sistema operativo, o evadir métodos de autenticación de manera no autorizada SQL Injection Dentro de las vulnerabilidades de inyección, el ataque de SQL Injection es que más hace daño a las bases de datos con las que interactúa la aplicación, 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 dinámicos para ejecutar sentencias SQL en la base de datos desde la aplicación. No se utilizan usuarios específicos con los privilegios mínimos necesarios para conectar a la base de datos desde la aplicación. No se sanitizan o filtran los datos de entrada enviados desde la aplicación a la base de datos para construir sentencias SQL y asegurar que los datos sean del tipo y tamaño esperado.

44 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 33 Figura 3.2: Causas que propician vulnerabilidades SQL Injection Aunque el ataque de SQL Injection generalmente se ejecuta sobre la capa aplicativa y no directamente sobre el SMBD, se deben implementar controles de seguridad en cada una de las capas con el fin de minimizar los riesgos de explotación o contener el impacto sobre los recursos del SMBD en caso de un ataque exitoso de SQL Injection. SQL es el lenguaje estándar para manipular datos en diferentes SMBD relacionales como Microsoft SQL Server, Oracle, MySQL, Sybase, Informix, etc., por lo que cualquier proceso desde la aplicación 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 explotación. Esta vulnerabilidad se agrava cuando el usuario utilizado para conectar a la

45 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 34 base de datos desde la aplicación cuenta con privilegios de administración, 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 función 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

46 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD Mal manejo de sesiones El manejo seguro de sesiones en una aplicación se refiere a proteger adecuadamente los parámetros de sesión 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 aplicación con dicha identidad de manera no autorizada. La forma más común de autenticar a una aplicación Web es por medio de passwords de acceso, por lo que el manejo y administración 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 autenticación. Las vulnerabilidades en el manejo de sesiones y en el proceso de autenticación se puede dar por las siguientes causas: Los IDs de sesión o password de acceso se exponen en la URL, es decir, se envían los parámetros por medio del método HTTP GET, por lo que estos datos pueden ser capturados y modificados por un atacante. Los IDs de sesión no se generan con un algoritmo robusto que asegure IDs aleatorios, por lo que un atacante puede falsificar los IDs de sesión y robar la identidad de un usuario valido. Las sesiones no expiran por tiempo de inactividad. No se destruyen e invalidan los parámetros de sesión después del cierre de sesión de la aplicación. Los parámetros de sesión y password de acceso se envían en canales no cifrados.

47 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 36 Los password se resguardan en texto claro. No hay políticas robustas de password en la aplicación, se permite el uso de password débiles y estos no expiran por inactividad. Figura 3.4: Escenario de vulnerabilidades en el manejo de sesiones

48 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 37 Para ejemplificar esta vulnerabilidad, supongamos que tenemos una aplicación Web que genera un ID de sesión por cada usuario que se autentica a la aplicación, este ID de sesión es utilizado para permitir acceso a diferentes funcionalidades en la aplicación. Figura 3.5: Mal manejo de sesiones en una aplicación Web

49 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 38 Esta aplicación tiene la vulnerabilidad de que los IDs de sesión no se generan con un algoritmo robusto que asegure que el ID de sesión se genera de manera no predecible. En este caso se puede observar que el algoritmo utilizado para generar el ID de sesión se genera con un algoritmo simple de transposición 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, después sustituyendo cada letra por su sucesor tenemos ubphcfx. Por lo que en este caso el algoritmo utilizado es débil y puede ser vulnerado para lograr acceso a la aplicación. Figura 3.6: modificación de los parámetros de sesión

50 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 39 Algunas veces se utilizan mecanismos débiles 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 aplicación. En este ejemplo, un atacante puede acceder a la aplicación sin proporcionar un password valido de acceso, inyectando un ID de sesión valido, puede ingresar a la aplicación de manera no autorizada. Figura 3.7: Acceso no autorizado a una aplicación por vulnerabilidades en el manejo de sesiones

51 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD Cross-Site Scripting - XSS Esta vulnerabilidad ocurre cuando una aplicación, 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 código 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 aplicación, por lo que cada vez que un usuario ingrese al módulo vulnerado, el script malicioso se ejecuta automáticamente. XSS Reflejado: en este tipo de vulnerabilidad el script malicioso se adjunta en algún parámetro utilizado por la aplicación y que es interpretado por el navegador Web de la víctima cuando dicho parámetro es interpretado. XSS Basado en DOM. El escenario de la vulnerabilidad de XSS es la siguiente:

52 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 41 Figura 3.8: Escenario del ataque de XSS En el siguiente ejemplo se tiene una aplicación vulnerable a XSS almacenado, la aplicación tiene un módulo de visitas donde los usuarios de la aplicación ingresan y dejan sus comentarios sobre el sitio, debido a que este módulo no valida adecuadamente los datos ingresados por los usuarios, es posible ingresar scripts maliciosos que son almacenados por el servidor.

53 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 42 Figura 3.9: Inyección de script malicioso XSS almacenado Cuando un usuario entra a la aplicación, el script malicioso es interpretado por el navegador del usuario. Para evitar este tipo de ataques la aplicación debe validar que los datos de entrada sean del tipo y tamaño esperado por la aplicación.

54 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 43 Figura 3.10: El navegador de la víctima interpreta el código 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 información, 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

55 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 44 obtener información sensible como passwords de acceso al SMBD, en su lugar se debe implementar un protocolo seguro de comunicación (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, esté no pueda obtener información sensible. En un ejemplo donde se tiene un servidor MySQL en la IP con el puerto default de MySQL 3306 habilitado para permitir conexiones remotas sin utilizar un protocolo seguro de comunicación 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 información sensible como passwords de acceso, comando ejecutados, datos de tarjeta de crédito, información financiera u otro tipo de información sensible. Figura 3.11: Captura de trafico no cifrado Si un usuario inicia una sesión al servidor MySQL desde el

56 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 45 cliente sin utilizar un protocolo seguro de comunicación 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 información 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 el usuario 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 utilizó protocolos seguros de comunicación que cifren los datos enviados desde el cliente al servidor MySQL, de esta manera el atacante logra capturar la creación de

57 CAPÍTULO 3. ENFOQUE OFENSIVO DE SEGURIDAD 46 un usuario obteniendo el usuario y password de acceso al SMBD. Figura 3.14: El atacante obtiene el usuario y password de acceso

58 Capítulo 4 Metodología para identificar vulnerabilidades contra ataques de SQL Injection Existen diferentes controles de seguridad para tratar de mitigar un ataque de SQL Injection, también en aplicaciones grandes es difícil detectar puntos de entrada vulnerables a inyección, aún 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 inyección exitosa en la aplicación. Para identificar vulnerabilidades de inyección eficientemente se propone la siguiente metodología: Figura 4.1: Panorama general de una metodología de explotación SQL Injection 47

59 CAPÍTULO 4. METODOLOGÍA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQU Figura 4.2: Pasos de una metodología de explotación SQL Injection

60 CAPÍTULO 4. METODOLOGÍA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQU Reconocimiento pasivo En el reconocimiento pasivo se ejecutan operaciones normales sobre la aplicación con la finalidad de entender el comportamiento de la aplicación, este entendimiento de la aplicación es útil para identificar los módulos que tienen una interacción sobre algún recurso del SMBD. Este tipo de reconocimiento no es intrusivo y no se espera que la aplicación responda de manera inesperada o que genere algún tipo de alarma que informe sobre las actividades que esta ejecutando el atacante Identificar los módulos que interactúan con el SMBD Debido a que el enfoque de ataque propuesto para esta investigación es de caja negra, no se tiene acceso al código de la aplicación que se esta atacando u otro tipo de información que nos ayude a perfilar y obtener detalle de la arquitectura del sistema, por lo que para identificar los módulos que interactúan con algún recurso del SMBD se pueden utilizar herramientas proxy que nos permiten analizar la comunicación entre un cliente y una aplicación Web. Figura 4.3: Uso de proxy para analizar el comportamiento lógico de la aplicación

61 CAPÍTULO 4. METODOLOGÍA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQU En una arquitectura básica de tres capas, la lógica de la aplicación se encuentra en la capa aplicativa, en esta capa se encuentra el código que interactúa y envía operaciones al SMBD. Un usuario final generalmente interactúa con la capa aplicativa a través de un navegador Web, desde donde envía datos a la aplicación a través de métodos HTTP GET/POST. La capa aplicativa recibe estos datos de entrada por medio de parámetros o variables, y los utiliza posteriormente para enviar instrucciones al SMBD. Por ejemplo, un usuario puede realizar la búsqueda de registros hacia una Base de Datos a través de un formulario Web de búsqueda, los datos recibidos por la aplicación son utilizados para armar una sentencia SQL que es enviada al SMBD para su ejecución, la capa aplicativa también se encarga de regresar una respuesta al usuario final. Figura 4.4: Ejecución de operaciones al SMBD desde la aplicación

62 CAPÍTULO 4. METODOLOGÍA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQU Generalmente el método HTTP GET es el método más simple para obtener recursos de un servidor, dichos recursos pueden ser páginas HTML, imágenes JPEG u otro tipo de archivos, por el contrario con el método POST no solo se pueden obtener recursos de un servidor, si no también se puede enviar datos al servidor para ser procesados. Otra diferencia entre el método GET y POST, es que el primero expone los parámetros 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 fácilmente por un atacante para ejecutar inyecciones con dichos parámetros. Figura 4.5: Estructura del método HTTP GET

63 CAPÍTULO 4. METODOLOGÍA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQU Figura 4.6: Estructura del método HTTP POST

64 CAPÍTULO 4. METODOLOGÍA PARA IDENTIFICAR VULNERABILIDADES CONTRA ATAQU La identificación de los parámetros utilizados por la aplicación para ejecutar operaciones en el SMBD por medio de los métodos HTTP GET/POST es muy importante ya que estos parámetros son utilizados para ejecutar ataques de SQL Injection modificando los datos enviados a través de los mismos. En este ejemplo se puede observar que la aplicación envía el parámetro id por el método HTTP GET. Figura 4.7: Identificación de parámetros que envían datos a través de HTTP GET y POST