ESTADO DEL ARTE DE LA APLICACIÓN DE TÉCNICAS …

1

CIS1010SD03

ESTADO DEL ARTE DE LA APLICACIÓN DE TÉCNICAS ANTIFORENSES EN BASES DE

DATOS ORACLE. CONCEPTOS Y RETOS PARA LOS INFORMÁTICOS FORENSES

Autores:

GUILLERMO ALFONSO FERRO RODRIGUEZ

PEDRO ALEJANDRO SANTIESTEBAN

http://pegasus.javeriana.edu.co/~CIS1010SD03/

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERÍA

CARRERA DE INGENIERÍA DE SISTEMAS

BOGOTÁ D.C.

http://pegasus.javeriana.edu.co/~CIS1010SD03/

2

ESTADO DEL ARTE DE LA APLICACIÓN DE TÉCNICAS ANTIFORENSES EN BASES DE

DATOS ORACLE. CONCEPTOS Y RETOS PARA LOS INFORMÁTICOS FORENSES

Autores:

GUILLERMO ALFONSO FERRO RODRIGUEZ

PEDRO ALEJANDRO SANTIESTEBAN

Trabajo de grado presentado para optar el título de Ingeniero de Sistemas

Director:

Ingeniero Jeimy José Cano Martínez, PhD




BOGOTÁ D.C.

3




Rector Magnífico

Padre Joaquín Emilio Sánchez García S.J.

Decano Académico Facultad de Ingeniería Ingeniero Francisco Javier Rebolledo Muñoz

Decano del Medio Universitario Facultad de Ingeniería Padre Sergio Bernal Restrepo S.J.

Director Carrera de Ingeniería de Sistemas Ingeniero Luis Carlos Díaz Chaparro

Director Departamento de Ingeniería de Sistemas César Julio Bustacara Medina

4

Nota de Aceptación ______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

______________________________________________________

Jeimy José Cano Martínez

Director del Proyecto

________________________________________

José Luis Lara

________________________________________

Julio Carreño

5

Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de

grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no

contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar

la verdad y la Justicia”

6

CONTENIDO

TABLA DE ILUSTRACIONES ......................................................................................................... 9

RESUMEN EJECUTIVO ................................................................................................................. 12

1 DESCRIPCIÓN GENERAL DEL TRABAJO DE GRADO ................................................ 14

1.1 Formulación ................................................................................................................................. 14

1.2 Justificación .................................................................................................................................. 15

1.3 Objetivo general ........................................................................................................................... 17

1.4 Objetivos específicos.................................................................................................................... 18

2 REVISIÓN DE LITERATURA ............................................................................................ 19

2.1 Administración Bases de datos .................................................................................................... 19

2.1.1 Estado Actual ....................................................................................................................... 19

2.2 Bases de datos Oracle ................................................................................................................... 22

2.2.1 Conceptos básicos de Bases de datos Oracle ....................................................................... 22

2.2.2 Arquitectura Oracle .............................................................................................................. 22

2.3 TECNICAS ANTI-FORENSES .................................................................................................. 27

2.3.1 Definición ............................................................................................................................. 28

2.3.2 Objetivos .............................................................................................................................. 29

2.3.3 Destrucción de evidencia...................................................................................................... 29

2.3.4 Ocultación de evidencia ....................................................................................................... 29

2.3.5 Eliminación de fuentes de evidencia .................................................................................... 30

2.3.6 Falsificación de evidencia .................................................................................................... 30

2.4 ATAQUES EN ORACLE ............................................................................................................ 31

2.4.1 SQL INJECTION ................................................................................................................. 31

2.4.2 TIPOS DE ATAQUES SQL INJECTION ........................................................................... 33

2.4.3 SQL MANIPULATION ....................................................................................................... 34

2.4.4 CODE INJECTION .............................................................................................................. 35

2.4.5 FUNCTION CALL INJECTION ......................................................................................... 35

2.4.6 BUFFER OVERFLOWS ..................................................................................................... 37

2.5 TÉCNICAS FORENSES EN BASES DE DATOS ORACLE .................................................... 37

2.5.1 ENTORNO ........................................................................................................................... 38

2.5.2 PRINCIPALES FUENTES DE EVIDENCIA EN ORACLE .............................................. 38

2.5.3 HERRAMIENTAS ÚTILES EN UN ENTORNO ORACLE .............................................. 80

7

2.6 CASO DE ESTUDIO ................................................................................................................... 86

2.6.1 EVIDENCIA DE LAS ACCIONES DEL ATACANTE ..................................................... 86

2.7 TECNICAS ANTI FORENSES EN BASES DE DATOS ORACLE.......................................... 87

2.7.1 Técnicas anti forenses en contra del Redo Log .................................................................... 87

2.7.2 Técnicas anti forenses contra los rastros dejados por la eliminación de objetos .................. 88

2.7.3 Técnicas anti forenses en contra de las tablas de auditoria .................................................. 88

2.8 GUíA METODOLOGICA PARA EL ANáLISIS DE BASES DE DATOS ORACLE .............. 88

2.9 RECOMENDACIONES PARA LOS INVESTIGADORES FORENSES EN INFORMÁTICA

EN BASES DE DATOS ORACLE. ........................................................................................................ 91

3 CONCLUSIONES ................................................................................................................ 92

4 TRABAJOS FUTUROS ....................................................................................................... 93

5 ANEXOS .............................................................................................................................. 94

5.1 Anexo 1 ........................................................................................................................................ 94

5.2 Anexo 2 ........................................................................................................................................ 95

5.3 Anexo 3 ........................................................................................................................................ 96

5.4 Anexo 4 ........................................................................................................................................ 97

5.5 Anexo 5 ........................................................................................................................................ 98

5.6 Anexo 6 ........................................................................................................................................ 99

5.7 Anexo 7 ...................................................................................................................................... 100

5.8 Anexo 8 ...................................................................................................................................... 101

5.9 Anexo 9 ...................................................................................................................................... 102

5.10 Anexo 10 .................................................................................................................................... 103

5.11 Anexo 11 .................................................................................................................................... 104

5.12 Anexo 12 .................................................................................................................................... 106

5.13 Anexo 13 .................................................................................................................................... 107

5.14 Anexo 14 .................................................................................................................................... 108

5.15 Anexo 15 .................................................................................................................................... 109

5.16 Anexo 16 .................................................................................................................................... 110

5.17 Anexo 17 .................................................................................................................................... 111

5.18 Anexo 18 .................................................................................................................................... 112

5.19 Anexo 19 .................................................................................................................................... 113

5.20 Anexo 20 .................................................................................................................................... 114

5.21 Anexo 21 .................................................................................................................................... 115

5.22 Anexo 22 .................................................................................................................................... 116

5.23 Anexo 23 .................................................................................................................................... 117

8

5.24 Anexo 24 .................................................................................................................................... 118

5.25 Anexo 25 .................................................................................................................................... 123

5.26 Anexo 26 .................................................................................................................................... 134

5.27 Anexo 27 .................................................................................................................................... 135

5.28 Anexo 28 .................................................................................................................................... 136

5.29 Anexo 29 .................................................................................................................................... 137

5.30 Anexo 30 .................................................................................................................................... 138

5.31 Anexo 31 .................................................................................................................................... 139

5.32 Anexo 32 .................................................................................................................................... 140

5.33 Anexo 33 .................................................................................................................................... 141

5.34 Anexo 34 .................................................................................................................................... 142

5.35 Anexo 35 .................................................................................................................................... 143

5.36 Anexo 36 .................................................................................................................................... 144

5.37 Anexo 37 .................................................................................................................................... 146

5.38 Anexo 38 .................................................................................................................................... 149

5.39 Anexo 39 .................................................................................................................................... 150

5.40 Anexo 40 .................................................................................................................................... 151

5.41 Anexo 41 .................................................................................................................................... 152

5.42 Anexo 42 .................................................................................................................................... 153

5.43 Anexo 43 .................................................................................................................................... 154

5.44 Anexo 44 .................................................................................................................................... 156

5.45 Anexo 45 .................................................................................................................................... 157

5.46 Anexo 46 .................................................................................................................................... 158

5.47 Anexo 47 .................................................................................................................................... 159

5.47.1 Recaudo de la información ................................................................................................. 160

5.48 Anexo 48 .................................................................................................................................... 164

6 TRABAJOS CITADOS ...................................................................................................... 166

9

TABLA DE ILUSTRACIONES

Ilustración 1: Promedio de ataques bloqueados por día [1]. ........................................................................ 17 Ilustración 2: Ventajas de hacer las cosas bien [1] ....................................................................................... 20 Ilustración 3: Rastros en el audit trail de un intento de ejecutar una sentencia con privilegios insuficientes

[25] ............................................................................................................................................................... 58 Ilustración 4: Audit trail justo después de iniciar sesión [25] ...................................................................... 58 Ilustración 5: Audit trail justo después de cerrar sesión [25] ....................................................................... 59 Ilustración 6: Campo LOGOFF$TIME de la tabla AUD$ [25] ................................................................... 59 Ilustración 7: Volcado de los predicados LIKE_PREDS [34] ..................................................................... 77 Ilustración 8: Creación diccionario de datos ................................................................................................ 83 Ilustración 9: Mapa de Acción ..................................................................................................................... 88 Ilustración 10: Sofisticación Vs. Conocimiento del atacante [41]. .............................................................. 94 Ilustración 11: Intrusiones de seguridad en 2010 [1] ................................................................................... 95 Ilustración 12: Actualizaciones de seguridad [1] ......................................................................................... 96 Ilustración 13: Estructura de la base de datos Oracle [6] ........................................................................... 97 Ilustración 14: Técnicas Anti-forenses [3] ................................................................................................... 98 Ilustración 15: Vulnerabilidad usada para comprometer el sistema [9] ....................................................... 99 Ilustración 16: Configuración de los Redo Logs en la creación de la base de datos .................................. 100 Ilustración 17: Bloque de datos Oracle [19] ............................................................................................... 102 Ilustración 18: Consulta de verificación del estado de las funciones de auditoria [21] ............................ 103 Ilustración 19: Volcado de información a partir de los tipos de dato de la tabla OBJ$ [19] ...................... 105 Ilustración 20: Entradas en el listener log generadas al ejecutar sidguess.exe [25] ................................... 106 Ilustración 21: Registro de eventos de conexiones privilegiadas SYSDBA y SYSOPER en Windows [25]

