1 CIS1010SD03
ESTADO DEL ARTE DE LA APLICACIÓN DE TÉCNICAS ANTIFORENSES EN BASES DE DATOS ORACLE. CONCEPTOS Y RETOS PARA LOS INFORMÁTICOS FORENSES
Autores:
GUILLERMO ALFONSO FERRO RODRIGUEZ PEDRO ALEJANDRO SANTIESTEBAN
http://pegasus.javeriana.edu.co/~CIS1010SD03/
PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS
2 ESTADO DEL ARTE DE LA APLICACIÓN DE TÉCNICAS ANTIFORENSES EN BASES DE
DATOS ORACLE. CONCEPTOS Y RETOS PARA LOS INFORMÁTICOS FORENSES
Autores:
GUILLERMO ALFONSO FERRO RODRIGUEZ PEDRO ALEJANDRO SANTIESTEBAN
Trabajo de grado presentado para optar el título de Ingeniero de Sistemas
Director:
Ingeniero Jeimy José Cano Martínez, PhD PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS
3 PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMAS
Rector Magnífico
Padre Joaquín Emilio Sánchez García S.J.
Decano Académico Facultad de Ingeniería Ingeniero Francisco Javier Rebolledo Muñoz
Decano del Medio Universitario Facultad de Ingeniería Padre Sergio Bernal Restrepo S.J.
Director Carrera de Ingeniería de Sistemas Ingeniero Luis Carlos Díaz Chaparro
Director Departamento de Ingeniería de Sistemas César Julio Bustacara Medina
4 Nota de Aceptación ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ Jeimy José Cano Martínez Director del Proyecto
________________________________________ José Luis Lara
________________________________________ Julio Carreño
5 Artículo 23 de la Resolución No. 1 de Junio de 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia”
6 CONTENIDO
TABLA DE ILUSTRACIONES ... 9
RESUMEN EJECUTIVO ... 12
1 DESCRIPCIÓN GENERAL DEL TRABAJO DE GRADO ... 14
1.1 Formulación ... 14
1.2 Justificación ... 15
1.3 Objetivo general ... 17
1.4 Objetivos específicos... 18
2 REVISIÓN DE LITERATURA ... 19
2.1 Administración Bases de datos ... 19
2.1.1 Estado Actual ... 19
2.2 Bases de datos Oracle ... 22
2.2.1 Conceptos básicos de Bases de datos Oracle ... 22
2.2.2 Arquitectura Oracle ... 22 2.3 TECNICAS ANTI-FORENSES ... 27 2.3.1 Definición ... 28 2.3.2 Objetivos ... 29 2.3.3 Destrucción de evidencia... 29 2.3.4 Ocultación de evidencia ... 29
2.3.5 Eliminación de fuentes de evidencia ... 30
2.3.6 Falsificación de evidencia ... 30
2.4 ATAQUES EN ORACLE ... 31
2.4.1 SQL INJECTION ... 31
2.4.2 TIPOS DE ATAQUES SQL INJECTION ... 33
2.4.3 SQL MANIPULATION ... 34
2.4.4 CODE INJECTION ... 35
2.4.5 FUNCTION CALL INJECTION ... 35
2.4.6 BUFFER OVERFLOWS ... 37
2.5 TÉCNICAS FORENSES EN BASES DE DATOS ORACLE ... 37
2.5.1 ENTORNO ... 38
2.5.2 PRINCIPALES FUENTES DE EVIDENCIA EN ORACLE ... 38
7
2.6 CASO DE ESTUDIO ... 86
2.6.1 EVIDENCIA DE LAS ACCIONES DEL ATACANTE ... 86
2.7 TECNICAS ANTI FORENSES EN BASES DE DATOS ORACLE... 87
2.7.1 Técnicas anti forenses en contra del Redo Log ... 87
2.7.2 Técnicas anti forenses contra los rastros dejados por la eliminación de objetos ... 88
2.7.3 Técnicas anti forenses en contra de las tablas de auditoria ... 88
2.8 GUíA METODOLOGICA PARA EL ANáLISIS DE BASES DE DATOS ORACLE ... 88
2.9 RECOMENDACIONES PARA LOS INVESTIGADORES FORENSES EN INFORMÁTICA EN BASES DE DATOS ORACLE. ... 91
3 CONCLUSIONES ... 92 4 TRABAJOS FUTUROS ... 93 5 ANEXOS ... 94 5.1 Anexo 1 ... 94 5.2 Anexo 2 ... 95 5.3 Anexo 3 ... 96 5.4 Anexo 4 ... 97 5.5 Anexo 5 ... 98 5.6 Anexo 6 ... 99 5.7 Anexo 7 ... 100 5.8 Anexo 8 ... 101 5.9 Anexo 9 ... 102 5.10 Anexo 10 ... 103 5.11 Anexo 11 ... 104 5.12 Anexo 12 ... 106 5.13 Anexo 13 ... 107 5.14 Anexo 14 ... 108 5.15 Anexo 15 ... 109 5.16 Anexo 16 ... 110 5.17 Anexo 17 ... 111 5.18 Anexo 18 ... 112 5.19 Anexo 19 ... 113 5.20 Anexo 20 ... 114 5.21 Anexo 21 ... 115 5.22 Anexo 22 ... 116 5.23 Anexo 23 ... 117
8 5.24 Anexo 24 ... 118 5.25 Anexo 25 ... 123 5.26 Anexo 26 ... 134 5.27 Anexo 27 ... 135 5.28 Anexo 28 ... 136 5.29 Anexo 29 ... 137 5.30 Anexo 30 ... 138 5.31 Anexo 31 ... 139 5.32 Anexo 32 ... 140 5.33 Anexo 33 ... 141 5.34 Anexo 34 ... 142 5.35 Anexo 35 ... 143 5.36 Anexo 36 ... 144 5.37 Anexo 37 ... 146 5.38 Anexo 38 ... 149 5.39 Anexo 39 ... 150 5.40 Anexo 40 ... 151 5.41 Anexo 41 ... 152 5.42 Anexo 42 ... 153 5.43 Anexo 43 ... 154 5.44 Anexo 44 ... 156 5.45 Anexo 45 ... 157 5.46 Anexo 46 ... 158 5.47 Anexo 47 ... 159 5.47.1 Recaudo de la información ... 160 5.48 Anexo 48 ... 164 6 TRABAJOS CITADOS ... 166
9
TABLA DE ILUSTRACIONES
Ilustración 1: Promedio de ataques bloqueados por día [1]. ... 17
Ilustración 2: Ventajas de hacer las cosas bien [1] ... 20
Ilustración 3: Rastros en el audit trail de un intento de ejecutar una sentencia con privilegios insuficientes [25] ... 58
Ilustración 4: Audit trail justo después de iniciar sesión [25] ... 58
Ilustración 5: Audit trail justo después de cerrar sesión [25] ... 59
Ilustración 6: Campo LOGOFF$TIME de la tabla AUD$ [25] ... 59
Ilustración 7: Volcado de los predicados LIKE_PREDS [34] ... 77
Ilustración 8: Creación diccionario de datos ... 83
Ilustración 9: Mapa de Acción ... 88
Ilustración 10: Sofisticación Vs. Conocimiento del atacante [41]. ... 94
Ilustración 11: Intrusiones de seguridad en 2010 [1] ... 95
Ilustración 12: Actualizaciones de seguridad [1] ... 96
Ilustración 13: Estructura de la base de datos Oracle [6] ... 97
Ilustración 14: Técnicas Anti-forenses [3] ... 98
Ilustración 15: Vulnerabilidad usada para comprometer el sistema [9] ... 99
Ilustración 16: Configuración de los Redo Logs en la creación de la base de datos ... 100
Ilustración 17: Bloque de datos Oracle [19] ... 102
Ilustración 18: Consulta de verificación del estado de las funciones de auditoria [21] ... 103
Ilustración 19: Volcado de información a partir de los tipos de dato de la tabla OBJ$ [19] ... 105
Ilustración 20: Entradas en el listener log generadas al ejecutar sidguess.exe [25] ... 106
Ilustración 21: Registro de eventos de conexiones privilegiadas SYSDBA y SYSOPER en Windows [25] ... 107
Ilustración 22: Evidencia de inicio de sesión cuando la auditoria esta desactivada [25] ... 107
Ilustración 23: Localización traza ... 108
Ilustración 24: Traza sin formato ... 108
Ilustración 25: Sentencias de volcado ... 109
Ilustración 26: Volcado NOSYS ... 109
Ilustración 27:Comando Time ... 110
Ilustración 28: Comando Date... 110
Ilustración 29: Comando net user ... 111
Ilustración 30: Detalles de usuario ... 111
Ilustración 31: Lista de conexiones y puertos ... 112
Ilustración 32: Ubicación Home ... 113
Ilustración 33: Ubicación Archivo de Inicio ... 113
Ilustración 34: Validación Ruta diccionario Logminer ... 115
Ilustración 35: Configuración ruta diccionario ... 115
Ilustración 36: Validación Pos activación ... 115
Ilustración 37: Agregando archivos de investigación ... 116
Ilustración 38: Tipos de datos LogMiner ... 117
Ilustración 39: Creando el usuario a explotar ... 118
Ilustración 40: Revisando los privilegios del usuario ... 118
Ilustración 41: Verificando los permisos Java del usuario ... 119
Ilustración 42: Sentencia de inyección para obtener privilegios Java arbitrarios... 119
Ilustración 43: Verificación de inserción de nuestra Política Java ... 120
10
Ilustración 45: Creación de un usuario en el sistema operativo ... 121
Ilustración 46: Agregando el usuario al grupo de administradores del sistema operativo ... 121
Ilustración 47: Lateral Injection al re direccionar la salida de un error ... 122
Ilustración 48: Ejecución de un paquete de SYS con parámetros inválidos para ejecutar nuestro ataque . 122 Ilustración 49: Proceso para darle formato al archivo trc... 124
Ilustración 50: Sentencia 1 Ejecución de un procedimiento para explotar vulnerabilidad de aurora ... 124
Ilustración 51: Sentencia 2 Permisos para modificar la entrada y salida del sistema ... 125
Ilustración 52: Sentencia 3 Creación de archivo de salida OUT.LST ... 125
Ilustración 53: Creación de un usuario dentro del sistema operativo ... 125
Ilustración 54: Ejecución de permisos para Otorgar perfil de DBA ... 126
Ilustración 55: Flujo de información para crear el overflow ... 126
Ilustración 56: Set Role as DBA ... 126
Ilustración 57: Evidencia del ataque en los Redo Logs ... 127
Ilustración 58: Verificación de la evidencia obtenida en el volcado generado por la herramienta "dumpaction.exe" ... 128
Ilustración 59: XML para filtrar entradas sospechosas de un Redo Log ... 129
Ilustración 60: Entradas relacionadas a BONIFACIO en la tabla de auditoría AUD$ ... 130
Ilustración 61: Código de acción relacionado al valor hallado en la tabla AUD$ ... 130
Ilustración 62: Técnica anti forense de eliminación de la evidencia almacenada en la tabla AUD$ ... 131
Ilustración 63: Sentencia de uso de Orablock para hallar evidencia relacionada a la tabla AUD$ en el Data File SYSTEM01.DBF ... 132
Ilustración 64: Archivo de estructura de la tabla AUD$ ... 132
Ilustración 65: Evidencia de filas eliminadas de la tabla AUD$ ... 133
Ilustración 66 : Diagrama de flujo para detectar vulnerabilidades de SQL Injection – Adaptado de [12] 134 Ilustración 67: Volcado Hexadecimal de un bloque asignado a la tabla SOURCE$ [19] ... 135
Ilustración 68: Información contenida en las filas eliminadas asociadas al objeto 51850 [19] ... 135
Ilustración 69: Volcado Hexadecimal de los bloques asignados a la tabla IDL_UB1$ [19] ... 137
Ilustración 70: Diferencia entre autenticación de la cuenta SYS con y sin "AS SYSDBA" [25] ... 138
Ilustración 71: Búsqueda ruta trace files ... 139
Ilustración 72: SPFile Texto ... 140
Ilustración 73: Ruta Listener logs [26] ... 141
Ilustración 74: Versión ... 142
Ilustración 75: Descripción de la columna COL_USAGE$ [34] ... 143
Ilustración 76: Filt1.xml ... 144
Ilustración 77: Filt-bool.xml ... 144
Ilustración 78: Filt-grant.xml ... 145
Ilustración 79:Filt-xid.xml ... 145
Ilustración 80: Parámetros de la herramienta Orablock ... 145
Ilustración 81: Errores del TNS Listener [23] ... 146
Ilustración 82: Entradas en el listener log para los comandos SERVICES y STATUS [25] ... 146
Ilustración 83: Entradas en el audit trail para intentos de conexión de usuarios no existentes [25] ... 147
Ilustración 84: Entrada del audit trail usando la columna COMMENT$TEXT [25] ... 147
Ilustración 85: Evidencia del uso de orapwdbrute.exe [25] ... 147
Ilustración 86: Consulta para extraer la fecha en que se bloquea una cuenta ... 148
Ilustración 87: Entradas en el listener log generadas al ejecutar sidgusser.exe [25] ... 149
Ilustración 88: Búsqueda SID y Serial # ... 150
Ilustración 89: Encabezado de un archivo Oracle ... 151
Ilustración 90: Ejemplo de verificación del tamaño de un archivo Oracle ... 151
11
Ilustración 92: Estructura del encabezado de un Red Log – Adaptado de [16] ... 153
Ilustración 93: Encabezado de una fila eliminada [19] ... 154
Ilustración 94: Extracción de información de columnas de una fila eliminada [19] ... 154
Ilustración 95: Volcado hexadecimal de una fila [19] ... 155
Ilustración 96: Discriminación de columnas a partir de un volcado hexadecimal [19] ... 155
Ilustración 97: Volcado Hexadecimal de un bloque asignado a la tabla MY_TEMP_TABLE [19] ... 156
Ilustración 98: TimeStamp tabla dual [36] ... 157
Ilustración 99: TimeStampLogMiner [36] ... 157
Ilustración 100: SentenciaSpool [36] ... 158
Ilustración 101: Estructura LogMiner Redo Logs [36] ... 158
12
RESUMEN EJECUTIVO
A partir de los diferentes mecanismos de control que provee Oracle podemos recrear todo tipo de actividades que se hayan realizado en la base de datos, en esta investigación inicialmente mostraremos la motivación y el porque es necesario este trabajo, desde las estadísticas de intrusión hasta las tendencias actuales que demuestran que las bases de datos son el principal objetivo de los atacantes a la hora de buscar información sensible de las corporaciones. Posteriormente en el Capítulo 2 se realiza la toda la revisión de Literatura existente, esta revisión se divide en:
Administración bases de datos
En esta sección se verifica cada una de las tendencias actuales que se presentan con las bases de datos, desde las estadísticas de intrusión hasta políticas y buenas prácticas que se deben tener en cuenta por los DBA´s que son los encargados de la administración de la seguridad. También se muestra cual es el estado actual del manejador de Base de datos Oracle con respecto a otros manejadores y cuáles han sido su fallas y sus aciertos en lo que a temas de seguridad se refiere.
Bases de datos Oracle
En esta sección se explican los conceptos básicos de la arquitectura de las base de datos Orcale, desde los espacios en memoria hasta la arquitectura física y lógica de manejador de bases de datos. También podemos encontrar el primer acercamiento a los diferentes medios de almacenamiento de evidencia y los principales mecanismos de recuperación de información.
Técnicas anti-forenses
En esta sección se presentan las diferentes agrupaciones de técnicas anti-forenses las cuales son:
Destrucción de evidencia
Ocultación de evidencia
Eliminación de fuentes de evidencia
Falsificación de evidencia
13 Dentro de esta sección podemos encontrar 2 clasificaciones de ataques a nivel general la primera se dividió de la siguiente forma:
Ataques de primer orden
Ataques de segundo orden
Inyección lateral
Buffer overflows
La otra Clasificación es la siguiente:
Sql manipulation
Code injection
Function call injection
Buffer overflows
Técnicas forenses en bases de datos Oracle
Se explican las principales fuentes de evidencia, se explica su configuración y sus diferentes formas de análisis. Dentro de las fuentes de evidencia que se encuentran en esta sección podemos ver:
Redo Logs
Archivos TNS Logs
Archivos Trace de Oracle
Datafiles Oracle
AUD$
Caso de estudio
Vemos de manera práctica lo presentado en la sección anterior, mostrando detalladamente el ataque escogido y estudiándolo a la luz de las posibles pruebas y reconstrucción de eventos del ataque.
Recomendaciones para los investigadores forenses en informática en bases de datos
Oracle.
Finalmente en esta sección presentamos las consideraciones que debe poseer un informático forense a la hora de realizar una investigación que implique un sistema gestor de base de datos de Oracle.
14
1
DESCRIPCIÓN GENERAL DEL TRABAJO DE GRADO
1.1 FORMULACIÓN
A medida que los sistemas avanzan y toman protagonismo en un mundo cada vez más exigente y productivo, se perfila de manera cada vez más evidente la necesidad de hacer a los sistemas más seguros, ya que el avance no sólo se presenta en la eficacia y productividad, sino también en la calidad y en la cantidad de los ataques informáticos que aquejan los sistemas actualmente. Ver Anexo 1
Como se puede ver en la Ilustración No. 1 cada día es más notorio que la tendencia es que los atacantes sean cada vez más efectivos y que el conocimiento de los mismos sea cada vez menor. Este asunto es preocupante ya que esta tendencia de los ataques y la facilidad de los mismos es clara y se encuentra en aumento, lo cual tendrá como consecuencia que los eventos de seguridad informática sean cada vez más específicos, eficaces y elaborados.
Es necesario también que los involucrados en la administración de la seguridad de los sistemas de bases de datos no sólo conozcan muy bien sus plataformas sino que además también conozcan las posibles fallas de seguridad que nativamente poseen, ya que si sabemos nuestras debilidades es más sencillo saber dónde investigar e intentar fortalecerlas para que cada vez sean menos los incidentes a los cuales podríamos exponer nuestras corporaciones.
En la actualidad las bases de datos no se escapan de la tendencia anteriormente evidenciada ya que estas son las herramientas de mayor importancia para las corporaciones y la vida cotidiana en general, el comercio web y las transacciones. El constante crecimiento de internet ha hecho que las bases de datos tengan que ser accesibles de manera rápida y eficiente pero también de manera más insegura, por lo cual, lo que antes era accesible por diferentes tipos de capas ahora es accesible casi que de manera inmediata. Indirectamente todos los datos que nosotros suministramos de manera web como nuestros nombres, nuestras relaciones, nuestras contraseñas y todo tipo de información que componga nuestra vida digital, finalmente quedara en un repositorio de datos en alguna parte del mundo, y como si esto fuera poco no solo nuestra información personal se encuentra almacenada en la bases de datos, sino que además, estos sistemas se encargan de administrar un gran porcentaje de la economía mundial. Al ser el lugar donde permanece más tiempo la información y donde se puede encontrar mayor cantidad de esta, los atacantes
15 buscaran la forma de infiltrarse dentro de la base de datos para cometer sus ilícitos. Por todo lo anterior encontramos que la seguridad de las bases de datos es un tema que debe ser estudiado a profundidad y de manera concienzuda, evitando e identificando los posibles tipos de técnicas que los criminales puedan llegar a usar para lograr su objetivo, con el fin de volver mucho más seguros lo repositorios en los cuales la información sensible de la empresa se encuentra [1].
Para este caso estudiaremos en detalle los ataques más comunes y los tipos de técnicas anti-forenses que utilizan los criminales para alterar, ocultar y eliminar las posibles evidencias que puedan quedar de sus actos, sobre las bases de datos Oracle específicamente, ya que Oracle es uno de los manejadores de bases de datos más utilizado a nivel mundial, por lo cual es de esperarse que los atacantes aprenderán y desarrollarán todo tipo de técnicas para evadir los mecanismos de seguridad. Esto hace que el estudio de las técnicas anti-forenses mencionadas que usen los atacantes, sea un estudio necesario para toda la comunidad de informáticos forenses y administradores de bases de datos que serán los encargados de realizar las investigaciones.
Teniendo en cuenta el panorama anteriormente visto, este documento, posee como objetivo principal tratar de dar respuesta a la pregunta: ¿Cómo identificar, investigar y prevenir el uso de técnicas anti forenses en Bases de datos Oracle?
1.2 JUSTIFICACIÓN
Oracle es uno de los manejadores de bases de datos más usados a nivel mundial, esto implica que los investigadores forenses deben estar preparados para enfrentarse a investigaciones que involucren bases de datos Oracle. A medida que estos manejadores van avanzando, también es necesario avanzar en las técnicas y procedimientos usados para realizar una investigación forense que pueda identificar de manera efectiva y eficiente los hechos acontecidos en la escena del crimen, además de los procedimientos usados para realizar el ataque o la intrusión dentro de la base de datos. En la revisión realizada en este trabajo, se identificaron artículos que hablan de ataques específicos, limitados documentos con información sobre métodos para adelantar investigaciones forenses en bases de datos Oracle y muchos menos sobre las posibles técnicas anti-forenses que un atacante podría usar para evitar que sus acciones sean descubiertas por un examinador forense.
La seguridad total es imposible, ya que no existe ningún sistema que no se encuentre en relación con un entorno o con otro sistema bien sea humano o digital. Si tenemos esto como premisa, podemos determinar
16 que la seguridad de un sistema está determinada por la inseguridad a la cual se encuentre expuesto, lo que permite crear políticas y estrategias que incrementan y ayudan a complicar el acceso de los usuarios no permitidos, haciendo de esta manera, sistemas más seguros [2]. Actualmente los atacantes no solo se han enfocado en realizar el ataque sino en, además, hacer todo lo posible para que sea virtualmente imposible recrear los hechos, haciendo que sus huellas sean eliminadas o distorsionadas para no ser atrapados, “Haz difícil que te encuentren e imposible de probar que te encontraron” [2], es la premisa actual de todo atacante, esto ha hecho que las investigaciones sean cada vez más desafiantes y mucho más exigentes para los investigadores forenses.
Al ser las bases de datos una de las herramientas más usuales y que más servicios le presta a los procesos dentro de nuestra sociedad, es necesario identificar y poder recrear los hechos acontecidos dentro de una base de datos en el momento de adelantar una investigación forense, analizándolo todo bajo los principios de las posibles técnicas anti-forenses enunciadas por Harris (Eliminación de la fuente, ocultamiento, borrado y la falsificación de las evidencias Digitales) [3], ya que con esto se podría lograr acotar de manera más precisa cuál fue el rumbo de acción del atacante y de esta manera lograr resultados más exactos y confiables.
Ya que la informática forense tiene como propósito “apoyar el proceso investigativo utilizando la evidencia digital que sustente y verifique las afirmaciones que sobre los hechos delictivos se han materializado en el caso bajo estudio” [4], es completamente válido y además necesario sugerir una práctica o crear una guía metodológica que permita a los investigadores forenses tener una guía que les permita identificar que la evidencia recolectada dentro de la investigación no haya sido modificada o alterada de ninguna manera.
La seguridad de las bases de datos ya no es un tema de apostar a la no ocurrencia de un posible ataque como podría haber sucedido hace 10 años, sino que la pregunta real es ¿cuándo nos van a atacar? [1]. Según un estudio hecho por Xforce de IBM solamente los ataques por SQL injection se han multiplicado de manera vertiginosa en el 2008 y es una tendencia que se encuentra en crecimiento, demostrando así que el problema es real y que es ahora cuando debemos tomar cartas sobre el asunto.
17 Ilustración 1: Promedio de ataques bloqueados por día [1].
Teniendo como base que la seguridad sobre las bases de datos es un tema que debe ser tratado a la mayor brevedad, es necesario identificar quiénes serán los actores que se encargarán de mantener la información que se encuentra en nuestra base de datos segura. Esta respuesta, aunque aparentemente obvia, es fácilmente olvidada y difuminada entre la cantidad de usuarios, desarrolladores y administradores de los sistemas utilizados para el almacenamiento de información.
Este trabajo de grado tiene como objetivo lograr que por medio de la computación anti-forense se pueda aprender a reconocer y entender las limitaciones de seguridad que posee el manejador de bases de datos Oracle, para comprender en materialización de sus vulnerabilidades, las fuentes de información y puntos específicos de análisis que deben ser considerados por los informáticos forenses y así apoyar el análisis de resultados de incidentes sobre este tipo de elemento informático. También se pretende proveer un marco de elementos conceptuales y prácticos acerca de este manejador de bases de datos. Los posibles tipos de ataques que se pueden realizar sobre esta plataforma, además de los diferentes tipos de técnicas utilizados para ocultar y alterar las evidencias, deben ser prioridades en los estudios en el área, para que las investigaciones forenses puedan ser concluyentes y confiables.
En una segunda instancia propondremos una guía metodológica que provea los elementos necesarios para evidenciar el uso de técnicas anti-forenses sobre las bases de datos Oracle.
1.3 OBJETIVO GENERAL
Desarrollar una guía metodológica para un análisis forense sobre bases de datos Oracle, teniendo en cuenta los rastros de las principales técnicas anti-forenses y herramientas de identificación, investigación y prevención disponibles en la actualidad.
18
1.4 OBJETIVOS ESPECÍFICOS
Estudiar la arquitectura de las bases de datos Oracle, identificando los componentes de seguridad y sus posibles brechas.
Realizar un análisis acerca de cuáles son los rastros más significativos y de qué manera se materializan las técnicas anti forenses en las bases de datos Oracle.
Estudiar cómo se adelanta una investigación o análisis forense en una base de datos y especificar los detalles de la misma sobre Oracle.
Identificar y comprender las principales categorías de ataques informáticos dentro de los ambientes de bases de datos Oracle.
Explorar qué tipo de herramientas existen o se utilizan para soportar las investigaciones en Bases de Datos Oracle.
19
2
REVISIÓN DE LITERATURA
2.1 ADMINISTRACIÓN BASES DE DATOS
2.1.1 Estado Actual
Actualmente y aunque parezca completamente incoherente, la administración de la seguridad de bases de datos ha quedado relegada a un segundo plano y en muchas de las corporaciones no la tienen en cuenta, pues no representa un valor agregado en primera instancia para el funcionamiento del negocio. Este tipo de pensamiento ya no es viable en un mundo en el cual la conectividad ha crecido de tal manera que es posible realizar transacciones desde cualquier parte del globo haciendo uso de internet. La mayoría de las bases de datos actualmente se rigen por políticas de facilidad y comodidad más que por las políticas de seguridad [1]. Ver Anexo 2
Tan solo en 2008, las bases de datos fueron los objetivos principales de los atacantes con un 75% de registros de intento de ataques y un 30% de intrusiones exitosas. Esto es entendible ya que las bases de datos son el lugar en el cual la información permanece más tiempo y donde aparentemente no presenta un control más exigente que el que preste el manejador.
La tendencia de las corporaciones a publicar sus servicios de manera web y dar facilidades de interconexión entre los partners, ha dado un rumbo peligroso al manejo de la información, puesto que la mayoría de bases de datos se encuentran atadas a una interfaz web, es necesario usar políticas de seguridad, porque de no ser así sería el escenario perfecto para un atacante [1], [5].
Otros factores que también influyeron dentro de la explosión WEB fueron el comercio electrónico, la facilidad de compra y venta de artículos, y la automatización de las finanzas. Estos fueron eventos de suma importancia para que las bases de datos y las aplicaciones WEB surgieran con gran fuerza pero también con muchos inconvenientes y problemas que representan oportunidades de negocio para los hackers, y dolores de cabeza para los DBA1 y los expertos en seguridad [5].
Aunque los manejadores de bases de datos han incrementado notoriamente su seguridad, hay gran cantidad de componentes que aún no se pueden controlar. Oracle ha publicado 69 alertas de seguridad hasta el momento. Sus parches críticos de actualización y alertas de seguridad, arreglan un alto porcentaje de bugs y posibles brechas que posee la herramienta, Solo hasta el parche 68 los bugs solucionados ascendían a más de 50.
1
20 La seguridad de las bases de datos definitivamente tiene que ser un asunto de los usuarios, de las corporaciones y de los DBA, ya que nadie más que ellos, conoce al detalle las mismas. En noviembre de 2008 ForresterResearch demostró por medio de una gran encuesta, que los DBA dedican menos del 5 % de su tiempo para los temas de seguridad de la base de datos. Los administradores de las bases de datos actualmente se encuentran tan atareados con las tareas de almacenamiento, tunning up, migraciones y copias de seguridad que no le dan el tiempo ni la importancia necesarios, a la administración de las políticas de seguridad, dice el analista de Forrester Noel Yuhanna. [1].
Ilustración 2: Ventajas de hacer las cosas bien [1]
Según un estudio realizado por el grupo Aberdeen, las ventajas que poseen las empresas que hacen una auditoria a sus sistemas de seguridad son notables porque poseen un aumento ostensible en la prevención de incidentes de seguridad informática y por ende un incremento en la productividad de las corporaciones, ya que se disminuyen los tiempos en los cuales los sistemas se encuentran sin servicio. La seguridad de las bases de datos debe ser una tarea de los DBA´s. Las principales tareas que pueden ser desarrolladas por ellos para mantener la confidencialidad de las bases de datos son:
1. Cifrado de las bases de datos: Las bases de datos pueden ser cifradas completamente o parcialmente. Si es cifrada completamente, puede que el rendimiento se reduzca dependiendo del tamaño de la base de datos. En caso de que sea cifrada parcialmente, puede tenerse un cifrado de tablas, de columnas, de filas o hasta de celdas específicamente. Para la toma de decisiones acerca del nivel al cual se debe tener el cifrado de datos, tenemos que tener en cuenta qué aplicaciones dependen de la base de datos, qué impacto podría tener en los procesos empresariales y que medidas habría que tomar para que este impacto sea mínimo.
21 2. Manejo de políticas de contraseñas: Según Alexander Kornbrust esta es la práctica más importante para la administración de seguridad de una base de datos ya que “en mi opinión, este tema es el más importante, porque aunque usted aplique las mejores prácticas en seguridad de bases de datos, son inútiles si alguien se hace de las contraseñas legítimas, todo lo demás es más o menos una pérdida de tiempo”2.
3. Actualizaciones y parches de seguridad: Es importante que los DBA´s mantengan sus bases de datos actualizadas ya que gran parte de los ataques se realizan haciendo uso de la falencia de los parches y actualizaciones de seguridad. Ver Anexo 3
Un estudio realizado por la asociación de usuarios independientes de Oracle demostró que un 26% de los usuarios actualizan sus sistemas 6 meses después de que ha sido liberado un parche de seguridad y que el 11% jamás los actualizan [1].
Aunque los DBMS actuales poseen gran cantidad de mecanismos para la prevención y análisis de incidentes forenses, como lo son la autenticación, la autorización, el control de acceso y otras técnicas un poco más elaboradas como es la auditoria y el monitoreo, solamente el 25 % de las corporaciones hacen uso de estas. [1]
4. Configuración de privilegios: Todos los usuarios deben tener la menor cantidad de permisos de usuario, única y exclusivamente lo necesario para poder realizar sus tareas ya que muchas veces los usuarios tienen más privilegios de los que necesitan y pueden comprometer la seguridad de la información con o sin intención.
Tras revisar brevemente el estado actual de la seguridad en las bases de datos y las acciones al respecto por parte de los administradores de estas, pasaremos a estudiar en más detalle el DBMS Oracle (que es el que concierne directamente a este trabajo), trataremos los conceptos básicos de arquitectura y la manera en que se encuentran organizados los archivos de una base de datos de este tipo, así mismo las estructuras de memoria más importantes y los procesos más relevantes para entender el funcionamiento básico de Oracle y así tener mayor probabilidad de éxito a la hora realizar una investigación forense en este entorno.
2
22
2.2 BASES DE DATOS ORACLE
Hablar de una base de datos segura o hablar del mejor motor de bases de datos es muy sutil si lo vemos desde el punto de vista del conocimiento, pues en la medida en que una persona conoce las capacidades y las debilidades de un motor de bases de datos, aumenta su habilidad para administrarla y por ende su capacidad de garantizar la seguridad de la información contenida en la misma. Entre más características o capacidades posee un motor de bases de datos, mayor se hace el rango de información que un DBA debe cubrir para garantizar la óptima administración de su manejador. El hecho de cómo saber cómo funciona su DBMS permite garantizar, que mientras se cumplan las políticas de seguridad planteadas por los expertos en seguridad, la información almacenada estará más segura y conservara su integridad. [5] Como Oracle es un DBMS con tantas funcionalidades, no es el punto central de este trabajo describirlas y analizarlas todas, pero si debemos estudiar los conceptos básicos antes de poder enfrentarnos adecuadamente a una investigación forense. A continuación se tratan dichos conceptos de manera breve.
2.2.1 Conceptos básicos de Bases de datos Oracle
Oracle es el servidor de bases de datos más popular y es usado en diversas áreas de mercado, esto se debe a que lleva un largo tiempo compitiendo en este sector y desde sus comienzos ofreció un motor de bases de datos relacional que corría en diversos sistemas operativos; y aunque aún lo hace, su entorno preferido parece inclinarse hacia Linux. Con la explosión del comercio electrónico Oracle ganó popularidad como la base de datos escogida para aplicaciones web. Al sacar la base de datos de un entorno controlado de acceso limitado a las máquinas de la empresa y pasarla al entorno web, obtenemos grandes ventajas, pero asimismo la acercamos al atacante y por ende debemos ser mucho más cuidadosos a la hora de administrar la seguridad. Es por esto que es de vital importancia comenzar conociendo las funcionalidades básicas del RDBMS para así poder entender posteriormente, en qué debilidades se basan los atacantes a la hora de planear un crimen en un entorno Oracle. [5]
2.2.2 Arquitectura Oracle
“Un servidor Oracle es el componente que permite una administración y desarrollo de bases de datos. Tiene tres posibilidades de ejecución [6]:
Local o basada en host. El servidor se ejecuta en la misma máquina en la que se conectan los clientes. La versión personal de Oracle produce servidores de este tipo.
23 Cliente-Servidor. Enfoque más típico. El servidor reside en un ordenador distinto respecto al que
los usuarios van a usar para conectarse a la base de datos.
Cliente-Servidor de Aplicaciones-Servidor. Los usuarios acceden a un servidor de aplicaciones (Oracle Application Server) que, a su vez, accede al servidor Oracle. Los tres elementos (cliente, servidor de aplicaciones, servidor Oracle) pueden estar en tres máquinas distintas.
Elementos del servidor Oracle
El servidor Oracle está formado por dos elementos:
La instancia de la base de datos
“Consta de datos (estructuras de memoria) y de procesos en memoria (procesos background) necesarios para dar servicio a los usuarios de la base de datos. Puede haber más de una instancia si se distribuye la base de datos en más de una máquina. Cada instancia abre una y sólo una base de datos” [6].
Ficheros en disco.
Representan la base de datos en sí. Se dividen en: [6]:
Estructuras lógicas: Tablespaces, objetos del esquema de usuario.
Estructuras físicas: Los ficheros de datos almacenados en disco. Los ficheros de datos (asociados a los tablespaces), los ficheros redo log y los ficheros de control.
Conexiones
Para establecer una sesión con la base de datos, el usuario necesita conectarse con la instancia de la base de datos. Normalmente esto significa utilizar una herramienta cliente como SQL*Plus o ejecutar una aplicación de desarrollo de bases de datos (como Oracle Forms); entonces se ejecuta un proceso de usuario [6].
Cuando esto ocurre, en el servidor se establece un proceso de servidor. Este proceso es el encargado de comunicar al usuario con la instancia Oracle en nombre del proceso de usuario. Cada vez que el usuario ejecuta instrucciones SQL, éstas son transmitidas a la instancia Oracle por el proceso servidor [6].
24 Cada sesión es una conexión de un usuario con el servidor Oracle. Un usuario puede establecer múltiples sesiones (si se conecta desde diferentes herramientas y máquinas) [6].
Estructura de las bases de datos Oracle
Desde el punto de vista de Oracle, una base de datos es una colección de datos tratados como una única unidad. Una base de datos Oracle contiene tres tipos de ficheros [6]:
Archivos de datos. Contiene los datos actuales de la base de datos así como el diccionario de datos.
Archivos rehacer (Redo Logs). Almacenan datos recuperables en caso de error grave. Archivos de control. Necesarios para mantener la integridad de la base de datos. Archivos de parámetros. Que definen algunas características de una instancia Oracle. Archivos de contraseñas. Que sirven para autentificar a los usuarios.
Copias de archivos rehacer. Utilizadas para la recuperación de datos.
Instancia de la base de datos Oracle
La instancia de la base de datos es uno de los dos elementos de cualquier base de datos Oracle. Sirve para gestionar la información de la base de datos y proporcionar servicio a los usuarios que acceden a la misma [6].
Está compuesta de:
Estructuras en memoria. Procesos en segundo plano Estructuras en memoria
SGA
Es la abreviatura de System Global Area, Área Global de Sistema. Está situada al inicio de los datos de la instancia y contiene los datos e información de control de la instancia [6].
25 Shared pool, fondo común compartido. Almacena las últimas instrucciones SQL y PL/SQL
ejecutadas. Posee dos estructuras internas:
o Caché de instrucciones (Library cache). Almacena las últimas instrucciones SQL y PL/SQL ejecutadas. Administra los datos mediante algoritmo LRU.
o Caché del diccionario de datos. Almacena las últimas definiciones de la base de datos utilizadas (tablas, índices, privilegios, usuarios,..etc.). Cada vez que una instrucción utiliza un nombre de la base de datos (tabla, índice,...) se comprueba en el diccionario de datos y se almacena en este caché. De este modo la siguiente vez no hace falta acceder al diccionario de datos real.
Caché buffer de la base de datos. Almacena los últimos bloques de datos accedidos por los usuarios.
Buffer de archivo rehacer. Almacena los últimos cambios realizados a los bloques de datos de la base de datos.
Large pool. Opcional. Se utiliza como memoria de sesión y para realizar operaciones de backup. Java pool. Opcional. Se utiliza como caché de los comandos Java [6].
PGA
Zona global de los programas (Program Global Area). En ella se almacenan los datos correspondientes a un proceso (sólo un proceso puede utilizar esta área). Incluye [6]:
Áreas de ordenamiento. Para acelerar las tareas de ordenamiento de datos. Información de sesión. Usuario, privilegios, etc.
Estado del cursor. Tareas SQL actualmente en ejecución. Espacio de pila. Variables y otros datos.
En Oracle los procesos pueden ser de estos tipos [6]:
26 Proceso de servidor. Hacen de enlace entre los procesos de usuarios y el servidor Oracle. Se utilizan como manejadores de los procesos de usuario. Los comandos de usuario se envían a estos procesos que se encargan de solicitar peticiones a la base de datos mediante el interfaz de programas de Oracle (OPI, Oracle Program Interface).
Procesos en segundo plano (background). Cada instancia de Oracle arranca una serie de procesos background. Los procesos obligatorios son [6]:
DBWR (DataBaseWRiter). Proceso encargado de escribir en los ficheros de datos los buffers más antiguos de la memoria, para que la base de datos vaya almacenando los cambios.
LGWR (LoGWRiter). Escribe los datos a los ficheros rehacer (redo) desde la caché de archivos rehacer.
CKPT. Actualiza todas las cabeceras de los ficheros de datos para que aparezca la nueva disposición de datos. Esto ocurre cuando se genera un punto de comprobación.
SMON (System MONitor). Permite recuperar la instancia de la base de datos en caso de caída fatal (cuando el sistema falla por ejemplo). Cuando se reinicia de nuevo la instancia de la base de datos.
PMON (ProcessMONitor). Es el encargado de gestionar adecuadamente los procesos que fallan. Ante caídas de procesos, PMON se encarga de restaurar los datos adecuadamente.
SQL *Net Listener. Es el encargado de encaminar por una red solicitudes de un cliente a un servidor de base de datos Oracle. Este procesoestá tanto en el cliente como en el servidor. Puede encaminar solicitudes que se dirigen a varias instancias.”
Oracle provee funcionalidades para casi todos los gustos y necesidades, pero por cada necesidad que satisface también genera una nueva oportunidad para el atacante. “El código detrás del RDBMS ha sido sujeto de varias sobrecargas y otros problemas de seguridad, como PL/SQL Injection en paquetes y procedimientos por defecto, que han requerido parches de actualización en el pasado” [5] [7].
Asumiendo que no vamos a ser atacados podríamos dedicarnos a disfrutar de las grandes funcionalidades que provee Oracle, pero seamos realistas, hoy en día casi que podemos tener la certeza de que teniendo
27 nuestra base de datos en un entorno web, es decir, más cerca del atacante, muy seguramente esta va a ser atacada, y por eso para poder defenderla comenzamos por entender la arquitectura web que maneja Oracle. “La pregunta hoy en día no es ¿Voy a ser atacado?, sino ¿Cuándo y cómo voy a ser atacado?” [5].
Para entender el funcionamiento de una base de datos Oracle se hace importante estudiar: la disposición física de la base de datos, los procesos y la manera en que estos interactúan con la red, la autenticación y autorización, y finalmente la disposición lógica [5].
Procesos Oracle y Oracle en la Red
El elemento más crucial de interacción con la red posiblemente sea el TNS Listener. El TNS Listener Oracle
El TNS listener es el centro de actividad de todas las comunicaciones en Oracle, sus siglas hacen referencia a “Transparent Network Substrate” que es el protocolo usado para la comunicación entre cliente y servidor. Cuando un servidor de base de datos arranca por primera vez, este se registra con el TNS Listener usando el comando service_register_NSGR, esto le permite al TNS Listener saber que la base de datos está preparada para recibir conexiones [5] [7].
Después de hacer una revisión sobre los conceptos básicos del DBMS Oracle podemos pasar a revisar en qué consisten las técnicas anti forenses, cómo se clasifican, cuáles son las principales técnicas usadas por los atacantes para cubrir sus crímenes y posteriormente relacionar los conceptos tratados en este capítulo con dichas técnicas para poder definir las principales fuentes de evidencia en Oracle, es decir, en dónde debe buscar un investigador forense los rastros de ataques a la base de datos, en qué debe fijarse, cómo debe buscar y qué herramientas se sugiere usar.
2.3 TECNICAS ANTI-FORENSES
“Nadie puede diseñar un sistema, que alguien más no pueda comprometer o vulnerar”. [4]
Las técnicas anti forenses han existido desde el mismo momento en que nacieron las técnicas de investigación y los procesos puntuales de recolección de evidencias. Estas surgieron como la necesidad de evitar que las pruebas de un crimen sean factores determinantes a la hora de demostrar el grado de implicación de un sospechoso dentro de un crimen. Por esta razón los criminales alteran, borran, evitan y falsifican las evidencias para que de esta manera los resultados de las investigaciones no arrojen a los
28 criminales como culpables y queden sus fechorías impunes, ya que las pruebas no fueron lo suficientemente contundentes como para demostrar su culpabilidad.
Por esta razón es necesario estudiar de manera exhaustiva cuántas y cuáles son las posibles técnicas que los criminales puedan llegar a usar para alterar el curso de una investigación. En esta sección hablaremos de las diferentes clasificaciones de las técnicas anti-forenses y el porqué es necesario tenerlas en cuenta a la hora de realizar una investigación.
2.3.1 Definición
Existen gran cantidad de aproximaciones hacia la definición de técnica anti forense, pero solamente hasta la publicación de Arriving at an forensicsconsensus: Examining how to define and control the anti-forensics problem de Ryan Harris se llegó a una estandarización de los principios básicos que se deben tener en cuenta, para los expertos en seguridad y específicamente en las investigaciones forenses. [3]
Según Ryan Harris “las técnicas anti forenses comprenden cualquier intento por comprometer la disponibilidad o usabilidad de la evidencia para el proceso forense”. De modo que una técnica anti-forense es todo aquello que pueda comprometer la disponibilidad de la evidencia incluyendo evitar que la evidencia se genere, esconder a la evidencia existente o manipular la evidencia para que no esté al alcance del investigador. La usabilidad se puede comprometer por obstrucción de la evidencia en si misma o destruyendo su integridad. Entendiendo evidencia como "cualquier información que, sujeta a una intervención humana u otra semejante, ha sido extraída de un medio informático". [3] [4]
Existen tres tipos de evidencia digital
Aquellos registros que se encuentren almacenados en el equipo de tecnología informática como lo son los correos electrónicos archivos de aplicaciones ofimáticas e imágenes.
Registros generados por los equipos de tecnología informática (registros de auditoría, registros de transacciones, registros de eventos, etc.).
Registros que parcialmente han sido generados y almacenados en los equipos de tecnología informática. (hojas de cálculo financieras, consultas especializadas en bases de datos, vistas parciales de datos, etc.). [4]
29 Según Harris existen cuatro clases fundamentales de técnicas anti-forenses, las cuales son:
Destrucción de evidencia Ocultación de evidencia
Eliminación de fuentes de evidencia
Falsificación de evidencia [3]2.3.2 Objetivos
Los objetivos de las técnicas anti forenses- según GARFINKEL: Limitar la detección de un evento que haya ocurrido. Distorsionar la información residente en el sitio.
Incrementar el tiempo requerido para la investigación del caso.
Generar dudas en el informe forense o en el testimonio que se presente. Engañar y limitar la operación de las herramientas forenses informáticas.
Diseñar y ejecutar un ataque contra el investigador forense que realiza la pericia. Eliminar los rastros que pudiesen haber quedado luego de los hechos investigados. [8]
2.3.3 Destrucción de evidencia
La evidencia puede ser destruida para prevenir que sea encontrada o para reducir su usabilidad en caso de que sea encontrada. Como las acciones de destrucción trabajan sobre evidencia existente, el proceso de destrucción en sí puede generar nueva evidencia. Por ejemplo, sobrescribir un archivo obstruye la evidencia en el archivo pero la aplicación que se usa para sobrescribirlo puede crear nueva evidencia. La destrucción dentro de las bases de datos puede manejarse de diferentes maneras, entre ellas se encuentra el borrado de los Logs que genera el sistema, que permiten realizar la auditoria de los eventos del sistema como qué acciones se realizaron, quiénes las realizaron y en qué intervalo de tiempo las realizaron. [3]
2.3.4 Ocultación de evidencia
La evidencia no es destruida o manipulada, sin embargo, es escondida de la vista casual para reducir su disponibilidad para el investigador. Muchas veces encontrar la evidencia escondida no es necesario sino que el hecho de hallar herramientas de ocultación puede ser evidencia en sí mismo. Al esconder evidencia los archivos pueden ser colocados en lugares poco comunes para explotar las limitaciones de las
30 herramientas de software forense o renombrado para tomar ventaja de los puntos ciegos inherentes del investigador. [3]
2.3.5 Eliminación de fuentes de evidencia
La eliminación de las fuentes es todo acto que impida que una evidencia pueda ser generada. Por ejemplo, en bases de datos la eliminación de los Logs, posibles fuentes de evidencia, pueden ser destruidos para asegurarse de que la evidencia nunca sea generada. La ausencia total de evidencia puede ser indicio de un crimen bien planeado. Es claro que en el momento en que se elimina una fuente, las pruebas que esta posiblemente albergaría ya no se generarán, pero este evento también puede considerarse como evidencia del uso de técnicas anti-forenses [3].
2.3.6 Falsificación de evidencia
La evidencia puede falsificarse para redirigir la culpabilidad, para explotar debilidades del proceso y de las herramientas o bien para corromper la validez de la evidencia de manera que no sea útil para el investigador. Falsificar evidencia puede ser crear evidencia que parece ser algo que no es, esto puede ser crear evidencia que funciona como ataque a las herramientas o al proceso forense en sí. Algunas de las categorías anteriores pueden necesitarse para conseguir el objetivo final de esta. Un ejemplo de esto puede ser usar las cuentas de otras personas para realizar ataques y así desviar la culpa del real perpetrador. [3]Ver Anexo 5
.
31
2.4 ATAQUES EN ORACLE
En lo que a ataques a bases de datos Oracle respecta, podemos encontrar varias categorías, pero sin duda la mayoría van a estar relacionadas directa o indirectamente con SQL Injection y especialmente con modificaciones y combinaciones de este tipo de ataque. Comenzaremos entonces por estudiarlo desde lo particular y simple para luego abordar las combinaciones y categorías de ataques más complejos.
2.4.1 SQL INJECTION
El “SQL Injection” es un ataque simple y conocido, pero no por eso deja de representar una amenaza para cualquier base de datos, trátese de Oracle, MySQL o cualquier otra. De hecho, contrario a lo que se pensaría al hablar de un ataque del cual se tiene tanta información en la actualidad, tras varias encuestas y estudios realizados en el año 2010 por OWASP (Open Web Application Security Project) se determinó que entre las mayores brechas de seguridad que terminan comprometiendo datos, los ataques de este tipo predominan con un 60% del total si contamos los casos en que este ataque es combinado con malware [9]. Ver Anexo 6
“Muchos desarrolladores de aplicaciones subestiman el riesgo de ataques SQL Injection a aplicaciones web que usen Oracle como base de datos de respaldo final” [10], aunque Oracle represente una alternativa muy confiable, ningún desarrollador o analista de seguridad debe bajar sus defensas frente a los ataques de SQL Injection. Debemos percatarnos de que por su amplia divulgación y su alto porcentaje de efectividad, la sofisticación de estos ataques se encuentra en aumento y así mismo deberían aumentar los esfuerzos por detectar vulnerabilidades, corregir fallas y proteger las aplicaciones e interfaces con el fin de garantizar la seguridad e integridad de la información [9]. Entre el 2007 y el 2010 los ataques de inyección, entre los cuales encontramos el SQL Injection como el principal representante, pasaron del segundo lugar al primero en el Top 10 presentado por OWASP anualmente en el cual se clasifican los principales ataques y vulnerabilidades en aplicaciones web. En el segundo lugar actualmente se encuentra el Cross Site Scripting (XSS), que como veremos más adelante también representa una amenaza para Oracle [11] [12].
OWASP califica los ataques de inyección de fácil uso, frecuencia común, detectabilidad promedio e impacto severo; pueden ser realizados por cualquier persona que pueda enviar datos no confiables al sistema, incluyendo usuarios externos, usuarios internos, y administradores del sistema. Entre las principales consecuencias podemos encontrar perdida de información, falta de responsabilidad,
32 denegación de servicios y en algunos casos pueden llevar a la toma de posesión total del servidor por parte del atacante [11].
Los ataques de SQL Injection se aprovechan principalmente, de las malas prácticas de desarrollo de aplicaciones, explotando la falta de un manejo adecuado de la entrada de datos por parte del usuario que posteriormente serán usados en sentencias SQL [10]. Los atacantes engañan al motor de la base de datos para que este ejecute comandos no deseados, suministrando cadenas de texto hechas especialmente para este fin, consiguiendo así acceso no autorizado a la base de datos para visualizar o manipular información restringida [12].
La mayoría de estos ataques se presentan en interfaces web, por el hecho de que en una aplicación web el atacante puede realizar ataques de SQL Injection sin ninguna autenticación en la base de datos o la aplicación. Dicho esto, es claro que estas representan una vulnerabilidad para las organizaciones y por ende debe realizarse un análisis cuidadoso del beneficio de proveer acceso web frente al costo de la posible pérdida de información [10] [12].
Las técnicas de SQL Injection pueden variar, pero todas explotan una misma vulnerabilidad: “Cadenas de texto validadas o no validadas que son concatenadas en una sentencia SQL dinámica, e interpretadas como código por el motor SQL” [12].
Oracle se ha manejado bien frente a los ataques de SQL Injection por varias características entre las cuales es de destacar el uso de bind arguments(variables de enlace)que si bien fueron diseñadas principalmente para mejorar el desempeño, proveen también una fuerte protección contra dichos ataques cuando se programa SQL dinámico pues obligan a la base de datos a utilizar exclusivamente el valor de la variable y no interpretar su contenido de ningún modo [12] [10] [13]. Aunque Oracle puede proveer mayor protección frente a estas técnicas, que otras bases de datos, aplicaciones sin las defensas apropiadas pueden ser vulnerables [10].
Para inmunizar cualquier código contra ataques SQL Injection, deben usarse bind arguments, bien sea automáticamente en SQL estático o explícitamente en SQL dinámico, y adicionalmente validar y desinfectar cada entrada concatenada a SQL dinámico. La validación comprueba que la entrada cumpla ciertos criterios (Ej. que no contenga comillas simples independientes) y la desinfección modifica la entrada para asegurar que es válida (Ej. doblar las comillas simples) [12]. Oracle provee un paquete PL/SQL llamado DBMS_ASSERT, el cual contiene funciones que permiten validar y desinfectar cadenas de entrada [12].
33 En el Anexo 26 se presenta un diagrama de flujo que expone los pasos para medir la vulnerabilidad de cualquier código SQL.
Para detalles más específicos sobre cómo protegerse frente a técnicas de SQL Injection al programar en PL/SQL, se recomienda revisar el tutorial provisto por Oracle titulado “SQL Injection Tutorial” el cual es gratuito, descargable y contiene lecciones por capítulos con evaluaciones interactivas al final de capa sección [12].
2.4.2 TIPOS DE ATAQUES SQL INJECTION
Tras revisar varias categorizaciones de los ataques de inyección se decidió unir las dos que consideramos más relevantes y acertadas, relacionándolas entre sí como se expondrá a continuación. Los ataques de inyección son comúnmente divididos en:
2.4.2.1 ATAQUES DE PRIMER ORDEN
El atacante simplemente ingresa una cadena de texto maliciosa y provoca que el código modificado sea ejecutado inmediatamente. El ejemplo más común consiste en modificar la cláusula WHERE de una consulta de autenticación para que siempre retorne verdadero [12].
2.4.2.2 ATAQUES DE SEGUNDO ORDEN
El atacante inyecta en datos almacenados permanentemente que son considerados una fuente confiable (Ej. una fila de una tabla) y posteriormente otra actividad ejecuta el ataque indirectamente [12]. Este tipo de ataques requieren un mayor conocimiento de la aplicación objetivo y aprovechan la naturaleza stateless de muchas aplicaciones web que acostumbran pasar información entre páginas almacenando valores en la base de datos, generando así una vulnerabilidad [10].
2.4.2.3 INYECCIÓN LATERAL
El atacante puede explotar procedimientos PL/SQL que ni siquiera reciben entrada de usuario. Contrario a lo que se puede pensar, cuando una variable cuyo tipo es de fecha o numérico, y está concatenada en el texto de una sentencia SQL, puede existir una vulnerabilidad [12].
Adicionalmente podemos dividir los ataques de SQL Injection a Oracle en las siguientes categorías [10]:
1. SQL Manipulation
2. CodeInjection
34
4. Buffer Overflows
Las dos primeras categorías pueden incluirse dentro de los ataques de primer orden mencionados anteriormente, son las más comunes, y se aplican a todos los tipos de bases de datos. Aunque la segunda sea menos común en Oracle que en otras bases de datos, por el hecho de no soportar peticiones de múltiples sentencias SQL por base de datos, se pueden presentar casos de Code Injection en Oracle cuando se trabaja con SQL dinámico en PL/SQL [10] [12] [13].
Las últimas dos categorías contienen ataques más específicos a Oracle, son menos comunes que las primeras, y por ende se encuentra menos documentación disponible sobre estas, lo cual incrementa su aparición como vulnerabilidades en la mayoría de auditorías de seguridad realizadas a aplicaciones web [10]. A continuación se expone con mayor detalle cada uno de los tipos de Inyección en Oracle, pero se hará énfasis en los últimos dos tipos por las razones mencionadas anteriormente.
2.4.3 SQL MANIPULATION
SQL Manipulation representa el tipo más común de ataque de SQL Injection. El atacante intenta modificar la sentencia SQL adicionando elementos a la cláusula WHERE o extendiendo la consulta con operadores como UNION, INTERSECT o MINUS [10]. El ejemplo clásico de este ataque se presenta en la autenticación de usuarios de una aplicación donde se ejecuta una consulta como la siguiente:
SELECT * FROM usuarios
WHERE nombreusuario= „miusuario‟ and contraseña = „micontraseña‟
El atacante podría manipular la sentencia SQL con una consulta como esta: SELECT * FROM usuarios
WHERE nombreusuario= „miusuario‟ and contraseña = „micontraseña‟ or „1‟ = „1‟
Si no se tienen las medidas adecuadas de verificación en la aplicación, la consulta anterior retornaría verdadero para todas las filas basándose en la precedencia de operadores [10].
También suele ser común el uso del operador UNION para retornar filas de otra tabla. Por ejemplo se puede intentar listar todos los productos disponibles de una tienda y usando este operador hacer que se listen también todos los usuarios de la base de datos [10].
35
2.4.4 CODE INJECTION
Este ataque consiste en inyectar comandos o sentencias dentro de una sentencia SQL. Este tipo de ataque no es tan común en Oracle como en otras bases de datos debido a que Oracle no proporciona ninguna sentencia correspondiente a la sentencia EXECUTE (SQL Server), ni permite la solicitud de ejecución de varias sentencias por base de datos [10].
Sin embargo algunas API‟s permiten ejecutar dinámicamente bloques anónimos de PL/SQL los cuales son vulnerables ante un ataque de Code Injection.
Por ejemplo, un atacante puede manipular el bloque PL/SQL, que ejecuta un proceso almacenado de la base de datos que cifra y almacena una contraseña de usuario [10]:
BEGIN ENCRYPT PASSWORD ('Javeriana', 'micontraseña'); END; Y convertirlo en el siguiente [10]:
BEGIN ENCRYPT PASSWORD ('Javeriana', 'micontraseña'); DELETE FROM users WHERE upper (username) = upper ('admin'); END;
2.4.5 FUNCTION CALL INJECTION
Los ataques de FunctionCallInjection insertan funciones Oracle o funciones tradicionales dentro de sentencias SQL vulnerables con el fin de invocar llamadas de sistema operativo o manipular información almacenada en la base de datos [10].
Oracle permite ejecutar funciones como parte de sentencias SQL y adicionalmente provee más de 1000 funciones contenidas en aproximadamente 175 paquetes, de las cuales sólo algunas pocas son útiles para ataques de SQL Injection. Cualquier función tradicional o que esté almacenada en un paquete tradicional puede ser invocada desde una sentencia SQL [10].
Principalmente, sólo las funciones ejecutadas dentro de sentencias INSERT, UPDATE o DELETE pueden modificar información almacenada en la base de datos. Usando las funciones estándar de Oracle, un atacante puede enviar información a otras máquinas o ejecutar nuevos ataques desde el servidor de la base de datos. Muchas aplicaciones basadas en Oracle incluyen paquetes que pueden ser explotados por un atacante. Estos pueden contener funciones que cambien contraseñas o realicen actividades sensibles de transacciones [10].
36 El principal asunto a tener en cuenta cuando tratamos Function Call Injection, es que cualquier sentencia SQL generada dinámicamente es vulnerable, incluso las sentencias más sencillas. A continuación se mostrara un ejemplo que corrobora lo recientemente afirmado [10]:
SELECT TRANSLATE(„entradaDeUsuario‟,
„0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ‟, „0123456789‟)
FROM dual;
Esta sentencia que hace uso de la función TRANSLATE de la base de datos, no es vulnerable a otros tipos de inyección pero puede ser manipulada de la siguiente manera para realizar un ataque de Function Call Injection [10]:
SELECT TRANSLATE ('' || UTL_HTTP.REQUEST('http://192.168.1.1/') || '', '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ', '0123456789')
FROM dual;
La anterior sentencia hace un REQUEST a una página de un servidor web. El atacante podría manipular dicha sentencia para recopilar información de la base de datos y enviarla a al servidor web especificado en la URL, o bien, si la base de datos está tras un firewall, podría atacar otros servidores en la red interna [10].
Las funciones tradicionales también pueden ser ejecutadas en este tipo de ataques, particularmente las que se encuentran marcadas como “PRAGMA TRANSACTION”, pues pueden ser ejecutadas bajo cualquier circunstancia especial, y por estar marcadas de esta manera pueden escribir en la base de datos incluso dentro de una sentencia SELECT [10].
Un claro ejemplo del uso de este ataque fue presentado el presente año por David Litchfield en la conferencia de seguridad “BlackHat DC 2010”, en su ataque, Litchfield combina Lateral Injection, Function Call Injection y PL/SQL Injection para aprovechar la implementación implícita de Java en Oracle, que ha sido denominada Aurora, y así tomar control total de la base de datos [14] [15].
El ataque comienza obteniendo privilegios arbitrarios de Java desde una sesión con pocos privilegios, haciendo uso del paquete DBMS_JVM_EXP_PERMS, el cual usualmente permite importar o exportar las políticas de java entre distintos servidores de la base de datos. Este paquete, puede ser ejecutado por el rol
37 PUBLIC, es decir, por cualquier usuario común e incluye un procedimiento llamado IMPORT_JVM_PERMS que recibe como argumento una Java Policy. Un atacante puede crear su propia Policy y enviarla como argumento a esta función, y al hacer esto, como el procedimiento se ejecuta con privilegios de SYS, la Policy creada por el atacante es adicionada a la tabla JAVA$POLICY$, permitiéndole al atacante concederse a sí mismo permisos Java arbitrarios como por ejemplo el permiso Java execute para todos los archivos [14] [15].
2.4.6 BUFFER OVERFLOWS
Varias funciones estándar de Oracle son susceptibles a Buffer Overflows que pueden ser aprovechados mediante el uso de SQL Injection sobre bases de datos que no tengan las actualizaciones y parches de seguridad adecuados. Algunos de los paquetes y funciones estándar de la base de datos que son vulnerables sonTZ_OFFSET, TO_TIMESTAMP_TZ, AND BFILENAME, FROM_TZ, NUMTOYMINTERVAL, y NUMTODSINTERVAL [10].
Un ataque de Buffer Overflow es ejecutado usando los métodos de Function Injection descritos anteriormente para llamar las funciones vulnerables mencionadas en el párrafo anterior. Haciendo uso de Buffer Overflowsse puede llegar a obtener acceso remoto al sistema operativo. Adicionalmente, algunas aplicaciones y servidores web no manejan adecuadamente la pérdida de conexión de la base de datos debida a desbordamientos, haciendo de este tipo de ataques un potencial ataque de DoS3 que será efectivo por ejemplo si un proceso web se queda colgado esperando a que la conexión con un cliente termine [10]. Tras categorizar los principales tipos de ataques a bases de datos Oracle y con la ayuda de las secciones anteriores, pasaremos a revisar las técnicas forenses que pueden ser usadas cuando se investiga un entorno Oracle en busca de rastros de los ataques expuestos anteriormente.
2.5 TÉCNICAS FORENSES EN BASES DE DATOS ORACLE
Entender los conceptos básicos de Oracle y los principales tipos de ataques expuestos en secciones anteriores nos permite comprender con mayor facilidad dónde están situadas las principales fuentes de evidencia en Oracle y de qué manera se manifiestan los diversos tipos de ataques en las diversas estructuras de la base de datos. Para hacer más claros, específicos y repetibles los análisis expuestos a continuación, se hace esencial definir un entorno y posteriormente aventurarse a explorar con detenimiento las estructuras de la base de datos.
3
