1 cis1010sd03 estado del arte de la aplicación de técnicas
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
BOGOTÁ D.C.
1
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
BOGOTÁ D.C.
2
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
3
Nota de Aceptación
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
______________________________________________________
Jeimy José Cano Martínez
Director del Proyecto
________________________________________
José Luis Lara
________________________________________
Julio Carreño
4
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”
5
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
2.2
Estado Actual .......................................................................................................................19
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
2.5.3
HERRAMIENTAS ÚTILES EN UN ENTORNO ORACLE ..............................................80
6
2.6
CASO DE ESTUDIO ...................................................................................................................86
2.6.1
2.7
EVIDENCIA DE LAS ACCIONES DEL ATACANTE .....................................................86
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
7
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
5.48
6
Recaudo de la información .................................................................................................160
Anexo 48 ....................................................................................................................................164
TRABAJOS CITADOS ...................................................................................................... 166
8
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
Ilustración 44: Sentencia para ejecutar comandos de sistema operativo ....................................................120
9
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
Ilustración 91: Encabezado de un bloque en un archivo Oracle Redo Log................................................152
10
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
Ilustración 102: Verificación Serial Commit Number [36] ........................................................................159
11
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
Ataques en Oracle
12
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.
13
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
14
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
15
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.
16
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.
17
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.
18
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
DBA: Administrador de Bases de Datos (DatabaseAdministrator)
19
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.
20
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
Traducción libre del autor.
21
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.
22
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].
23
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].
Está formada por las siguientes estructuras Ver Anexo 5.4 :
24
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]:
Proceso de usuario. Lanzado por el usuario para pedir interacción con la base de datos.
25
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
26
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
27
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 anti-forensicsconsensus: Examining how to define and control the antiforensics 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 antiforense 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]
28
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
29
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.
30
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,
31
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].
32
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
3. FunctionCallInjection
33
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].
34
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].
35
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
36
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 DoS 3 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
DoS: Denegación de servicio (Denial Of Service)
37
2.5.1 ENTORNO
Todos los análisis y conclusiones que serán expuestos en las siguientes secciones se llevaran a cabo en una
instalación de Oracle 11g release 1 recién instalada, es decir, sin haber aplicado parches de seguridad,
corriendo en un servidor Windows server 2008 Enterprise. Definir claramente el entorno de análisis se
hace importante pues las conclusiones que se expondrán posteriormente pueden no aplicar para otras
versiones de Oracle corriendo en otros sistemas operativos [16].
Se trabajara sobre una versión sin parches de la base de datos pues algunos de dichos parches corrigen
vulnerabilidades expuestas en este trabajo, y con la intención de reforzar la importancia tanto de la
instalación de parches como de la adecuada administración de la base de datos en general, nos
enfocaremos en el estudio de las vulnerabilidades de una instancia de la base de datos recién instalada.
2.5.2 PRINCIPALES FUENTES DE EVIDENCIA EN ORACLE
Cuando se habla de análisis forense en bases de datos Oracle se hace imposible no mencionar a David
Litchfield, considerando como uno de los pioneros y mayores promotores tanto de la investigación de
vulnerabilidades, como del respectivo análisis de rastros que quedan en la etapa posterior a un ataque a
una base de datos Oracle. Por esto decidimos retomar la clasificación propuesta por dicho investigador en
el 2007 sobre las principales fuentes de evidencia [17]:
Redo Logs
Archivos TNS Logs
Archivos Trace de Oracle
Datafiles Oracle
Apache Logs(Servidor de aplicación Oracle)
A continuación, examinaremos en detalle las cuatro primeras fuentes mencionadas, explicando que tipos
de evidencia se pueden encontrar en cada una y que estrategias y/o herramientas podemos utilizar cuando
llevamos a cabo una investigación forense sobre una base de datos Oracle. Dado que el foco de la
investigación son los rastros propios del manejador, el análisis de los rastros de los logs de apache estará
fuera del alcance de este documento.
2.5.2.1 REDO LOGS
38
El RDBMS de Oracle fue pensado para proveer poder de recuperación y por esto mismo es que cada vez
que ocurre un evento en la base de datos, por ejemplo la creación de una tabla, se guarda un registro
exacto en un log de manera que si es necesario en caso de un fallo, cualquier cambio pueda ser realizado
de nuevo. Esto tiene un valor grandísimo para un investigador forense pues dependiendo de la
configuración de la base de datos, cualquier acción ejercida por un atacante que haya cambiado el estado
de la base de datos debe quedar registrada en los Logs [16].
2.5.2.1.1 ¿Cómo operan los Redo Logs?
Cada cambio a la base de datos genera un registro del evento conocido como “redo entry” y es escrito en
los buffers de la base de datos en la memoria SGA del servidor. Cada 3 segundos o cuando sucede un
COMMIT, el LGWR descarga estos buffers a un conjunto de archivos en disco conocidos como “The
Online Redo Log” [16].
Al instalar Oracle y crear la base de datos, se configura cuántos grupos de archivos de redo log se tendrán,
cuántos archivos contendrá cada grupo, y qué tamaño se le asignara a cada uno de dichos archivos. En
nuestro caso escogimos la opción por defecto que es de un grupo de Redo Logs conformado por 3 archivos
redo log cada uno con un tamaño de 51200K. A continuación se muestra una captura de pantalla del
proceso de configuración de los Redo Logs y otros archivos de la base de datos durante la creación de la
base de datos. Ver Anexo 7
Cuando uno de los archivos de este conjunto se llena, el servidor cambia al siguiente archivo. Cuando
todos los archivos se llenan, el servidor retorna al primero y comienza a sobrescribir entradas anteriores.
Para evitar perder información que puede ser requerida para recuperar la base de datos, Oracle tiene un
proceso de Archivo en segundo plano (ARCn) que guarda los archivos de Redo Logs cuando se llenan. Sin
embargo es importante notar que no todas las bases de datos tienen la función de archivado activada,
dependiendo de si un servidor tiene esta función activada se dice que trabaja en modo ARCHIVELOG o
NONARCHIVELOG. Este punto es muy importante para el examinador forense pues si esta función no
está activada, la evidencia de ataques puede ser sobrescrita rápidamente [16].
Como la cantidad de consultas que modifiquen el estado de la base de datos tiene un efecto en la rapidez
con que se sobrescriba evidencia, un atacante puede usar esto como ventaja. Se puede revisar si la función
de archivado esta activa mirando el valor del parámetro LOG_ARCHIVE_START en el archivo de
39
parámetros de inicio del servidor o ejecutando el siguiente comando SQL durante la investigación de
respuesta en vivo [16]:
SELECT VALUE FROM V$PARAMETER WHERE NAME = „log_archive_start‟;
2.5.2.1.2 ¿Por qué no simplemente usar “ALTER SYSTEM DUMP LOG FILE”?
El archivo binario de Redo Log puede descargarse a un archivo ASCII legible en cualquier editor de texto
usando este comando, aunque parezca que esto permite realizar un análisis sin necesidad de interpretar la
versión binaria esto es incorrecto pues el analista forense no siempre tiene acceso a un servidor de bases
de datos Oracle que pueda usar para descargar el archivo, no se puede usar el servidor comprometido pues
al hacerlo se sobre escribirán porciones del disco en el sistema comprometido con la posibilidad de
destruir evidencia en forma de archivos eliminados. Adicionalmente el archivo generado no muestra toda
la información que realmente existe en el archivo original pues el proceso de LGWR va asignando
números de secuencia a los archivos y sólo los archivos con el número actual de secuencia serán
descargados. Por último, el texto de cualquier sentencia DDL4 puede ser encontrado en el archivo binario
mas no en el archivo descargado con el comando DUMP implicando que el investigador forense no vea
toda la evidencia disponible [16].
2.5.2.1.3 Formato binario de un Redo log
Muchos de los archivos binarios Oracle y particularmente los archivos de log que son los que nos
interesan en esta sección, tienen dos encabezados, el encabezado del archivo como tal, y el encabezado del
Redo log en sí, adicionalmente, cada bloque posee su encabezado. A continuación explicaremos
brevemente cada uno [16]:
El encabezado del archivo: contiene información del archivo en sí como tipo, cantidad de bloques y
tamaño de los bloques, Magic (identificador de un archivo Oracle), Checksum de integridad.
El encabezado del Redo Log: contiene información pertinente a la instancia de la base de datos en sí
misma. Por ejemplo El SID de la Base de datos, la versión de la base de datos, la fecha en que
comenzó el logging y cuatro SCN„s5 que son usados para indicar una instancia particular de un estado.
2.5.2.1.4 Encabezado del archivo
Así se ve el encabezado del archivo de ejemplo REDO01.log. Ver Anexo 40.
4
5
DDL: Lenguaje de definición de datos (Data DefinitionLanguage)
SCN: Numero de cambio del sistema (SystemChangeNumber)
40
Tipo de archivo: 0x22 es el identificador que corresponde a los archivos de Redo log. [16]
Tamaño del archivo: Tamaño de bloque * (numero de bloques +1) [16]
Para nuestro caso 512 es el tamaño de un bloque pues es el valor asignado por Windows, y tenemos un
total de 102400 + 1 bloques pues se debe sumar el bloque del encabezado en sí. Finalmente al realizar la
multiplicación obtenemos el tamaño total del archivo que es de (Ver Anexo 40.):
512* 102401 = 52429312 bytes y lo podemos confirmar revisando las propiedades del archivo.
Magic: Es un marcador usado por Oracle para identificar sus archivos. [16]
2.5.2.1.5 Encabezado de un bloque
Cada bloque cuenta con su propio encabezado de 16 bytes, incluso si una Redo Entry debe ser dividida en
dos bloques. Por esta razón es de gran importancia considerar este aspecto, especialmente a la hora de
buscar cadenas de caracteres en los Redo Logspues dichas cadenas pueden encontrarse divididas en dos
bloques y por ende estarán divididas por un encabezado de bloque como se muestra en el siguiente
ejemplo. [16]
En el Anexo 41 podemos ver como la sentencia CREATE PROCEDURE se encuentra truncada por el
encabezado de un nuevo bloque, que podemos identificar por la estructura mostrada. A la hora de realizar
una investigación forense, los dos aspectos más importantes de este encabezado son el desplazamiento y la
suma de verificación. [16]
El Desplazamiento nos indica cuántos bytes debemos movernos desde el comienzo del bloque para llegar
al comienzo de la siguiente redo entry cuando se ha tenido que truncar alguna. [16]
La suma de comprobación nos permite verificar la integridad de un bloque. Para esto cada uno de ellos es
dividido en sub bloques de 64 bytes y para realizar la verificación de los mismos se lleva a cabo el
siguiente proceso para cada uno de los sub bloques mencionados [16]:
1. XOR entre el primer conjunto de 16 bytes con el segundo.
2. XOR entre el segundo conjunto de 16 bytes con el tercero.
3. XOR entre los resultados de los puntos 1 y 2
4. XOR entre el primer y el segundo bloque de 4 bytes del resultado del punto 3
5. XOR entre el resultado del punto 4 y el tercer conjunto de 4 bytes resultante del punto 3
6. XOR entre el resultado del punto 5 y el cuarto conjunto de 4 bytes resultante del punto 3
41
7. El punto 6 resulta en cuatro bytes llamados DWORD (Double Word) de este resultado debemos
comparar los 16 bits más significativos con los 16 menos significativos, si son iguales entonces la
suma de verificación es correcta.
Si los 16 bits más significativos de la DWORD resultante no coinciden con los 16 menos significativos,
significa que hay algún problema con el bloque. La suma de verificación puede ser “reparada” realizando
un XOR entre el resultado del punto 7 y la suma de verificación que aparece en el encabezado del bloque.
[16]
Por ejemplo si la suma de verificación de un bloque es 0x4E50 y la DWORD resultante después de llevar
a cabo todas las operaciones XOR pertinentes es 0x59B109B1 entonces tendremos 0x59B1 para los 16
bits más significativos y 0x09B1 para los menos significativos. Al realizar un XOR entre estos dos
conjuntos de bits obtendremos 0x5000, si la suma de verificación fuera correcta, deberíamos haber
obtenido 0x0000. Como este no es el caso, hacemos un XOR entre el resultado obtenido tras el proceso de
verificación (DWORD) y la suma de verificación original para obtener lo siguiente [16]:
0x4E50 XOR 0x5000 = 0x1E50
Si a continuación cambiáramos la suma de verificación por 0x1E50, la verificación sería exitosa, aunque
el bloque estuviera corrupto. Esta situación será analizada más adelante en la sección2.7.1Técnicas anti
forenses en contra del Redo Log [16].
Con el fin de brindar mayor claridad al proceso de verificación, explicamos la secuencia de pasos de
manera gráfica y detallada en el Anexo 8.
2.5.2.1.6 Encabezado del Redo Log
En el Anexo 42 podemos ver que se tienen 4 SCN6 o números de cambios del sistema distintos: de inicio,
siguiente, habilitado y de hilo cerrado. Cada uno de estos tiene asociado un timestamp. Estos números de
cambios del sistema le permiten a Oracle indicar una instancia particular de un estado, es decir, si el
estado de la base de datos cambia por ejemplo por la ejecución de una sentencia INSERT seguida de un
COMMIT, Oracle puede seguir este cambio usando un SCN. Si se requiere restaurar la base de datos a un
estado anterior, esto puede ser logrado usando los SCN para indicar cuál “versión” o a qué punto de la
base de datos desea retornar específicamente. [16]
6
System Change Number, también conocidos como System commit numbers
42
2.5.2.1.7 ¿Cómo se registra el tiempo en los Redo Logs
Cada entrada Redo tiene asociada una estampilla de tiempo medida en segundos que puede ser usada por
el examinador forense para construir una línea de tiempo. Es importante notar que dicha estampilla es
relativa al momento en que la entrada fue escrita en el archivo y no a cuando sucedió el evento
relacionado y esto puede implicar un retardo entre el momento en que sucede un evento y el instante en
que este se escribe en disco. Específicamente se puede afirmar que no se debe confiar totalmente en la
precisión de las estampillas para operaciones DML7 mas por otro lado puede considerarse adecuada la
estampilla de las operaciones DDL para construir una línea de tiempo pues son comprometidas
inmediatamente [16].
2.5.2.1.8 ¿Qué es una RedoEntry?
UnaRedo Entrycontiene todos los cambios para un SCN dado. La entrada tiene un encabezado y uno o
más “vectores de cambio”. Puede haber uno o más vectores de cambio para un evento dado. Por ejemplo,
si un usuario realiza un INSERT en una tabla que tiene un índice entonces se crean varios vectores de
cambio. Habrá un vector Redo y un vector Undo para el INSERT y luego una fila para el índice y un
commit. Cada vector de cambio tiene su propio código de operación que puede ser usado para
diferenciarlos [16]:
5.1 Undo Record
5.4 Commit
11.2 INSERT on single row
11.3 DELETE
11.5 UPDATE single row
11.11 INSERT multiple rows
11.19 UPDATE multiple rows
10.2 INSERT LEAF ROW
10.4 DELETE LEAF ROW
13.1 Allocate space [e.g. after CREATE TABLE]
24.1 DDL
El examinador forense debe desplazarse por cada entrada Redo, deducir qué paso e intentar separar las
entradas normales de las que parezcan ser parte de un ataque [16].
7
Lenguaje de manipulación de datos (Data ManipulationLanguage)
43
2.5.2.1.9 Examinando operaciones DML
Las sentencias de manipulación de datos causan cambios en el estado de la base de datos y por lo tanto se
crea una RedoEntry. Si un atacante realiza cualquiera de esas operaciones entonces se deben poder
encontrar en el Redo Log [16].
Por ejemplo en el archivo hexadecimal generado por un INSERT podemos encontrar el objeto en el cual
fueron insertados datos. Un examinador forense, durante la investigación, habrá descargado la lista de
objetos, los tipos, y los propietarios de cada objeto en la base de datos. Usando esto, puede ver en cuál
tabla se insertó y cuántos datos se insertaron [16].
Después de un vector de cambio Redo INSERT hay dos vectores de cambio, un encabezado Undo y un
Undo. El Undo contiene el Id del usuario asociado con el INSERT. Haciendo uso de esto el investigador
forense puede confirmar si el usuario encontrado tenía permisos de inserción en la tabla o si usó alguna
modalidad de SQL Injection para efectuar un ataque [16].
2.5.2.1.10 Examinando operaciones DDL
Una manera fácil y rápida de descargar sentencias DDL de los Redo Logs es usar una utilidad como
“strings”, grep” o “findstr”. Sin embargo se debe tener cuidado pues si el texto de una sentencia DDL
pertenece a la frontera de dos bloques, el texto se cortara en la mitad. Así, si se busca por “GRANT” y el
“GRA” está en el final de un bloque y el “NT” esta al comienzo del siguiente, no se encontrará [16].
2.5.2.1.11 Realizar un post-mortem de los Redo Logs después de un ataque
Muchos ataques en Oracle se basan en distintas vulnerabilidades SQL Injection pero sin importar la
modalidad, las acciones del atacante aparecen en los Redo Logs. Es críticamente importante para un
examinador forense notar que a pesar de que una acción DML sea iniciada por otro usuario, la entrada
Redo mostrara el Id del usuario de la cuenta que posee el Stored Procedure vulnerable lo cual tiene
sentido pues es la cuenta que está ejecutando la sentencia en realidad [16].
Como fuente adicional de información y como complemento a la evidencia que se ha mostrado se puede
obtener de los Redo Logs, tenemos la información contenida en los Data Files de Oracle. Por este motivo
la siguiente sección tiene como objeto estudiar la manera de detectar objetos eliminados examinando
dichos Data Files y recuperar evidencia que pueda ser relacionada con los eventos en los Redo Logs con
el fin de llevar a cabo una investigación forense confiable.
44
2.5.2.2 ORACLE DATAFILES
“Una base de datos se divide en unidades lógicas denominadas TABLESPACES. Un tablespace no es un
fichero físico en el disco, simplemente es el nombre que tiene un conjunto de propiedades de
almacenamiento que se aplican a los objetos (tablas, secuencias…) que se van a crear en la base de datos
bajo el tablespace indicado. Un datafile es la representación física de un tablespace. Es el "fichero de
datos" donde se almacena la información físicamente.” [18]
2.5.2.2.1 OBJETOS ELIMINADOS (DROPPED OBJECTS)
Después de tener éxito atacando un servidor de bases de datos, el atacante seguramente tratara de ocultar
sus actos, lo cual incluye “eliminar” los objetos que se crearon durante el ataque tales como tablas,
funciones o procedimientos. En la mayoría de los casos, aunque un objeto haya sido “bajado” (dropped),
habrá pedazos restantes de este que pueden ser “cosidos” para dar una imagen clara de las acciones del
atacante. Sin embargo dependiendo de con que velocidad se realice la investigación pertinente, dicha
evidencia puede perderse parcial o totalmente. [19]
2.5.2.2.1.1 Bloques de datos Oracle
Antes de investigar los objetos borrados es pertinente analizar los bloques de datos Oracle. Todo archivo
de datos, está dividido en bloques. El tamaño de cada bloque está definido por el servidor usando el
parámetro de inicialización DB_BLOCK_SIZE. Existen diferentes tipos de bloques que almacenan
información diferente como datos de tablas, datos de índices, datos de agrupamiento, ente otros. Cada
bloque está dividido en sub secciones. En el Anexo 9 se puede ver una ilustración de un bloque de datos
Oracle y sus secciones [19].
En la sección 2.5.2.1.3 hablamos acerca de los encabezados de un archivo, de un redo log y de un bloque,
estos encabezados son muy similares a los tratados en dicha sección. Después del encabezado tenemos un
directorio de tabla y un directorio de filas, ambos de tamaño variable. El directorio de filas contiene
información sobre cuantas filas de datos hay en el bloque y por cada una de estas tiene una entrada de dos
bytes que apunta a los datos reales de la fila. Este apuntador se añade al corrimiento (offset) dentro del
archivo del comienzo del bloque del directorio de filas para dar un desplazamiento a la ubicación de la
fila de datos. [19]
45
La información de filas se escribe de abajo hacia arriba consumiendo el espacio libre del bloque, cuando
esté está lleno, el servidor comienza a llenar un nuevo bloque. Cada fila en el bloque tiene un encabezado
de tres bytes. [19]
El primer byte es un marcador que contiene flags indicando el estado de la fila. Por ejemplo si una fila es
borrada, el quinto bit del primer byte es “encendido”. Un estado común para el conjunto marcador del
primer byte de una fila es 0x2C, que se convertiría en 0x3C cuando se encienda el flag de borrado. Este es
un indicador clave cuando se están buscando objetos [19]. Ver Anexo 43.
El segundo byte del encabezado de una fila es usado para determinar el estado de bloqueo, y el tercer byte
contiene la cantidad exacta de información (columnas) que efectivamente hay en la fila. Si la cantidad de
información supera los 255 bytes, entonces el encabezado de la fila es de 4 bytes para permitir hasta
65536 bytes. Justo después del encabezado de la fila se encuentran los datos como tal. Cada columna es
precedida por un byte indicando su tamaño. Si alguna determinada columna es nula, se representa con un
0xFF. En el Anexo 43 se presenta un ejemplo [19].
En este volcado hexadecimal podemos identificar que estamos tratando con una fila borrada pues el
primer byte del encabezado se encuentra en 0x3C. Adicionalmente podemos deducir que tenemos 17
columnas pues 0x11 equivale a 17 en decimal. Justo después del encabezado encontramos un contador de
longitud que nos indica cuántos bytes debemos desplazarnos para encontrar el siguiente contador y así
sucesivamente hasta llegar al número total de columnas, que en este caso como lo mencionamos es de 17.
Ver Anexo 43.
Cuando una fila es eliminada, tanto el espacio que habían ocupado los datos, como la entrada en el
directorio de filas quedan disponibles, pero mientras que llega el momento de ser utilizados de nuevo, esta
información permanece ahí disponible y recuperable para una investigación. Cuando tanto la entrada en el
directorio de filas como el espacio que antes ocupaba la fila permanecen sin ser reutilizados, Litchfield
llama a estos conjuntos filas borradas enlazadas y afirma que pueden ser detectadas fácilmente como se
mostrara más adelante. Cuando la entrada en el directorio de filas ha sido reutilizada pero el espacio que
ocupaba la fila aún no ha sido usado de nuevo, Litchfield las bautiza filas borradas flotantes y menciona
que son más difíciles de detectar que las enlazadas pero que con un poco más de esfuerzo también puede
conseguirse. [19]
46
2.5.2.2.1.2 ¿Cómo ubicar filas eliminadas?
Es importante poder señalar cuando una fila ha sido eliminada pues cuando un objeto (tabla) es eliminado,
todas las filas de datos relacionadas con dicho objeto son eliminadas, es decir, una fila eliminada es un
indicio de una tabla eliminada. Localizar una fila borrada es fácil, basta con tomar un bloque Oracle,
encontrar el directorio de filas y por cada entrada en este buscar la fila a la cual se está apuntando. Usando
el primer byte del encabezado de cada fila, nos desplazamos hasta el quinto bit y revisamos si esta
“encendido”, lo cual indicara que dicha fila ha sido eliminada (Existe algunas pocas excepciones en las
cuales aun si el quinto bit no está encendido, pueden existir filas eliminadas como lo es el caso de una fila
de la tabla OBJ$ que ha sido eliminada, estos casos son considerados “rarezas” de Oracle). Podemos saltar
de fila en fila sin tener en cuenta la información haciendo uso del último byte del encabezado de cada fila
para desplazarnos hasta el comienzo de la siguiente fila hasta el final del archivo. Una vez que hemos
recorrido todas estas filas borradas enlazadas cualquier información que no haya sido revisada, se
encuentra o bien flotando o ha quedado como restante de una operación de actualización anterior. Este
proceso debe ejecutarse para cada bloque asignado a tablas u objetos de interés. [19]
2.5.2.2.1.3 ¿Cómo ubicar bloques asignados a objetos de interés?
Existe una serie de tablas de interés cuando queremos localizar objetos eliminados, por ejemplo la tabla
OBJ$, también algunos grupos e índices. Sin importar de qué caso se trata, el proceso para ubicar la
información de tablas, grupos o índices eliminados es el mismo. Como se mencionó, cada bloque tiene un
encabezado dentro del cual podemos ubicar el ID del objeto al cual se encuentra asociado desplazándonos
24 bytes, haciendo uso de esta información es fácil ubicar los objetos de interés simplemente con abrir el
Data File y comparar en cada bloque el ID para ver si corresponde al del objeto en el cual estamos
interesados. Si el ID corresponde, analizamos el bloque en cuestión, en caso contrario proseguimos a
comparar el ID del siguiente bloque. [19]
2.5.2.2.1.4 Creación y eliminación de objetos
Es esencial comprender qué sucede cuando un objeto de la base de datos es creado pues esto determina y
ayuda a entender muchas de las ubicaciones en las cuales buscaremos más adelante. Cada vez que se crea
un objeto, se inserta una fila en la tabla OBJ$. Esta tabla tiene tres índices I_OBJ1, I_OBJ2 e I_OBJ3, y
una entrada es generada en cada uno de ellos cuando un objeto es creado. El I_OBJ2 indexa el nombre del
objeto y el ID del propietario. Dependiendo el tipo de objeto que es creado, se insertan otros valores en
otros lugares. Por ejemplo, cuando se crea una tabla, se inserta una fila a la tabla TAB$ y una o más filas a
la tabla COL$ dependiendo de las columnas de la nueva tabla. En el fondo, tanto la tabla TAB$ como
47
COL$ existen en el grupo C_OBJ# y es allí donde las filas son creadas realmente. La tabla COL& tiene un
índice I_COL1 que indexa el ID de objeto de la tabla y los nombres de columna de la tabla así que
información sobre la tabla también es insertada en este índice. Cuando se crea una función o un
procedimiento, una o más filas son insertadas en las tablas SOURCE$, IDL_UB1$ e IDL_CHAR$.
Pequeñas cantidades de información sobre el objeto son almacenadas en toda la base de datos, siendo esto
lo que eventualmente nos dará pistas cuando estemos tratando de ubicar un objeto eliminado.Todas estas
tablas, índices y grupos, son de interés para el investigador y deben ser examinados exhaustivamente. [19]
Ahora que hemos estudiado lo que sucede cuando un objeto es creado, pasaremos a entender lo que
sucede cuando un objeto es eliminado. Cuando se elimina un objeto, la fila en la tabla OBJ$ se marca
como eliminada cambiando el marcador de 0x2C a 0x3C, lo que como explicamos anteriormente, equivale
a “encender” el quinto bit del primer byte del encabezado de la fila. Toda la información como el nombre
del objeto, su ID, etc, aún persisten, solo que la fila es marcada como eliminada. Podríamos comparar esta
situación con la que tiene lugar cuando eliminamos un archivo en Windows y el sistema operativo
simplemente deja de mostrar dicho archivo mientras que la información permanece guardada en los
clústeres del disco magnéticamente hasta que se realice una sobre escritura, caso en el cual aún se puede
recuperar la información con técnicas y herramientas forenses especiales como File Scavenger. Así como
simplemente se marcan como eliminadas las filas en la tabla OBJ$, sucede con las demás tablas que han
almacenado información referente al objeto y con la información almacenada en los índices respectivos.
[19]
Para versiones iguales o posteriores a Oracle 10g como es nuestro caso, Oracle provee una funcionalidad
llamada flash back, que permite trabajar sobre estados pasados de la base de datos sin necesidad de
realizar una restauración a un estado anterior en el tiempo. Esta funcionalidad permite realizar consultas
que retornan información del pasado, restaurar tablas a estados anteriores mientras la base de datos sigue
en línea y rastrear y archivar automáticamente cambios transaccionales en los datos. [20]
Si se tiene activada la funcionalidad flash back (activada por defecto), cuando se elimina un objeto, se crea
una fila en la tabla de papelera de reciclaje RECICLBIN$. Si por algún motivo, en un momento posterior
la papelera de reciclaje es vaciada o el objeto en cuestión es vaciado de la papelera, dicha fila es marcada
como eliminada. Nuevamente, la información sigue ahí, solo que el marcador es cambiado de 0x2C a
0x3C. El espacio de cualquiera de las filas mencionadas que han sido marcadas como eliminadas, puede
ser reutilizado en cierto punto, destruyendo evidencia. Sin embargo como existen diversas ubicaciones
donde se almacena información de un objeto dado, existe una buena posibilidad de que no todas las filas
48
eliminadas relacionadas al objeto eliminado hayan sido reutilizadas cuando se lleve a cabo la
investigación de un servidor comprometido. [19]
2.5.2.2.1.5 ¿Cómo rastrear la evidencia?
Oracle provee varias funciones de auditoría integradas en sus versiones posteriores a la 9g, y aunque en el
caso de 11g vienen activadas por defecto, dichas características no siempre están activadas.
Adicionalmente muchas empresas se ven abrumadas por la cantidad de opciones a elegir y en muchos
casos optan por activarlas todas, lo cual genera registros muy extensos y por ende incómodos de leer y
analizar, así que finalmente deciden volver a desactivar todas las características. Usualmente las
compañías usan firewalls y sistemas de detección de intrusos para determinar si la red y/o el sistema
operativo están siendo usados anormalmente o abusados, entonces, ¿por qué no proteger el activo más
valioso de la compañía, la información? La auditoría de Oracle puede ayudar a detectar accesos no
autorizados o uso inadecuado de la información contenida en la base de datos. Para verificar el estado de
los parámetros de auditoría podemos usar la siguiente sentencia [21] [22] Ver Anexo 10:
SHOW PARAMETER AUDIT
Para activar las funciones de auditoría se debe modificar el parámetro AUDIT_TRAIL, el cual puede
recibir cualquiera de las siguientes opciones [21]:
none o false: Auditoría desactivada
db o true: Auditoría activada, con todos los registros almacenados en el proceso de auditoría de la
base de datos (SYS.AUD$).
db,extended: Igual que db, pero las columnas SQL_BIND y SQL_TEXT también son activadas.
xml: Auditoría activada, con todos los registros almacenados en formato XML.
xml,extended: Igual que xml, pero las columnas SQL_BIND y SQL_TEXT también son activadas.
os: Auditoria activada, con todos los registros dirigidos al proceso de auditoría del sistema operativo.
Como hemos mencionado antes, las opciones de auditoría de Oracle vienen desactivadas en algunas
versiones y en caso de ser activadas por una organización su utilización suele resultar fallida debido a un
manejo inadecuado. Supongamos que un DBA sospecha que uno de sus servidores ha sido comprometido
y no se tenían activadas las funciones de auditoría de Oracle. ¿Existe alguna evidencia para sustentar que
fue cometido un ataque? [22] [19]
49
2.5.2.2.1.6 ¿Cómo detectar tablas eliminadas?
Consideremos el volcado hexadecimal mostrado en la Ilustración 93, tomado del archivo SYSTEM.DBF
el cual es usado por el tablespace SYSTEM. Como podemos ver en el rectángulo azul, este bloque ha sido
asignado al objeto con ID 0x12 o 18 en decimal, que corresponde a la tabla OBJ$. Varios bytes más
adelante podemos observar un encabezado de una fila que ha sido marcada como eliminada (rectángulo
rojo) con el valor 3C. Ver Anexo 43.
Cuando mapeamos todas las entradas en el directorio de filas y bloqueamos los datos para cada entrada,
encontramos que existen un par de “lagunas”. Estas lagunas son filas borradas flotantes, en otras palabras,
hay información de filas presente mas no existen entradas para ésta en el directorio de filas. EL 0x3C
mostrado en la Ilustración 93 representa una fila borrada flotante. Con el comienzo del directorio de filas
en 0x189D379D debería haber una entrada de0x1759 pero no la hay, lo cual confirma que es una fila
borrada flotante. Aunque se puede ver en el ASCII de la derecha el nombre MY_TEMP_TABLE,
necesitamos extraer el resto de la información. [19]
2.5.2.2.1.7 ¿Cómo extraer la información?
El encabezado de la fila mostrado en la Ilustración 93 es 3C 01 11, como explicamos anteriormente, el
ultimo byte nos indica que tenemos 0x11 o 17 columnas, y antes de las datos de la columna siempre
encontramos un contador de la longitud de los datos. Entonces para extraer los datos recorremos las
columnas teniendo en cuenta las longitudes indicadas en dichos contadores. Ver Anexo 43.
Ahora nuestra labor consistirá en hacer que dicha información sea humanamente comprensible, para esto
debemos revisar los tipos de las columnas de la tabla que estemos estudiando, para nuestro caso las
columnas de la tabla OBJ$ tienen los tipos mostrados en el Anexo 11 [19].
Podemos notar que la tabla llamada MY_TEMP_TABLE fue creada por el usuario con ID 55, a las
17:07:37 del 23 de Marzo de 2007. También podemos ver que la tabla tiene 51846 como identificador de
objeto. Si realizamos una búsqueda en el Data file por el ID del objeto codificado (04 C3 06 13 2F),
encontraremos que también existe evidencia de esta tabla en la tabla MON_MODS$, los índices
I_MON_MODS$_OBJ y RECYCLEBIN$_OBJ, y en el grupo C_FILE#_BLOCK#. Una vez que hemos
localizado todos los demás ítems que han sido eliminados por el atacante, localizaremos la tabla eliminada
como tal y veremos, si es el caso, la información que contiene. [19]
50
2.5.2.2.1.8 ¿Cómo detectar funciones eliminadas?
Cuando una función es eliminada, extrañamente, el primer byte del encabezado de la fila asociada a dicha
función en la tabla OBJ$, permanece intacto, es decir, no se enciende el quinto bit del primer byte para
indicar una eliminación. En su lugar, son modificados los últimos dos bytes de la columna STIME y se
colocan en 0x3C, que como hemos visto, es el marcador típico para indicar algún objeto eliminado.
Aunque no se conoce la razón por la cual las funciones eliminadas son marcadas de esta manera
particular, conocerla nos permite localizarlas fácilmente. Ahora supongamos que en los bloques asignados
a la tabla OBJ$ no encontramos ningún indicio de una función eliminada, esto no implica necesariamente,
que no se hayan creado y eliminado funciones sino que existe la posibilidad de que la evidencia haya sido
sobrescrita. Para verificar esta posibilidad debemos examinar las tablas SOURCE$ e IDL_UB1 [19].
En el Anexo 27 podemos ver como el directorio de filas contiene varias entradas que apuntan a filas
borradas enlazadas, y la manera en que dicho enlace realiza se muestra en el Anexo 28. Todas estas filas
están asociadas al ID de objeto C3 06 13 33 que en decimal equivale a 51850. Con el fin de saber que
contenía dicho objeto podemos extraer el texto de la información borrada, es decir el contenido de dichas
filas [19]. Ver Anexo 27.
Este código pertenece a una función llamada EXTRACT_SYS_PASSWORD y aunque no sabemos quién
la creo, al no tener evidencia en los bloques de la tabla OBJ$, podemos ver que realiza una inserción de
datos en la tabla MY_TEMP_TABLE, que recientemente habíamos detectado como eliminada. Lo que
hace esta función es extraer el hash del password de la cuenta SYS e insertarlo en la tabla mencionad.
Para saber si el ataque fue exitoso debemos examinar la tabla IDL_UB1$, esta tiene un ID con valor 73,
entonces hacemos un volcado de todos los bloques asociados al objeto con ID 73. Dicho volcado se
muestra en el Anexo 29 y en este podemos encontrar algunas entradas borradas enlazadas relacionadas
con el mismo ID de objeto (51850), también podemos ver varios segmentos del texto de la función,
incluida su “sustancia” es decir, la inserción del password de la cuenta SYS en la tabla
MY_TEMP_TABLE. [19]
2.5.2.2.1.9 ¿Cómo encontrar la tabla MY_TEMP_TABLE?
De la información extraída de la tabla OBJ$ sabemos que el ID de objeto de la tabla eliminada es 51846,
entonces localizamos los bloques asociados a esta tabla en los data files pertenecientes al tablespace
USERS y buscamos el ID de objeto mencionado 24 bytes dentro del encabezado del bloque. El volcado
hexadecimal del Anexo 44 muestra uno de dichos bloques y como el directorio de filas no está vacío,
51
existe información. Podemos encontrar dicha información al final del bloque encerrada en verde, y
notaremos que en efecto, es el hash del password de la cuenta SYS. [19].
De todo lo anterior podemos concluir que el 23 de Marzo de 2007 a la 17:07:37, el usuario SCOTT creó
una tabla llamada MY_TEMP_TABLE con ID 51846. También en algún momento se creó la función
EXTRACT_SYS_PASSWORD con ID de objeto 51850 con el fin de insertar el hash del password del
usuario SYS en la tabla mencionada anteriormente. El hash del password efectivamente se encuentra en la
tabla, y aunque es muy probable que dicha función haya sido usada para obtener el hash, no podemos
asegurarlo, pues además del texto de la función, no existe ningún otro vínculo directo entre las dos. Dicho
esto podemos afirmar que existe una gran probabilidad de que la función EXTRACT_SYS_PASSWORD
haya sido creada como una función auxiliar de inyección en un ataque de PL/SQL injection en contra de
un paquete propiedad de SYS. [19]
Tras analizar la evidencia encontrada en los Data Files de Oracle y relacionarla con los eventos de los
Redo Logs, podemos conformar un buen conjunto de evidencia pertinente para una investigación forense.
De todos modos existen otras fuentes de información que aún no hemos revisado. A continuación se
explicará lo relativo al archivo donde se almacena el registro de eventos relacionados con el listener de
Oracle, hablaremos sobre las trazas de auditoría sobre el tráfico de red y veremos cómo hallar evidencia
adicional en el registro de comandos emitidos al listener.
2.5.2.3 TNS LISTENER, LISTENER LOG Y AUDIT TRAIL
El listener de Oracle, es el componente de software de la base de datos que maneja el tráfico de red entre
la base de datos, los clientes, y otras bases de datos. Oracle provee la opción de llevar un registro de las
actividades relacionadas con el TNS Listener en un archivo llamado Listener log. Este archivo permite
recolectar y analizar estadísticas del uso de la red, así como información sobre las peticiones de conexión
realizadas por los clientes, y registro de comandos RELOAD, START, STOP, STATUS, o SERVICES,
emitidos por la utilidad de control del listener (lsnrctl). [23] [24]
Oracle 11g tiene activada por defecto la opción de llevar los registros de eventos (LOG_STATUS=ON),
pero en algunas versiones anteriores o incluso en una 11g mal configurada podría estar desactivada, así
que como primera medida en este capítulo se recomienda revisar el estado del parámetro LOG_STATUS
y activar el registro en caso de estar desactivado. Cuando el registro está activado, el directorio por defecto
dependiendo
de
la
versión
puede
ser:
$ORACLE_HOME/network/admino
52
C:\app\<USUARIO>\diag\tnslsnr\<NOMBRE_DE_LA_MAQUINA>\listener\alerty el archivo de registro
es <SID>.log o log.xml [23]
En el registro del archivo podemos encontrar un timestamp, comando emitido, y código de resultado. Si se
retorna un error de Oracle, también incluirá el mensaje de error. En el Anexo 37 presentamos un cuadro
donde se muestran algunos errores TNS que pueden significar ataques o actividad inapropiada referente al
TNS Listener y posteriormente pasaremos a estudiar en más detalle todo lo referente al archivo de registro
de eventos del listener o listener log [23].
2.5.2.3.1 Evidencia de ataques al mecanismo de autenticación
Un aspecto clave a la hora de realizar una investigación sobre la base de datos, es preguntarse ¿Existió una
brecha de seguridad?, y la mejor manera de abordar esta pregunta es revisando si se realizó un inicio de
sesión exitoso o no, pues aunque no todos los ataques requieren una autenticación previa, la gran mayoría
de hecho si la requiere. A continuación revisaremos la evidencia que dejan los ataques en contra del
mecanismo de autenticación en el archivo listener log y la traza de auditoría (asumiendo que el comando
CREATE SESSION está siendo auditado), para revisar si un intento de autenticación fue exitoso o no.
[25]
2.5.2.3.1.1 Localizando intentos por obtener el SID de la base de datos
Para poder acceder al RDBMS, un atacante debe conocer el identificador de servicio de la base de datos o
SID. En versiones anteriores a la 10g se podían usar los comandos SERVICES o STATUS para obtenerlo
del TNS Listener, y la ejecución de dichos comandos generaba entradas en el archivo listener log [25].Ver
Anexo 37.
A partir de la versión 10g, obtener el SID dejo de ser una tarea tan sencilla pero aparecieron nuevas
estrategias de las cuales se hablara a continuación.
2.5.2.3.1.2 Ataques de fuerza bruta para obtener el SID de la base de datos
Como se mencionó en el numeral anterior, a partir de la versión 10g, los atacantes debieron idear nuevas
formas de obtener el SID de la base de datos. Una de dichas estrategias consiste en tratar de adivinarlo por
medio de un ataque de fuerza bruta. Existen herramientas disponibles en internet que se encargan de
realizar esta tarea, entre ellas podemos encontrar sidgusser.exe de CQure.net, sidguess.exe de
Red
Database Security, y ora-brutesid.exe de DatabaseSecurity.com. Cada una de las herramientas
mencionadas genera entradas similares en el listener log y a la vez cada una tiene sus particularidades. Las
entradas de log presentadas en el Anexo 38, fueron generadas por el listener después de ejecutar
53
sidgusser.exe [25]. Sidguesser.exe crea sus propios TNS packets para hacer parecer que el intento de
conexión lo realizó un cliente haciendo uso de JDBC, un atacante podría implementar su propia
herramienta de fuerza bruta usando JDBC y las entradas en el listener log se verían iguales a las generadas
por sidgusser.exe. Las entradas presentadas en el Anexo 12 fueron generadas por el listener tras ejecutar
sidguess.exe [25].
Esta herramienta usa librerías de Cliente Oracle, y provee información “extra” en el listener log tal como
el hostname del cliente que se está conectando (APOLLO) y el nombre de usuario del SO de la persona
que está ejecutando la herramienta (DAVID). Aunque a primera vista, esto puede parecer evidencia útil,
se debe tener en cuenta que estos datos están bajo el control del cliente y podrían ser “disfrazados”, por
ende no existe ningún impedimento para que un atacante escriba su propia herramienta de fuerza bruta, en
la cual el hostname sea, por dar un ejemplo, “GW.ORACLE.COM” y el nombre de usuario sea
“L.ELLISON” (Lawrence Ellison, fundador y figura principal de Oracle). Así como el atacante puede
enviar datos “disfrazados”, también puede elegir no enviar ninguna información adicional, dicha falta de
información “extra” se convierte en una “firma” de la herramienta en sí misma. [25]
Asumiendo que un atacante logra obtener el SID de la base de datos, entonces procederá a autenticarse.
2.5.2.3.1.3 Detectando ataques de enumeración de usuarios
Durante la etapa de autenticación Oracle, el cliente presenta su nombre de usuario al servidor en un
paquete. Si el nombre de usuario existe en la base de datos entonces el servidor emite una clave de sesión
y el cliente envía su contraseña cifrada en un segundo paquete. Si el usuario no existe el servidor envía de
vuelta un error ORA-01017: invalidusername/password; logon denied. Debido a estos dos
comportamientos, un atacante puede determinar si un usuario existe o no. Como el cliente solo necesita
enviar el primer paquete para determinar si el usuario existe, nunca se hace un intento completo de
autenticación. En este punto juega un papel importante el audit trail de Oracle, pues si la cuenta no existe,
se genera una entrada con código de retorno 1017 como se muestra en el Anexo 37 [25].
Sin embargo si la cuenta existe, no se genera ninguna entrada en el audit trail porque la autenticación
nunca se completa. Si el audit trail muestra una gran cantidad de entradas de usuarios no existentes,
especialmente en un periodo corto de tiempo y provenientes de la misma ubicación, esto probablemente
indique un ataque de enumeración de usuarios. Para conocer la ubicación desde la cual se realizan los
intentos, usamos la columna COMMENT$TEXT, la cual contiene la dirección IP del sistema que está
intentando iniciar sesión. [25]. Ver Anexo 37.
54
Dependiendo de la herramienta que haya sido usada para realizar el ataque de enumeración de usuarios, el
archivo listener log, también puede ser una buena fuente de evidencia. Un atacante no tiene necesidad de
crear distintas conexiones TCP para enviar distintos intentos de enumeración, una vez conectado al
servidor, puede enviar tantos intentos como desee usando el mismo circuito TCP. Solo algunas
herramientas avanzadas como ora-brutesid.exe mantienen la misma conexión TCP para realizar todos los
intentos, sin embargo, la mayoría de herramientas de enumeración no usan la misma conexión sino que se
reconectan al listener antes de hacer un nuevo intento, llenando el listener log de entradas. [25]
En la Imagen presentada en el Anexo 13 podemos ver varias entradas “establish” en un corto periodo de
tiempo asociadas a la dirección 192.168.1.64. El fragmento del listener log en sí mismo, no provee
suficiente evidencia para afirmar que se realizó un ataque de enumeración de usuarios, sin embargo al
combinar esta evidencia con la recolectada previamente del audit trail, parece mucho más probable pues
los timestamps de los dos coinciden y las cuentas listadas en el audit trail no existen. Como se mencionó
anteriormente, una herramienta más avanzada como ora-brutesid.exe no se reconectara antes de realizar
cada intento de enumeración y por ende solo aparecerá una entrada “establish” en el listener log,
dejándonos únicamente con la evidencia del audit trail que muestra intentos de autenticación para varias
cuentas inexistentes. [25]
2.5.2.3.1.4 Detectando ataques de adivinación de contraseñas
Una vez que un atacante tiene una lista de usuarios puede proceder a intentar adivinar sus contraseñas.
Una herramienta de fuerza bruta simple creará una conexión al servidor por cada intento de adivinar una
contraseña y esto implicara conectarse nuevamente al listener lo cual se registrará como una entrada
“establish” en el listener log. Las entradas generadas por múltiples intentos de adivinar una contraseña
son exactamente iguales a las generadas por un ataque de fuerza bruta que intenta enumerar las cuentas de
la base de datos. Si nos fijamos en dichas entradas, notaremos que el número de puerto del cliente que se
está intentando conectar va incrementándose. Este es el comportamiento estándar cuando es creada una
nueva conexión TCP. Sin embargo no podemos afirmar definitivamente que tuvo lugar un ataque de
fuerza bruta pues podría tratarse sencillamente, por ejemplo, de un servidor de aplicación mal configurado
tratando de autenticarse con un nombre de usuario o contraseña erróneos. Por lo tanto la dirección IP
almacenada en la entrada del listener log será un indicador importante a la hora de decidir si se trata de un
host conocido o de un posible atacante. [25]
Una herramienta de fuerza bruta avanzada como orapwdbrute.exe (www.databasesecurity.com), no se
reconectara para cada intento, sin embargo existe una “particularidad” en la manera en que Oracle graba el
55
código de retorno en el audit trail para algunos de los intentos realizados por esta herramienta en los
cuales es arrojado el siguiente error diciendo que se envió una contraseña nula [25]:
ORA-1005: null password provided; logon denied
Al parecer, Oracle se confunde levemente al recibir múltiples intentos de una misma conexión demasiado
rápido, orapwdbrute.exe puede realizar 170 intentos por segundo sobre la red, lo cual nos deja con solo 15
millones de intentos por adivinar la contraseña en un día, más que suficientes para cubrir todos las
contraseñas posibles de hasta 5 caractéres de longitud. El Anexo 37 contiene un fragmento del audit trail
que muestra el código de retorno 1005 del cual estamos hablando [25].
Aunque el error indique que se envió una contraseña nula, al realizar una captura del tráfico de red, se
puede verificar que no fue así, como lo afirma la entrada. [25]
Otra fuente importante de evidencia que puede indicar un intento de fuerza bruta, especialmente si no se
tiene activada la auditoria, es la columna LCOUNT de la tabla USER$. Si la funcionalidad account
lockout esta activada, por cada intento fallido de inicio de sesión, el valor en esta columna para el usuario
en cuestión es incrementado en 1. Esto lo podemos verificar haciendo uso de la siguiente sentencia [25]:
SQL> SELECT NAME, LCOUNT FROM USER$ WHERE LCOUNT>0;
Si account lockout esta activada y la cuenta es bloqueada, entonces el valor de LCOUNT no pasará del
umbral de bloqueo especificado. Entonces, si el perfil del usuario especifica 10 intentos fallidos de
contraseña antes de que la cuenta sea bloqueada, el valor de LCOUNT siempre tendrá un máximo de 10.
Si la cuenta es desbloqueada, usando la sentencia ALTER USER <NAME> ACCOUNT UNLOCK,
entonces le valor de LCOUNT será reiniciado en cero. EL valor de LCOUNT también será colocado en
cero cuando el usuario logra iniciar sesión exitosamente. Finalmente, en lo que respecta a la columna
LCOUNT, si el usuario en cuestión tiene un perfil en el cual el campo FAILED_LOGIN_ATTEMPTS
está establecido en UNLIMITED el valor de LCOUNT no variará y será siempre cero [25].
Asumiendo que account lockout esta activada para el usuario, existe otro rastro de información que puede
llegar a ser útil cuando se esté construyendo un línea de tiempo de eventos. Hay una columna de fecha que
graba el momento en que la cuenta fue bloqueada. Ver Anexo 37.
Es importante tener en cuenta que si la cuenta es desbloqueada en algún punto, la columna LTIME
mantendrá el valor de la última vez que la cuenta fue bloqueada, esta no es despejada como LCOUNT.
56
2.5.2.3.1.5 Ataques de fuerza bruta contra la cuenta SYS
¿Cuál es la diferencia entre intentar autenticarse con la cuenta SYS con el parámetro AS SYSDBA y
hacerlo sin dicho parámetro? En una primera inspección podría parecer que solo se trata de un cambio en
una bandera de un bit [25]. Ver Anexo 30.
El byte enmarcado en rojo en el Anexo 30 indica el nivel de privilegio solicitado de la conexión. El sexto
bit es “encendido” si nos estamos conectando como SYSDBA y el séptimo es “encendido” si nos
conectamos como SYSOPER. Aun si ninguno de estos dos bits se encuentra “encendido”, un atacante
puede intentar iniciar sesión como SYS y resolver si tiene la contraseña correcta: si la contraseña no es
correcta, recibirá un error ORA-01017: invalidusername/password; logon denied. Si la contraseña es
correcta recibirá un ORA-28009: connectiontosysshould be as sysdbaorsysoper. Esta diferencia en las
respuestas le permite al atacante saber si ha conseguido obtener la contraseña correcta y luego podrá
iniciar sesión usando “AS SYSDBA”. Mientras que sólo se cambia un bit en lo que respecta al tráfico de
red, hay un mundo de diferencia en lo que le concierne al audit trail. Si no se especifica “AS SYSDBA” o
“AS SYSOPER” durante el intento de inicio de sesión, se genera una entrada en la tabla de auditoría
AUD$. Si el intento no tiene éxito al adivinar la contraseña, el código de retorno es 1017; si el atacante
logra adivinar la contraseña, el código de retorno será 28009. Sin embargo si el atacante coloca el nivel de
privilegio en SYSDBA o SYSOPER, entonces no quedará nada registrado en el audit trail, y por ende
cuando se trata de conexiones privilegiadas SYSDBA y SYSOPER debemos buscar en otros lugares. En
esos casos Oracle escribe una entrada en el sistema de registro del sistema operativo. En Windows este
sistema es el “Registro de Aplicación” (Application Log) del “servicio de registro de eventos”
(EventLoggingService) y podemos acceder a dicho registro de eventos ingresando en Panel de Control,
Herramientas Administrativas, Administración del computador, Visor de Eventos, Aplicación. [25] Ver
Anexo 13.Si existen múltiples entradas en el log del sistema operativo con el código de estado 1017,
indica un ataque de fuerza bruta en contra de la cuenta SYS con el bit de privilegios “encendido”. [25]
2.5.2.3.1.6 Intentos de aprovechar la falla en AUTH_ALTER_SESSION
Asumiendo que un usuario tiene un nombre de usuario y su respectiva contraseña, o bien ha logrado
conseguir uno, puede intentar aprovechar la bien conocida falla en la etapa final de la autenticación. Una
vez que el nombre de usuario y la contraseña de un cliente son validados, el cliente ejecuta una sentencia
ALTER SESSION con privilegios SYS, por ende un atacante podría cambiar la sentencia de un ALTER
SESSION a un GRANT DBA que posteriormente se ejecutaría con éxito cuando el cliente inicia sesión.
Aunque esta falla fue detectada y corregida hace algún tiempo, es importante saber cómo detectar los
intentos por explotarla aun en sistemas que ya no son vulnerables. Siempre que la auditoria esté activada
57
para CREATE SESSION, cuando un atacante intente ejecutar cualquier sentencia SQL para la cual aún no
tiene permisos de ejecución, se generara un error ORA-00604: error ocurred at recursive SQL level 1.
Ora-01031: insuficientprivileges. Esto aparece en el audit trail con un código de 604. [25]
Ilustración 3: Rastros en el audit trail de un intento de ejecutar una sentencia con privilegios insuficientes [25]
2.5.2.3.1.7 ¿La auditoría esta desactivada?
Si la auditoría no está activada, aún puede existir evidencia que muestre que usuarios iniciaron sesión y en
qué momento lo hicieron. La vista fija (fixedview) V$ACTIVE_SESSION_HISTORY utiliza un buffer
circular (de tamaño fijo) en el SGA para almacenar información de muestreo tomada cada segundo sobre
las
sesiones
activas.
Estas
sesiones
son
descargadas
del
SGA
a
la
tabla
WRH$_ACTIVE_SESSION_HISTORY con cierta frecuencia como parte de un repositorio automático de
carga de trabajo. Por lo tanto, estos datos históricos contienen información que puede ser útil para un
investigador forense, pues graban efectivamente quién y cuándo inició una sesión. [25]
En el Anexo 13 podemos ver que el usuario con ID 24 (dbnsmp) inició sesión el 27 de Marzo de 2007 a
las 7:02. En la ausencia de información de auditoría, estos datos pueden ser extremadamente útiles para
determinar quién inicio sesión y cuándo lo hizo. [25]
En lo que respecta al audit trail, debemos ser cuidadosos en un aspecto, cuando un usuario inicia sesión
exitosamente, una fila se inserta en el audit trail. Dicha fila tiene un campo ACTION# con valor 100
(LOGON), el campo RETURNCODE estará en cero por tratarse de un inicio de sesión exitoso y la
columna TIMESTAMP# reflejará cuando ocurrió dicho inicio de sesión. [25]
Ilustración 4: Audit trail justo después de iniciar sesión [25]
Sin embargo, cuando el usuario cierra sesión, si revisamos de nuevo el audit trail, podemos ver que el
campo ACTION# ha cambiado de 100 a 101 (LOGOFF) pero el campo TIMESTAMP# permanece igual.
58
Ilustración 5: Audit trail justo después de cerrar sesión [25]
Al construir
una línea de tiempo es importante tener en cuenta esta situación pues el campo
TIMESTAMP# en realidad esconde el momento en que el usuario se conectó. De todos modos, si
examinamos la columna LOGOFF$TIME en la tabla AUD$ del Audit trail, podemos reconciliar los
tiempos de inicio y fin de sesión [25]:
Ilustración 6: Campo LOGOFF$TIME de la tabla AUD$ [25]
Concluyendo esta sección, podemos decir que potencialmente podemos encontrar evidencia de ataques de
autenticación tanto en el archivo listener log, como en la tabla AUD$ del Audit trail. Debemos recordar
que herramientas distintas dejan rastros distintos. Se debe prestar especial atención al código de retorno en
el audit trail, muchas entradas con código 1017 y posiblemente algunas con 1005, seguidas de una entrada
con código 0, indican un ataque de fuerza bruta exitoso en contra del sistema de autenticación. También es
importante recordar que Oracle tiene muchas cuentas y contraseñas por defecto, que seguramente serán la
primera elección del atacante a la hora de realizar ataques de autenticación. [25]
2.5.2.4 Trace Files
Los trace files de Oracle, o archivos de seguimiento, son archivos especiales que contienen información
relacionada a una sesión que se encuentra bajo seguimiento. Los trace files son creados por los procesos
de background. Usualmente estos archivos poseen información sobre la puesta a punto de las bases de
datos, pero para nuestro caso también nos servirán para el recaudo de información que nos permitan
evidenciar una intrusión maliciosa [26] [27].
59
2.5.2.4.1 Validación
Los archivos de seguimiento de Oracle se encuentran activados para los procesos primarios como LGWR,
si se encuentra activado, o SMON. Si se quiere saber la ruta donde se están almacenando los archivos de
seguimiento de Oracle, podemos hacer uso de la siguiente sentencia [28] [29] [30]. Ver Anexo 31.
2.5.2.4.2 Activación
Para activar los trace files podemos hacerlo de dos formas, la primera es a nivel usuario para que todo lo
que haga dentro de su sesión se vea reflejado y almacenado dentro de archivo de trace. La segunda forma
es haciendo que el trace no se limite únicamente a un usuario, sino que quede a nivel global para que de
esta manera, los manejos de sesión de cada uno de los usuarios, independientemente de la base de datos,
queden almacenados para un posterior estudio [28].
Para esta investigación solamente las enunciaremos y las explicaremos brevemente sin entrar a un mayor
nivel de detalle, en caso de querer información más detallada acerca del tema favor referirse a [28].
2.5.2.4.2.1 Grados de almacenamiento
Para poder realizar el almacenamiento de registros dentro de los .TRC files debemos tener en cuenta en
qué grado lo estamos haciendo. Oracle nos permite almacenarlos a diferentes niveles de exactitud que van
del 0 al 16 [28].
Level 0 = ninguna estadística es generada
Level 1 = seguimiento estándar de salida incluyendo análisis, ejecución y consultas.
Level 2 = igual que el nivel 1.
Level 4 = Igual que el nivel 1 solo que incluye información de los atamientos (BIND)
Level 8 = igual que el nivel 1 solo que también posee información de los waits
Level 12 = Igual que el nivel 1 solo que posee información de los binds y los wait
2.5.2.4.2.2 Activación Global
Inicialmente comenzaremos con las formas de activación globales. Estas son las menos aconsejables ya
que van en detrimento directo del rendimiento de las bases de datos, porque almacena información de
todos los usuarios. En caso de que se encuentre configurado con el mayor nivel de detalle, se demora más
cada una de las consultas dentro de la transacción puesto que tendrá que ir primero al trace file a realizar
el registro y después resolver la consulta, lo cual se podría volver muy complicado dependiendo del
60
número de usuarios que posea la base de datos. En caso de que sea totalmente necesario, existen las
siguientes maneras de activarlo [27] [28] [29].
Se puede usar la sentencia ALTER para modificar los parámetros del spfile. Para hacerlo utilizamos la
siguiente sentencia [27] [28].
alter system set sql_trace=true scope=spfile;
El paquete monitor (DBMS_MONITOR) también nos permite configurar el trace file para el manejo de
instancias [27] [28].
execdbms_service.create_service('Test Service','test network');
2.5.2.4.2.3 Actividad por sesión
Para generar un trace file por sesión necesitamos tener en cuenta a qué usuario vamos a realizar el
seguimiento. Para esto necesitamos el SID y serial# del usuario. Para hallarlo usamos la consulta
presentada en el Anexo 39 [27] [28].
En la imagen anterior podemos ver que la sentencia, nos muestra el SID y el serial# de cada uno de los
usuarios que se encuentran conectados actualmente a la base de datos [28].
Para poder generar un buen archivo de traza, primero debemos configurar los parámetros de tiempo para
que cuando cree las entradas de almacenamiento, tenga en cuenta el tiempo de la entrada con su
timestamp. También debemos configurar el tamaño con el valor máximo que puede llegar a tomar el
archivo de traza, para esto utilizamos las siguientes sentencias [28].
exec dbms_system.set_bool_param_in_session(144,947,'timed_statistics',true);
exec dbms_system.set_int_param_in_session(144,947,'max_dump_file_size',2147483647);
Una vez tenemos el nombre de usuario al cual queremos realizar el seguimiento, lo activamos únicamente
para ese usuario de la siguiente manera [28]:
execdbms_system.set_sql_trace_in_session(144,947,true);
Para acabar la traza utilizamos la siguiente sentencia:
execdbms_system.set_sql_trace_in_session(144,947,false);
61
Con la anterior sentencia estamos haciendo un seguimiento al usuario Bonifacio. Una vez hemos esperado
a que el usuario haga sus funciones dentro de la base podemos ver el archivo de traza ubicado dentro de la
ruta que nos proporciona el procedimiento de la sección 1 de este numeral. Ahora que tenemos el archivo
de traza del usuario nos surgen varias preguntas, ¿Cuál es el nombre del archivo que contiene la traza del
usuario? , ¿Cómo accedo a él?, ¿En dónde puedo encontrar el archivo generado?, ¿necesito algún
programa especial para poder ver de manera estructurada el contenido del archivo? Las respuestas a estas
preguntas las expondremos a continuación [27] [31].
Para poder acceder a los archivos de traza entramos a la ruta que nos fue especificada anteriormente
cuando corrimos el procedimiento de la sección de validación. Una vez dentro de esta ruta, nos aparecen
todas las trazas del sistema y las trazas que nosotros especificamos. Es importante que cuando hayamos
creado una traza tengamos en cuenta la hora en la cual iniciamos la recolección de datos, ya que los
nombres de los archivos son administrados por el sistema [31]. Ver Anexo 14
Los archivos traza especificados por el usuario poseen la siguiente estructura, <SID>_ora_<numero de
sistema>.trc. Una vez hemos identificado el archivo que contiene la traza del usuario especificado,
podemos abrirlo de dos maneras. La primera es usando un editor de texto para abrir el archivo sin formato,
la segunda es usando la herramienta TKPROF. Si abrimos el archivo con un editor de texto se pueden ver
desorganizadas las entradas que fueron generadas cuando iniciamos la traza del usuario, pero es muy
complicado entender la secuencia de eventos dentro del archivo ya que se encuentra sin formato [31]
[24].Ver Anexo 14.
Utilizando la siguiente forma podemos analizar todas las sentencias que ejecutó el sistema y que ejecutó el
usuario. Para entrar al editor, utilizando Windows, iniciamos una consola y entramos a la funcionalidad
tkprof, seguido de la ruta donde se encuentra el archivo traza y la opción con la cual queremos iniciar el
volcado. Existen muchas opciones, pero para funciones forenses utilizaremos la opción SYS=NO que
elimina todas las sentencias ejecutadas por SYS y sólo deja aquellas que sean ejecutadas por el usuario.
Ver Anexo 15 [31].
2.5.2.5 Live Response
Cuando se presente un posible evento forense dentro de una base de datos Oracle, es importante analizar
todos los posibles lugares en los cuales pueda residir información que pueda ser usada en una corte como
evidencia, por esto es importante que en caso de que tengamos la oportunidad de acceder al sistema justo
después de que el ataque se haya presentado podamos obtener la información que se encuentra dentro de
62
la memoria Volátil (Memoria RAM) garantizando la fiabilidad, la veracidad y la integridad de la misma.
Es importante tener en cuenta que esta información sólo podrá obtenerse en caso de que el sistema
comprometido no haya sido apagado para efectos de aislamiento, ya que la información que resida dentro
de la memoria volátil será permanentemente eliminada y por ende se estaría descartando evidencia
potencial. Es importante que el proceso que se sigue para el manejo de la información adquirida sea
completamente documentado y respaldado ya que los resultados que se obtengan de la adquisición de esta
información no pueden ser reproducidos. Esto lo hace blanco de desacreditaciones [26] [32].
Aunque existen amenazas que puedan alterar la información que hay dentro de la memoria Volátil, como
por ejemplo que el atacante modifique el proceso NTDLL.dll8 para que cuando el investigador forense
utilice alguna de sus herramientas para captura de evidencia el proceso realice rutinas que el atacante
haya programado para entorpecer y complicar la investigación, es importante tener esta información por
las siguientes razones [32]:
No todos los atacantes comprometerán los procesos que administran la información volátil.
La mayoría de los atacantes no llegan hasta ese nivel para encubrir sus huellas.
En caso de que la información volátil no muestre ningún tipo de evento sospechoso y otros
logs si lo hagan, ya se puede garantizar que se ha hecho uso de una técnica anti forense.
Teniendo en cuenta el porqué es importante la información volátil es necesario determinar un modo de
proceder para garantizar que la información que se obtenga sea fiable.
2.5.2.5.1 Secuencia de administración para Live Response
Al enfrentarnos a un evento forense debemos tener en que cuenta que hay que ser lo menos invasivos
posible ya que cualquier cosa que hagamos puede alterar la información volátil dentro del sistema o
podría sobrescribir cualquier sector del disco que posea algún tipo de información que haya sido borrada.
Si es posible, lo ideal es inicialmente sacar una imagen RAW del sistema que se encuentra bajo
investigación. Posterior a esto en el evento de que se necesite acceder al sistema para la recolección de la
información volátil es necesario que solamente se ejecuten acciones que sean absolutamente necesarias a
la hora de interactuar con el sistema, como por ejemplo autenticarse dentro del sistema, aunque el solo
hecho de autenticarse ya está modificando dentro de la memoria RAM los valores de la paginación, es un
evento que es necesario y por lo tanto es aceptable. Los eventos que no son aceptables son aquellos que
8
NTDLL.dll es la librería dentro de los sistemas Windows que se encarga de ejecutar las funciones base del kernel.
[44]
63
siendo evitables no se tengan en cuenta y modifiquen el estado del sistema, como por ejemplo que los
resultados de las herramientas sean almacenados en archivos planos dentro del sistema que se encuentra
en estudio, porque esta acción podría sobrescribir sectores del disco que posean información relevante
para la investigación. Por lo anteriormente explicado, la primera medida que se debe tomar dentro de la
recolección de información es tener herramientas que tengan la posibilidad de redireccionar sus flujos de
salida a sistemas externos logrando de esta manera que el sistema investigado se mantenga intacto [32].
Existen tres maneras para recolectar la información adquirida en el sistema víctima y enviarla a un sistema
externo [32] [26].
Redireccionando los flujos utilizando funciones del sistema
Utilizando herramientas como Netcat o Cryptocat para realizar la administración remota de los
flujos.
Utilizar herramientas forenses que ya tengan incluida esta funcionalidad.
Dentro de cualquier proceso de Live Response independientemente de si es en una base de datos o en una
investigación de sistema de archivos, es necesario adquirir toda la información que se encuentre
relacionada con el estado del sistema. Esto implica que necesitamos adquirir los logs de auditoría del
sistema y todo tipo de datos de control que nos puedan proporcionar algún tipo de información acerca del
evento de seguridad, ya que en esta información podría residir algún tipo de evidencia que nos sirva para
esclarecer los hechos. La información clave y más general que podemos recaudar es la siguiente [32] [26].
Fecha y hora del sistema: La fecha y hora del sistema actual es la primera información que un
investigador debe recaudar ya que esta le permitirá tener un punto de partida para la investigación que
se vaya a realizar. Para adquirir esta información el investigador puede hacer uso de los comando
Date y Time, en caso de que la investigación se esté realizando en un sistema Windows [32]. Ver
Anexo 16.
Usuarios que se encuentren dentro del sistema: Es importante saber qué usuarios se encuentran
dentro del sistema y por cuánto tiempo, ya que el atacante se puede encontrar aún dentro del sistema.
Para esta tarea podemos hacer uso de herramientas como PsLoggedOn que nos permite saber que
usuarios se encuentran dentro del sistema [32] [26].
Lista de usuarios: La información de todos los usuarios que se encuentren dentro del dominio interno
de la máquina, sus privilegios y los grupos a los cuales pertenecen. Esta información la podemos
64
adquirir utilizando el comando net user para saber la lista de usuarios, y para saber el detalle de cada
uno usamos net user + Usuario [32] [26]. Ver Anexo 17.
Listado de conexiones y puertos: El listado de las conexiones y los puertos establecidos nos pueden
prestar gran ayuda en caso de que el ataque se encuentre en proceso o que la conexión aún se encuentre
establecida. Para encontrar la lista de conexiones podemos hacer uso del comando netstat y
combinarlo con los parámetros –a y –b que nos permitirán saber qué aplicaciones son las que las están
usando y bajo qué puertos están corriendo [32] [26].
Como se muestra en el Anexo 18, tenemos que ver cuáles son las conexiones que Oracle tiene
establecidas y ver a dónde es que se están conectando, ya que podríamos evidenciar el ataque que se
encuentre en proceso. En la imagen anterior podemos ver que aunque se encuentre en estado de
escucha, aún no hay ninguna conexión que se encuentre establecida [32] [26].
Listado de los procesos que se encuentran corriendo: Es necesario que se muestren los procesos y
las aplicaciones que se encuentren corriendo dentro de la máquina ya que esta información nos puede
dar detalles del ataque. Para adquirir esta información podemos hacer uso de herramientas como Fport
y PSLIST [32] [26].
Lista de DLL y objetos compartidos: Tener en cuenta que librerías fueron cargadas por medio de la
red [26].
Listados de Handles que se encuentren abiertos: Los handles son los manejadores de los procesos y
por medio de ellos podemos detectar procesos sin padres [26].
Realizar volcados de memoria: Los volcados de memoria deben realizarse aun si los procesos se ven
benignos ya que muchas veces se puede cargar código en espacios designados a procesos como
Notepad y demás [26].
Realizar volcados de memoria del sistema: Estos volcados cubren la información que posiblemente
no se alcance a revelar en los volcados de memoria. Para realizar los volcados dentro de un sistema
Windows, podemos utilizar la funcionalidad que provee Microsoft OEM package para realizar los
userdumps [32] [26].
Árbol y nombres de Archivos: Es necesario tener toda la información de cada uno de los archivos
que se encuentre dentro del sistema afectado. Se debe tener en cuenta que esta información debe tener
el nombre del dueño de cada archivo y quien está en la jerarquía [26].
65
Volcado de información del registro: La información del registro podría revelarnos la presencia de
cualquier tipo de rootkit [32] [26].
Copia de los logs del servidor: Todos los sistemas con arquitectura de servidor deben tener los logs
de mensajes y los logs de archivos [26].
Con la información anteriormente listada podemos obtener los datos que nos dan un valor agregado a la
investigación y que posiblemente nos aporten evidencia que pueda ser presentada en un corte, pero esta
información solamente no nos sirve en caso de que el ataque se haya hecho a una base de datos, ya que es
el nivel más general que nos puede proporcionar el sistema. Existen archivos de Oracle que nos pueden
proporcionar gran cantidad de evidencia en un evento de Live Response [26].
Los archivos de Oracle nos podrían proporcionar más información ya que son archivos más específicos y
nos dan una visión más acertada en caso de que una base de datos se vea comprometida. Los archivos que
nos pueden proporcionar más información dentro de un evento de Live Response son archivos de Log,
Trace y Control. Inicialmente es necesario verificar en el archivo de inicio del sistema de Oracle que se
encuentra en el home de la instanciapara saber las diferentes rutas que maneja la instancia de la base de
datos. Para esto debemos ir al registro y buscar la instancia de la base de datos a la cual queremos hacerle
seguimiento.
La
información
que
debemos
buscar
se
encuentra
en
Hkey_Local_Machine\Software\Oracle\Database_instance. Cada uno de los registros de la instancia nos
dice cuál es la ubicación dentro del disco de cada una de las instancias, específicamente nos dice la ruta
del home como se muestra en la ilustración 28. [26] Ver Anexo 19.
Una vez nos encontramos dentro de la ruta especificada, debemos buscar el archivo de inicio que se
encuentra en la carpeta database en los sistemas operativos Windows. El archivo usualmente se llama
“spfilesid.ora” donde el Sid es el Identificador del sistema [26]. Ver Anexo 19.
Dentro de este archivo encontraremos las rutas en las cuales se escriben los logs [26]. Ver Anexo 32.
A continuación vamos a realizar una explicación de cada una de las rutas.
Audit_File_Dest: En caso de que la auditoría se encuentre habilitada y configurada para
almacenarse en el sistema de archivos del sistema operativo, los archivos serán almacenados en
esta locación [26].
66
Background_dump_dest: En esta ruta se encuentran los archivos de seguimiento del sistema y el
alert.log de los procesos que corren en Background [26].
Core_Dump_Dest: Los volcados del núcleo de del servidor Oracle son colocados en esta ruta
[26].
Db_Recovery_file_Dest: En esta dirección se encuentra el área del flash recovery y también se
encuentran todos los Redo Logs que hayan sido almacenados en caso de que el proceso de
Archiver se encuentre activado [26].
User_Dump_Dest: Archivos de información del seguimiento de todos los usuarios se encuentran
en esta ruta [26].
User_File_Dir: En esta dirección se encuentran los archivos de PL/SQL de entrada y salida,
como por ejemplo UTL_FILE [26].
Control_Files: Los archivos de control contienen la información de todos los archivos de Datos
(Data Files) [26].
Db_create_online_log_dest_n: En esta ruta es donde se encuentran los Redo Logs. La n es el
número del redo log al cual se desea acceder y comienzan desde 1 [26].
Log_archive_dest, log_archive_dest_n and log_archive_duplex_dest: Este directorio también
nos puede servir para almacenar Redo Logs.
Oracle_Data_Files: Los archivos de control poseen las rutas en las cuales se encuentran los
archivos de datos (Data Files), ya que en muchos casos los Archivos de datos pueden llegar a ser
del tamaño de varias Teras, o en algunos casos de Pentas. Es muy complicado realizar una copia
a un servidor de recolección, por esto, en caso de no ser posible el almacenamiento total de la
misma debemos copiar aquella información que pueda ser más importante, como lo son los
espacios de tabla SYSTEM, SYSAUX, TEMP y UNDO [26].
External_Files: Oracle puede escribir archivos dentro del sistema operativo haciendo uso de las
funciones de la máquina virtual de java o utilizando el paquete UTL_FILEPL/SQL. El parámetro
de UTL_FILE_DIR determina en qué ruta es que Oracle lee o escribe los archivos externos. Estos
archivos deben ser recolectados para un posterior análisis dentro de un evento forense [26].
Listener_Log_Files:
Los
archivos
de
los
Listeners
se
encuentran
en
la
ruta
ORACLE_HOME/network/admin/listener.ora. Estos archivos contienen la información de que
recolecta el listener de los eventos de comunicación con la base de datos. La información que se
encuentre dentro de estos archivos puede ser modificada en caso de que no posea una contraseña
configurada en el estado, que aplica por ejemplo para versiones como Oracle 9i. En muchos casos
67
el atacante puede modificar la ruta o hasta desactivarlos. Al correr el comando “lsnrctl status”
obtenemos la ruta actual en la cual se encuentran los logs del listener, al correr este comando se
obtiene la escritura de un registro del “Status” dentro del log [26]. Ver Anexo 33.
Realizando esto se genera una entrada en el log similar a la siguiente: [26]
06-APR-2007 01:30:04 *
(CONNECT_DATA=(CID=(PROGRAM=)(HOST=)(USER=david))(COMMAND=status)(ARG
UMENTS=64)(SERVICE=LISTENER)(VERSION=169869824)) * status * 0
Ya que hemos visto cuáles son los archivos más relevantes dentro de la base de datos y el sistema
operativo, pasaremos al análisis desde la base de datos para ver cuáles son los focos de análisis dentro de
ésta, haciendo uso del middleware SQLplus [26].
2.5.2.5.1.1 Sqlplus Para Búsquedas
En el proceso de Live Response, dentro de un evento forense, la conexión a la base de datos debe ser el
último paso que se debe realizar. Primero se debe recolectar toda la información anteriormente listada. En
ningún caso el investigador debe Ejecutar Sentencias DML como DELETE, UPDATE, INSERT ya que
modificarían el estado de la base de datos. Tampoco se deben usar sentencias como DROP o CREATE y
no se deben crear en ningún caso objetos incluso así sean temporales. No se debe en ningún caso otorgar
permisos, por lo cual las sentencias GRANT y REVOKE no se pueden usar. Tampoco se debe usar el
comando ALTER y tampoco usar DUMP para bajar la información que se encuentre en los Logs de
registro. Hay que tener en cuenta esto ya que sólo el hecho de conectarse a la base de datos ya está
generando un registro dentro de los logs del listener. Es importante que la persona que se encuentre
realizando la investigación se conecte con la cuenta SYS que en caso de que no, cada vez que realice una
acción se generaran registros dentro de la tabla de auditoría y estaríamos cambiando el estado de la base
de datos, además que también estaríamos generando registros dentro de los logs del sistema operativo.
Cuando el investigador vaya a conectarse a la base de datos debe realizarlo por medio de un middleware,
puesto que si no se hace, modificaría vistas como V$SQL que son alteradas cada vez que se use una
sentencia SQL [26].
68
Para este ejercicio el investigador se conecta utilizando sqlplus, pero antes de comenzar el investigador
debe verificar que los siguientes archivos se encuentren, y en caso de que la respuesta sea positiva,
entonces que verifique no contengan ninguna de las sentencias sql que puedan modificar el estado de la
base de datos, como las que se mostraron anteriormente [26].
$ORACLE_HOME/bin/LOGIN.SQL
$ORACLE_HOME/dbs/LOGIN.SQL
$ORACLE_HOME/SQLPlus/admin/glogin.sql
Muchas veces los atacantes pueden disfrazar sus sentencias modificando DBA_ROLE_PRIVS para que
no se vea una sentencia explícita de otorgamiento de privilegios como la siguiente [26]
SQL> SELECT GRANTEE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE = 'DBA';
GRANTEE
---------------------------SYS
SYSMAN
SYSTEM
Sin embargo podrán ser vistos en búsquedas de tablas aledañas como el siguiente [26]:
SQL> SELECT U.NAME FROM SYS.USER$ U, SYS.SYSAUTH$ A WHERE U.USER# =
A.GRANTEE# AND PRIVILEGE# = (SELECT USER# FROM SYS.USER$ WHERE NAME =
'DBA');
NAME
-----------------------------SYS
HACK101
SYSTEM
SYSMAN
Antes de conectarse a la base de datos o realizar cualquier actividad, todas las salidas del sistema deben
ser re direccionadas a un archivo de texto. Para realizar esto, se hace uso del comando SPOOL seguido
del nombre del archivo. El nombre del archivo debe tener el número del caso y la fecha y hora de
recolección [26].
69
C:\oracle\product\10.2.0\db_1\BIN>TIME
The current time is: 6:12:22.93
Enter the new time:
C:\oracle\product\10.2.0\db_1\BIN>DATE
The current date is: 27/03/2007
Enter the new date: (dd-mm-yy)
C:\oracle\product\10.2.0\db_1\BIN>SQLPLUS /NOLOG
SQL*Plus: Release 10.2.0.2.0 - Production on Tue Mar 27 06:12:29 2007
Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
SQL> SPOOL C:\IR-CASES\N0017\SQL-CASE-N0017-27-03-2007-06-12-
22.TXT
La conexión se debe realizar desde un computador externo utilizando la cuenta SYS como se muestra a
continuación [26].
SQL> CONNECT SYS/[email protected]:1521/ORCL AS SYSDBA
Una vez conectados se debe alterar el formato de hora para que se muestren las horas [26].
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
2.5.2.5.1.2 Obteniendo las sentencias SQL Anteriormente Ejecutadas
La primera sentencia de búsqueda que debe realizar un investigador es una copia de las últimas sentencias
SQL ejecutadas en el sistema, que puede ser obtenida de la vista fija V$SQL de la siguiente manera [26].
SQL> SELECT LAST_ACTIVE_TIME, PARSING_USER_ID, SQL_TEXT FROM V$SQL
ORDER BY LAST_ACTIVE_TIME ASC;
Con la anterior sentencia podemos obtener todas las consultas que se encuentren almacenas dentro de la
vista fija V$SQL. El número de estas consultas se encuentran alrededor de 2500 consultas. El
comportamiento cíclico de esta vista hace que cada vez que se ejecute una sentencia y la vista se encuentre
llena, ésta borrará el registro con fecha más antigua que encuentre. Al ser un número tan limitado, entre
más rápido se acceda a esta tabla después del incidente entonces mayor será la probabilidad de que se
encuentre algún tipo de rastro del ataque dentro de esta tabla. En cualquier caso, es necesario que se
realice la búsqueda así el servidor sea de alto rendimiento, ya que si se llega a encontrar información que
sea útil, podríamos obtener el usuario y la fecha en que se realizó la búsqueda. Cabe la pena anotar que
70
también esta información se encuentra disponible en los DUMPS de memoria que mostramos
anteriormente [26].
Desde Oracle 10g en adelante el historial del repositorio de Carga de trabajo Automática
(WorkLoadRepository) WRH$_SQLTEXT y WRH$_SQLSTAT, también contienen evidencia y se debe
consultar de la siguiente manera [26].
SQL> SET LONG 2000000000
SQL> SELECT ST.PARSING_SCHEMA_ID, TX.SQL_TEXT FROM WRH$_SQLSTAT ST,
WRH$_SQLTEXT TX WHERE TX.SNAP_ID = ST.SNAP_ID;
El parámetro “SET LONG 2000000000”, es para especificar el tamaño en que el sqlplus debe mostrar
caracteres del SQL_TEXT, ya que en caso de que no se especifique se verá truncado ya que de otra forma
será del tipo CLOB [26].
Dentro de la tabla WRH$_SQLTEXT hay una gran probabilidad de encontrar información que pueda llegar
a ser útil para la investigación. En esta tabla se pueden encontrar aquellas sentencias UPDATE, DELETE,
SELECT e INSERT y algunas sentencias ALTER que se tomaron un tiempo prudencial de ejecución.
Muchos de los ataques que se hagan por red y hagan uso de paquetes como UTL_INADDR, UTL_HTTP ,
UTL_SMTP y UTL_TCP se verán reflejados dentro de estas tablas en caso de que se haya hecho uso para
extraer la información por medio de la red [26].
Este método nos permite ver sentencias SELECT en caso de que el AUDIT haya sido deshabilitado. Una
vez la información que se encuentra dentro de estas consultas es salvada, podríamos pasar a la ejecución
de otras consultas. Es importante que se salve primero la información que está dentro de la tabla
WRH$_SQLTEXT puesto que las siguientes consultas que haremos sobrescribirán los registros que se
encuentren dentro de ésta [26].
Una vez tenemos esta información debemos entrar a analizar la información que se encuentre dentro del
log de auditoría. Para entrar a administrar la información que se encuentre dentro del log de auditoría
utilizamos la siguiente consulta [26].
71
SQL> SELECT * FROM AUD$;
2.5.2.5.1.3 Información de acceso al sistema utilizando AUD$
Dentro de la tabla de auditoría podemos encontrar toda la información acerca del acceso de los usuarios al
sistema .En la tabla de auditoría podemos encontrar que usuarios que se registraron en el sistema, pero en
caso de que la auditoria no se encuentre habilitada también podemos encontrar información en la vista fija
V$ACTIVE_SESSION_HISTORY que utiliza un buffer circular dentro del SGA para almacenar la
información del estado de las cuentas activas dentro del sistema. Esta información es almacenada
posteriormente dentro de la tabla WRH$_ACTIVE_SESSION_HISTORY como parte del Automatic
WorkLoad Repository. Para consultar esta tabla podemos utilizar la siguiente consulta [26].
SQL> SELECT USER_ID, SESSION_ID, SAMPLE_TIME FROM
SYS.WRH$_ACTIVE_SESSION_HISTORY
La anterior consulta nos suministra la información de las entradas al sistema pero adicionalmente
debemos recaudar la información de los usuarios que se encuentran dentro del sistema actualmente [26].
SQL> SELECT SID, USER#, USERNAME, TERMINAL, OSUSER, PROGRAM,
LOGON_TIME FROM V$SESSION;
2.5.2.5.1.4 Información de usuarios y roles
Es necesario seleccionar la lista de usuarios y de los roles que se encuentran actualmente configurados
dentro del sistema. Un investigador debe recolectar el password para determinar qué passwords son los
más factibles de ser descifrados por medio de un ataque de adivinación, verificar el estado actual de las
cuentas, esto quiere decir que debe verificar si la cuenta se encuentra abierta o cerrada y en caso de que se
encuentre cerrada ver a qué hora fue que cambio su estado a cerrada. También debemos ver la fecha de
creación de todas las cuentas de usuario y sus últimas fechas de cambio de contraseñas. Para recaudar esta
información podemos hacer uso de la siguiente sentencia [26] [33]:
SQL> SELECT USER#, NAME, ASTATUS, PASSWORD, CTIME, PTIME, LTIME FROM SYS.USER$ WHERE
TYPE#=1;
Una vez adquirimos la información relativa a los usuarios también debemos tener en cuenta a qué roles
pueden pertenecer los usuarios anteriormente listados, para hallar estos roles podemos utilizar esta
sentencia sql [26]:
72
SQL> SELECT USER#, NAME, PASSWORD, CTIME, PTIME FROM SYS.USER$ WHERETYPE#=0;
También debemos tener en cuenta dentro de la lista de roles, cuáles usuarios poseen permisos de DBA y
verificar que los usuarios que estén con estos permisos hayan sido avalados por el administrador de la base
de datos [26].
SQL> SELECT U.NAME AS "GRANTEE", U2.NAME AS "ROLE" FROM SYS.USER$ U, SYS.USER$ U2,
SYS.SYSAUTH$ A WHERE U.USER# = A.GRANTEE# AND PRIVILEGE# = U2.USER#;
La lista de privilegios de cada usuario debe ser extraída del sistema para la investigación que se está
llevando a cabo, esta lista la podemos sacar de las tablas del sistema SYS.USER$, SYS.USER$,
SYS.TABLE_PRIVILEGE_MAP, SYS.OBJ$ y SYS.OBJAUTH$. Para hallar esta información hacemos
lo siguiente [26].
SQL> SELECT U.NAME AS "GRANTEE", P.NAME AS "PRIVILEGE", U2.NAME AS "OWNER", O.NAME AS
"OBJECT" FROM SYS.USER$ U, SYS.USER$ U2,
SYS.TABLE_PRIVILEGE_MAP P, SYS.OBJ$ O, SYS.OBJAUTH$ A WHERE U.USER# = A.GRANTEE# AND
A.OBJ# = O.OBJ# AND P.PRIVILEGE = A.PRIVILEGE# AND O.OWNER#=U2.USER#;
Obtener la lista de todos los privilegios del sistema también es necesario [26].
SQL> SELECT U.NAME AS "GRANTEE", S.NAME AS "PRIVILEGE" FROM SYS.USER$ U, SYS.SYSAUTH$
A, SYS.SYSTEM_PRIVILEGE_MAP S WHERE U.USER# = A.GRANTEE# AND PRIVILEGE# = S.PRIVILEGE
ORDER BY U.NAME;
El informático forense o la persona que se encuentre encargada de realizar la investigación, debe buscar
además todos los permisos sobre los objetos [26].
SQL> SELECT OBJ#, OWNER#, NAME, TYPE#, CTIME, MTIME, STIME FROM
SYS.OBJ$ ORDER BY CTIME ASC;
Lista de tablas que hayan sido borradas [26]
73
SQL> SELECT U.NAME, R.ORIGINAL_NAME, R.OBJ#, R.DROPTIME, R.DROPSCN FROM
SYS.RECYCLEBIN$ R, SYS.USER$ U WHERE R.OWNER#=U.USER#;
2.5.2.5.1.5 Listado de cambios sobre los bloques
Cada Data file se encuentra separado en bloques de datos y cada bloque contiene un sello de tiempo que
indica la última fecha en el cual fue modificado el objeto, como por ejemplo cuando se usó por última vez
un commit. Cada sello de tiempo es almacenado en los SCN o System Commit Number, por ende cada
vez que se modifique una fila dentro del objeto, el SCN se actualizará con el sello de tiempo de la
modificación. Por ejemplo si usamos la siguiente sentencia [26].
SQL> SELECT O.ORA_ROWSCN, O.CTIME, O.MTIME, O.STIME, U.NAME, O.NAME FROM SYS.OBJ$ O,
SYS.USER$ U WHERE U.USER#=O.OWNER# ORDER BY 1;
Y su resultado es:
…
2282280 05-APR-07 06-APR-07 05-APR-07 SYS WRH$_SERVICE_WAIT_CLASS
2282280 05-APR-07 05-APR-07 05-APR-07 SYS WRH$_SERVICE_WAIT_CLASS_PK
2282280 05-APR-07 05-APR-07 05-APR-07 SYS P_TEST
2282280 05-APR-07 05-APR-07 05-APR-07 SYS VP_TEST
2282280 05-APR-07 05-APR-07 05-APR-07 SYS P_TEST
2282280 05-APR-07 05-APR-0705-APR-07 SYS VANISH
2282280 05-APR-07 09-APR-07 09-APR-07 SYS X
2282280 05-APR-07 06-APR-07 05-APR-07 SYS WRH$_SQLSTAT
2282280 05-APR-07 06-APR-07 05-APR-07 SYS WRH$_SYSTEM_EVENT
…
Si convertimos el SCN que encontramos dentro de la consulta a TimeStamp encontraremos lo siguiente
[26]. Para otro ejemplo ver Anexo 20.
SQL> SELECT SYS.SCN_TO_TIMESTAMP(2282280) FROM DUAL;
SYS.SCN_TO_TIMESTAMP(2282280)
-----------------------------------------------------------09-APR-07 14.39.56.000000000
74
2.5.2.5.1.6 Obtener la versión y el nivel de actualización de los parches
En una investigación es necesario saber bajo qué versión de Oracle el servidor se encuentra corriendo, ya
que en muchas ocasiones los parches de seguridad solucionan muchos de los huecos de seguridad de la
aplicación. Para hallar esta información se hace uso de sentencia presentada en el Anexo 34 [26].
2.5.2.6 ALGUNAS FUENTES DE EVIDENCIA EN LA AUSENCIA DE AUDIT TRAIL
En el mundo físico cuando un robo es cometido, usualmente es notado inmediatamente por la ausencia de
algún objeto, pero en el caso de la computación forense y particularmente de un servidor de base de datos,
cuando un atacante roba información, únicamente se lleva una copia de los datos mientras que las
versiones originales permanecen intactas y por ende es mucho menos inmediato y a la vez más complejo
detectar una situación de robo. Se hace necesario entonces detectar cuando un atacante ha obtenido acceso
no autorizado para ejecutar sentencias SELECT sobre los datos, incluso en el caso de que la función de
auditoría de Oracle (Audit trail) se encuentre desactivada. [34]
En la sección 2.5.2.2.1 revisamos cómo detectar los eventos en los cuales un atacante logra acceder a la
base de datos y crea objetos como funciones y tablas aun si posteriormente los elimina en un intento de
esconder sus acciones. Sin embargo, cuando el atacante ingresa y simplemente realiza consultas de tipo
SELECT para obtener información como, por ejemplo, usuarios y contraseñas de cuentas bancarias y
posteriormente se desconecta sigilosamente, puede ser mucho más complejo localizar evidencia de dichas
acciones. Aun si la auditoria Oracle se encuentra desactivada, existen algunos lugares donde podemos
buscar evidencia de la ejecución de sentencias SELECT, por ejemplo el repositorio automático de carga
de trabajo AWR9, el optimizador basado en costos CBO10 y algunas vistas fijas en el área de memoria
compartida. [34]
2.5.2.6.1 Optimizador basado en costos CBO
Cada vez que un usuario ejecuta una consulta SQL, el servidor necesita compilarla en un plan de
ejecución. EL CBO es el encargado de hacer esto de la mejor manera, es decir, reduciendo al mínimo la
cantidad de recursos del sistema usados para atender la consulta. Estadísticas acerca del CBO son
guardadas en tablas por el proceso de segundo plano Monitor del sistema SMON11. Una de dichas tablas
es la tabla COL_USAGE$, la cual es usada para guardar información sobre los predicados usados en las
sentencias SELECT, en otras palabras, las columnas usadas en una clausula WHERE y el tipo de
9
AutomaticWorkloadRepository
CostBasedOptimizer
11
System Monitor
10
75
predicado, entre otras cosas. Esta tabla suele ser actualizada cada veinte minutos por el proceso SMON.
La información almacenada en esta tabla puede ser usada por un investigador forense para inferir detalles
relacionados a consultas SELECT que han sido ejecutadas en la base de datos, las cuales pueden indicar
cuándo es posible que haya ocurrido un robo de información o no. Antes de continuar es importante
revisar la definición de la tabla mencionada haciendo uso de la sentencia DESC [34]. Ver Anexo 35.
La columna OBJ# contiene el ID de objeto de la tabla que está siendo consultada y la columna INTCOL#
contiene el número de columna, tomado tal cual, de la columna COL# en la tabla COL$, usada en el
predicado. Entonces, por ejemplo, si Z está definida en COL$ como la tercera columna en la tabla
COLTEST y una consulta of „SELECT * FROM COLTEST WHERE Z = 0‟ es ejecutada, entonces la
columna INTCOL# en la tabla COL_USAGE$ tendrá un valor de 3. La columna TIMESTAMP guarda el
segundo más cercano al momento en que la entrada fue añadida a la tabla COL_USAGE$ y no al
momento en que la consulta que está siendo registrada fue ejecutada. Tener en cuenta esto es de gran
relevancia a la hora de construir una línea de tiempo de eventos. Como el proceso SMON realiza cambios
a la tabla COL_USAGE$ cada veinte minutos, puede haber una desviación de máximo 20 minutos para
una entrada determinada. Otro aspecto a notar sobre la columna TIMESTAMP es que, si una nueva
consulta sobre la misma tabla usando el mismo predicado es ejecutada, la columna TIMESTAMP es
actualizada; así, entradas anteriores serán sobrescritas. Las columnas restantes indican el tipo de
predicado. Por ejemplo, una entrada para EQUALITY_PREDS será generada después de una consulta
„SELECT X FROM COLTEST WHERE Z = 5‟. Una fila será generada para RANGE_PREDS después de
una consulta „SELECT X FROM COLTEST WHERE Z > 0 AND Z < 100‟. Una fila NULL_PREDS será
generada luego de ejecutar una sentencia „SELECT Y FROM COLTEST WHERE Y IS NULL‟ y
finalmente una fila LIKE_PREDS se generara después de una consulta „SELECT Y FROM COLTEST
WHERE Y LIKE „%A%‟‟. [34]
Al volcar los contenidos de esta tabla podemos obtener una imagen completa de cuáles tablas fueron
consultadas, qué columnas fueron usadas y qué predicados se utilizaron. Para obtener un formato de
resultados más claro, cada tipo de predicado puede ser consultado por separado. Por ejemplo, un volcado
de los predicados LIKE_PREDS puede realizarse como se muestra a continuación [34]:
76
Ilustración 7: Volcado de los predicados LIKE_PREDS [34]
Si nos fijamos en la primera fila de información podemos notar que alguien ha seleccionado de la tabla
COL$ usando la sexta columna con un predicado LIKE. Como es el caso, esta fila ha sido creada en la
tabla COL_USAGE$ luego de que un atacante, en su búsqueda de tablas interesantes de las cuales volcar
información, ejecuto la siguiente consulta SQL [34]:
SQL> SELECT TABLE_NAME FROM DBA_TAB_COLS WHERE COLUMN_NAME LIKE
'%CREDITCARD%';
DBA_TAB_COL es una vista que mapea en la tabla COL$, COLUMN_NAME corresponde a la sexta
columna en la tabla COL$ que es NAME, en otras palabras el nombre de la columna. Un aspecto a notar
es que la columna OBJ# en la tabla COL_USAGE$ no se refiere al ID de objeto de la vista sino al de la
tabla subyacente.
Claramente para que este método sea útil, necesitamos adquirir una línea base con la cual la información
actual pueda ser comparada. Esta línea base puede ser establecida de varias maneras. Si se ha realizado
una copia de seguridad de la tabla COL_USAGE$ se pueden realizar comparaciones con dicha copia,
siempre que dicha copia haya sido realizada en un momento fuera de la intrusión. Si no se tienen copias de
seguridad de la tabla COL_USAGE$ disponibles, puede ser posible determinar, a través de exámenes a las
aplicaciones de bases de datos de la organización y de conversaciones con DBAs y desarrolladores, cuáles
tablas deberían aparecer en la tabla COL_USAGE$ y bajo qué circunstancias. Por ejemplo, si las
aplicaciones de la organización únicamente consultan las tablas 1, 2 3 y resulta que la tabla 4 aparece en
los datos de la tabla COL_USAGE$, uno podría inferir entonces que esto está fuera de lo normal,
implicando investigaciones adicionales. Existen algunas limitaciones cuando nos enfrentamos a inferir
77
detalles de ataques usando la información de la tabla COL_USAGE$. Si nos fijamos con mayor detalle, si
un atacante no implica en su consulta una columna de la tabla en cuestión, entonces no se generara
ninguna entrada en la tabla COL_USAGE$. Así si un atacante realiza la consulta „SELECT PASSWORD
FROM SYS.USER$ WHERE NAME = „SYS‟„, entonces una fila será creada. Sin embargo si la consulta
fuera „SELECT PASSWORD FROM SYS.USER$„ ninguna fila sería creada. [34]
Si un atacante puede ejecutar consultas SQL arbitrariamente con privilegios de DBA, por ejemplo
explotando una brecha de PL/SQL injection, el atacante puede realizar sentencias DELETE en esta tabla.
Sin embargo al llevar a cabo dichas acciones, la evidencia de dichos DELETE quedaría en los Redo Logs
así como en los data files, como se explicó previamente en las secciones 2.5.2.1. y 2.5.2.2. [34]
2.5.2.6.2 Vistas Fijas V$ en el área compartida (shared pool)
Existen varias tablas virtuales y vistas que Oracle mantiene con propósitos de rendimiento. Estas vistas
son accesibles a los DBAs y en algunas ocasiones pueden contener evidencia de ataques. Dos de dichas
vistas son de nuestro particular interés, V$SQL y V$DB_OBJECT_ CACHE. La vista fija V$SQL
contiene una lista de las sentencias SQL ejecutadas recientemente. Ésta es un buffer circular por lo cual a
medida que se va llenando de nueva información, va desechando información antigua. Dependiendo del
tamaño del área compartida (shared pool) y de la longitud de cada consulta, el buffer puede contener una
gran cantidad de consultas antes de que las antiguas sean borradas. La siguiente consulta nos permite
volcar información de la vista V$SQL [34]:
SQL> SET LONG 3000000
SQL> SELECT LAST_ACTIVE_TIME, PARSING_USER_ID, SQL_FULLTEXT FROM V$SQL;
Evidencia de las actividades de un atacante puede ser hallada en esta vista fija y un examen cuidadoso del
SQL_FULLTEXT debería revelarla. Debemos subrayar que si un atacante puede encontrar un modo de
ejecutar SQL arbitrariamente como DBA, de los cuales hay varios mencionados en la sección 2.4.2,
entonces dicho atacante podrá borrar las sentencias SQL de esta vista ejecutando la sentencia ALTER
SYSTEM FLUSH SHARED_POOL‟. [34]
La vista V$DB_OBJECT_CACHE contiene detalles sobre objetos en la librería cache. Existen dos
puntos de interés con respecto a esta vista en particular. El primero es que, si un objeto existe en el cache
78
entonces este probablemente ha sido accedido recientemente, y el segundo es que esta vista puede
contener segmentos de sentencias SQL ejecutadas recientemente [34]. Ver Anexo 36.
El tipo de información almacenada en la columna NAME depende de la columna NAMESPACE. Si la
columna NAMESPACE de una fila es „CURSOR‟ entonces NAME contiene información SQL, si
NAMESPACE es „TABLE/PROCEDURE‟ entonces NAME contiene una tabla o proceso accedidos
recientemente. Así para volcar una lista de consultas ejecutadas recientemente podemos ejecutar [34]:
SQL> SELECT NAME FROM V$DB_OBJECT_CACHE WHERE NAMESPACE = 'CURSOR';
Así mismo para acceder a una lista de procesos y tablas accedidas recientemente podemos ejecutar [34]:
SQL> SELECT OWNER, NAME FROM V$DB_OBJECT_CACHE WHERE NAMESPACE =
'TABLE/PROCEDURE' ORDER BY 1;
Examinando esta información un investigador forense puede determinar si contiene evidencia de un
ataque. Esta vista fija ofrece ciertas ventajas sobre la vista V$SQL. Como ya se indicó, un atacante puede
eliminar la información de la vista V$SQL al ejecutar la sentencia ALTER SYSTEM FLUSH
SHARED_POOL‟, sin embargo, la información de la vista V$DB_OBJECT_CACHE permanece intacta
aun después de la ejecución de dicha sentencia [34].
2.5.2.6.3 Repositorio automático de carga de trabajo AWR
El AWR o repositorio automático de carga de trabajo es usado para recolectar estadísticas relacionadas al
rendimiento. Este guarda información detallada sobre consultas SQL y acceso a objetos y por esto mismo
puede revelar las acciones que un atacante haya tomado. El AWR tiene algunas ventajas frente a las vistas
V$ pues su información es persistente en comparación con la de las vistas V$ que se pierde cuando la base
de datos es desactivada y reiniciada, pero tiene la desventaja de que necesita tomar una “instantánea”, una
vez cada hora, al mismo tiempo que el ataque está en curso. Asumiendo que algunas de las acciones del
atacante han sido capturadas por el AWR entonces las podemos hallar ejecutando la siguiente consulta:
SQL> SELECT ST.PARSING_SCHEMA_ID, TX.SQL_TEXT FROM WRH$_SQLSTAT
ST,
WRH$_SQLTEXT TX WHERE TX.SQL_ID = ST.SQL_ID;
79
Para localizar consultas “interesantes” podemos obtener un timestamp referenciando el SQL_ID:
SQL> SELECT TIMESTAMP FROM WRH$_SQL_PLAN WHERE SQL_ID = „b7v16a01s0f86‟
2.5.3 HERRAMIENTAS ÚTILES EN UN ENTORNO ORACLE
2.5.3.1 LogMiner
LogMiner es una herramienta que provee dos funcionalidades a las bases de datos Oracle. La primera
funcionalidad es la capacidad de LogMiner para recrear el estado de la base de datos en un determinado
instante de tiempo. La segunda funcionalidad es que LogMiner permite a los investigadores forenses
recrear los eventos acontecidos en una línea de tiempo, logrando de esta manera evidenciar paso a paso las
acciones realizadas por los atacantes. Esta segunda funcionalidad es en la que nos enfocaremos, logrando
utilizar sus fortalezas para conseguir evidencia que sea verificable y repetible dentro de una investigación
forense. Los Redo Logs son el insumo principal para LogMiner, ya que en ellos se encuentra la
información histórica del uso de la base de datos. Dentro de cada Redo Log se encuentra todo tipo de
información de manejo de la base de datos, desde datos de creación y eliminación de tablas (DDL),
sentencias de actualización y selección de datos (DML), hasta el tiempo en que se realizó el cambio en la
base de datos y quién realizó la acción. [35] [33] [36]
2.5.3.1.1 Funcionamiento
LogMiner es una herramienta de Oracle que permite recuperar el estado de una base de datos en un
determinado lapso de tiempo. También permite a los investigadores forenses recrear los eventos sucedidos
dentro de la base de datos para realizar una investigación para así poder recaudar pruebas que puedan ser
presentadas ante una corte en un juicio formal. Por esta razón es necesario saber cuál es su funcionamiento
y cuál es estructura. A continuación explicaremos los principios básicos de la herramienta y su forma de
proceder para generar la evidencia. [36] [33] [35]
2.5.3.1.2 Principios
LogMiner hace uso del diccionario de datos, éste en conjunto con los Redo Logs, le permiten a LogMiner
recrear la información histórica. El diccionario de datos se encuentra en el espacio de memoria del SGA
(System Global Directory). Dentro del SGA también se encuentra información útil para que LogMiner
pueda recrear eventos dentro de una línea de tiempo, como por el ejemplo el nombre y la cantidad de
tablas que posee esa instancia de la base de datos. Los Redo Logs son los archivos que poseen toda la
información de la base de datos, desde su creación hasta la última inserción que se realizó en una tabla.
80
Cada registro de un redo log se realiza en el momento en que una transacción se consuma, es decir, cada
vez que se realice una inserción o en un borrado y se dé la instrucción COMMIT. Este almacenamiento de
datos no se realiza en un archivo legible por ASCCI sino que se almacena de forma binaria, por lo cual no
se puede leer a simple vista, y por ende es necesario que se utilice Logminer o algún editor hexadecimal.
[35] Cada vez que se presenta una instrucción COMMIT, el sistema asigna un número de secuencia para
poder identificar posteriormente el orden de los acontecimientos. Este número es conocido como SCN y
aunque se encuentra relacionado con el orden de los acontecimientos, no es un dato que podamos tener en
cuenta para relacionar directamente con el tiempo real del acontecimiento, para que se pueda realizar un
seguimiento detallado de los eventos sobre una base de datos es necesario que el proceso del ARCHIVE
MODE se encuentre en true, ya que este proceso es el encargado de sacar copia del Redo Log a medida
que estos se van llenando. Este proceso por defecto y en la instalación estándar se encuentra en false. [35]
Logminer se encuentra compuesto por los siguientes paquetes [35]:
Dbmlsmd.sql
Dbmlsm.sql
Dbmlsms.sql
Plitblm.sql
Prvtlmd.plb
Prvtlm.plb
Prvtlmrd.plb
Prvtlms.plb
Principalmente paquetes de dos tipos; .plb y .sql, los .sql son paquetes que poseen sentencias SQL y los
.plb son archivos que poseen código PL/SQL que por disposición de Oracle, estos se encuentran
codificados y protegidos para que no se les hagan modificaciones [33] [35].
Con los datos anteriormente explicados, podemos entrar a exponer cuál es la forma en la que funciona
LogMiner de una manera más detallada [35].
2.5.3.1.3 Proceso
Inicialmente el proceso LOGWRITTER de Oracle se encarga de escribir los eventos que sucedan sobre la
base de datos en el buffer de los Online Redo Logs que se encuentra ubicado en el espacio de memoria
SGA. Una vez se encuentra esta información en el buffer, está es llevada a los archivos de los Redo Logs
81
que se encuentran almacenados dentro del disco duro del sistema en el cual se encuentre corriendo la base
de datos. Esta operación se realiza cada vez que se envíe una sentencia COMMIT o cada vez que pasen 3
segundos. Los Redo Logs son llenados de manera secuencial por el proceso LGWR, por los cual la
información que es almacenada dentro de los Redo Logs se encuentra almacenada de manera secuencial,
cosa que es fundamental para poder recrear una secuencia de eventos. Esto se debe a que en caso de que se
necesite recuperar el estado de una base de datos, se pueda recrear de manera idéntica a la original [35]
[36].
Una vez los Redo Logs que fueron creados se llenan, el LGWR sobrescribe de manera cíclica los Redo
Logs anteriores, por lo que existe un proceso que se encarga de descargar la información que hay en ellos
y almacenarla en un lugar diferente. De esta manera el Logwritter puede seguir escribiendo los eventos sin
perder la información histórica de la base de datos, proceso llamado ARCHIVER PROCESS o ARC. En
la instalación por defecto, este proceso se encuentra en false, por lo cual cada vez que se llenen los Redo
Logs la información histórica será sobre escrita. Oracle permite la multiplexación de estos archivos, es
decir, copias de los archivos en diferentes locaciones. Esta funcionalidad permite a un investigador
realizar un análisis de la base de datos sin tener que tocar el sistema original, además que proporciona
otras ventajas a la hora de realizar una investigación, ya que se puede realizar comparaciones entre las
copias para verificar que no haya sido ninguna alterada [36] [33].
Finalmente Logminer usará los Redo Logs como insumo principal para poder realizar consultas sobre los
hechos acontecidos haciendo uso del lenguaje SQL y proporcionando una interfaz de consulta con una
menor dependencia técnica [33] [36].
2.5.3.1.4
Configuración
Por defecto las funcionalidades de LogMiner se encuentran desactivadas, por lo tanto es necesario validar
que dentro del servidor que se encuentren configuradas las rutas de almacenamiento del diccionario, para
poder hacer uso de esta herramienta. Inicialmente debemos validar la ruta del diccionario de datos, para
esto podemos hacer uso de la siguiente sentencia. Ver Anexo 21 [37]
Select value from v$parameter where name='utl_file_dir';
Si la herramienta ya se encuentra configurada entonces aparecerá la ruta en la cual se almacenaran los
diccionarios de datos, en caso de que no sea así, entonces la tendremos que configurar de esta manera.
[37]
alter system set utl_file_dir='[ruta]' scope=spfile;
82
Ya que modificamos un valor dentro del archivo de parámetros del sistema, entonces debemos reiniciar la
base de datos para que esta tome los nuevos cambios que fueron colocados para el inicio de la ruta del
diccionario de datos como se muestra en el Anexo 21. Luego de esto se vuelve a validar la ruta de
configuración del diccionario.
2.5.3.1.5 Creación del diccionario
El diccionario es el archivo encargado de almacenar un listado general de aquellos Online Redo Logs u
Offline Redo Logs que se vayan a analizar dentro de la investigación. Para crear un diccionario de datos
debemos ejecutar la siguiente sentencia. [37]
exec
DBMS_LOGMNR_D.BUILD(
DICTIONARY_FILENAME
=>'[nombre
del
fichero]',
DICTIONARY_LOCATION => '[ruta donde crear el fichero]');
Ilustración 8: Creación diccionario de datos
Es necesario que se cree el diccionario dentro de la carpeta que fue especificada anteriormente en la
configuración inicial de LogMiner.
2.5.3.1.6 Agregar Logs al diccionario de datos
Una vez hemos creado nuestro diccionario, ya podemos cargarlo con los archivos que deseamos
investigar, para hacer esto debemos usar la siguiente sentencia. Ver Anexo 22
exec DBMS_LOGMNR.add_logfile('[fichero REDO con ruta completa]');
Una vez ya tenemos nuestros archivos de investigación cargados en el diccionario de datos, entonces ya
podemos comenzar a analizarlos.
En caso de que ya no queramos analizar un archivo que se encuentre incluido dentro del diccionario
podemos utilizar la siguiente sentencia para eliminarla del diccionario de datos. [37]
exec DBMS_LOGMNR.REMOVE_LOGFILE (LOGFILENAME => '[fichero REDO con ruta completa]');
83
2.5.3.1.7 Iniciar Logminer con un diccionario de datos especificado
Para iniciar Log Miner podemos hacerlo de dos formas. La primera forma es únicamente colocando el
archivo de diccionario especificado que posteriormente le proporcionara a logminer el acceso a los
archivos que en él fueron configurados anteriormente. La segunda forma es especificando la actualización
automática de las sentencias DDL. [37]
Forma 1
exec
DBMS_LOGMNR.START_LOGMNR(DICTFILENAME
=>'[ruta
y
nombre
del
diccionario]');
Forma 2
exec DBMS_LOGMNR.START_LOGMNR(DICTFILENAME =>'[ruta y nombre del diccionario]',
OPTIONS => -DBMS_LOGMNR.DDL_DICT_TRACKING
);
2.5.3.1.8 Creación de las secuencias de tiempo
Para ver la creación de secuencias de tiempo mirar Anexo 46.
2.5.3.1.9 Problemas
Para ver los problemas comues que posee Log Miner ver 5.45
2.5.3.1.10 Timestamps
Dentro de LogMiner por medio de la instrucción descc$logmnr_contents podemos ver los tipos de datos
que maneja la aplicación. Si aplicamos esta instrucción, podemos ver que el TIMESTAMP dentro de la
aplicación maneja un tipo de datos date, que no es un tipo de datos TIMESTAMP. Los tipos de datos date
solamente tienen una precisión de un segundo, por lo cual cuando logminer lo traduce, únicamente lo
coloca en un date y de esta forma lo presenta, lo cual es un inconveniente ya que muchas transacciones
pueden haberse realizado en el mismo segundo y por ende hace imposible saber cómo diferenciar una
transacción de otra, por lo que no se puede saber el tiempo en exacto para ser presentado dentro de una
corte. [35] [33] [36]. Ver Anexo 23.
84
2.5.3.2 SANS 2010 TOOLS
David Litchfield ha hecho un gran aporte a nivel investigativo en todo lo relacionado con análisis forense
sobre bases de datos Oracle y hace algunos años noto la necesidad de contar con herramientas forenses
específicamente pensadas para proveer al examinador forense los medios para extraer de forma sencilla y
confiable la información de las diversas fuentes de evidencia en la base de datos Oracle. En torno a esta
situación, Litchfield ha venido trabajando en un conjunto de herramientas que ha publicado, en una
versión preliminar, en la página web de su compañía V3rity Software, dichas herramientas han sido
empaquetadas provisionalmente bajo el nombre de “SANS 2010 Tools” y dentro de dicho paquete
encontramos:
Dumpaction: Al parecer una versión mejorada de su herramienta “ddldump” pues permite volcar las
entradas DDL de un archivo Redo Log a un archivo XML fácilmente comprensible. Afirmamos que es
una nueva versión pues en “ddldump” encontramos algunos errores a la hora de crear las etiquetas de
cierre del campo <SQL STATEMENT> y en “dumpaction” se añade la funcionalidad de volcar las
sentencias INSERT cambiando el parámetro “ddl” por “ins”. Las funcionalidades para volcar
sentencias DELETE y UPDATE vienen enunciadas pero al intentar usarlas aparece un mensaje que nos
informa que aún se encuentran en etapa de desarrollo.
Dumpextents: Permite extraer la información de un Undo File de Oracle y marca las entradas de
interés para un examinador forense, tales como filas eliminadas, inserción de datos, etc.
Filter: Recibe como parámetros dos archivos XML, el primero debe contener el volcado generado
anteriormente por dumpaction y el segundo contiene la información de filtro que deseamos aplicar a las
entradas del primer archivo. Litchfield provee algunos ejemplos de filtro:
o
Filt1: extrae las entradas relacionadas con un parámetro deseado, en este caso las que tienen un
valor de 511 en el parámetro OBJECT_ID. Ver Anexo 36.
o
Filt-bool: extrae únicamente las entradas para las cuales se cumple un predicado booleano, en este
caso, las entradas con CURRENT_USER igual a SYS y SESSION_USER diferente. Esto será de
gran utilidad en el capítulo 2.6.1 para estudiar con mayor facilidad las acciones de un atacante.
Ver Anexo 36.
o
Filt-grant: extrae todas las sentencias para las cuales el campo SQL_STATEMENT contiene una
expresión determinada, en este caso “GRANT DBA”. Ver Anexo 36.
85
o
Filt-xid: extrae las entradas para las cuales el campo XID, que representa el identificador de la
transacción, sea igual al contenido entre las etiquetas<WHAT>. Ver Anexo 36.
Orablock – Oratime: Previamente publicadas bajo el nombre de CADFILE. Orablock permite
determinar cuándo un bloque de datos Oracle ha sido modificado sin necesidad de montar los data files
en un servidor Oracle, lo cual haría que se modifiquen. Oratime toma un SCN Timestamp de un Redo
Log y lo convierte a Fecha y Hora. [38] [39] Ver Anexo 36.
2.6 CASO DE ESTUDIO
Para validar las técnicas y herramientas mostradas en los capítulos anteriores presentaremos a
continuación, un caso de estudio en el cual, tras realizar un ataque de escalamiento de privilegios,
pasaremos a tomar ventaja de la máquina virtual de java implícita en Oracle, denominada Aurora, para
obtener o “concedernos” permisos arbitrarios de Java., los cuales, entre otras cosas, son necesarios para
leer y escribir archivos y para ejecutar sentencias de sistema operativo. Dichos permisos son almacenados
en Oracle en la tabla JAVA$POLICY$. Dentro de los paquetes PL/SQL instalados por defecto en Oracle,
se encuentra el paquete DBMS_JVM_EXP_PERMS, que fue pensado para permitir migrar las políticas de
Java entre distintos servidores de base de datos, y que va a ser nuestra puerta de entrada hacia la
adquisición de privilegios o permisos arbitrarios de Java. El paquete mencionado, es propiedad de SYS
pero es ejecutable por PUBLIC. Dentro del paquete encontramos un procedimiento llamado
IMPORT_JVM_PERMS que recibe como parámetro una Java Policy. Usaremos precisamente esta
característica para crear nuestra propia política Java, dentro de la cual incluiremos un ataque de PL/SQL
injection que nos concederá permisos Java de entrada y salida sobre archivos. Como el procedimiento es
ejecutado con privilegios de SYS, por tratarse de un paquete que define derechos, nuestra política es
agregada a la tabla. [15] [14]. Ver Anexo 24.
2.6.1 EVIDENCIA DE LAS ACCIONES DEL ATACANTE
Sabiendo que se realizó el ataque exitosamente, veremos las posibles pistas que el atacante dejo en las
diferentes fuentes de información. Ver Anexo 25.
86
2.7
TECNICAS ANTI FORENSES EN BASES DE DATOS ORACLE
2.7.1 Técnicas anti forenses en contra del Redo Log
Si un usuario consigue privilegios de DBA, por ejemplo, a través de SQL injection, entonces puede
entremeterse con los Redo Logs. Esto puede ser tan simple como ejecutar el comando ALTER DATABASE
CLEAR LOGFILE el cual limpia completamente todas las Redo Entrys de los archivos de Log removiendo
la mayoría de la evidencia de lo que hizo. Sin embargo al ejecutar el comando, el texto de la sentencia se
registrara en el archivo Redo actual, como se menciona en la sección 2.5.2.1 . Muchas veces un ataque de
destrucción evidencia genera nueva evidencia. Intentar limpiar el registro actual resultará en error [16] [3].
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
ALTER DATABASE CLEAR LOGFILE GROUP 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of instance orcl (thread 1)
ORA-00312: online log 1 thread 1:
'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG'
Aun si el atacante cambia el archivo de Log usando el comando “ALTER SYSTEM SWITCH
LOGFILE”, el nuevo archivo Log contendrá cualquier intento de borrar el archivo. Intentar borrar el
archivo de Log usando UTL_FILE falla debido a una violación de intercambio [16].
Cualquier intento de limpiar los Redo Logs de estas maneras será advertido. Un atacante astuto puede en
lugar de esto elegir escribir o sobre escribir entradas validas con entradas falsas en los Redo Logs.
Entendiendo como se genera la suma de comprobación para un bloque dado, todos las acciones DDL y
DML del atacante pueden ser sobre escritas dejando el resto del archivo Log intacto. Esto será difícil de
detectar [16].
Si un sistema no está corriendo en modo de archivado, un atacante sin permisos de DBA puede cubrir sus
huellas o al menos reemplazarlas con actividad de apariencia más benigna. Por ejemplo, puede realizar
múltiples INSERTS en una tabla y cuando los archivos de Log se van llenando y se cambian, las entradas
previas se sobrescribirán [16].
87
2.7.2 Técnicas anti forenses contra los rastros dejados por la eliminación de objetos
Un atacante profesional debe dejar la menor cantidad de rastros y por ende es poco probable que cree y
elimine muchos objetos. De hecho, al usar un ataque de CURSOR INJECTION [40], un atacante no
necesita crear objetos de ningún tipo. Teniendo conocimiento de cómo se crea y se verifica el checksum de
un bloque, como se explicó en la sección 2.7.1. , no está más allá de los medios técnicos de un atacante el
modificar el bloque sobre la marcha usando UTL_FILE o Java desde dentro de la misma base de datos
para esconder sus acciones del investigador forense.
2.7.3 Técnicas anti forenses en contra de las tablas de auditoria
Como se explicó en la sección 2.5.2.3, un atacante que haya realizado un escalamiento de privilegios
exitoso, puede hacer uso de una sencilla técnica anti forense de eliminación consistente en realizar un
DELETE bien sea de las filas relacionadas a su usuario en la tabla SYS.AUD$, o cualquier otra tabla del
Audit Trail de Oracle, o sencillamente todas las filas de la tabla en cuestión. Esta acción puede ser
detectada por un examinador forense tanto en los Redo Logs como en los Data Files En los primeros se
almacenara la sentencia DELETE como tal en los segundos permanecerán temporalmente las filas
marcadas como eliminadas mientras llega el momento de reutilizar el espacio que ocupaban.
2.8 GUÍA METODOLOGICA PARA EL ANÁLISIS DE BASES DE DATOS ORACLE
Ilustración 9: Mapa de Acción
88
A continuación mostraremos cual es la manera en la que un investigador forense debe abordar una escena
que involucre un manejador de bases de datos Oracle.
1. Verifique el estado del servidor
a. En caso de que el servidor este apagado valide por qué está apagado con el DBA o la
persona a cargo y bajo qué circunstancias se apagó.
b. En caso de estar prendido continúe.
2. Recoja la información Volátil
a. Recaude la fecha y la hora del sistema usando el comando date. (Ver Live Response).
b. Recoja los usuarios que se encuentren actualmente activos dentro del sistema. (Ver Live
Response).
c. Recaude la información de todos los usuarios dentro del directorio activo. (Ver Live
Response).
d. Lista de conexiones y puertos. (Ver Live Response).
e. Listado de procesos actualmente en ejecución dentro de la máquina. (Ver Live Response).
f.
Lista de DLL y objetos compartidos. (Ver Live Response).
g. Listados de Handles que se encuentren abiertos. (Ver Live Response).
h. Realizar volcados de memoria. (Ver Live Response).
i.
Realizar volcados de memoria del sistema. (Ver Live Response).
j.
Árbol y nombres de Archivos. (Ver Live Response).
k. Volcado de información del registro. (Ver Live Response).
l.
Copia de los logs del servidor. (Ver Live Response).
3. Conéctese a la base de datos utilizando el usuario SYS as SYSDBA.
4. Recaude la información que se encuentra en las vistas fijas V$SQL, WRH$_SQLSTAT y
WRH$_SQLTEX
5. Desconéctese de la base de datos. (Ver validación listener)
6. Conéctese al TNSlistener colocando en la consola tnslstnr. (Ver validación listener)
7. Verifique la versión del TNSlistener. (Ver validación listener)
8. Verifique si el listener se encuentra activado (Ver validación listener)
89
9. Verifique la ruta en que se están almacenando los logs. (Ver validación listener)
10. Recolecte los logs que se encuentran especificados en el paso 9.
11. Una vez tenga estos datos desconéctese del TNSListener.
12. Conéctese a la base de datos Utilizando Usuario SYS
13. Recolecte la información de acceso al sistema utilizando AUD$ (Ver tabla AUD$).
14. Recoja la información de usuarios y roles (Ver Usuarios y roles).
15. Recoja la lista de todos los privilegios del sistema(Ver lista de privilegios)
16. Recolecte los permisos sobre los objetos(Ver Lista de permisos sobre objetos)
17. Lista de objetos (Ver listado de objetos)
18. Verifique la configuración del Archiver(Ver validación Archiver)
a. En caso de estar en Archivemode verifique la ruta.
i. Verifique el número de Redo Logs configurados. (Ver manejo Redo log)
ii. Lugares en que se multiplexó (en caso de que hayan multiplexado). (Ver manejo
Redo log)
iii. Tamaño en kilo bytes de los mismos. (Ver manejo Redo log)
iv. Halle el Md5 de los mismos en caso de que esté disponible y
compárelos para verificar la integridad. (Ver manejo Redo log)
b. En caso de que este apagado continué.
19. Una vez tenga los Redo logs almacénelos en una ubicación segura.
20. Vaya a al home de la aplicación y recolecte todos los archivos con extensión .dta (datafiles).( Ver
ubicación data files)
21. Almacene los archivos.
22. Recolecte los archivos de trace que se encuentren configurados en el sistema. ( Ver ubicación
Trace files)
23. Cierre la conexión con la base de datos.
24. Abra el archivo .xml que recolecto del TNSlistener. (Ver validación listener)
25. Busque dentro del archivo los registros sospechosos y almacene los tiempos de ejecución.
26. Almacene la ip del registro y el nombre de máquina del registro.
27. Haga este proceso para todos los registros a investigar.
28. Abra la tabla de auditoria que fue almacenada en el paso 13 y busque aquellos registros que
concatenen con los tiempos almacenados en el paso anterior. (Ver tabla de Auditoria)
90
29. Abra los archivos RedoLog con la herramienta de investigación que esté usando (Sans2010,
LogMiner o Winhex).
30. Verifique todos los registros que posean un ID que concuerde con los extractados en el paso 29 y
almacénelos.
31. Abra el TKPROF para hacer los análisis de los archivos trace recolectados en el paso 22. ( Ver
Trace files)
32. Verifique dentro de estos archivos los ID que concuerden con los de los ID encontrados en los
pasos 30 y 29.
33. Correlacione.
2.9 RECOMENDACIONES PARA LOS INVESTIGADORES FORENSES EN
INFORMÁTICA EN BASES DE DATOS ORACLE.
Para ver las recomendaciones forenses favor referirse al Anexo 47
91
3
CONCLUSIONES
Como hemos visto a través del documento existe una gran cantidad de fuentes de las cuales Oracle hace
uso para garantizar la confiabilidad, integridad, y no repudio del sistema. Dichas funcionalidades pueden
ser utilizadas por un investigador forense como fuentes de evidencia para detectar, seguir y analizar las
acciones de un atacante sobre una base de datos.
Es fundamental saber cuáles son las fuentes de información existentes, cómo verificar que se encuentran
disponibles y la forma de configurarlas, para garantizar que en un evento, pueda apoyar la identificación,
reconstrucción y prueba de la ocurrencia de un posible ataque conservando la confiabilidad e integridad de
la evidencia.
De los Redo Logs podemos extraer las sentencias DML y DDL que fueron ejecutadas en la base de datos
en un lapso de tiempo determinado, El usuario con el cual se inició sesión, el usuario que ejecuta la
sentencia, y el texto de la sentencia.
Para garantizar que la evidencia almacenada en los Redo Logs no sea sobrescrita rápidamente debemos
prestar especial atención al parámetro Log_Archive_Start.
Aunque los trace files nos proporcionan gran cantidad de información acerca de los movimientos de los
usuarios, debemos tener mucho cuidado con su configuración ya que pueden representar gran cantidad de
uso de espacio en disco y además puede repercutir en el rendimiento de la base de la datos.
Para estudiar todo lo relacionado con la actividad de la interacción de la base de datos con los clientes,
podemos valernos del TNS listener log en el cual encontramos evidencia de posibles ataques de
enumeración de usuarios y contraseñas. Con una adecuada correlación de eventos entre las entradas
almacenadas en el listener log y las entradas que se encuentran dentro de la tabla de auditoría AUD$
podemos identificar de manera precisa el origen y el momento exacto de inicio de un ataque.
Aunque LogMiner tiene una falla mayor en la administración de los timeStamps, sigue siendo una
herramienta que apoyada en otras, como DumpAction o alter system dump file, puede ayudar a esclarecer
de manera muy precisa las secuencias de eventos dentro de una investigación forense, dando resultados
confiables.
92
Es fundamental tener un buen kit de herramientas ya que muchas de las fuentes de evidencia pueden llegar
a ser muy extensas y su análisis muy tedioso.
Los logs de acceso del servidor pueden dar una gran ayuda para esclarecer los eventos acontecidos en ella.
Dependiendo de una buena correlación de eventos con los TNS Logs, las tabla de auditoría y las demás
fuentes de información.
Es importante que los Redo Logs se encuentren en varias ubicaciones ya que esto disminuirá el impacto de
que un atacante utilice alguna técnica anti-forense y elimine de manera definitiva la fuente de evidencia.
Los Oracle Data files nos permiten recuperar filas y por ende objetos eliminados siempre y cuando el
espacio que ocupaban en los bloques de datos no haya sido reutilizado. Para realizar un análisis sencillo y
eficiente es de vital importancia determinar en primera instancia cuales son los objetos de interés para la
investigación, de lo contrario nos enfrentaríamos a un proceso sumamente extenso y desgastante.
4
TRABAJOS FUTUROS
A continuación enunciamos los trabajos que consideramos pueden dar continuidad a esta investigación, si
desea ver una descripción más detallada, diríjase al Anexo 48.
Herramienta general de análisis de Fuentes de evidencia
Análisis de Checksums en Oracle
Time Stamps- Logminer
Extensión a otros entornos
93
5
ANEXOS
5.1 ANEXO 1
Ilustración 10: Sofisticación Vs. Conocimiento del atacante [41].
94
5.2 ANEXO 2
Ilustración 11: Intrusiones de seguridad en 2010 [1]
95
5.3 ANEXO 3
Ilustración 12: Actualizaciones de seguridad [1]
96
5.4 ANEXO 4
Ilustración 13: Estructura de la base de datos Oracle [6]
97
5.5 ANEXO 5
Ilustración 14: Técnicas Anti-forenses [3]
98
5.6 ANEXO 6
Ilustración 15: Vulnerabilidad usada para comprometer el sistema [9]
99
5.7 ANEXO 7
Ilustración 16: Configuración de los Redo Logs en la creación de la base de datos
100
5.8 ANEXO 8
Sub Bloque (64 Bytes)
16 Bytes
16 Bytes
16 Bytes
16 Bytes
XOR
XOR
XOR
16 Bytes
4 Bytes
4 Bytes
4 Bytes
4 Bytes
XOR
4 Bytes
XOR
4 Bytes
XOR
4 Bytes (DWORD)
A (16 Bits)
B (16 Bits)
Si A == -B -> La suma de verificación es correcta
101
5.9 ANEXO 9
Ilustración 17: Bloque de datos Oracle [19]
102
5.10 ANEXO 10
Ilustración 18: Consulta de verificación del estado de las funciones de auditoria [21]
103
5.11 ANEXO 11
Nombre de la columna
Tipo de dato
OBJ#
NUMBER
DATAOBJ#
NUMBER
OWNER#
NUMBER
NAME
VARCHAR2 (30)
NAMESPACE
NUMBER
SUBNAME
VARCHAR2(30)
TYPE#
NUMBER
CTIME
DATE
MTIME
DATE
STIME
DATE
STATUS
NUMBER
REMOTEOWNER
VARCHAR2 (30)
LINKNAME
VARCHAR2 (128)
FLAGS
NUMBER
OID$
RAW (16)
SPARE1
NUMBER
SPARE2
NUMBER
SPARE3
NUMBER
SPARE4
NUMBER
Tabla 1: Tipos de datos de la tabla OBJ$ [19]
104
Ilustración 19: Volcado de información a partir de los tipos de dato de la tabla OBJ$ [19]
105
5.12 ANEXO 12
Ilustración 20: Entradas en el listener log generadas al ejecutar sidguess.exe [25]
106
5.13 ANEXO 13
Ilustración 21: Registro de eventos de conexiones privilegiadas SYSDBA y SYSOPER en Windows [25]
Ilustración 22: Evidencia de inicio de sesión cuando la auditoria esta desactivada [25]
107
5.14 ANEXO 14
Ilustración 23: Localización traza
Ilustración 24: Traza sin formato
108
5.15 ANEXO 15
Ilustración 25: Sentencias de volcado
Ilustración 26: Volcado NOSYS
109
5.16 ANEXO 16
Ilustración 27:Comando Time
Ilustración 28: Comando Date
110
5.17 ANEXO 17
Ilustración 29: Comando net user
Ilustración 30: Detalles de usuario
111
5.18 ANEXO 18
Ilustración 31: Lista de conexiones y puertos
112
5.19 ANEXO 19
Ilustración 32: Ubicación Home
Ilustración 33: Ubicación Archivo de Inicio
113
5.20 ANEXO 20
Otro ejemplo es el siguiente [26]:
SQL> SELECT U.ORA_ROWSCN, U.NAME FROM SYS.USER$ U WHERE TYPE#=1 ORDER BY 1;
ORA_ROWSCN NAME
---------- -----------------------------537106 EXFSYS
537106 DMSYS
537106 TSMSYS
537106 DBSNMP
537106 ANONYMOUS
537106 XDB
537106 CTXSYS
537106 WMSYS
1465169 OUTLN
1465169 DIP
1465169 SYS
1465169 SYSTEM
2277427 MARK_POINT2
2277427 PWDTEST
2277427 MARK_POINT
2277427 FINDME_TOO
2277427 FINDME
2277427 SCOTT
2277427 MGMT_VIEW
2277427 MDDATA
2277427 SYSMAN
2277427 MDSYS
2277427 SI_INFORMTN_SCHEMA
2277427 ORDPLUGINS
2277427 TESTUSER
2277427 OLAPSYS
2277427 ORDSYS
27 rowsselected.
114
5.21 ANEXO 21
Ilustración 34: Validación Ruta diccionario Logminer
Ilustración 35: Configuración ruta diccionario
Ilustración 36: Validación Pos activación
115
5.22 ANEXO 22
Ilustración 37: Agregando archivos de investigación
116
5.23 ANEXO 23
Ilustración 38: Tipos de datos LogMiner
117
5.24 ANEXO 24
Como primera medida creamos un nuevo usuario (BONIFACIO) únicamente con el privilegio CREATE
SESSION, desde el cual realizaremos el ataque:
Ilustración 39: Creando el usuario a explotar
Verificamos que el usuario BONIFACIO únicamente tenga el privilegio que le acabamos de asignar y que
no posee ninguna entrada, es decir, no tiene ningún permiso en la tabla de políticas de Java:
Ilustración 40: Revisando los privilegios del usuario
118
Ilustración 41: Verificando los permisos Java del usuario
Para esta última verificación debimos desconectarnos y luego autenticarnos como SYS.
Posteriormente intentamos autenticarnos con BONIFACIO como SYSDBA pero como era de esperarse,
recibimos un mensaje de privilegios insuficientes. Entonces iniciamos sesión normalmente y procedemos
a atacar. Una vez conectados como BONIFACIO, creamos la política Java POL, y un cursor C1 que
incluye dentro de sus líneas el ataque de PL/SQL inyection. Posteriormente ejecutamos el cursor, el cual
alimenta nuestra política, y finalmente ejecutamos el procedimiento IMPORT_JVM_PERMS con POL
como parámetro, lo cual agregará la nueva política Java para el usuario BONIFACIO [15] [14]:
Ilustración 42: Sentencia de inyección para obtener privilegios Java arbitrarios
Ahora nos desconectamos, e iniciamos sesión como SYS para mostrar que efectivamente, logramos
conceder permisos Java al usuario BONIFACIO:
119
Ilustración 43: Verificación de inserción de nuestra Política Java
Si el usuario BONIFACIO tuviera el privilegio CREATE PROCEDURE, podría haciendo uso de una
clase Java y un PL/SQLWrapper, creados por él y ejecutar sentencias de Sistema Operativo, pero como no
lo posee, usamos la función de Oracle DBMS_JAVA_TEST.FUNCALL, que recibe como único
parámetro
una
cadena
String,
para
hacer
un
llamado
al
método
main()
de
la
clase
“oracle/aurora/util/Wrapper”, con el cual abrimos una consola de Windows (cmd.exe) y ejecutamos un
comando de sistema operativo. En nuestro caso, dicho comando simplemente guarda la salida de la
consola en un archivo que hemos llamado OUT.LST [14] [15].
Ilustración 44: Sentencia para ejecutar comandos de sistema operativo
Aunque al correr esta sentencia parece que nada ha sucedido, podemos verificar en la ruta especificada
que el archivo en cuestión ha sido creado, confirmando el éxito de nuestro ataque. Si bien escogimos
simplemente guardar la salida de la consola en un archivo, pudimos haber elegido ejecutar cualquier otro
comando del sistema operativo como mostraremos a continuación. [15] [14]
120
Ahora que podemos ejecutar comandos de sistema operativo, procedemos a crear un nuevo usuario del
sistema con nombre “BONIFACIO” y contraseña “Javeriana.2010” [14] [15]:
Ilustración 45: Creación de un usuario en el sistema operativo
Y tras haber creado el usuario de sistema, lo agregamos al grupo de administradores ejecutando la
siguiente sentencia [14] [15]:
Ilustración 46: Agregando el usuario al grupo de administradores del sistema operativo
Ahora usamos la función SET_OUTPUT_TO_JAVA, también incluida en el paquete DBMS_JAVA, la
cual recibe como dos de sus parámetros una sentencia SQL y puede ser explotada por un ataque de Lateral
Injection. Dicha función nos permite re direccionar la salida escrita en System.out y System.err hacia una
nueva sesión virtual de Java, y ejecuta las sentencias que se le pasaron en los parámetros
INITIALIZATION_STATEMENT y FINALIZATION_STATEMENT, así que en nuestro caso, cuando
se genere alguna salida de error dirigida a System.out o System.err, se ejecutará la sentencia GRANT
DBA TO BONIFACIO. [14] [15]
121
Ilustración 47: Lateral Injection al re direccionar la salida de un error
Sin embargo, dicha sentencia requiere ser ejecutada con privilegios de SYS, por lo que usaremos el
paquete DBMS_CDC_ISUBSCRIBE que es públicamente ejecutable y es propiedad de SYS, el cual
simplemente envuelve una aplicación Java. Al pasarle un nombre de suscripción inválido al procedimiento
INT_PURGE_WINDOW de este paquete, forzamos un error que es escrito a System.err. Cuando esto
ocurre, la sentencia que inyectamos en la función anterior será ejecutada en una nueva sesión, que es
propiedad de SYS y por ende es ejecutada con privilegios de SYS, y de este modo conseguimos
concederle privilegios de DBA al usuario BONIFACIO. [14] [15]
Ilustración 48: Ejecución de un paquete de SYS con parámetros inválidos para ejecutar nuestro
ataque
Como vemos en la Ilustración 48, tras generar la salida de error, nuestro ataque tiene éxito y el usuario
BONIFACIO puede establecer su rol como DBA.
122
5.25 ANEXO 25
Para examianr las diferentes fuentes de evidencia tras el ataque, comenzamos con el archivo de log del
TNS Listener. Para acceder al archivo del TNS Listener nos dirigimos a la ruta especificada en el campo
Listener Log File y comenzamos a mirar cuales posibles conexiones pueden ser sospechosas sabiendo ya
, que el evento de seguridad tuvo lugar en un determinado lapso de tiempo. Sabiendo que el ataque se
presento el 15 de Noviembre, podemos acotar todas las conexiones sospechosas que se hayan generado en
esa ventana de tiempo.
Habiendo Realizado un análisis detallado del log encontramos tres entradas sospechosas en esa ventana de
tiempo.
<msg time='2010-11-15T014:55:27.186-08:00' org_id='oracle'
comp_id='tnslsnr'
type='UNKNOWN' level='16' host_id='WIN-L68IWUFYSVD'
host_addr='192.168.0.4'>
<txt>15-NOV-2010 14:55:26 *
(CONNECT_DATA=(SERVICE_NAME=javeriana)(CID=(PROGRAM=C:\app\Administrato
r\product\11.1.0\db_1\bin\sqlplus.exe)(HOST=WINOOR7X3B1SNQ)(USER=Administrator))) *
(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.0.26)(PORT=49169)) * establish *
javeriana * 0
</txt>
</msg>
Como podemos ver en la anterior entrada podemos encontrar dos características particulares dentro de los
campos. El primero es que es una conexión externa proveniente de la maquina WIN-OOR7X3B1SNQ
identificada con la IP 192.168.0.26. Lo extraño dentro de esta entrada es que en todo el día, no se
presentaron más conexiones provenientes de fuera de la base de datos haciendo de esta entrada y este host
una entada sospechosa dentro del log. Posteriormente debemos tener en cuenta esta información para
poder realizar correlación de eventos con las tablas de auditoría, porque estas tienen información de los
nombres de las maquinas que se conectan y además nos proporcionan la cuenta dentro de la base de datos
en caso de que se haya conectado a la misma.
123
Bajo este mismo orden de ideas también podemos hacer uso de los archivos de traza que genera el
sistema. Estos archivos de traza se encargan de almacenar absolutamente todas la actividades que realice
un usuario mientras se encuentre activada la traza sobre él, para este caso de estudio se configuro una traza
para saber cuáles fueron las acciones realizadas por el atacante. Para ver las trazas nos dirigimos a la ruta
donde se encuentren almacenadas las trazas de usuario. Una vez allí la abrimos con tkprof para darle
formato y colocarlo en el computador del investigador.
Ilustración 49: Proceso para darle formato al archivo trc
Una vez tenemos listo este archivo podemos ver que sentencias y cuál fue la actividad que realizo el
usuario dentro de la base de datos, encontrando clara evidencia del ataque ya que podemos identificar de
manera exacta que tipo de sentencia utilizo. Dentro de este archivo podemos ver la secuencia exacta de
eventos en el sistema. El usuario ejecuto 7 sentencias que muestran como fue el ataque.
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
Ilustración 52: Sentencia 3 Creación de archivo de salida OUT.LST
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
Ilustración 55: Flujo de información para crear el overflow
Ilustración 56: Set Role as DBA
126
Como podemos ver en los trace files queda de manera exacta la traza del eventos y de acciones ejecutadas
por el usuario que se encuentra bajo investigación.
Después de revisar la evidencia existente en el TNS Log y los Trace Files pasamos a examinar los Redo
Logs de nuestra base de datos en busca de evidencia, para realizar la inspección de una manera más
sencilla y eficiente, usamos la herramienta “dumpaction.exe”, publicada por David Litchield en la página
de su empresa V3rity Software (www.v3rity.com/products) dentro del paquete “SANS 2010 Tools”. Esta
herramienta parece ser una versión mejorada de una herramienta publicada también en la página
denominada “ddldump.exe” la cual tenía algunos errores además de una funcionalidad limitada. La nueva
herramienta nos permite examinar un archivo de Redo Log y realizar un volcado de todas las sentencias
DDL que este contenga, en un archivo con formato XML. Tras examinar nuestros tres Redo Logs
pasandole a la herramienta el parámetro “ddl”, encontramos evidencia contundente del ataque en el
segundo archivo llamado REDO02.LOG [42]:
Ilustración 57: Evidencia del ataque en los Redo Logs
127
Como se observa en la Ilustración 57, en las dos entradas presentadas el usuario que inicia sesión es
BONIFACIO pero el que ejecuta la sentencia es SYS, lo cual es un indicio de un posible ataque de
inyección. Como las entradas parecen sospechosas las analizamos en mayor detalle y notamos que en la
primera, se modificaron las políticas de Java, lo cual no debería poder hacer un usuario como
BONIFACIO y es precisamente en este punto donde el atacante obtuvo permisos Java arbitrarios.
Analizando la segunda entrada encontramos la evidencia de la segunda parte de ataque en la cual
BONIFACIO logra concederse privilegios de DBA. Para verificar la información obtenida en el volcado
de la herramienta podemos usar el campo <RDRCOFST> que indica el desplazamiento (offset) dentro del
archivo para encontrar la Redo Entry que contiene la sentencia que estamos analizando. Así mismo el
campo <CHVCOFST> indica el desplazamiento para encontrar el Change Vector que contiene la
sentencia SQL. En nuestro caso al desplazarnos a la posición 0030B4B4 encontramos efectivamente el
Change Vector que contiene la sentencia de asignación de privilegios DBA a BONIFACIO.
Ilustración 58: Verificación de la evidencia obtenida en el volcado generado por la herramienta "dumpaction.exe"
Aunque las herramientas de Litchfield aun se encuentra en desarrollo, nos permiten revisar con facilidad y
confiabilidad la posible evidencia existente en un archivo Redo Log, pues además de hacer un volcado
completo de las sentencias DDL contenidas en el archivo, en un formato comprensible, también podemos
filtrar las entradas generadas en un archivo XML haciendo uso de “filter.exe”, también provista por
128
Litchfield. Dicha herramienta recibe un archivo XML de los que habíamos generado con
“dumpaction.exe” y otro archivo XML conteniendo la información del filtro que deseamos aplicar, por
ejemplo, el siguiente XML provisto por Litchfield nos ayuda a extraer únicamente las entradas para las
cuales el usuario que ejecuta la sentencia SQL es SYS pero no concuerda con el usuario que inicio sesión:
Ilustración 59: XML para filtrar entradas sospechosas de un Redo Log
Adicionalmente con la herramienta “dumpaction.exe”, podemos usar el parámetro “ins”, con el cual le
indicamos que deseamos volcar las sentencias INSERT en lugar de las DDL. Las funcionalidades para
volcar sentencias DELETE y UPDATE no se incluyen en la versión actual de la herramienta.
Para verificar la utilidad, en el ámbito de una investigación forense, de la tabla AUD$, perteneciente a la
funcionalidad de auditoría de Oracle (Audit Trail), realizaremos una correlación de la evidencia hallada
en los Redo Logs con la información que nos provee la tabla de auditoría. Basta con revisar
superficialmente los datos de la tabla AUD$ para encontrar evidencia adicional relacionada al intervalo de
tiempo que estamos estudiando, es decir, el lapso temporal cercano al timestamp mostrado en la
Ilustración 57. La entrada del Redo Log correspondiente a dicho timestamp nos indica que el 15 de
Noviembre del año 2010 a las 3:15 PM alguien logro llevar a cabo exitosamente un ataque de inyección a
través del cual concedió privilegios de DBA al usuario BONIFACIO. Consultando las entradas de la tabla
AUD$ con USERID = „BONIFACIO‟ y buscando las relacionadas al momento de interés, encontraremos
la evidencia que buscamos. Con el fin de mostrar lo encontrado de una manera más clara, ejecutamos una
129
sentencia que nos filtra únicamente los campos que nos aportan información de interés para un
examinador forense:
SELECT USERID, USERHOST, ACTION#, RETURNCODE, OBJ$NAME, SPARE1, NTIMESTAMP#
FROM SYS.AUD$ WHERE USERID = 'BONIFACIO';
Ilustración 60: Entradas relacionadas a BONIFACIO en la tabla de auditoría AUD$
Así luce la entrada generada en la tabla AUD$ cuando el usuario BONIFACIO ejecuta el comando SET
ROLE DBA, esto lo sabemos pues el campo ACTION# tiene un valor de 55 con el cual consultamos la
tabla AUDIT_VALUES y obtenemos lo siguiente:
Ilustración 61: Código de acción relacionado al valor hallado en la tabla AUD$
130
Adicionalmente en la Ilustración 60 podemos ver que el nombre de objeto relacionado con la acción es
DBA, basta con relacionar estos dos campos para construir nueva evidencia en contra del atacante. De los
demás campos que seleccionamos podemos obtener información adicional de gran relevancia como el
nombre de la maquina desde la cual se llevo a cabo la acción (USERHOST) y la cuenta de sistema
operativo bajo la cual estaba autenticado el atacante(SPARE1).
Así como nosotros descubrimos esta evidencia fácilmente, un atacante precavido, puede ser consciente o
haber notado que estas entradas se generaron en la tabla AUD$ y teniendo rol de DBA decide borrar todas
las acciones relacionadas con su cuenta. ¿Cómo podemos darnos cuenta de esta técnica anti forense? La
respuesta a esta pregunta es: haciendo uso de los Data Files.
Ilustración 62: Técnica anti forense de eliminación de la evidencia almacenada en la tabla AUD$
Al ejecutar la sentencia mostrada en la Ilustración 62, el usuario elimina toda la información existente en
la tabla AUD$ que podría ser usada por un investigador como evidencia en su contra. Sin embargo como
explicamos en la sección 2.5.2.2.1, las filas eliminadas, o mejor, la información de dichas filas permanece
en los Data files marcada como eliminada mientras que las posiciones que ocupaba tanto en el directorio
de filas como en el espacio de filas no sean reutilizadas.
Para recolectar información del Data File mencionado se debe seguir el procedimiento explicado
originalmente por David Litchfield y que presentado en este documento en la sección recientemente
mencionada. Adicionalmente para detectar filas eliminadas también podemos hacer uso de una
herramienta publicada por Litchfield en el sitio web de su empresa denominada “orablock.exe” la cual
recibe un Data file y permite realizar un volcado de la información contenida filtrándola de diversas
maneras, una de ellas y la más importante para nuestro caso, es la de volcar únicamente la información
eliminada relacionada a un objeto en particular. Para hacer uso adecuado de la herramienta debemos
primero definir cual o cuales objetos son de interés en nuestra investigación, objetos de interés general son
131
la tabla OBJ$, la tabla SOURCE$ y la tabla AUD$. Luego de examinar el Data File SYSTEM01.DBF
con base a las tablas de interés encontramos nuestra evidencia en las entradas relacionadas a la tabla de
auditoría, como era de esperarse. Para analizar únicamente las entradas eliminadas de la tabla AUD$
debemos ejecutar el programa como se muestra a continuación:
Ilustración 63: Sentencia de uso de Orablock para hallar evidencia relacionada a la tabla AUD$ en el Data File
SYSTEM01.DBF
Los parámetros usados en la sentencia de la Ilustración 63, son explicados con mayor precisión en la
sección 2.5.3.2 de este documento, únicamente mostraremos en esta sección el contenido del archivo de
parámetro formatoAUD.txt que le permite a la herramienta extraer correctamente la información de
acuerdo a la estructura del objeto que estamos examinando, en este caso la tabla AUD$.
Ilustración 64: Archivo de estructura de la tabla AUD$
132
La salida generada en el documento filaseliminadasAUD$.txt luce así:
Ilustración 65: Evidencia de filas eliminadas de la tabla AUD$
En la Ilustración 65, encontramos un ejemplo de las entradas generadas al usar Orablock, escogimos esta
en particular pues muestra el valor DBA que como vimos anteriormente corresponde a la columna
OBJ$NAME y el valor 55 para la columna ACTION# que corresponde a un set role en la tabla de
acciones de auditoría, también encontramos otra información valiosa que fue explicada anteriormente
cuando explicamos la evidencia en la tabla AUD$.
133
5.26 ANEXO 26
Ilustración 66 : Diagrama de flujo para detectar vulnerabilidades de SQL Injection – Adaptado de [12]
134
5.27 ANEXO 27
Ilustración 67: Volcado Hexadecimal de un bloque asignado a la tabla SOURCE$ [19]
Ilustración 68: Información contenida en las filas eliminadas asociadas al objeto 51850 [19]
135
5.28 ANEXO 28
Entrada en el directorio + desplazamiento = localización fila
0x1D39805C + 0x11AB = 0x1D399207
0x1D39805C + 0x11E4 = 0x1D399240
0x1D39805C + 0x1204 = 0x1D399260
0x1D39805C + 0x1213 = 0x1D39926F
0x1D39805C + 0x123E = 0x1D39929A
0x1D39805C + 0x1250 = 0x1D3992AC
0x1D39805C + 0x12D8 = 0x1D399334
0x1D39805C + 0x12EC = 0x1D399348
0x1D39805C + 0x1306 = 0x1D399362
Tabla 2: Filas borradas enlazadas en la tabla SOURCE$
136
5.29 ANEXO 29
Ilustración 69: Volcado Hexadecimal de los bloques asignados a la tabla IDL_UB1$ [19]
137
5.30 ANEXO 30
Ilustración 70: Diferencia entre autenticación de la cuenta SYS con y sin "AS SYSDBA" [25]
138
5.31 ANEXO 31
Ilustración 71: Búsqueda ruta trace files
Set serveroutput on size 100000000 for wra
Declare
paramname varchar2(256);
integervalbinary_integer;
stringval varchar2(256);
paramtypebinary_integer;
beginparamtype:=dbms_utility.get_parameter_value('user_dump_dest',integerval,s
tringval);
ifparamtype=1 then
dbms_output.put_line(stringval);
else
dbms_output.put_line(integerval);
endif;
end;
/
139
5.32 ANEXO 32
Ilustración 72: SPFile Texto
140
5.33 ANEXO 33
Ilustración 73: Ruta Listener logs [26]
141
5.34 ANEXO 34
Ilustración 74: Versión
142
5.35 ANEXO 35
Ilustración 75: Descripción de la columna COL_USAGE$ [34]
143
5.36 ANEXO 36
Ilustración 76: Filt1.xml
Ilustración 77: Filt-bool.xml
144
Ilustración 78: Filt-grant.xml
Ilustración 79:Filt-xid.xml
Ilustración 80: Parámetros de la herramienta Orablock
145
5.37 ANEXO 37
Ilustración 81: Errores del TNS Listener [23]
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]
Ilustración 84: Entrada del audit trail usando la columna COMMENT$TEXT [25]
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
5.38 ANEXO 38
Ilustración 87: Entradas en el listener log generadas al ejecutar sidgusser.exe [25]
149
5.39 ANEXO 39
SQL> col sid for 999999
SQL> col serial# for 999999
SQL> col username for a20
SQL> col osuser for a20
SQL> select
s.sid,s.serial#,s.username,s.osuser
fromv$sessions,v$process p
wheres.paddr=p.addr;
Ilustración 88: Búsqueda SID y Serial #
150
5.40 ANEXO 40
Ilustración 89: Encabezado de un archivo Oracle
Ilustración 90: Ejemplo de verificación del tamaño de un archivo Oracle
151
5.41 ANEXO 41
Ilustración 91: Encabezado de un bloque en un archivo Oracle Redo Log
152
5.42 ANEXO 42
Ilustración 92: Estructura del encabezado de un Red Log – Adaptado de [16]
153
5.43 ANEXO 43
Ilustración 93: Encabezado de una fila eliminada [19]
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]
Ilustración 96: Discriminación de columnas a partir de un volcado hexadecimal [19]
155
5.44 ANEXO 44
Ilustración 97: Volcado Hexadecimal de un bloque asignado a la tabla MY_TEMP_TABLE [19]
156
5.45 ANEXO 45
LogMiner posee actualmente 2 problemas a la hora de realizar una investigación forense y que es
fundamental se tenga en cuenta en caso de que se piense adelantar una investigación con esta herramienta
[36] [33]:
Problemas de manejo de registros de tiempo cuando se trata de entradas históricas
LogMiner pierde completamente la información fraccional del TIMESTAMP cuando se
recupera información sobre la base de datos.
El error del TIMESTAMP se puede verificar inicialmente realizando una consulta a la tabla dual donde se
encuentran los registros de las transacciones de las bases de datos. Finalmente los REDOLOGS toman el
valor del tiempo de la transacción de este TIMESTAMP [33].
Ilustración 98: TimeStamp tabla dual [36]
Ilustración 99: TimeStampLogMiner [36]
Como podemos ver en la consulta anterior, los TIMESTAMPS que maneja el sistema son de una precisión
de 10ˆ-6 dígitos mientras que los TIMESTAMPS que presenta el sistema son de una precisión mínima ya
que solo muestra el segundo en que sucedió. Esto sucede ya que LogMiner decodifica el TIMESTAMP de
una manera incompleta, y aunque en los Redo Logs se encuentre correcta la información, esta se verá
truncada a la hora de presentarla dentro de la herramienta. Más adelante mostraremos la forma en la cual
se almacenan los Time Stamps dentro de los Redo Logs. [36]
157
5.46 ANEXO 46
Para construir una línea de tiempo es necesario utilizar el comando SPOOL que se encarga de dirigir los
resultados de las consultas a archivos planos de texto. Posteriormente se utiliza la sentencia SQL
v$logmnr_contents, que lo que hace es leer los Redo Logs de la base de datos y realizar una
representación gráfica de los eventos captados. Finalmente estos datos son plasmados en los archivos de
texto que permitimos con el comando SPOOL [33] [36].
Ilustración 100: SentenciaSpool [36]
El anterior query muestra en el archivo Serial commit Number, el tiempo en que se registró la sentencia, el
usuario que la procesó, el nombre de la tabla en que se realizó y la operación que se usó. Dentro de los
redoLogs los SCN hacen el papel de ID de las transacciones y además nos proporcionan una referencia
temporal dentro de los eventos realizados en la base de datos, por lo cual una buena práctica es utilizar
estos números para realizar nuestras consultas. [33] [36]
Ilustración 101: Estructura LogMiner Redo Logs [36]
Una de las características que se pueden evidenciar una vez se tiene la información en archivos planos de
texto es que hay muchas entradas que poseen la misma hora y también el mismo Número de compromiso
de la transacción (SCN), esto sucede ya que lo que realmente se almacena dentro de los Redo Logs es el
momento en el que el LWRG escribe información dentro del buffer del redo log y este se guarda una vez
se presenta un COMMIT, por lo cual si son varias operaciones estas recibirán el mismo SCN y el mismo
TIMESTAMP . [35] [36] [33]
158
Si se introduce un nuevo registro dentro de la base de datos, se puede evidenciar bajo que SCN se
encuentra esta transacción realizando una búsqueda a partir del nombre de la tabla, como es mostrado en
la siguiente gráfica.
Ilustración 102: Verificación Serial Commit Number [36]
5.47 ANEXO 47
Cuando nos enfrentemos a la escena física, es necesario que se tengan en cuenta los siguientes aspectos:
¿Se encuentra encendido o no el servidor?
Es importante revisar si el computador se encuentra encendido, ya que en muchos casos hay gran variedad
de información que podemos adquirir dependiendo de que se encuentre prendida la maquina
comprometida. Esta información es:
o
En muchos casos los atacantes programan tareas que se disparan una vez un usuario por el pánico
apaga el sistema que fue víctima del ataque como se muestra a continuación.
CREATE OR REPLACE TRIGGER VANISH BEFORE SHUTDOWN ON DATABASE
BEGIN
DELETE FROM SYS.AUD$;
END;
/
159
La anterior sentencia se encarga de borrar todo el contenido de la tabla de auditoría. La tabla de
Auditoria posee el historial de las conexiones a la base de datos, este borrado podría entorpecer
enormemente el curso de una investigación. Por estas razones es importante mantener el sistema
encendido hasta que la información que es volátil pueda ser almacenada y asegurada, garantizando
que los datos no vayan a ser modificados o que en su defecto se pierdan
Análisis del servidor
Para analizar el servidor no lo podemos hacer directamente desde él, porque se pueden sobre escribir
gran cantidad de espacios en memoria que pueden tener información valiosa para un investigador. Es
necesario que se instale un programa que permita el paso de información a través de la red a una
terminal segura. Se recomienda hacer uso de los siguientes programas:
Netcat12
Crypto Cat13
o
Información en la memoria Volátil. (Ver Live Response).
o
Verificar estado del servido. Tenga en cuenta que usuarios se encuentran actualmente conectados,
que usuarios están dentro del dominio del sistema, quienes tienen acceso y los logs de
administración. (Ver Live Response).
5.47.1 Recaudo de la información
Es necesario dentro una investigación que involucre una base de datos se encuentre presente el DBA o la
persona con más conocimiento sobre el sistema, esto es necesario por dos razones:
1. Al ser la persona que más conoce el sistema, nos puede proporcionar información de anormalidades
dentro del estado de la base de datos, por ejemplo nos puede ayudar a validar que fuentes de evidencia
(Ver Fuentes de Evidencia) se encuentran activadas y cuáles no, además del estado general de las
mismas. También informar de la existencia de usuarios que anteriormente no se encontraban y que
posiblemente son parte del evento de seguridad.
2. Al ser un testigo fiel de la cadena de custodia y del proceso general de recaudo y administración de
las evidencias encontradas dentro del servidor, puede ser presentado dentro de una corte para validar
la integridad, veracidad y valides de las pruebas.
12
13
http://netcat.sourceforge.net/
http://sourceforge.net/projects/cryptcat/
160
5.47.1.1 Información Volátil dentro de Oracle
Dentro de Oracle hay tablas especiales que se modifican dependiendo de la cantidad de acciones que se
realicen dentro de la base de datos y que pueden proporcionar información útil para una investigación.
Dependiendo del tiempo que demore el inicio de la investigación y la fecha exacta en que ocurrió el
evento de seguridad, podríamos encontrar o no información que aporte evidencia para una investigación.
Por lo cual un informático forense como primera medida debe ver:
Conectarse como SYS.(Ver conexión SYS)
Recaudar
la
información
que
se
encuentra
en
V$SQL,
WRH$_SQLSTAT
y
WRH$_SQLTEX.(Ver V$SQL y Live Response)
Es importante que el investigador Forense no ejecute ninguna sentencia UPDATE, DELETE, DROP o
INSERT, ya que de esta manera estaría comprometiendo la integridad y veracidad de la información (Ver
Recaudo de información).
5.47.1.2 Validar el estado del listener
El investigador debe validar cual es el estado actual del listener, para hacer esto debe tener en cuenta:
Que versión del listener se está usando. (Ver validación listener)
Si el listener se encuentra activado. (Ver validación listener)
La ruta en que se están almacenando los logs. (Ver validación listener)
Es necesario realizar estas validaciones, ya que si el listener se encuentra desactivado o los logs del mismo
no se encuentran, es posible que el atacante haya utilizado alguna técnica anti-forense (Ver técnicas antiforenses) para entorpecer la investigación.
5.47.1.3 Verificación el estado de las fuentes de información
Para un investigador forense es necesario validar con que fuentes de posible evidencia cuenta para realizar
su investigación dentro del servidor comprometido (Ver Fuentes de Evidencia). Para realizar este proceso
el investigador debe verificar lo siguiente:
Ver la versión de Oracle con la que está tratando (Ver Versión Oracle)
Es importante recaudar la información del estado del sistema, esto implica:
o
Información de acceso al sistema utilizando AUD$ (Ver tabla AUD$)
o
Información de usuarios y roles (Ver Usuarios y roles)
161
o
Lista de todos los privilegios del sistema(Ver lista de privilegios)
o
Permisos sobre los objetos(Ver Lista de permisos sobre objetos)
o
Lista de objetos (Ver listado de objetos)
5.47.1.3.1 Validación
Una vez recaudada la información general del sistema debemos entrar a verificar cuales de las posibles
fuentes de evidencia se encuentran configuradas y cuáles no. Las fuentes de evidencia que debe validar
son:
Redo Logs: Para cada uno de los trace files debe validar que esté cumpliendo con los parámetros con
los que se configuro el manejo de los Redo Logs, para esto se debe tener en cuenta:
o
Configuración del proceso Archiver.
o
Numero de Redo Logs Configurados.
o
Lugares en que se multiplexó (en caso de que hayan multiplexado).
o
Tamaño en kilo bytes de los mismos.
o
Md5 de los mismos en caso de que esté disponible.
La primera medida es revisar si la base de datos se encuentra en Archive mode o en nonArchive mode (Ver
Archive Mode).
Numerar los Redo Logs lo hacemos con el fin de verificar en primera instancia que no han usado ningún
tipo de técnica anti-forense como eliminación de la fuente o eliminación u ocultamiento de evidencia
(Ver técnicas Anti-forenses).Esto con el fin de ayudar a que el investigador llegue a una conclusión
satisfactoria de los hechos.
Verificamos los lugares donde se multiplexaron los Redo Logs, con el fin de verificar que el atacante no
haya borrado las posibles fuentes de evidencia (Ver técnicas Anti-forenses) o que haya cambiado las rutas
en las cuales almacenan los Redo Logs (Ver Redo Logs). Una vez hemos validado cada una de las rutas
en las cuales los Redo Logs han sido multiplexados, comparamos el tamaño de los mismos para validar
que la integridad no se haya visto afectada de primera mano, ya que en caso de que los valores de los
pesos difieran, podemos desconfiar de ellos. Si los pesos son iguales podemos entrar a comparar los md5
de cada uno de los archivos, ya que el solo hecho de que los pesos sean iguales no quiere decir que su
contenido sea el mismo. Si un atacante sabe el modo de modificar los checksums de validación, entonces
no se notaria a primera vista que fue modificado.
162
Datafiles: Los data files se encargan de almacenar físicamente la base de datos, pero además también
nos sirven como evidencia ya que gracias a ellos también podemos validar que información
determinada aun se mantenga y en caso de que sea borrada aun podamos recuperarla o saber que fue
borrada. Para hacer esto Inicialmente:
o
Accedemos a la Ruta de configuración
o
Copiamos Los data files Existentes
Trace Files: En caso de que se encuentren configurados los trace files para usuarios que posean
permisos muy elevados dentro del sistema debemos también recaudarlos para la investigación.
Una vez nos hemos hecho de esta información el sistema comprometido puede o no volver a
funcionamiento, dependiendo de la importancia del mismo dentro de la empresa y del juicio del
investigador que lleva a cabo la investigación.
Posterior a esto el investigador debe analizar las posibles fuentes de evidencia de manera cronológica.
Esto quiere decir que las fuentes se deben analizar de la siguiente manera.
1. Datos e información del servidor: Ya que la información del servidor viene en .txt
y es
completamente legible, no hay que hacerle un tratamiento especial para poder analizarlo. Para esta
información es necesario que se haya tratado de manera remota habiendo utilizado las herramientas
anteriormente listadas.
2. Archivos TNS Listener: Para el archivo de log del Listener debemos tener en cuenta las rutas que
anteriormente listamos. Este log se encuentra en formato XML y puede ser leído desde un navegador
como Mozilla preferiblemente o desde un editor de texto PSPAD o notepad ++.
3. Archivos Redo Log: Para el análisis de este tipo de archivos podemos utilizar diferentes tipos de
herramientas. Dentro del mercado existen tres tipos de herramientas, que podrían ser útiles dentro de
una investigación.
a. Dump action: Herramienta desarrollada por David Litchfield que permite ver que sentencias DDL
fueron usadas en el servidor. Esta herramienta es la más recomendada ya que a diferencia de las
otras, esta posee una gran precisión traduciendo los time stamps que se encuentran almacenados
dentro de los Redo Logs.
b. LogMiner: Es una de las herramientas que provee Oracle para el análisis y administración de los
Redo Logs. Aunque da un buen acercamiento inicial a los acontecimientos dentro de una base de
datos, no es recomendable utilizarlo como herramienta principal dentro de una investigación ya
que la exactitud dentro de los time stamps es muy reducida.
163
c. FlashBack: Es una de las herramientas que provee Oracle más recientes en el mercado. A pesar de
que no es una Herramienta creada para el análisis forense, esta puede ser una buena opción para el
análisis de los Redo Logs siempre y cuando la información a estudiar sea reciente.
4. Data Files: Para el análisis de los data files podemos hacer uso de las herramientas que David
Litchfield a publicado.
a. Dump extends: Es una de las ultimas herramientas que ha liberado al público y permite realizar
análisis de los data files que sean del tipo UNDO con gran precisión.
Trace Files: Para los dumps de los archivos trace file es recomendable hacer uso de TkProf.
5.48 ANEXO 48
Herramienta general de análisis de Fuentes de evidencia
Resultaría conveniente la creación de una herramienta forense que permita analizar de manera integrada
las principales fuentes de evidencia de Oracle, permitiendo construir de manera gráfica las secuencias de
eventos en un espacio de tiempo y realizando correlación de eventos con las diferentes fuentes. Esto
implica analizar y correlacionar:
1. TNS Logs
2. RedoLogs
3. TraceFile
4. DataFiles
5. OracleAudit trail
Es necesario que esta herramienta tenga en cuenta nombre de usuarios en la base de datos, fechas,
direcciones IP, nombres de usuarios del sistema operativo, sentencias utilizadas, privilegios de los
usuarios que ejecutan las sentencias, entre otros.
Adicionalmente los resultados obtenidos tras la investigación deben poder exportarse en un formato que
pueda ser entendido en una corte por individuos sin una formación técnica en sistemas y seguridad
164
informática, sin dejar de ser confiables y verificables. Se esperaría de esta herramienta un especial cuidado
con el manejo de la precisión de los TimeStamps con el fin de proporcionar confiabilidad a los resultados
obtenidos y no caer en las falencias de herramientas como logMiner. Actualmente hay un proyecto en
curso liderado por David Litchfield que pretende generar una herramienta como la anteriormente descrita.
Análisis de Checksums en Oracle
El análisis de la creación y validación de los check sums dentro de Oracle permitiría dar una precisión
mayor a una investigación forense, ya que se contemplarían ataques de mayor complejidad. Actualmente,
sin un atacante logra comprender claramente la manera en que Oracle genera sus 99 Checksums, podría
ingeniar nuevas maneras de cubrir sus rastros hasta hacer parecer que un archivo corrupto, parezca valido
para el sistema. Aunque Oracle provee herramientas de verificación de los Checksums de sus archivos,
dichas herramientas se limitan a verificar que cada archivo tenga un Checksum coherente con su contenido
pero no están en capacidad de detectar la alteración de contenido seguida de la alteración del Checksum.
Time Stamps- Logminer
Aunque LogMiner es una herramienta forense con gran capacidad técnica posee una falencia con el
manejo de los TimeStamps, por lo cual sería conveniente la creación de un API que mejore la
administración de las marcas de tiempo, teniendo en cuenta los decimales que se ven truncados a la hora
de extraerlos de los Redo Logs y almacenarlos en las estructuras que son usadas para los reportes de
investigación. Esto le daría una mayor veracidad a los resultados que genera LogMiner, logrando de esta
manera, incrementar la fiabilidad y confiabilidad de los resultados obtenidos por esta herramienta.
Extensión a otros entornos:
Se esperaría que con base en este trabajo otras personas pudieran extender las ideas presentadas acá, a
otros entornos de bases de datos como MySQL, SQL Server, DB2, MAXDB, etc. Sí para el entorno más
usado a nivel mundial se encuentra disponible información limitada sobre análisis forense, es de esperarse
que para los demás entornos esta situación sea aún más crítica y aunque las fuentes de evidencia puedan
variar en cierto modo, se esperaría que las maneras de analizarlas puedan ser extrapoladas en la mayoría
de los casos.
165
6
TRABAJOS CITADOS
[1] Ericka Chickowski, "Why Your Databases Are Vulnerable To Attack– And What You Can Do About
It," Information week : Analytics, pp. 1-12, Junio 2009.
[2] Scott Berinato. (2007, June 01) The Rise of Anti-Forensics. [Online].
http://www.csoonline.com/article/221208/The_Rise_of_Anti_Forensics
[3] Ryan Harris. (2006) Digital Forensic Research Workshop. [Online].
http://www.dfrws.org/2006/proceedings/6-Harris.pdf
[4] Jeimy Cano. (2006, Junio) Introducción a la informática forense. [Online].
www.acis.org.co/fileadmin/Revista_96/dos.pdf
[5] David Litchfield, The Database Hacker's Handbook — Defending Database Servers, John Wiley, Ed.
Indianapolis, Indiana, United States of America: Wiley, 2005.
[6] Jorge Sanchez. (2004) Arquitectura del DBMS Oracle, Guia de iniciacion. [Online].
http://www.jorgesanchez.net/bd/arquOracle.pdf
[7] Arquitectura Oracle. Oracle Manual y Capacitacion Oracle, Pl/Sql, Discoverer, Forms, Sql y Plsql Orape. [Online]. www.orape.net/subidos/manualbd/arquitectura.doc
[8] Jeimy José Cano Martínez. (2007, Septiembre) Estrategias anti-forenses en informática: Repensando
la computación forense. [Online]. http://www.alfa-redi.org/rdi-articulo.shtml?x=9608
[9] Carsten Maple and Alan Phillips. (2010, Enero) 7Safe. [Online]. www.7safe.com/breach_report
[10] Stephen Kost. (2007, Marzo) Integrigy Coprporation. [Online]. www.integrigy.com/securityresources/whitepapers/Integrigy_Oracle_SQL_Injection_Attacks.pdf
[11] Vicente Díaz. (2010, Febrero) OWASP Top 10 2010: Riesgos de seguridad en las Aplicaciones Web.
Presentacion de diapositivas.
[12] Oracle. (2009) SQL Injection Tutorial. Manual Electronico.
[13] Lance Ashdown and Oracle, Oracle® Database Application Developer's Guide - Fundamentals 10g
Release 2., 2005.
[14] David Litchfield. (2010, Febrero) BlackHat DC 2010: Hacking Oracle 11g. Conferencia Grabada.
[15] David Litchfield. (2009, Octubre) Database Security - Hacking Aurora in Oracle 11g. [Online].
www.databasesecurity.com/HackingAurora.pdf
166
[16] David Litchfield. (2007, Marzo) Oracle Forensics Part 1: Dissecting the Redo Logs. Artículo
Científico.
[17] David Litchfield. (2007) Dissection of an Oracle Attack. Conferencia Black Hat 2007.
[18] Jose Manuel Navarro. (2009, Febrero) Conceptos de almacenamiento en Oracle. [Online].
http://www.wikilearning.com/curso_gratis/iniciacion_a_oracleconceptos_de_almacenamiento_en_oracle/3861-6
[19] David Litchfield. (2007, Marzo) Oracle Forensics Part 2: Locating Dropped Objects. [Online].
http://www.ngssoftware.com/media-room/WhitePapers.aspx
[20] Oracle. Oracle® Database Advanced Application Developer's Guide, Chapter 13: Using Oracle
Flashback Technology. [Online].
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_flashback.htm
[21] Tim Hall. Auditing in Oracle 10g Release 2. [Online]. http://www.oraclebase.com/articles/10g/Auditing_10gR2.php
[22] Pete Finnigan. (2003, Abril) Introduction to Simple Oracle Auditing. [Online].
http://www.symantec.com/connect/es/articles/introduction-simple-oracle-auditing
[23] Stephen Kost and Jack Kanter. (2007, Abril) ORACLE DATABASE LISTENER SECURITY
GUIDE. [Online]. http://www.integrigy.com/securityresources/whitepapers/Integrigy_Oracle_Listener_TNS_Security.pdf
[24] ORACLE. (2010, Julio) Oracle® Database Net Services Administrator's Guide 11g Release 2 (11.2):
Analyzing Listener Log Files. [Online].
http://download.oracle.com/docs/cd/E11882_01/network.112/e10836.pdf
[25] David Litchfield. (2007, Marzo) Oracle Forensics: Part 3 Isolating Evidence of Attacks Against the
Authentication Mechanism. [Online]. http://www.ngssoftware.com/media-room/WhitePapers.aspx
[26] David Litchfield. (2007, Abril) Oracle Forensics Part 4: Live Response. [Online].
http://www.ngssoftware.com/media-room/WhitePapers.aspx
[27] Orasite. (2009) Conceptos basicos tunning Oracle. [Online].
http://www.orasite.com/tutoriales/conceptos-basicos-tunning-oracle.html
[28] Pete Finnigan. (2004, Marzo) How to set trace for others sessions, for your own session and at
instance level. [Online]. http://www.petefinnigan.com/ramblings/how_to_set_trace.htm
[29] H.Tonguç Yılmaz. (2007) Introduction to Oracle Trace Utulity and Understanding The Fundamental
Performance Equation. [Online]. http://tonguc.wordpress.com/2006/12/30/introduction-to-oracletrace-utulity-and-understanding-the-fundamental-performance-equation/
[30] adp-gmbh. (2003) Output format of a 10046 trace file. [Online]. http://www.adp-
167
gmbh.ch/ora/misc/trace_file_format.html
[31] plsql.biz. (2007, Junio) Uso del comando TKPROF para formatear los ficheros de trazado PL/SQL.
[Online]. http://www.plsql.biz/2007/06/uso-del-comando-tkprof-para-formatear.html
[32] Richard Bejtlich, "Real Digital Forensics: Computer Security and Incident Response," in Real Digital
Forensics: Computer Security and Incident Response.: Syngress, 2006, ch. 1, pp. 1-80.
[33] Arup Nanda. (2011, febrero) Oracle Database 11g:The Top New Features for DBAs and Developers.
[Online]. http://www.oracle.com/technetwork/articles/sql/11g-transactionmanagement-092065.html
[34] David Litchfield. (2007, Agosto) Oracle Forensics part 5: Finding Evidence of Data Theft in the
Absence of Auditing. [Online]. http://www.ngssoftware.com/media-room/WhitePapers.aspx
[35] Pete Finnigan. (2007, Octubre) Oracle Forensics. [Online].
http://www.petefinnigan.com/Oracle_Forensics_scotland.pdf
[36] Paul Wright. (2003, Junio) Oracle Database Forensics using LogMiner. [Online]. http://computerforensics.sans.org/community/papers/oracle-database-forensics-logminer_159
[37] Paul M. Wright. (2005, Enero) Oracle Database Forensics using LogMiner. Artículo Científico.
[38] David Litchfield. (2008, Noviembre) Oracle Forensics Part 7: Using the Oracle System Change
Number in Forensic Investigations. [Online]. http://www.databasesecurity.com/dbsec/oracleforensics-scns.pdf
[39] David Litchfield. Cadfile. [Online]. http://www.databasesecurity.com/oracle-forensics.htm
[40] David Litchfield. (2007, Febrero) Cursor Injection A New Method for Exploiting PL/SQL Injection
and Potential Defences. [Online]. http://www.databasesecurity.com/dbsec/cursor-injection.pdf
[41] Michael S. Pallos. Attack Trees: It's a Jungle out there. [Online].
www.bizforum.org/whitepapers/candle-4.htm
[42] David Litchfield. (2010) V3rity Software. [Online]. http://www.v3rity.com/products.php
[43] Bhavish Sood, Dan Sommer, and Hideaki Horiuchi Colleen Graham. (2010, April 30)
http://www.oracle.com/. [Online]. http://www.oracle.com/us/products/database/number-onedatabase-069037.html
[44] Microsoft Corporation. (2003, Marzo) How RPC Works. [Online]. http://technet.microsoft.com/enus/library/cc738291(WS.10).aspx
[45] Oracle. Data Blocks, Extents, and Segments. [Online].
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/logical.htm
[46] Oracle. (2004) Troubleshooting Oracle Net Services. [Online].
168
http://download.oracle.com/docs/cd/B14117_01/network.101/b10775/troublestng.htm#i452616
169
© Copyright 2024