.................................................................................................................................................................... 107 Ilustración 22: Evidencia de inicio de sesión cuando la auditoria esta desactivada [25] ........................... 107 Ilustración 23: Localización traza .............................................................................................................. 108 Ilustración 24: Traza sin formato ............................................................................................................... 108 Ilustración 25: Sentencias de volcado ........................................................................................................ 109 Ilustración 26: Volcado NOSYS ................................................................................................................ 109 Ilustración 27:Comando Time .................................................................................................................... 110 Ilustración 28: Comando Date.................................................................................................................... 110 Ilustración 29: Comando net user ............................................................................................................... 111 Ilustración 30: Detalles de usuario ............................................................................................................. 111 Ilustración 31: Lista de conexiones y puertos ............................................................................................ 112 Ilustración 32: Ubicación Home ................................................................................................................ 113 Ilustración 33: Ubicación Archivo de Inicio .............................................................................................. 113 Ilustración 34: Validación Ruta diccionario Logminer .............................................................................. 115 Ilustración 35: Configuración ruta diccionario .......................................................................................... 115 Ilustración 36: Validación Pos activación .................................................................................................. 115 Ilustración 37: Agregando archivos de investigación ................................................................................ 116 Ilustración 38: Tipos de datos LogMiner ................................................................................................... 117 Ilustración 39: Creando el usuario a explotar ............................................................................................. 118 Ilustración 40: Revisando los privilegios del usuario ................................................................................ 118 Ilustración 41: Verificando los permisos Java del usuario ......................................................................... 119 Ilustración 42: Sentencia de inyección para obtener privilegios Java arbitrarios...................................... 119 Ilustración 43: Verificación de inserción de nuestra Política Java ............................................................. 120 Ilustración 44: Sentencia para ejecutar comandos de sistema operativo .................................................... 120

10

Ilustración 45: Creación de un usuario en el sistema operativo ................................................................. 121 Ilustración 46: Agregando el usuario al grupo de administradores del sistema operativo ......................... 121 Ilustración 47: Lateral Injection al re direccionar la salida de un error ..................................................... 122 Ilustración 48: Ejecución de un paquete de SYS con parámetros inválidos para ejecutar nuestro ataque . 122 Ilustración 49: Proceso para darle formato al archivo trc........................................................................... 124 Ilustración 50: Sentencia 1 Ejecución de un procedimiento para explotar vulnerabilidad de aurora ......... 124 Ilustración 51: Sentencia 2 Permisos para modificar la entrada y salida del sistema ................................ 125 Ilustración 52: Sentencia 3 Creación de archivo de salida OUT.LST ........................................................ 125 Ilustración 53: Creación de un usuario dentro del sistema operativo ......................................................... 125 Ilustración 54: Ejecución de permisos para Otorgar perfil de DBA .......................................................... 126 Ilustración 55: Flujo de información para crear el overflow ...................................................................... 126 Ilustración 56: Set Role as DBA ................................................................................................................ 126 Ilustración 57: Evidencia del ataque en los Redo Logs .............................................................................. 127 Ilustración 58: Verificación de la evidencia obtenida en el volcado generado por la herramienta

"dumpaction.exe" ....................................................................................................................................... 128 Ilustración 59: XML para filtrar entradas sospechosas de un Redo Log .................................................... 129 Ilustración 60: Entradas relacionadas a BONIFACIO en la tabla de auditoría AUD$ .............................. 130 Ilustración 61: Código de acción relacionado al valor hallado en la tabla AUD$ ..................................... 130 Ilustración 62: Técnica anti forense de eliminación de la evidencia almacenada en la tabla AUD$ ......... 131 Ilustración 63: Sentencia de uso de Orablock para hallar evidencia relacionada a la tabla AUD$ en el Data

File SYSTEM01.DBF ................................................................................................................................ 132 Ilustración 64: Archivo de estructura de la tabla AUD$ ............................................................................ 132 Ilustración 65: Evidencia de filas eliminadas de la tabla AUD$ ................................................................ 133 Ilustración 66 : Diagrama de flujo para detectar vulnerabilidades de SQL Injection – Adaptado de [12] 134 Ilustración 67: Volcado Hexadecimal de un bloque asignado a la tabla SOURCE$ [19] .......................... 135 Ilustración 68: Información contenida en las filas eliminadas asociadas al objeto 51850 [19] ................. 135 Ilustración 69: Volcado Hexadecimal de los bloques asignados a la tabla IDL_UB1$ [19] ..................... 137 Ilustración 70: Diferencia entre autenticación de la cuenta SYS con y sin "AS SYSDBA" [25] .............. 138 Ilustración 71: Búsqueda ruta trace files ................................................................................................... 139 Ilustración 72: SPFile Texto ....................................................................................................................... 140 Ilustración 73: Ruta Listener logs [26] ....................................................................................................... 141 Ilustración 74: Versión ............................................................................................................................... 142 Ilustración 75: Descripción de la columna COL_USAGE$ [34] ............................................................... 143 Ilustración 76: Filt1.xml ............................................................................................................................. 144 Ilustración 77: Filt-bool.xml ...................................................................................................................... 144 Ilustración 78: Filt-grant.xml ..................................................................................................................... 145 Ilustración 79:Filt-xid.xml ......................................................................................................................... 145 Ilustración 80: Parámetros de la herramienta Orablock ............................................................................. 145 Ilustración 81: Errores del TNS Listener [23] ............................................................................................ 146 Ilustración 82: Entradas en el listener log para los comandos SERVICES y STATUS [25] ..................... 146 Ilustración 83: Entradas en el audit trail para intentos de conexión de usuarios no existentes [25] .......... 147 Ilustración 84: Entrada del audit trail usando la columna COMMENT$TEXT [25] ................................ 147 Ilustración 85: Evidencia del uso de orapwdbrute.exe [25] ....................................................................... 147 Ilustración 86: Consulta para extraer la fecha en que se bloquea una cuenta ............................................ 148 Ilustración 87: Entradas en el listener log generadas al ejecutar sidgusser.exe [25] .................................. 149 Ilustración 88: Búsqueda SID y Serial # .................................................................................................... 150 Ilustración 89: Encabezado de un archivo Oracle ...................................................................................... 151 Ilustración 90: Ejemplo de verificación del tamaño de un archivo Oracle ................................................ 151 Ilustración 91: Encabezado de un bloque en un archivo Oracle Redo Log ................................................ 152

11

Ilustración 92: Estructura del encabezado de un Red Log – Adaptado de [16] ......................................... 153 Ilustración 93: Encabezado de una fila eliminada [19] .............................................................................. 154 Ilustración 94: Extracción de información de columnas de una fila eliminada [19] .................................. 154 Ilustración 95: Volcado hexadecimal de una fila [19] ............................................................................... 155 Ilustración 96: Discriminación de columnas a partir de un volcado hexadecimal [19] ............................. 155 Ilustración 97: Volcado Hexadecimal de un bloque asignado a la tabla MY_TEMP_TABLE [19] ......... 156 Ilustración 98: TimeStamp tabla dual [36] ................................................................................................. 157 Ilustración 99: TimeStampLogMiner [36] ................................................................................................. 157 Ilustración 100: SentenciaSpool [36] ......................................................................................................... 158 Ilustración 101: Estructura LogMiner Redo Logs [36] .............................................................................. 158 Ilustración 102: Verificación Serial Commit Number [36] ........................................................................ 159

12

RESUMEN EJECUTIVO

A partir de los diferentes mecanismos de control que provee Oracle podemos recrear todo tipo de

actividades que se hayan realizado en la base de datos, en esta investigación inicialmente mostraremos la

motivación y el porque es necesario este trabajo, desde las estadísticas de intrusión hasta las tendencias

actuales que demuestran que las bases de datos son el principal objetivo de los atacantes a la hora de

buscar información sensible de las corporaciones. Posteriormente en el Capítulo 2 se realiza la toda la

revisión de Literatura existente, esta revisión se divide en:

Administración bases de datos

En esta sección se verifica cada una de las tendencias actuales que se presentan con las bases de datos,

desde las estadísticas de intrusión hasta políticas y buenas prácticas que se deben tener en cuenta por los

DBA´s que son los encargados de la administración de la seguridad. También se muestra cual es el estado

actual del manejador de Base de datos Oracle con respecto a otros manejadores y cuáles han sido su fallas

y sus aciertos en lo que a temas de seguridad se refiere.

Bases de datos Oracle

En esta sección se explican los conceptos básicos de la arquitectura de las base de datos Orcale, desde los

espacios en memoria hasta la arquitectura física y lógica de manejador de bases de datos. También

podemos encontrar el primer acercamiento a los diferentes medios de almacenamiento de evidencia y los

principales mecanismos de recuperación de información.

Técnicas anti-forenses

En esta sección se presentan las diferentes agrupaciones de técnicas anti-forenses las cuales son:

Destrucción de evidencia

Ocultación de evidencia

Eliminación de fuentes de evidencia

Falsificación de evidencia

Ataques en Oracle

13

Dentro de esta sección podemos encontrar 2 clasificaciones de ataques a nivel general la primera se

dividió de la siguiente forma:

Ataques de primer orden

Ataques de segundo orden

Inyección lateral

Buffer overflows

La otra Clasificación es la siguiente:

Sql manipulation

Code injection

Function call injection

Buffer overflows

Técnicas forenses en bases de datos Oracle

Se explican las principales fuentes de evidencia, se explica su configuración y sus diferentes formas de

análisis. Dentro de las fuentes de evidencia que se encuentran en esta sección podemos ver:

Redo Logs

Archivos TNS Logs

Archivos Trace de Oracle

Datafiles Oracle

AUD$

Caso de estudio

Vemos de manera práctica lo presentado en la sección anterior, mostrando detalladamente el ataque

escogido y estudiándolo a la luz de las posibles pruebas y reconstrucción de eventos del ataque.

Recomendaciones para los investigadores forenses en informática en bases de datos

Oracle.

Finalmente en esta sección presentamos las consideraciones que debe poseer un informático forense a la

hora de realizar una investigación que implique un sistema gestor de base de datos de Oracle.

14

1 DESCRIPCIÓN GENERAL DEL TRABAJO DE GRADO

1.1 FORMULACIÓN

A medida que los sistemas avanzan y toman protagonismo en un mundo cada vez más exigente y

productivo, se perfila de manera cada vez más evidente la necesidad de hacer a los sistemas más seguros,

ya que el avance no sólo se presenta en la eficacia y productividad, sino también en la calidad y en la

cantidad de los ataques informáticos que aquejan los sistemas actualmente. Ver Anexo 1

Como se puede ver en la Ilustración No. 1 cada día es más notorio que la tendencia es que los atacantes

sean cada vez más efectivos y que el conocimiento de los mismos sea cada vez menor. Este asunto es

preocupante ya que esta tendencia de los ataques y la facilidad de los mismos es clara y se encuentra en

aumento, lo cual tendrá como consecuencia que los eventos de seguridad informática sean cada vez más

específicos, eficaces y elaborados.

Es necesario también que los involucrados en la administración de la seguridad de los sistemas de bases de

datos no sólo conozcan muy bien sus plataformas sino que además también conozcan las posibles fallas de

seguridad que nativamente poseen, ya que si sabemos nuestras debilidades es más sencillo saber dónde

investigar e intentar fortalecerlas para que cada vez sean menos los incidentes a los cuales podríamos

exponer nuestras corporaciones.

En la actualidad las bases de datos no se escapan de la tendencia anteriormente evidenciada ya que estas

son las herramientas de mayor importancia para las corporaciones y la vida cotidiana en general, el

comercio web y las transacciones. El constante crecimiento de internet ha hecho que las bases de datos

tengan que ser accesibles de manera rápida y eficiente pero también de manera más insegura, por lo cual,

lo que antes era accesible por diferentes tipos de capas ahora es accesible casi que de manera inmediata.

Indirectamente todos los datos que nosotros suministramos de manera web como nuestros nombres,

nuestras relaciones, nuestras contraseñas y todo tipo de información que componga nuestra vida digital,

finalmente quedara en un repositorio de datos en alguna parte del mundo, y como si esto fuera poco no

solo nuestra información personal se encuentra almacenada en la bases de datos, sino que además, estos

sistemas se encargan de administrar un gran porcentaje de la economía mundial. Al ser el lugar donde

permanece más tiempo la información y donde se puede encontrar mayor cantidad de esta, los atacantes

15

buscaran la forma de infiltrarse dentro de la base de datos para cometer sus ilícitos. Por todo lo anterior

encontramos que la seguridad de las bases de datos es un tema que debe ser estudiado a profundidad y de

manera concienzuda, evitando e identificando los posibles tipos de técnicas que los criminales puedan

llegar a usar para lograr su objetivo, con el fin de volver mucho más seguros lo repositorios en los cuales

la información sensible de la empresa se encuentra [1].

Para este caso estudiaremos en detalle los ataques más comunes y los tipos de técnicas anti-forenses que

utilizan los criminales para alterar, ocultar y eliminar las posibles evidencias que puedan quedar de sus

actos, sobre las bases de datos Oracle específicamente, ya que Oracle es uno de los manejadores de bases

de datos más utilizado a nivel mundial, por lo cual es de esperarse que los atacantes aprenderán y

desarrollarán todo tipo de técnicas para evadir los mecanismos de seguridad. Esto hace que el estudio de

las técnicas anti-forenses mencionadas que usen los atacantes, sea un estudio necesario para toda la

comunidad de informáticos forenses y administradores de bases de datos que serán los encargados de

realizar las investigaciones.

Teniendo en cuenta el panorama anteriormente visto, este documento, posee como objetivo principal tratar

de dar respuesta a la pregunta: ¿Cómo identificar, investigar y prevenir el uso de técnicas anti forenses en

Bases de datos Oracle?

1.2 JUSTIFICACIÓN

Oracle es uno de los manejadores de bases de datos más usados a nivel mundial, esto implica que los

investigadores forenses deben estar preparados para enfrentarse a investigaciones que involucren bases de

datos Oracle. A medida que estos manejadores van avanzando, también es necesario avanzar en las

técnicas y procedimientos usados para realizar una investigación forense que pueda identificar de manera

efectiva y eficiente los hechos acontecidos en la escena del crimen, además de los procedimientos usados

para realizar el ataque o la intrusión dentro de la base de datos. En la revisión realizada en este trabajo, se

identificaron artículos que hablan de ataques específicos, limitados documentos con información sobre

métodos para adelantar investigaciones forenses en bases de datos Oracle y muchos menos sobre las

posibles técnicas anti-forenses que un atacante podría usar para evitar que sus acciones sean descubiertas

por un examinador forense.

La seguridad total es imposible, ya que no existe ningún sistema que no se encuentre en relación con un

entorno o con otro sistema bien sea humano o digital. Si tenemos esto como premisa, podemos determinar

16

que la seguridad de un sistema está determinada por la inseguridad a la cual se encuentre expuesto, lo que

permite crear políticas y estrategias que incrementan y ayudan a complicar el acceso de los usuarios no

permitidos, haciendo de esta manera, sistemas más seguros [2]. Actualmente los atacantes no solo se han

enfocado en realizar el ataque sino en, además, hacer todo lo posible para que sea virtualmente imposible

recrear los hechos, haciendo que sus huellas sean eliminadas o distorsionadas para no ser atrapados, “Haz

difícil que te encuentren e imposible de probar que te encontraron” [2], es la premisa actual de todo

atacante, esto ha hecho que las investigaciones sean cada vez más desafiantes y mucho más exigentes para

los investigadores forenses.

Al ser las bases de datos una de las herramientas más usuales y que más servicios le presta a los procesos

dentro de nuestra sociedad, es necesario identificar y poder recrear los hechos acontecidos dentro de una

base de datos en el momento de adelantar una investigación forense, analizándolo todo bajo los principios

de las posibles técnicas anti-forenses enunciadas por Harris (Eliminación de la fuente, ocultamiento,

borrado y la falsificación de las evidencias Digitales) [3], ya que con esto se podría lograr acotar de

manera más precisa cuál fue el rumbo de acción del atacante y de esta manera lograr resultados más

exactos y confiables.

Ya que la informática forense tiene como propósito “apoyar el proceso investigativo utilizando la

evidencia digital que sustente y verifique las afirmaciones que sobre los hechos delictivos se han

materializado en el caso bajo estudio” [4], es completamente válido y además necesario sugerir una

práctica o crear una guía metodológica que permita a los investigadores forenses tener una guía que les

permita identificar que la evidencia recolectada dentro de la investigación no haya sido modificada o

alterada de ninguna manera.

La seguridad de las bases de datos ya no es un tema de apostar a la no ocurrencia de un posible ataque

como podría haber sucedido hace 10 años, sino que la pregunta real es ¿cuándo nos van a atacar? [1].

Según un estudio hecho por Xforce de IBM solamente los ataques por SQL injection se han multiplicado

de manera vertiginosa en el 2008 y es una tendencia que se encuentra en crecimiento, demostrando así que

el problema es real y que es ahora cuando debemos tomar cartas sobre el asunto.

17

Ilustración 1: Promedio de ataques bloqueados por día [1].

Teniendo como base que la seguridad sobre las bases de datos es un tema que debe ser tratado a la mayor

brevedad, es necesario identificar quiénes serán los actores que se encargarán de mantener la información

que se encuentra en nuestra base de datos segura. Esta respuesta, aunque aparentemente obvia, es

fácilmente olvidada y difuminada entre la cantidad de usuarios, desarrolladores y administradores de los

sistemas utilizados para el almacenamiento de información.

Este trabajo de grado tiene como objetivo lograr que por medio de la computación anti-forense se pueda

aprender a reconocer y entender las limitaciones de seguridad que posee el manejador de bases de datos

Oracle, para comprender en materialización de sus vulnerabilidades, las fuentes de información y puntos

específicos de análisis que deben ser considerados por los informáticos forenses y así apoyar el análisis de

resultados de incidentes sobre este tipo de elemento informático. También se pretende proveer un marco

de elementos conceptuales y prácticos acerca de este manejador de bases de datos. Los posibles tipos de

ataques que se pueden realizar sobre esta plataforma, además de los diferentes tipos de técnicas utilizados

para ocultar y alterar las evidencias, deben ser prioridades en los estudios en el área, para que las

investigaciones forenses puedan ser concluyentes y confiables.

En una segunda instancia propondremos una guía metodológica que provea los elementos necesarios para

evidenciar el uso de técnicas anti-forenses sobre las bases de datos Oracle.

1.3 OBJETIVO GENERAL

Desarrollar una guía metodológica para un análisis forense sobre bases de datos Oracle, teniendo en

cuenta los rastros de las principales técnicas anti-forenses y herramientas de identificación, investigación y

prevención disponibles en la actualidad.

18

1.4 OBJETIVOS ESPECÍFICOS

Estudiar la arquitectura de las bases de datos Oracle, identificando los componentes de seguridad

y sus posibles brechas.

Realizar un análisis acerca de cuáles son los rastros más significativos y de qué manera se

materializan las técnicas anti forenses en las bases de datos Oracle.

Estudiar cómo se adelanta una investigación o análisis forense en una base de datos y especificar

los detalles de la misma sobre Oracle.

Identificar y comprender las principales categorías de ataques informáticos dentro de los

ambientes de bases de datos Oracle.

Explorar qué tipo de herramientas existen o se utilizan para soportar las investigaciones en Bases

de Datos Oracle.

19

2 REVISIÓN DE LITERATURA

2.1 ADMINISTRACIÓN BASES DE DATOS

2.1.1 Estado Actual

Actualmente y aunque parezca completamente incoherente, la administración de la seguridad de bases de

datos ha quedado relegada a un segundo plano y en muchas de las corporaciones no la tienen en cuenta,

pues no representa un valor agregado en primera instancia para el funcionamiento del negocio. Este tipo

de pensamiento ya no es viable en un mundo en el cual la conectividad ha crecido de tal manera que es

posible realizar transacciones desde cualquier parte del globo haciendo uso de internet. La mayoría de las

bases de datos actualmente se rigen por políticas de facilidad y comodidad más que por las políticas de

seguridad [1]. Ver Anexo 2

Tan solo en 2008, las bases de datos fueron los objetivos principales de los atacantes con un 75% de

registros de intento de ataques y un 30% de intrusiones exitosas. Esto es entendible ya que las bases de

datos son el lugar en el cual la información permanece más tiempo y donde aparentemente no presenta un

control más exigente que el que preste el manejador.

La tendencia de las corporaciones a publicar sus servicios de manera web y dar facilidades de

interconexión entre los partners, ha dado un rumbo peligroso al manejo de la información, puesto que la

mayoría de bases de datos se encuentran atadas a una interfaz web, es necesario usar políticas de

seguridad, porque de no ser así sería el escenario perfecto para un atacante [1], [5].

Otros factores que también influyeron dentro de la explosión WEB fueron el comercio electrónico, la

facilidad de compra y venta de artículos, y la automatización de las finanzas. Estos fueron eventos de

suma importancia para que las bases de datos y las aplicaciones WEB surgieran con gran fuerza pero

también con muchos inconvenientes y problemas que representan oportunidades de negocio para los

hackers, y dolores de cabeza para los DBA1 y los expertos en seguridad [5].

Aunque los manejadores de bases de datos han incrementado notoriamente su seguridad, hay gran

cantidad de componentes que aún no se pueden controlar. Oracle ha publicado 69 alertas de seguridad

hasta el momento. Sus parches críticos de actualización y alertas de seguridad, arreglan un alto porcentaje

de bugs y posibles brechas que posee la herramienta, Solo hasta el parche 68 los bugs solucionados

ascendían a más de 50.

1DBA: Administrador de Bases de Datos (DatabaseAdministrator)

20

La seguridad de las bases de datos definitivamente tiene que ser un asunto de los usuarios, de las

corporaciones y de los DBA, ya que nadie más que ellos, conoce al detalle las mismas. En noviembre de

2008 ForresterResearch demostró por medio de una gran encuesta, que los DBA dedican menos del 5 %

de su tiempo para los temas de seguridad de la base de datos. Los administradores de las bases de datos

actualmente se encuentran tan atareados con las tareas de almacenamiento, tunning up, migraciones y

copias de seguridad que no le dan el tiempo ni la importancia necesarios, a la administración de las

políticas de seguridad, dice el analista de Forrester Noel Yuhanna. [1].

Ilustración 2: Ventajas de hacer las cosas bien [1]

Según un estudio realizado por el grupo Aberdeen, las ventajas que poseen las empresas que hacen una

auditoria a sus sistemas de seguridad son notables porque poseen un aumento ostensible en la prevención

de incidentes de seguridad informática y por ende un incremento en la productividad de las corporaciones,

ya que se disminuyen los tiempos en los cuales los sistemas se encuentran sin servicio. La seguridad de las

bases de datos debe ser una tarea de los DBA´s. Las principales tareas que pueden ser desarrolladas por

ellos para mantener la confidencialidad de las bases de datos son:

1. Cifrado de las bases de datos: Las bases de datos pueden ser cifradas completamente o

parcialmente. Si es cifrada completamente, puede que el rendimiento se reduzca dependiendo del

tamaño de la base de datos. En caso de que sea cifrada parcialmente, puede tenerse un cifrado de

tablas, de columnas, de filas o hasta de celdas específicamente. Para la toma de decisiones acerca

del nivel al cual se debe tener el cifrado de datos, tenemos que tener en cuenta qué aplicaciones

dependen de la base de datos, qué impacto podría tener en los procesos empresariales y que

medidas habría que tomar para que este impacto sea mínimo.

21

2. Manejo de políticas de contraseñas: Según Alexander Kornbrust esta es la práctica más importante

para la administración de seguridad de una base de datos ya que “en mi opinión, este tema es el

más importante, porque aunque usted aplique las mejores prácticas en seguridad de bases de

datos, son inútiles si alguien se hace de las contraseñas legítimas, todo lo demás es más o menos

una pérdida de tiempo”2.

3. Actualizaciones y parches de seguridad: Es importante que los DBA´s mantengan sus bases de

datos actualizadas ya que gran parte de los ataques se realizan haciendo uso de la falencia de los

parches y actualizaciones de seguridad. Ver Anexo 3

Un estudio realizado por la asociación de usuarios independientes de Oracle demostró que un 26%

de los usuarios actualizan sus sistemas 6 meses después de que ha sido liberado un parche de

seguridad y que el 11% jamás los actualizan [1].

Aunque los DBMS actuales poseen gran cantidad de mecanismos para la prevención y análisis de

incidentes forenses, como lo son la autenticación, la autorización, el control de acceso y otras

técnicas un poco más elaboradas como es la auditoria y el monitoreo, solamente el 25 % de las

corporaciones hacen uso de estas. [1]

4. Configuración de privilegios: Todos los usuarios deben tener la menor cantidad de permisos de

usuario, única y exclusivamente lo necesario para poder realizar sus tareas ya que muchas veces

los usuarios tienen más privilegios de los que necesitan y pueden comprometer la seguridad de la

información con o sin intención.

Tras revisar brevemente el estado actual de la seguridad en las bases de datos y las acciones al

respecto por parte de los administradores de estas, pasaremos a estudiar en más detalle el DBMS

Oracle (que es el que concierne directamente a este trabajo), trataremos los conceptos básicos de

arquitectura y la manera en que se encuentran organizados los archivos de una base de datos de este

tipo, así mismo las estructuras de memoria más importantes y los procesos más relevantes para

entender el funcionamiento básico de Oracle y así tener mayor probabilidad de éxito a la hora realizar

una investigación forense en este entorno.

2 Traducción libre del autor.

22

2.2 BASES DE DATOS ORACLE

Hablar de una base de datos segura o hablar del mejor motor de bases de datos es muy sutil si lo vemos

desde el punto de vista del conocimiento, pues en la medida en que una persona conoce las capacidades y

las debilidades de un motor de bases de datos, aumenta su habilidad para administrarla y por ende su

capacidad de garantizar la seguridad de la información contenida en la misma. Entre más características o

capacidades posee un motor de bases de datos, mayor se hace el rango de información que un DBA debe

cubrir para garantizar la óptima administración de su manejador. El hecho de cómo saber cómo funciona

su DBMS permite garantizar, que mientras se cumplan las políticas de seguridad planteadas por los

expertos en seguridad, la información almacenada estará más segura y conservara su integridad. [5]

Como Oracle es un DBMS con tantas funcionalidades, no es el punto central de este trabajo describirlas y

analizarlas todas, pero si debemos estudiar los conceptos básicos antes de poder enfrentarnos

adecuadamente a una investigación forense. A continuación se tratan dichos conceptos de manera breve.

2.2.1 Conceptos básicos de Bases de datos Oracle

Oracle es el servidor de bases de datos más popular y es usado en diversas áreas de mercado, esto se debe

a que lleva un largo tiempo compitiendo en este sector y desde sus comienzos ofreció un motor de bases

de datos relacional que corría en diversos sistemas operativos; y aunque aún lo hace, su entorno preferido

parece inclinarse hacia Linux. Con la explosión del comercio electrónico Oracle ganó popularidad como la

base de datos escogida para aplicaciones web. Al sacar la base de datos de un entorno controlado de

acceso limitado a las máquinas de la empresa y pasarla al entorno web, obtenemos grandes ventajas, pero

asimismo la acercamos al atacante y por ende debemos ser mucho más cuidadosos a la hora de

administrar la seguridad. Es por esto que es de vital importancia comenzar conociendo las funcionalidades

básicas del RDBMS para así poder entender posteriormente, en qué debilidades se basan los atacantes a la

hora de planear un crimen en un entorno Oracle. [5]

2.2.2 Arquitectura Oracle

“Un servidor Oracle es el componente que permite una administración y desarrollo de bases de datos.

Tiene tres posibilidades de ejecución [6]:

Local o basada en host. El servidor se ejecuta en la misma máquina en la que se conectan los

clientes. La versión personal de Oracle produce servidores de este tipo.

23

Cliente-Servidor. Enfoque más típico. El servidor reside en un ordenador distinto respecto al que

los usuarios van a usar para conectarse a la base de datos.

Cliente-Servidor de Aplicaciones-Servidor. Los usuarios acceden a un servidor de aplicaciones

(Oracle Application Server) que, a su vez, accede al servidor Oracle. Los tres elementos (cliente,

servidor de aplicaciones, servidor Oracle) pueden estar en tres máquinas distintas.

Elementos del servidor Oracle

El servidor Oracle está formado por dos elementos:

La instancia de la base de datos

“Consta de datos (estructuras de memoria) y de procesos en memoria (procesos background) necesarios

para dar servicio a los usuarios de la base de datos. Puede haber más de una instancia si se distribuye la

base de datos en más de una máquina. Cada instancia abre una y sólo una base de datos” [6].

Ficheros en disco.

Representan la base de datos en sí. Se dividen en: [6]:

Estructuras lógicas: Tablespaces, objetos del esquema de usuario.

Estructuras físicas: Los ficheros de datos almacenados en disco. Los ficheros de datos (asociados

a los tablespaces), los ficheros redo log y los ficheros de control.

Conexiones

Para establecer una sesión con la base de datos, el usuario necesita conectarse con la instancia de la

base de datos. Normalmente esto significa utilizar una herramienta cliente como SQL*Plus o ejecutar una

aplicación de desarrollo de bases de datos (como Oracle Forms); entonces se ejecuta un proceso de

usuario [6].

Cuando esto ocurre, en el servidor se establece un proceso de servidor. Este proceso es el encargado de

comunicar al usuario con la instancia Oracle en nombre del proceso de usuario. Cada vez que el usuario

ejecuta instrucciones SQL, éstas son transmitidas a la instancia Oracle por el proceso servidor [6].

24

Cada sesión es una conexión de un usuario con el servidor Oracle. Un usuario puede establecer múltiples

sesiones (si se conecta desde diferentes herramientas y máquinas) [6].

Estructura de las bases de datos Oracle

Desde el punto de vista de Oracle, una base de datos es una colección de datos tratados como una única

unidad. Una base de datos Oracle contiene tres tipos de ficheros [6]:

Archivos de datos. Contiene los datos actuales de la base de datos así como el diccionario de

datos.

Archivos rehacer (Redo Logs). Almacenan datos recuperables en caso de error grave.

Archivos de control. Necesarios para mantener la integridad de la base de datos.

Archivos de parámetros. Que definen algunas características de una instancia Oracle.

Archivos de contraseñas. Que sirven para autentificar a los usuarios.

Copias de archivos rehacer. Utilizadas para la recuperación de datos.

Instancia de la base de datos Oracle

La instancia de la base de datos es uno de los dos elementos de cualquier base de datos Oracle. Sirve

para gestionar la información de la base de datos y proporcionar servicio a los usuarios que acceden a la

misma [6].

Está compuesta de:

Estructuras en memoria.

Procesos en segundo plano

Estructuras en memoria

SGA

Es la abreviatura de System Global Area, Área Global de Sistema. Está situada al inicio de los datos de la

instancia y contiene los datos e información de control de la instancia [6].

Está formada por las siguientes estructuras Ver Anexo 5.4 :

25

Shared pool, fondo común compartido. Almacena las últimas instrucciones SQL y PL/SQL

ejecutadas. Posee dos estructuras internas:

o Caché de instrucciones (Library cache). Almacena las últimas instrucciones SQL y

PL/SQL ejecutadas. Administra los datos mediante algoritmo LRU.

o Caché del diccionario de datos. Almacena las últimas definiciones de la base de datos

utilizadas (tablas, índices, privilegios, usuarios,..etc.). Cada vez que una instrucción

utiliza un nombre de la base de datos (tabla, índice,...) se comprueba en el diccionario de

datos y se almacena en este caché. De este modo la siguiente vez no hace falta acceder al

diccionario de datos real.

Caché buffer de la base de datos. Almacena los últimos bloques de datos accedidos por los

usuarios.

Buffer de archivo rehacer. Almacena los últimos cambios realizados a los bloques de datos de la

base de datos.

Large pool. Opcional. Se utiliza como memoria de sesión y para realizar operaciones de backup.

Java pool. Opcional. Se utiliza como caché de los comandos Java [6].

PGA

Zona global de los programas (Program Global Area). En ella se almacenan los datos correspondientes a

un proceso (sólo un proceso puede utilizar esta área). Incluye [6]:

Áreas de ordenamiento. Para acelerar las tareas de ordenamiento de datos.

Información de sesión. Usuario, privilegios, etc.

Estado del cursor. Tareas SQL actualmente en ejecución.

Espacio de pila. Variables y otros datos.

En Oracle los procesos pueden ser de estos tipos [6]:

Proceso de usuario. Lanzado por el usuario para pedir interacción con la base de datos.

26

Proceso de servidor. Hacen de enlace entre los procesos de usuarios y el servidor Oracle. Se

utilizan como manejadores de los procesos de usuario. Los comandos de usuario se envían a

estos procesos que se encargan de solicitar peticiones a la base de datos mediante el interfaz

de programas de Oracle (OPI, Oracle Program Interface).

Procesos en segundo plano (background). Cada instancia de Oracle arranca una serie de

procesos background. Los procesos obligatorios son [6]:

DBWR (DataBaseWRiter). Proceso encargado de escribir en los ficheros de datos los

buffers más antiguos de la memoria, para que la base de datos vaya almacenando los

cambios.

LGWR (LoGWRiter). Escribe los datos a los ficheros rehacer (redo) desde la caché de

archivos rehacer.

CKPT. Actualiza todas las cabeceras de los ficheros de datos para que aparezca la nueva

disposición de datos. Esto ocurre cuando se genera un punto de comprobación.

SMON (System MONitor). Permite recuperar la instancia de la base de datos en caso de

caída fatal (cuando el sistema falla por ejemplo). Cuando se reinicia de nuevo la

instancia de la base de datos.

PMON (ProcessMONitor). Es el encargado de gestionar adecuadamente los procesos

que fallan. Ante caídas de procesos, PMON se encarga de restaurar los datos

adecuadamente.

SQL *Net Listener. Es el encargado de encaminar por una red solicitudes de un cliente a

un servidor de base de datos Oracle. Este procesoestá tanto en el cliente como en el

servidor. Puede encaminar solicitudes que se dirigen a varias instancias.”

Oracle provee funcionalidades para casi todos los gustos y necesidades, pero por cada necesidad que

satisface también genera una nueva oportunidad para el atacante. “El código detrás del RDBMS ha sido

sujeto de varias sobrecargas y otros problemas de seguridad, como PL/SQL Injection en paquetes y

procedimientos por defecto, que han requerido parches de actualización en el pasado” [5] [7].

Asumiendo que no vamos a ser atacados podríamos dedicarnos a disfrutar de las grandes funcionalidades

que provee Oracle, pero seamos realistas, hoy en día casi que podemos tener la certeza de que teniendo

27

nuestra base de datos en un entorno web, es decir, más cerca del atacante, muy seguramente esta va a ser

atacada, y por eso para poder defenderla comenzamos por entender la arquitectura web que maneja

Oracle. “La pregunta hoy en día no es ¿Voy a ser atacado?, sino ¿Cuándo y cómo voy a ser atacado?”

[5].

Para entender el funcionamiento de una base de datos Oracle se hace importante estudiar: la disposición

física de la base de datos, los procesos y la manera en que estos interactúan con la red, la autenticación y

autorización, y finalmente la disposición lógica [5].

Procesos Oracle y Oracle en la Red

El elemento más crucial de interacción con la red posiblemente sea el TNS Listener.

El TNS Listener Oracle

El TNS listener es el centro de actividad de todas las comunicaciones en Oracle, sus siglas hacen

referencia a “Transparent Network Substrate” que es el protocolo usado para la comunicación entre

cliente y servidor. Cuando un servidor de base de datos arranca por primera vez, este se registra con el

TNS Listener usando el comando service_register_NSGR, esto le permite al TNS Listener saber que la

base de datos está preparada para recibir conexiones [5] [7].

Después de hacer una revisión sobre los conceptos básicos del DBMS Oracle podemos pasar a revisar en

qué consisten las técnicas anti forenses, cómo se clasifican, cuáles son las principales técnicas usadas por

los atacantes para cubrir sus crímenes y posteriormente relacionar los conceptos tratados en este capítulo

con dichas técnicas para poder definir las principales fuentes de evidencia en Oracle, es decir, en dónde

debe buscar un investigador forense los rastros de ataques a la base de datos, en qué debe fijarse, cómo

debe buscar y qué herramientas se sugiere usar.

2.3 TECNICAS ANTI-FORENSES

“Nadie puede diseñar un sistema, que alguien más no pueda comprometer o vulnerar”. [4]

Las técnicas anti forenses han existido desde el mismo momento en que nacieron las técnicas de

investigación y los procesos puntuales de recolección de evidencias. Estas surgieron como la necesidad de

evitar que las pruebas de un crimen sean factores determinantes a la hora de demostrar el grado de

implicación de un sospechoso dentro de un crimen. Por esta razón los criminales alteran, borran, evitan y

falsifican las evidencias para que de esta manera los resultados de las investigaciones no arrojen a los

28

criminales como culpables y queden sus fechorías impunes, ya que las pruebas no fueron lo

suficientemente contundentes como para demostrar su culpabilidad.

Por esta razón es necesario estudiar de manera exhaustiva cuántas y cuáles son las posibles técnicas que

los criminales puedan llegar a usar para alterar el curso de una investigación. En esta sección hablaremos

de las diferentes clasificaciones de las técnicas anti-forenses y el porqué es necesario tenerlas en cuenta a

la hora de realizar una investigación.

2.3.1 Definición

Existen gran cantidad de aproximaciones hacia la definición de técnica anti forense, pero solamente hasta

la publicación de Arriving at an anti-forensicsconsensus: Examining how to define and control the anti-

forensics problem de Ryan Harris se llegó a una estandarización de los principios básicos que se deben

tener en cuenta, para los expertos en seguridad y específicamente en las investigaciones forenses. [3]

Según Ryan Harris “las técnicas anti forenses comprenden cualquier intento por comprometer la

disponibilidad o usabilidad de la evidencia para el proceso forense”. De modo que una técnica anti-

forense es todo aquello que pueda comprometer la disponibilidad de la evidencia incluyendo evitar que la

evidencia se genere, esconder a la evidencia existente o manipular la evidencia para que no esté al alcance

del investigador. La usabilidad se puede comprometer por obstrucción de la evidencia en si misma o

destruyendo su integridad. Entendiendo evidencia como "cualquier información que, sujeta a una

intervención humana u otra semejante, ha sido extraída de un medio informático". [3] [4]

Existen tres tipos de evidencia digital

Aquellos registros que se encuentren almacenados en el equipo de tecnología informática como lo

son los correos electrónicos archivos de aplicaciones ofimáticas e imágenes.

Registros generados por los equipos de tecnología informática (registros de auditoría, registros de

transacciones, registros de eventos, etc.).

Registros que parcialmente han sido generados y almacenados en los equipos de tecnología

informática. (hojas de cálculo financieras, consultas especializadas en bases de datos, vistas parciales

de datos, etc.). [4]

29

Según Harris existen cuatro clases fundamentales de técnicas anti-forenses, las cuales son:

Destrucción de evidencia

Ocultación de evidencia

Eliminación de fuentes de evidencia

Falsificación de evidencia [3]

2.3.2 Objetivos

Los objetivos de las técnicas anti forenses- según GARFINKEL:

Limitar la detección de un evento que haya ocurrido.

Distorsionar la información residente en el sitio.

Incrementar el tiempo requerido para la investigación del caso.

Generar dudas en el informe forense o en el testimonio que se presente.

Engañar y limitar la operación de las herramientas forenses informáticas.

Diseñar y ejecutar un ataque contra el investigador forense que realiza la pericia.

Eliminar los rastros que pudiesen haber quedado luego de los hechos investigados. [8]

2.3.3 Destrucción de evidencia

La evidencia puede ser destruida para prevenir que sea encontrada o para reducir su usabilidad en caso de

que sea encontrada. Como las acciones de destrucción trabajan sobre evidencia existente, el proceso de

destrucción en sí puede generar nueva evidencia. Por ejemplo, sobrescribir un archivo obstruye la

evidencia en el archivo pero la aplicación que se usa para sobrescribirlo puede crear nueva evidencia. La

destrucción dentro de las bases de datos puede manejarse de diferentes maneras, entre ellas se encuentra el

borrado de los Logs que genera el sistema, que permiten realizar la auditoria de los eventos del sistema

como qué acciones se realizaron, quiénes las realizaron y en qué intervalo de tiempo las realizaron. [3]

2.3.4 Ocultación de evidencia

La evidencia no es destruida o manipulada, sin embargo, es escondida de la vista casual para reducir su

disponibilidad para el investigador. Muchas veces encontrar la evidencia escondida no es necesario sino

que el hecho de hallar herramientas de ocultación puede ser evidencia en sí mismo. Al esconder evidencia

los archivos pueden ser colocados en lugares poco comunes para explotar las limitaciones de las

30

herramientas de software forense o renombrado para tomar ventaja de los puntos ciegos inherentes del

investigador. [3]

2.3.5 Eliminación de fuentes de evidencia

La eliminación de las fuentes es todo acto que impida que una evidencia pueda ser generada. Por ejemplo,

en bases de datos la eliminación de los Logs, posibles fuentes de evidencia, pueden ser destruidos para

asegurarse de que la evidencia nunca sea generada. La ausencia total de evidencia puede ser indicio de un

crimen bien planeado. Es claro que en el momento en que se elimina una fuente, las pruebas que esta

posiblemente albergaría ya no se generarán, pero este evento también puede considerarse como evidencia

del uso de técnicas anti-forenses [3].

2.3.6 Falsificación de evidencia

La evidencia puede falsificarse para redirigir la culpabilidad, para explotar debilidades del proceso y de

las herramientas o bien para corromper la validez de la evidencia de manera que no sea útil para el

investigador. Falsificar evidencia puede ser crear evidencia que parece ser algo que no es, esto puede ser

crear evidencia que funciona como ataque a las herramientas o al proceso forense en sí. Algunas de las

categorías anteriores pueden necesitarse para conseguir el objetivo final de esta. Un ejemplo de esto puede

ser usar las cuentas de otras personas para realizar ataques y así desviar la culpa del real perpetrador.

[3]Ver Anexo 5.

31

2.4 ATAQUES EN ORACLE

En lo que a ataques a bases de datos Oracle respecta, podemos encontrar varias categorías, pero sin duda

la mayoría van a estar relacionadas directa o indirectamente con SQL Injection y especialmente con

modificaciones y combinaciones de este tipo de ataque. Comenzaremos entonces por estudiarlo desde lo

particular y simple para luego abordar las combinaciones y categorías de ataques más complejos.

2.4.1 SQL INJECTION

El “SQL Injection” es un ataque simple y conocido, pero no por eso deja de representar una amenaza para

cualquier base de datos, trátese de Oracle, MySQL o cualquier otra. De hecho, contrario a lo que se

pensaría al hablar de un ataque del cual se tiene tanta información en la actualidad, tras varias encuestas y

estudios realizados en el año 2010 por OWASP (Open Web Application Security Project) se determinó

que entre las mayores brechas de seguridad que terminan comprometiendo datos, los ataques de este tipo

predominan con un 60% del total si contamos los casos en que este ataque es combinado con malware [9].

Ver Anexo 6

“Muchos desarrolladores de aplicaciones subestiman el riesgo de ataques SQL Injection a aplicaciones

web que usen Oracle como base de datos de respaldo final” [10], aunque Oracle represente una alternativa

muy confiable, ningún desarrollador o analista de seguridad debe bajar sus defensas frente a los ataques de

SQL Injection. Debemos percatarnos de que por su amplia divulgación y su alto porcentaje de efectividad,

la sofisticación de estos ataques se encuentra en aumento y así mismo deberían aumentar los esfuerzos por

detectar vulnerabilidades, corregir fallas y proteger las aplicaciones e interfaces con el fin de garantizar la

seguridad e integridad de la información [9]. Entre el 2007 y el 2010 los ataques de inyección, entre los

cuales encontramos el SQL Injection como el principal representante, pasaron del segundo lugar al

primero en el Top 10 presentado por OWASP anualmente en el cual se clasifican los principales ataques y

vulnerabilidades en aplicaciones web. En el segundo lugar actualmente se encuentra el Cross Site

Scripting (XSS), que como veremos más adelante también representa una amenaza para Oracle [11] [12].

OWASP califica los ataques de inyección de fácil uso, frecuencia común, detectabilidad promedio e

impacto severo; pueden ser realizados por cualquier persona que pueda enviar datos no confiables al

sistema, incluyendo usuarios externos, usuarios internos, y administradores del sistema. Entre las

principales consecuencias podemos encontrar perdida de información, falta de responsabilidad,

32

denegación de servicios y en algunos casos pueden llevar a la toma de posesión total del servidor por parte

del atacante [11].

Los ataques de SQL Injection se aprovechan principalmente, de las malas prácticas de desarrollo de

aplicaciones, explotando la falta de un manejo adecuado de la entrada de datos por parte del usuario que

posteriormente serán usados en sentencias SQL [10]. Los atacantes engañan al motor de la base de datos

para que este ejecute comandos no deseados, suministrando cadenas de texto hechas especialmente para

este fin, consiguiendo así acceso no autorizado a la base de datos para visualizar o manipular información

restringida [12].

La mayoría de estos ataques se presentan en interfaces web, por el hecho de que en una aplicación web el

atacante puede realizar ataques de SQL Injection sin ninguna autenticación en la base de datos o la

aplicación. Dicho esto, es claro que estas representan una vulnerabilidad para las organizaciones y por

ende debe realizarse un análisis cuidadoso del beneficio de proveer acceso web frente al costo de la

posible pérdida de información [10] [12].

Las técnicas de SQL Injection pueden variar, pero todas explotan una misma vulnerabilidad: “Cadenas de

texto validadas o no validadas que son concatenadas en una sentencia SQL dinámica, e interpretadas como

código por el motor SQL” [12].

Oracle se ha manejado bien frente a los ataques de SQL Injection por varias características entre las cuales

es de destacar el uso de bind arguments(variables de enlace)que si bien fueron diseñadas principalmente

para mejorar el desempeño, proveen también una fuerte protección contra dichos ataques cuando se

programa SQL dinámico pues obligan a la base de datos a utilizar exclusivamente el valor de la variable y

no interpretar su contenido de ningún modo [12] [10] [13]. Aunque Oracle puede proveer mayor

protección frente a estas técnicas, que otras bases de datos, aplicaciones sin las defensas apropiadas

pueden ser vulnerables [10].

Para inmunizar cualquier código contra ataques SQL Injection, deben usarse bind arguments, bien sea

automáticamente en SQL estático o explícitamente en SQL dinámico, y adicionalmente validar y

desinfectar cada entrada concatenada a SQL dinámico. La validación comprueba que la entrada cumpla

ciertos criterios (Ej. que no contenga comillas simples independientes) y la desinfección modifica la

entrada para asegurar que es válida (Ej. doblar las comillas simples) [12]. Oracle provee un paquete

PL/SQL llamado DBMS_ASSERT, el cual contiene funciones que permiten validar y desinfectar cadenas

de entrada [12].

33

En el Anexo 26 se presenta un diagrama de flujo que expone los pasos para medir la vulnerabilidad de

cualquier código SQL.

Para detalles más específicos sobre cómo protegerse frente a técnicas de SQL Injection al programar en

PL/SQL, se recomienda revisar el tutorial provisto por Oracle titulado “SQL Injection Tutorial” el cual es

gratuito, descargable y contiene lecciones por capítulos con evaluaciones interactivas al final de capa

sección [12].

2.4.2 TIPOS DE ATAQUES SQL INJECTION

Tras revisar varias categorizaciones de los ataques de inyección se decidió unir las dos que consideramos

más relevantes y acertadas, relacionándolas entre sí como se expondrá a continuación. Los ataques de

inyección son comúnmente divididos en:

2.4.2.1 ATAQUES DE PRIMER ORDEN

El atacante simplemente ingresa una cadena de texto maliciosa y provoca que el código modificado sea

ejecutado inmediatamente. El ejemplo más común consiste en modificar la cláusula WHERE de una

consulta de autenticación para que siempre retorne verdadero [12].

2.4.2.2 ATAQUES DE SEGUNDO ORDEN

El atacante inyecta en datos almacenados permanentemente que son considerados una fuente confiable

(Ej. una fila de una tabla) y posteriormente otra actividad ejecuta el ataque indirectamente [12]. Este tipo

de ataques requieren un mayor conocimiento de la aplicación objetivo y aprovechan la naturaleza stateless

de muchas aplicaciones web que acostumbran pasar información entre páginas almacenando valores en la

base de datos, generando así una vulnerabilidad [10].

2.4.2.3 INYECCIÓN LATERAL

El atacante puede explotar procedimientos PL/SQL que ni siquiera reciben entrada de usuario. Contrario a

lo que se puede pensar, cuando una variable cuyo tipo es de fecha o numérico, y está concatenada en el

texto de una sentencia SQL, puede existir una vulnerabilidad [12].

Adicionalmente podemos dividir los ataques de SQL Injection a Oracle en las siguientes categorías [10]:

1. SQL Manipulation

2. CodeInjection

3. FunctionCallInjection

34

4. Buffer Overflows

Las dos primeras categorías pueden incluirse dentro de los ataques de primer orden mencionados

anteriormente, son las más comunes, y se aplican a todos los tipos de bases de datos. Aunque la segunda

sea menos común en Oracle que en otras bases de datos, por el hecho de no soportar peticiones de

múltiples sentencias SQL por base de datos, se pueden presentar casos de Code Injection en Oracle

cuando se trabaja con SQL dinámico en PL/SQL [10] [12] [13].

Las últimas dos categorías contienen ataques más específicos a Oracle, son menos comunes que las

primeras, y por ende se encuentra menos documentación disponible sobre estas, lo cual incrementa su

aparición como vulnerabilidades en la mayoría de auditorías de seguridad realizadas a aplicaciones web

[10]. A continuación se expone con mayor detalle cada uno de los tipos de Inyección en Oracle, pero se

hará énfasis en los últimos dos tipos por las razones mencionadas anteriormente.

2.4.3 SQL MANIPULATION

SQL Manipulation representa el tipo más común de ataque de SQL Injection. El atacante intenta modificar

la sentencia SQL adicionando elementos a la cláusula WHERE o extendiendo la consulta con operadores

como UNION, INTERSECT o MINUS [10]. El ejemplo clásico de este ataque se presenta en la

autenticación de usuarios de una aplicación donde se ejecuta una consulta como la siguiente:

SELECT * FROM usuarios

WHERE nombreusuario= „miusuario‟ and contraseña = „micontraseña‟

El atacante podría manipular la sentencia SQL con una consulta como esta:

SELECT * FROM usuarios

WHERE nombreusuario= „miusuario‟ and contraseña = „micontraseña‟ or „1‟ = „1‟

Si no se tienen las medidas adecuadas de verificación en la aplicación, la consulta anterior retornaría

verdadero para todas las filas basándose en la precedencia de operadores [10].

También suele ser común el uso del operador UNION para retornar filas de otra tabla. Por ejemplo se

puede intentar listar todos los productos disponibles de una tienda y usando este operador hacer que se

listen también todos los usuarios de la base de datos [10].

35

2.4.4 CODE INJECTION

Este ataque consiste en inyectar comandos o sentencias dentro de una sentencia SQL. Este tipo de ataque

no es tan común en Oracle como en otras bases de datos debido a que Oracle no proporciona ninguna

sentencia correspondiente a la sentencia EXECUTE (SQL Server), ni permite la solicitud de ejecución de

varias sentencias por base de datos [10].

Sin embargo algunas API‟s permiten ejecutar dinámicamente bloques anónimos de PL/SQL los cuales son

vulnerables ante un ataque de Code Injection.

Por ejemplo, un atacante puede manipular el bloque PL/SQL, que ejecuta un proceso almacenado de la

base de datos que cifra y almacena una contraseña de usuario [10]:

BEGIN ENCRYPT PASSWORD ('Javeriana', 'micontraseña'); END;

Y convertirlo en el siguiente [10]:

BEGIN ENCRYPT PASSWORD ('Javeriana', 'micontraseña'); DELETE FROM users WHERE upper

(username) = upper ('admin'); END;

2.4.5 FUNCTION CALL INJECTION

Los ataques de FunctionCallInjection insertan funciones Oracle o funciones tradicionales dentro de

sentencias SQL vulnerables con el fin de invocar llamadas de sistema operativo o manipular información

almacenada en la base de datos [10].

Oracle permite ejecutar funciones como parte de sentencias SQL y adicionalmente provee más de 1000

funciones contenidas en aproximadamente 175 paquetes, de las cuales sólo algunas pocas son útiles para

ataques de SQL Injection. Cualquier función tradicional o que esté almacenada en un paquete tradicional

puede ser invocada desde una sentencia SQL [10].

Principalmente, sólo las funciones ejecutadas dentro de sentencias INSERT, UPDATE o DELETE pueden

modificar información almacenada en la base de datos. Usando las funciones estándar de Oracle, un

atacante puede enviar información a otras máquinas o ejecutar nuevos ataques desde el servidor de la base

de datos. Muchas aplicaciones basadas en Oracle incluyen paquetes que pueden ser explotados por un

atacante. Estos pueden contener funciones que cambien contraseñas o realicen actividades sensibles de

transacciones [10].

36

El principal asunto a tener en cuenta cuando tratamos Function Call Injection, es que cualquier sentencia

SQL generada dinámicamente es vulnerable, incluso las sentencias más sencillas. A continuación se

mostrara un ejemplo que corrobora lo recientemente afirmado [10]:

SELECT TRANSLATE(„entradaDeUsuario‟,

„0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ‟,

„0123456789‟)

FROM dual;

Esta sentencia que hace uso de la función TRANSLATE de la base de datos, no es vulnerable a otros tipos

de inyección pero puede ser manipulada de la siguiente manera para realizar un ataque de Function Call

Injection [10]:

SELECT TRANSLATE ('' || UTL_HTTP.REQUEST('http://192.168.1.1/') || '',

'0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ',

'0123456789')

FROM dual;

La anterior sentencia hace un REQUEST a una página de un servidor web. El atacante podría manipular

dicha sentencia para recopilar información de la base de datos y enviarla a al servidor web especificado en

la URL, o bien, si la base de datos está tras un firewall, podría atacar otros servidores en la red interna

[10].

Las funciones tradicionales también pueden ser ejecutadas en este tipo de ataques, particularmente las que

se encuentran marcadas como “PRAGMA TRANSACTION”, pues pueden ser ejecutadas bajo cualquier

circunstancia especial, y por estar marcadas de esta manera pueden escribir en la base de datos incluso

dentro de una sentencia SELECT [10].

Un claro ejemplo del uso de este ataque fue presentado el presente año por David Litchfield en la

conferencia de seguridad “BlackHat DC 2010”, en su ataque, Litchfield combina Lateral Injection,

Function Call Injection y PL/SQL Injection para aprovechar la implementación implícita de Java en

Oracle, que ha sido denominada Aurora, y así tomar control total de la base de datos [14] [15].

El ataque comienza obteniendo privilegios arbitrarios de Java desde una sesión con pocos privilegios,

haciendo uso del paquete DBMS_JVM_EXP_PERMS, el cual usualmente permite importar o exportar las

políticas de java entre distintos servidores de la base de datos. Este paquete, puede ser ejecutado por el rol

37

PUBLIC, es decir, por cualquier usuario común e incluye un procedimiento llamado

IMPORT_JVM_PERMS que recibe como argumento una Java Policy. Un atacante puede crear su propia

Policy y enviarla como argumento a esta función, y al hacer esto, como el procedimiento se ejecuta con

privilegios de SYS, la Policy creada por el atacante es adicionada a la tabla JAVA$POLICY$,

permitiéndole al atacante concederse a sí mismo permisos Java arbitrarios como por ejemplo el permiso

Java execute para todos los archivos [14] [15].

2.4.6 BUFFER OVERFLOWS

Varias funciones estándar de Oracle son susceptibles a Buffer Overflows que pueden ser aprovechados

mediante el uso de SQL Injection sobre bases de datos que no tengan las actualizaciones y parches de

seguridad adecuados. Algunos de los paquetes y funciones estándar de la base de datos que son

vulnerables sonTZ_OFFSET, TO_TIMESTAMP_TZ, AND BFILENAME, FROM_TZ,

NUMTOYMINTERVAL, y NUMTODSINTERVAL [10].

Un ataque de Buffer Overflow es ejecutado usando los métodos de Function Injection descritos

anteriormente para llamar las funciones vulnerables mencionadas en el párrafo anterior. Haciendo uso de

Buffer Overflowsse puede llegar a obtener acceso remoto al sistema operativo. Adicionalmente, algunas

aplicaciones y servidores web no manejan adecuadamente la pérdida de conexión de la base de datos

debida a desbordamientos, haciendo de este tipo de ataques un potencial ataque de DoS3 que será efectivo

por ejemplo si un proceso web se queda colgado esperando a que la conexión con un cliente termine [10].

Tras categorizar los principales tipos de ataques a bases de datos Oracle y con la ayuda de las secciones

anteriores, pasaremos a revisar las técnicas forenses que pueden ser usadas cuando se investiga un entorno

Oracle en busca de rastros de los ataques expuestos anteriormente.

2.5 TÉCNICAS FORENSES EN BASES DE DATOS ORACLE

Entender los conceptos básicos de Oracle y los principales tipos de ataques expuestos en secciones

anteriores nos permite comprender con mayor facilidad dónde están situadas las principales fuentes de

evidencia en Oracle y de qué manera se manifiestan los diversos tipos de ataques en las diversas

estructuras de la base de datos. Para hacer más claros, específicos y repetibles los análisis expuestos a

continuación, se hace esencial definir un entorno y posteriormente aventurarse a explorar con

detenimiento las estructuras de la base de datos.

3DoS: Denegación de servicio (Denial Of Service)

38

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

39

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

40

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.

4DDL: Lenguaje de definición de datos (Data DefinitionLanguage)

5SCN: Numero de cambio del sistema (SystemChangeNumber)

41

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

42

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

43

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

7Lenguaje de manipulación de datos (Data ManipulationLanguage)

44

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.

45

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]

46

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]

47

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

48

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

49

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]

50

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]

51

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,

52

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

53

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

54

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.

55

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

56

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.

57

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

58

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.

59

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

60

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

61

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

62

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

63

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]

64

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

65

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

66

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

67

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

68

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

69

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

70

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

71

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

72

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

73

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]

74

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

75

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 CBO

10 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

9AutomaticWorkloadRepository

10CostBasedOptimizer

11System Monitor

76

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

77

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

78

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

79

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;

80

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.

81

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

82

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;

83

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]');

84

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.

85

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.

86

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.

87

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

88

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

89

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)

90

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)

91

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

92

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.

93

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

94

5 ANEXOS

5.1 ANEXO 1

Ilustración 10: Sofisticación Vs. Conocimiento del atacante [41].

95

5.2 ANEXO 2

Ilustración 11: Intrusiones de seguridad en 2010 [1]

96

5.3 ANEXO 3

Ilustración 12: Actualizaciones de seguridad [1]

97

5.4 ANEXO 4

Ilustración 13: Estructura de la base de datos Oracle [6]

98

5.5 ANEXO 5

Ilustración 14: Técnicas Anti-forenses [3]

99

5.6 ANEXO 6

Ilustración 15: Vulnerabilidad usada para comprometer el sistema [9]

100

5.7 ANEXO 7

Ilustración 16: Configuración de los Redo Logs en la creación de la base de datos

101

5.8 ANEXO 8

4 Bytes

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

XOR

4 Bytes

XOR

4 Bytes (DWORD)

A (16 Bits) B (16 Bits)

Si A == -B -> La suma de verificación es correcta

102

5.9 ANEXO 9

Ilustración 17: Bloque de datos Oracle [19]

103

5.10 ANEXO 10

Ilustración 18: Consulta de verificación del estado de las funciones de auditoria [21]

104

5.11 ANEXO 11

Tabla 1: Tipos de datos de la tabla OBJ$ [19]

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

105

Ilustración 19: Volcado de información a partir de los tipos de dato de la tabla OBJ$ [19]

106

5.12 ANEXO 12

Ilustración 20: Entradas en el listener log generadas al ejecutar sidguess.exe [25]

107

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]

108

5.14 ANEXO 14

Ilustración 23: Localización traza

Ilustración 24: Traza sin formato

109

5.15 ANEXO 15

Ilustración 25: Sentencias de volcado

Ilustración 26: Volcado NOSYS

110

5.16 ANEXO 16

Ilustración 27:Comando Time

Ilustración 28: Comando Date

111

5.17 ANEXO 17

Ilustración 29: Comando net user

Ilustración 30: Detalles de usuario

112

5.18 ANEXO 18

Ilustración 31: Lista de conexiones y puertos

113

5.19 ANEXO 19

Ilustración 32: Ubicación Home

Ilustración 33: Ubicación Archivo de Inicio

114

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.

115

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

116

5.22 ANEXO 22

Ilustración 37: Agregando archivos de investigación

117

5.23 ANEXO 23

Ilustración 38: Tipos de datos LogMiner

118

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

119

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:

120

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]

121

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]

122

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.

123

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=WIN-

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

124

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

125

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

126

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

127

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

128

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

129

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

130

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$

131

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

132

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$

133

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

134

5.26 ANEXO 26

Ilustración 66 : Diagrama de flujo para detectar vulnerabilidades de SQL Injection – Adaptado de [12]

135

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]

136

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$

137

5.29 ANEXO 29

Ilustración 69: Volcado Hexadecimal de los bloques asignados a la tabla IDL_UB1$ [19]

138

5.30 ANEXO 30

Ilustración 70: Diferencia entre autenticación de la cuenta SYS con y sin "AS SYSDBA" [25]

139

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;

/

140

5.32 ANEXO 32

Ilustración 72: SPFile Texto

141

5.33 ANEXO 33

Ilustración 73: Ruta Listener logs [26]

142

5.34 ANEXO 34

Ilustración 74: Versión

143

5.35 ANEXO 35

Ilustración 75: Descripción de la columna COL_USAGE$ [34]

144

5.36 ANEXO 36

Ilustración 76: Filt1.xml

Ilustración 77: Filt-bool.xml

145

Ilustración 78: Filt-grant.xml

Ilustración 79:Filt-xid.xml

Ilustración 80: Parámetros de la herramienta Orablock

146

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]

147

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]

148

Ilustración 86: Consulta para extraer la fecha en que se bloquea una cuenta

149

5.38 ANEXO 38

Ilustración 87: Entradas en el listener log generadas al ejecutar sidgusser.exe [25]

150

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 #

151

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

152

5.41 ANEXO 41

Ilustración 91: Encabezado de un bloque en un archivo Oracle Redo Log

153

5.42 ANEXO 42

Ilustración 92: Estructura del encabezado de un Red Log – Adaptado de [16]

154

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]

155

Ilustración 95: Volcado hexadecimal de una fila [19]

Ilustración 96: Discriminación de columnas a partir de un volcado hexadecimal [19]

156

5.44 ANEXO 44

Ilustración 97: Volcado Hexadecimal de un bloque asignado a la tabla MY_TEMP_TABLE [19]

157

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]

158

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]

159

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;

/

160

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

http://netcat.sourceforge.net/ 13

http://sourceforge.net/projects/cryptcat/

161

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

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

162

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.

163

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.

164

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

165

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.

166

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/security-

resources/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

http://www.csoonline.com/article/221208/The_Rise_of_Anti_Forensics

http://www.dfrws.org/2006/proceedings/6-Harris.pdf

http://www.jorgesanchez.net/bd/arquOracle.pdf

http://www.alfa-redi.org/rdi-articulo.shtml?x=9608

167

[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_oracle-

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

base.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/security-

resources/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].


[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-oracle-

trace-utulity-and-understanding-the-fundamental-performance-equation/

[30] adp-gmbh. (2003) Output format of a 10046 trace file. [Online]. http://www.adp-

http://www.wikilearning.com/curso_gratis/iniciacion_a_oracle-conceptos_de_almacenamiento_en_oracle/3861-6

http://www.wikilearning.com/curso_gratis/iniciacion_a_oracle-conceptos_de_almacenamiento_en_oracle/3861-6


http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_flashback.htm

http://www.oracle-base.com/articles/10g/Auditing_10gR2.php

http://www.oracle-base.com/articles/10g/Auditing_10gR2.php

http://www.symantec.com/connect/es/articles/introduction-simple-oracle-auditing

http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Listener_TNS_Security.pdf

http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Listener_TNS_Security.pdf

http://download.oracle.com/docs/cd/E11882_01/network.112/e10836.pdf



http://www.orasite.com/tutoriales/conceptos-basicos-tunning-oracle.html

http://www.petefinnigan.com/ramblings/how_to_set_trace.htm

http://tonguc.wordpress.com/2006/12/30/introduction-to-oracle-trace-utulity-and-understanding-the-fundamental-performance-equation/

http://tonguc.wordpress.com/2006/12/30/introduction-to-oracle-trace-utulity-and-understanding-the-fundamental-performance-equation/

http://www.adp-gmbh.ch/ora/misc/trace_file_format.html

168

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://computer-

forensics.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/oracle-

forensics-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-one-

database-069037.html

[44] Microsoft Corporation. (2003, Marzo) How RPC Works. [Online]. http://technet.microsoft.com/en-

us/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].

http://www.adp-gmbh.ch/ora/misc/trace_file_format.html

http://www.plsql.biz/2007/06/uso-del-comando-tkprof-para-formatear.html

http://www.oracle.com/technetwork/articles/sql/11g-transactionmanagement-092065.html


http://www.petefinnigan.com/Oracle_Forensics_scotland.pdf

http://computer-forensics.sans.org/community/papers/oracle-database-forensics-logminer_159

http://computer-forensics.sans.org/community/papers/oracle-database-forensics-logminer_159

http://www.databasesecurity.com/dbsec/oracle-forensics-scns.pdf

http://www.databasesecurity.com/dbsec/oracle-forensics-scns.pdf

http://www.databasesecurity.com/oracle-forensics.htm

http://www.databasesecurity.com/dbsec/cursor-injection.pdf

http://www.v3rity.com/products.php

http://www.oracle.com/us/products/database/number-one-database-069037.html

http://www.oracle.com/us/products/database/number-one-database-069037.html

http://technet.microsoft.com/en-us/library/cc738291(WS.10).aspx

http://technet.microsoft.com/en-us/library/cc738291(WS.10).aspx

http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/logical.htm

169

http://download.oracle.com/docs/cd/B14117_01/network.101/b10775/troublestng.htm#i452616

http://download.oracle.com/docs/cd/B14117_01/network.101/b10775/troublestng.htm#i452616

ESTADO DEL ARTE DE LA APLICACIÓN DE TÉCNICAS …

Documents

Transcript of ESTADO DEL ARTE DE LA APLICACIÓN DE TÉCNICAS …