Anti-Forensics: Teoría de Evasión Forense
Con el desarrollo progresivo de los métodos de investigación forense, en los foros públicos, BBS's empezaron a aparecer posts referentes a las técnicas que los intrusos pueden utilizar para evitar que un forense cualificado pueda llevar acabo su trabajo con éxito. El trabajo del investigador forense depende de las pruebas encontradas en el sistema de ficheros de la máquina comprometida en todo caso, en el supuesto de que no exista ninguna prueba la eficacía de la investigación se reduce a nada.
El objetivo detrás de cualquier investigación realizada por un forense o un equipo de respuesta rápida sobre un sistema de ficheros puede ser de tipo 'legal' o 'casual'. Teniendo en consideración que estos términos no tienen un significado estandarizado para describir los motivos de una investigación y cada uno de ellos se diferencia bastante del otro debemos detallar más.
Investigación Legal: La mayoría de las investigaciones forenses de tipo legal tienen como objetivo asistir a los órganos oficiales a llevar acabo una investigación criminal a fin de llevar ante la justicia al culpable del delito. En investigaciones de este tipo es imprescindible seguir de forma estricta los procedimientos para el tratamiento de pruebas que van a ser presentadas en el juzgado. Por ejemplo, el mero error de sobreescribir cualquier prueba en el sistema de ficheros por información aleatoria (pérdida de datos) es suficiente para considerar el resto de las pruebas de la misma índole como inviables por parte de un juez o fiscal. Investigaciones legales, a menudo, únicamente se limitan a la conservación de datos y esfuerzos de mantener la integridad de información en el sistema de ficheros una vez el hecho del compromiso ha sido probado. Las pruebas tras ser tratadas de forma correcta se transfieren al poder de órganos oficiales para ser analizados por parte de sus recursos. El nivel de participación del forense en la investigación una vez las pruebas han sido transferidas depende del deseo del denunciante y la voluntad de órganos oficiales.
Investigación Casual: Cualquier tipo de investigación casual no tiene como objetivo la persecución legal del individuo responsable del acto criminal. La investigación se realiza por el interés desde el punto de vista forense, por lo tanto las técnicas, herramientas y metodología utilizada puede ser usada de forma más agresiva. La realización de una investigación forense casual requiere más conocimiento y experiencia por parte del investigador, ya que en estos casos no existen requerimientos estrictos de terceros referentes a la cantidad y calidad de pruebas obtenidas.
Indiferentemente del tipo de investigación los pasos iniciales deben ser básicamente los mismos en cada caso:
- El sistema de ficheros debe ser salvada
- La información que contiene el sistema de ficheros debe ser recogida
- Esa información debe ser tratada y almacenada como prueba
- Las pruebas deben ser examinadas
El concepto de prueba se forma por el contenido de los ficheros (datos) y la información sobre los ficheros (meta-datos). Basándose en las pruebas obtenidas del sistema de ficheros el investigador debe intentar a:
- Quien - Reunir la información sobre el/los individuo/s involucrados en el compromiso
- Que - Determinar la naturaleza exacta de eventos ocurridos
- Cuando - Reconstruir la secuencia temporal de los hechos
- Como - Descubrir que herramientas o exploits han sido utilizados para el compromiso
Como un ejemplo de proceso forense examinaremos un caso de recuperación de un fichero eliminado.
Cuando hablamos de borrar un archivo bajo GNU/Linux, Unix queremos decir que el contador interno de enlaces inode (i_links_count) se decrementa a 0. El decremento es alcanzado eliminando todos los pares de inodes de la tabla de directorio referentes al nombre del fichero. Una vez el inode es eliminado, el núcleo marcará este recurso como disponible para uso por otros ficheros o procesos, nada más. El inode eliminado va a seguir conteniendo la información sobre el fichero referenciado y los bloques de datos a que el inode hace referencia seguirán teniendo el contenido del archivo. Este estado se mantendrá hasta que el espacio se re-asigne y se reuse sobreescribiendo los datos residuales. Por lo tanto la recuperación de ficheros eliminados es esencial para cualquier analista forense, dicho en otras palabras la recuperación de archivos se reduce a la búsqueda de inodes con datos pero con el contador de enlaces a 0 (es decir no vírgenes). El resultado es el listado de inodes borrados. Los punteros indicarán el offset de bloques que contienen los datos del fichero, lo que permitirá posiblemente recuperar el/los archivo/s eliminados. Aunque los bloques de datos ya estén ocupados por otra información (imposible recuperar el/los fichero/s) el analista puede obtener mucha información sobre lo que ha ocurrido en el sistema de ficheros examinando los meta-datos presentes en el directorio de entradas y inodes.
Los meta-datos no son asequibles a través de la interfaz de llamadas de sistema del núcleo, por lo tanto no son alterables por las herramientas estándares del sistema operativo (desde el punto de vista forense). La industria forense digital hasta ahora tenía pocos problemas para analizar de forma efectiva sistemas de ficheros de servidores comprometidos, pero este hecho está cambiando.
[Subir]
Definición: El término de evasión forense (anti-forensics) se refiere a las técnicas de eliminación y/o de ocultación de pruebas para complicar o imposibilitar la efectividad del análisis forense.
El análisis forense informático está ocupando rápidamente un lugar importante en procedimientos de respuesta a incidentes. Hace varios años sólo existía un número limitado de profesionales y aplicaciones capaces de detectar de forma estandarizada los indicios en una investigación forense, incrementándose últimamente la demanda de estos profesionales y el número de herramientas disponibles.
Es asombroso, que a pesar del interés creciente en el área de informática forense, dentro de la industria de seguridad informática, se habla muy poco sobre temas de evasión forense o anti-forensics. Para remediar la carencia de la cobertura, este anexo, basado en la publicación del Phrack, presenta algunas técnicas y estrategias de evasión al análisis forense sobre sistemas de ficheros GNU/Linux y Unix. Están incluidos ejemplos de estas técnicas utilizando como base el sistema de ficheros utilizadas de forma más común - ext2fs.
[Subir]
b. Resumen Sistema de Ficheros ext2fs
Esta sección describirá la teoría del sistema de ficheros de Unix sin centrarse en las implementaciones o distribuciones específicas, cubriendo la estructura interna de meta datos usados para organizar el sistema de ficheros. Los archivos dentro del sistema operativo Unix son streams continuos de bytes de longitud arbitraria usados para la entrada y salida. Este documento se centrara en archivos en su sentido amplio de almacenamiento de datos en el disco y su organización por sistemas de ficheros.
Los datos en un disco con sistema de fichero Unix se dividen normalmente en dos grupos, la información sobre los archivos y los datos dentro de los archivos. La información de organización y estadística de sistema de ficheros (normalmente sólo visible al núcleo) se llama los "meta datos", e incluye los siguientes partes: el super-block, los inodes y los datos de directorio. El contenido almacenado dentro de los ficheros se considera simplemente como "información".
Para crear la imagen abstracta de un fichero el kernel tiene que traducir de forma transparente al usuario los datos almacenados en uno o más sectores del disco duro en una secuencia de bytes. El sistema de ficheros se utiliza para no perder de vista cuales, y en qué orden deben ser agrupados los datos para montar un fichero. Además, los grupos de sectores deben ser guardados de forma separada y ser visibles al sistema operativo de forma individual. Por esa razón existen varios tipos de "meta-datos", siendo cada uno de los tipos responsable de realizar una de las siguientes tareas.
El contenido de un archivo se almacena en bloques de datos que son clusters lógicos de sectores del disco duro. Cuanto más alto es el número de sectores por bloque de datos cuanta más rápida es la velocidad de la E/S del disco, mejorando el rendimiento del sistema de ficheros. Al mismo tiempo, cuanto más grande es el tamaño de bloques de datos más espacio de disco duro se derrocha para los archivos que no terminan en los límites del bloque. Los sistemas de ficheros modernos típicamente tienen el tamaño del bloque de 4096 o 8192 bytes y combaten el despilfarro del disco con "fragmentación" (algo no tratado en este documento).
La parte del disco dedicada a bloques de datos se organiza como un array, y los bloques son referidos por sus offsets dentro de este array. El estado de un bloque particular, es decir "libre" contra "utilizado", se almacena en un bitmap llamado "block bitmap".
Los bloques de datos son ordenados y organizados en archivos por inodes. El inode es la estructura de meta datos que representa archivos visibles al usuario; un inode para cada archivo único. Cada inode contiene un array de punteros del bloque de datos y otra información adicional sobre el archivo. Esa información adicional incluye los parámetros de UID, GID, tamaño, permisos, MAC, y otros ciertos datos. La cantidad de espacio limitada disponible para los inodes significa que el array del bloque puede contener solamente un número reducido de punteros.
Para permitir que los tamaños de los ficheros tengan un tamaño substancial, los inodes emplean "bloques indirectos". Un bloque indirecto actúa como una extensión al array del bloque, almacenando punteros adicionales. Los siguientes bloques indirectos contienen referencias a otros bloques indirectos, y estos otros bloques indirectos contienen referencia a siguientes bloques respectivamente (hasta almacenar el fichero). Los inodes se almacenan en un array llamado inode table, y son referidos por sus índices basados en 0 dentro de esta tabla. El estado de un inode, es decir libre contra utilizado, se almacena en un bitmap llamado de forma original "inode bitmap".
Los archivos, es decir, inodes, están asociados a nombres de los ficheros a través de las estructuras especiales llamadas directory entries y almacenadas dentro de ficheros de directorio. Estas estructuras se almacenan uno al lado del otro dentro del archivo de directorio. Las entradas de directorios tienen siguiente estructura básica:
struct dirent {
int inode;
short rec_size;
short name_len;
char file_name[NAME_LEN];
}; El elemento 'inode' de la estructura dirent contiene el número del inode que hace referencia al nombre del fichero, almacenado en la variable 'file_name'. Para ahorrar el espacio, la longitud real del nombre del fichero se registra variable 'name_len' y el espacio restante en el array file_name bajo el índice NAME_LEN y se utilizar por la siguiente estructura de entrada de directorio. El tamaño de un dirent se redondea generalmente hasta aproximadamente 2**2, y este dato se almacena en la variable 'rec_size'. Cuando se quita el enlace del nombre/inode del archivo, el valor del inode se fija a 0 y 'rec_size' del dirent precedente se extiende para abarcar el dirent eliminado. Esto tiene el efecto de almacenar los nombres de archivos suprimidos dentro de ficheros de directorio.
Cada vez que un nombre del archivo se asocia a un inode, el contador interno dentro del inode se incrementa. Asimismo, cada vez que se quita este enlace, el contador se decrementa. Cuando este contador alcanza el valor de 0, no quedan referencias al inode dentro de la estructura del directorio; eso significa que el archivo es borrado. Los archivos que han sido suprimidos pueden tener sus recursos, bloques de los datos, el inode sí mismo liberados con seguridad. Esto se logra modificando los bitmaps respectivos.
Los archivos de directorios se organizan de forma lógica como un árbol que empieza desde el directorio raíz. Este archivo de directorio de raíz se asocia al inode conocido (2) de modo que el núcleo pueda localizarlo, y monta el sistema de ficheros.
Para montar un sistema de ficheros el núcleo necesita conocer el tamaño y la ubicación de meta datos. La primera parte de meta datos - el "super block", se almacena en una ubicación conocida. El super-block contiene la información sobre el número de inodes y de bloques, del tamaño de un bloque, y mucha otra información adicional. Basándose en los datos contenidos dentro del super-block, el kernel puede calcular las localizaciones y los tamaños de la tabla de inodes y de la porción de los datos del disco.
Por razones del rendimiento, ningún sistema de ficheros moderno tiene sólo una tabla del inode y un array del bloque. Al contrario, los inodes y los bloques se organizan en grupos distribuidos a través del disco. Estos grupos normalmente contienen sus bitmaps privados de sus inodes y bloques, así como las copias del super-block para facilitar la recuperación en caso de la pérdida de datos.
En la siguiente sección cubriremos más en detalle la organización del sistema de ficheros ext2fs.
[Subir]
El 'second extended file system' (ext2fs) es un sistema de ficheros estandar de Linux OS. Este capítulo proporcionará detalles necesarios para conocer a fondo la organización de este sistema de ficheros. La lectura de este paper no servirá como sustitución al estudio de las especificaciones de este sistema de ficheros y examen de de los src del kernel y de la librería ext2fs. A continuación está la descripción del sistema de ficheros ext2 empezando por los bloques de datos, inodes y concluyendo con directorios.
Bloques - La unidad básica de un sistema de ficheros es un bloque de datos utilizado para almacenar el contenido de los ficheros. Tipicamente, desde el punto de vista físico y independientemente del sistema de ficheros, la unidad más pequeña de espacio en el disco duro es un sector (512 bytes), pero es muy poco desde el punto de vista del ratio entrada/salida de datos. Para incrementar el rendimiento múltiples sectores están agrupados en un cluster y son considerados como una unidad de almacenamiento de datos - bloque. Un bloque típico puede tener en ext2fs un tamañode 4096 bytes, pero también puede ser de 2048 bytes y incluso 1024 (8, 4 y 2 sectores respectivamente).
Inodes - La segunda parte del sistema de ficheros son inodes - el corazón del sistema de ficheros ext2fs. Los inodes contienen meta-datos sobre cada fichero incluyendo punteros (1) a los bloques de datos asociados, permisos (2) de los ficheros, tamaños (3), propietarios (4), grupos (5) así como mucha otra información útil. El formato de un inode ext2 es el siguiente:
---------------------------------------------------------------------------
struct ext2_inode {
__u16 i_mode; /* Modo del Fichero */
__u16 i_uid; /* UID Propietario */
__u32 i_size; /* Tamaño en bytes */
__u32 i_atime; /* Fecha de Acceso */
__u32 i_ctime; /* Fecha de Creación */
__u32 i_mtime; /* Fecha de Modificación */
__u32 i_dtime; /* Fecha Eliminación */
__u16 i_gid; /* GID Propietario */
__u16 i_links_count; /* Contador de enlaces */
__u32 i_blocks; /* Contador de bloques */
__u32 i_flags; /* Marcadores Fichero */
union {
struct {
__u32 l_i_reserved1;
} linux1;
struct {
__u32 h_i_translator;
} hurd1;
struct {
__u32 m_i_reserved1;
} masix1;
} osd1; /* Información dependiente del Sistema Operativo 1 */
__u32 i_block[EXT2_N_BLOCKS];/* Punteros a los Bloques */
__u32 i_version; /* Versión de fichero NFS */
__u32 i_file_acl; /* Fichero ACL */
__u32 i_dir_acl; /* Directorio ACL */
__u32 i_faddr; /* Dirección del fragmente */
union {
struct {
__u8 l_i_frag; /* Número Fragmento */
__u8 l_i_fsize; /* Tamaño Fragmento */
__u16 i_pad1;
__u32 l_i_reserved2[2];
} linux2;
struct {
__u8 h_i_frag; /* Número Fragmento */
__u8 h_i_fsize; /* Tamaño Fragmento */
__u16 h_i_mode_high;
__u16 h_i_uid_high;
__u16 h_i_gid_high;
__u32 h_i_author;
} hurd2;
struct {
__u8 m_i_frag; /* Número Fragmento */
__u8 m_i_fsize; /* Tamaño Fragmento */
__u16 m_pad1;
__u32 m_i_reserved2[2];
} masix2;
} osd2; /* Información dependiente del Sistema Operativo 2 */
};
---------------------------------------------------------------------------
Existen dos uniones porque ext2fs ha sido diseñado para ser utilizado por sistemas operativas ligeramente diferentes (implementaciones, distros). Aparte de las cosas puntuales los únicos elementos de la unión que importan son estructuras linux1 y linux2, el resto de las estructuras simplemente ahora pueden ser consideradas como facilidades adicionales ya que en la última implementación ext2fs se ignoran. El uso del resto de los valores de un inode están explicadas a continuación:
- i_mode - El modo del fichero, se refiere a los permisos octales de cualquier sistema GNU/Linux.
- i_uid - Este elemento contiene el UID del propietario del fichero.
- i_size - El tamaño de los ficheros en bytes. El tamaño máximo de un fichero puede ser de 4Gb por el tipo de variable unsigned int de 32 bit. El soporte para los tamaños de ficheros de 64 bits ha sido inventado creando una definición #define i_size_high i_dir_acl
- i_atime - La fecha de último acceso al fichero. Todos los valores temporales se expresan en el modo estandar de Unix de contar el tiempo - en segundos desde el inicio del siglo.
- i_ctime - La fecha de creación del fichero.
- i_mtime - La fecha de la última modificación del fichero.
- i_dtime - Fecha eliminación del fichero. Si el fichero todavía no ha sido eliminado el valor de este registro contiene 0x00000000.
- i_gid - El GID del fichero.
- i_links_count - Este registro contiene el contador de veces que el fichero se referencia en el sistema de ficheros de nivel superior. Es decir que cada hard link al fichero incrementa este contador. Cuando el último enlace del sistema de ficheros ha sido eliminado el valor del registro es 0, significa que el fichero ha sido eliminado. Los bloques asociados al inode están marcados en el bitmap como libres.
- i_blocks - El número de bloques referenciados por el inode. Este bloque no incluye bloques indirectos, sólo aquellos que contienen el contenido real del fichero.
- i_flags - Los atrubutos adicionales del ext2fs consisten en valor único o una combinación de los siguientes valores:
---------------------------------------------------------------------------
#define EXT2_SECRM_FL 0x00000001 /* Borrado Seguro */
#define EXT2_UNRM_FL 0x00000002 /* Recuperación */
#define EXT2_COMPR_FL 0x00000004 /* Compresión del Fichero */
#define EXT2_SYNC_FL 0x00000008 /* Actualización Sincronizada */
#define EXT2_IMMUTABLE_FL 0x00000010 /* Fichero inmutable */
#define EXT2_APPEND_FL 0x00000020 /* Únicamente añadir contenido */
#define EXT2_NODUMP_FL 0x00000040 /* No permitir el dump del fichero */
#define EXT2_NOATIME_FL 0x00000080 /* No actualizar el registro atime */
/* Reservado para el uso de compresión de datos... */
#define EXT2_DIRTY_FL 0x00000100
#define EXT2_COMPRBLK_FL 0x00000200 /* Comprimir clusters */
#define EXT2_NOCOMP_FL 0x00000400 /* No realizar compresión */
#define EXT2_ECOMPR_FL 0x00000800 /* Error de compresión */
/* Fin marcadores de compresión --- algunos no se utilizan */
#define EXT2_BTREE_FL 0x00001000 /* formato directorio btree */
#define EXT2_RESERVED_FL 0x80000000 /* reservado para la librería ext2 */
---------------------------------------------------------------------------
- i_block[] - Un array de punteros de bloques. Hay 15 elementos en el array, los primeros 12 elementos son punteros directos a bloques, estos contiene el contenido real de los ficheros. El puntero número 13 contiene la referencia al bloque que sirve como extensión para el array. Este bloque es un bloque indirecto, y los punteros que contiene apuntan al resto de los bloques directos adicionales. El elemento 14 del array contiene una referencia a otro array que incluye un array de punteros a los bloques indirectos. Este elemento es un bloque indirecto doble, mientras que el último elemento del array contiene referencia a los bloques indirectos dobles:
---------------------------------------------------------------------------
#define EXT2_NDIR_BLOCKS 12
#define EXT2_IND_BLOCK EXT2_NDIR_BLOCKS
#define EXT2_DIND_BLOCK (EXT2_IND_BLOCK + 1)
#define EXT2_TIND_BLOCK (EXT2_DIND_BLOCK + 1)
#define EXT2_N_BLOCKS (EXT2_TIND_BLOCK + 1)
---------------------------------------------------------------------------
- i_version - La versión del fichero. No se utiliza actualmente.
- i_file_acl - Un puntero a una lista ACL. En la versión ext2fs no se utiliza ya que no exiten listas ACL, puede que se utilice en las siguientes versiones del sistema de ficheros.
- i_dir_acl - Un puntero a una lista ACL. En la versión ext2fs no se utiliza como ACL sino como el valor de i_size_high. Estos son 32 bit del de espacio adicional para el tamaño del fichero. Permite tene el tamaño del fichero a 64 bits unsigned int.
- i_faddr - Dirección del fragmeto. Los fragmentos no se utilizan en ext2fs por lo tanto el valor de este registro es 0.
Algunos inodes tienen un significado especial dentro del sistema de ficheros.
---------------------------------------------------------------------------
#define EXT2_BAD_INO 1 /* Inode de bloques dañados */
#define EXT2_ROOT_INO 2 /* Inode de Raiz */
#define EXT2_ACL_IDX_INO 3 /* Inode ACL */
#define EXT2_ACL_DATA_INO 4 /* Inode ACL */
#define EXT2_BOOT_LOADER_INO 5 /* Inode del boot loader */
#define EXT2_UNDEL_DIR_INO 6 /* Inode de recuperación de un directorio borrado */
---------------------------------------------------------------------------
El inode de bloques dañados contiene punteros a los bloques de datos que contienen sectores dañados en el disco duro. El inode raiz es el directorio raiz que contiene el inicio del todo el arbol de directorio. El resto de los inodes no se utilizan normalmente en sistemas de producción. El primer inode utilizado para los ficheros de usuarios es el 11. Este inode es el directorio "lost+found", creado por la herramienta mkfs.
Superblock - El superblock es el único medio básico para proporcionarl al kernel la información del estado del sistema de ficheros. Este bloque indica el número de inodes, bloques, grupos y además mucha otra información adicional. Los elementos dentro del superblock cambian más frecuentemente que la información sobre inodes o datos del grupo porque libext2fs añade más funcionalidades a ext2fs que puede no ser implementado dentro del kernel. El formato que examinamos es de e2fsprogs-1.19. El super block es de 1024 bytes, y su offset está a 1024 bytes del inicio de una partición.
El formato del super block es el siguiente:
---------------------------------------------------------------------------
struct ext2fs_sb {
__u32 s_inodes_count; /* Contador de inodes */
__u32 s_blocks_count; /* Contador de bloques */
__u32 s_r_blocks_count; /* Contador bloques reservados */
__u32 s_free_blocks_count; /* Contador bloques libres */
__u32 s_free_inodes_count; /* Contador inodes libres */
__u32 s_first_data_block; /* Primer bloque de datos */
__u32 s_log_block_size; /* Tamaño del bloque */
__s32 s_log_frag_size; /* Tamaño fragmento */
__u32 s_blocks_per_group; /* # Bloques por grupo */
__u32 s_frags_per_group; /* # Fragmentos por grupo */
__u32 s_inodes_per_group; /* # Inodes por grupo */
__u32 s_mtime; /* Fecha de montura */
__u32 s_wtime; /* Fecha escritura */
__u16 s_mnt_count; /* Contador de montura */
__s16 s_max_mnt_count; /* Contador número máximo monturas */
__u16 s_magic; /* Firma mágica */
__u16 s_state; /* Estado sistema de ficheros */
__u16 s_errors; /* Comportamiento al encontrar errores */
__u16 s_minor_rev_level; /* Nivel de revisión - menor */
__u32 s_lastcheck; /* Fecha de última comprobación */
__u32 s_checkinterval; /* Periodo máximo entre comprobaciones */
__u32 s_creator_os; /* Sistema Operativo */
__u32 s_rev_level; /* Nivel de Revisión */
__u16 s_def_resuid; /* UID por defecto para bloques reservados */
__u16 s_def_resgid; /* GID por defecto para bloques reservados */
/*
* Estos campos son para superblocks de EXT2_DYNAMIC_REV.
*
* Nota informativa: la diferencia entre las carácteristicas compatibles y
* las incompatibles es que si dentro de las carácteristicas no soportadas
* un valor está marcado y kernel no lo reconoce, rechazará la montura del
* del sistema de ficheros.
*
*/
__u32 s_first_ino; /* Primer inode no reservado */
__u16 s_inode_size; /* Tamaño estructura inode */
__u16 s_block_group_nr; /* grupo de bloques # de este superblock */
__u32 s_feature_compat; /* características compatibles */
__u32 s_feature_incompat; /* características incompatibles */
__u32 s_feature_ro_compat; /* carácteristicas de solo lectura */
__u8 s_uuid[16]; /* Uuid de 128-bit del volumen */
char s_volume_name[16]; /* nombre volumen */
char s_last_mounted[64]; /* último punto de montura */
__u32 s_algorithm_usage_bitmap; /* para compresión */
/*
* Sugerencias de rendimiento. Si el registro EXT2_FEATURE_COMPAT_DIR_PREALLOC
* está activado, los directorios se reservan.
*/
__u8 s_prealloc_blocks; /* Número de bloques intentar reservar */
__u8 s_prealloc_dir_blocks; /* Número bloques reservar para directorios */
__u16 s_padding1;
/*
* Soporte para journaling.
*/
__u8 s_journal_uuid[16]; /* uuid del superblock del journal */
__u32 s_journal_inum; /* número inode del fichero journal */
__u32 s_journal_dev; /* número de dispositivo del fichero journal */
__u32 s_last_orphan; /* inicio de la lista de inodes a eliminar */
__u32 s_reserved[197]; /* Marca de finalización del bloque */
};
---------------------------------------------------------------------------
- s_inodes_count - Número total de inodes dentro del sistema de ficheros.
- s_blocks_count - Número total de bloques dentro del sistema de ficheros.
- s_r_blocks_count - Número de bloques reservados para el usuario root. En caso de que el sistema de ficheros se llene, éstos evitarán que los uauarios puedan hacer que el sistema de ficheros vuelva inestable.
- s_free_blocks_count - Número de bloques sin utilizar. Éste número se actualiza constantemente ya que cada momento los bloques se liberan y se ocupan.
- s_free_inodes_count - Número de inodes sin utilizar. Este valor se actualiza constantemente ya que cada momento los bloques se liberan y se ocupan de nuevo.
- s_first_data_block - Puntero al primer bloque de datos después de los bloques que sirven para almacenar tablas de inodes, bitmaps y grupos. El valor puede ser 0 o alternativamente el valor correcto.
- s_log_block_size - Tamaño del bloque. El valor se almacena de forma desplazada. El valor a desplazar es 1024, por lo tanto para obtener el tamaño del bloque real debemos utilizar la fórmula: bs = 1024 <<>
- s_log_frag_size - Tamaño del fragmento. Este valor se almacena de forma desplazada. Fragmentos no se utilizan en ext2fs por lo tanto el valor de este registro se ignora.
- s_blocks_per_group - Número bloques en un grupo.
- s_frags_per_group - Número de fragmentos en el grupo.
- s_inodes_per_group - Número de inodes en el grupo.
- s_mtime - Última fecha de montura del sistema de ficheros.
- s_wtime - La fecha de última escritura en el sistema de ficheros.
- s_mnt_count - Número de veces el sistema de ficheros fue montada.
- s_max_mnt_count - Número máximo de veces un sistema de ficheros puede ser montada antes de realizar un fsck. El valor por defecto es 20.
- s_magic - Número mágico del sistema de ficheros: 0xEF53.
- s_state - Estado del sistema de ficheros, puede ser clean o dirty. Los siguientes son los flags:
--------------------------------------------------------------------------
#define EXT2_VALID_FS 0x0001 /* Desmontado correctamente */
#define EXT2_ERROR_FS 0x0002 /* Errores detectados */
---------------------------------------------------------------------------
- s_errors - Cuando un error se detecta el comportamiento a tener en cuenta. Los siguientes son los valores:
---------------------------------------------------------------------------
#define EXT2_ERRORS_CONTINUE 1 /* Continuar ejecución */
#define EXT2_ERRORS_RO 2 /* Remontar el sistema de ficheros en solo lectura */
#define EXT2_ERRORS_PANIC 3 /* Generar Pánico */
#define EXT2_ERRORS_DEFAULT EXT2_ERRORS_CONTINUE
---------------------------------------------------------------------------
- s_minor_rev_level - Número menor de la revisión de la revisión ext2fs. El valor puede ser ignorado perfectamente.
- s_lastcheck - La fecha de la última verificación del sistema de ficheros fsck, almacenada en formato estandarizado de Unix.
- s_checkinterval - Periodo máximo de tiempo entre verificaciones de fsck. El sistema de ficheros tiene que ser verificada si el valor de este registro o del s_max_mnt_count se ha excedido.
- s_creator_os - El sistema operativo creador del sistema de ficheros. Los valores pueden ser los siguientes:
---------------------------------------------------------------------------
#define EXT2_OS_LINUX 0
#define EXT2_OS_HURD 1
#define EXT2_OS_MASIX 2
#define EXT2_OS_FREEBSD 3
#define EXT2_OS_LITES 4
---------------------------------------------------------------------------
- s_rev_level - Revisión del sistema de ficheros. La única diferencia en valores tiene que ver con el tamaño de inodes. La versión actual de ext2 utiliza el tamaño de 128 bytes de inode. Los siguientes son los valores válidos para el registro:
---------------------------------------------------------------------------
#define EXT2_GOOD_OLD_REV 0 /* Formato original */
#define EXT2_DYNAMIC_REV 1 /* Formato V2 con tamaño de inodes dinámico */
#define EXT2_CURRENT_REV EXT2_GOOD_OLD_REV
---------------------------------------------------------------------------
- s_def_resuid - UID por defecto de los bloques reservados. El valor por defecto es 0.
- s_def_resgid - GID por defecto para bloques reservados. El valor por defecto es 0.
- s_first_ino - El primer inode no reservado. Inodes menores de 10 están reservados, entonces el primer número inode válido es 11. Casi siempre el inode está asociado con la entrada "lost+found".
- s_inode_size - Tamaño del inode. El tamaño actual es 128 bytes.
- s_block_group_nr - El grupo de bloque dónde se almacena el superblock.
- s_feature_compat - Valores de carácteristicas soportadas por ext2fs. Los siguientes son los valores:
---------------------------------------------------------------------------
#define EXT2_FEATURE_COMPAT_DIR_PREALLOC 0x0001
---------------------------------------------------------------------------
- s_feature_incompat - Valores de carácteristicas no soportadas. Las siguientes son las incompatibilidades aceptadas.
---------------------------------------------------------------------------
#define EXT2_FEATURE_INCOMPAT_COMPRESSION 0x0001
#define EXT2_FEATURE_INCOMPAT_FILETYPE 0x0002
---------------------------------------------------------------------------
- s_feature_ro_compat - Valores de compatibilidad soportadas en modo solo lectura. Los siguientes son los valores posibles:
---------------------------------------------------------------------------
#define EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER 0x0001
#define EXT2_FEATURE_RO_COMPAT_LARGE_FILE 0x0002
#define EXT2_FEATURE_RO_COMPAT_BTREE_DIR 0x0004
---------------------------------------------------------------------------
- s_uuid - ID único de éste sistema de ficheros particular de tipo ext2fs.
- s_volume_name - Nombre del volumen. Este registro no tiene mucha importancia.
- s_last_mounted - El punto de montura que fue utilizado la última vez que el sistema de ficheros fue montado.
- s_algorithm_usage_bitmap - No dispongo de datos del uso de este registro, pero no presenta ningún interes en nuestro whitepaper.
- s_prealloc_blocks - Número de bloques a intentar reservar para un fichero.
- s_prealloc_dir_blocks - Número de bloques a intentar reservar para un fichero de directorio.
- s_padding1 - Padding.
- s_reserverd[] - Padding para rellenar el superblock de más de 1024 bytes.
Grupos- Grupos Ext2fs se utilizan para organizar los clusters de bloques y inodes. Cada uno de los grupos contiene un bitmap libre de inodes y un inode libre. De forma adicional cada grupo tiene una copia del superblock para ayudar en la prevensión de la pérdida de datos. Descriptores de grupos están almacenados en el bloque después del super block, y luego a continuación están los bitmaps y tablas de inodes. Luego vienen los bloques de datos.
El formato de los descriptores del grupo son siguientes:
-----------------------------------------------------------------------------
struct ext2_group_desc
{
__u32 bg_block_bitmap; /* Bloque del bloque bitmap */
__u32 bg_inode_bitmap; /* Inodes del bloque bitmap */
__u32 bg_inode_table; /* Bloque de tablas inode */
__u16 bg_free_blocks_count; /* Contador de libres bloques */
__u16 bg_free_inodes_count; /* Contador de libres inodes */
__u16 bg_used_dirs_count; /* Contador de directorios */
__u16 bg_pad;
__u32 bg_reserved[3];
};
-----------------------------------------------------------------------------
- bg_block_bitmap - Puntero del bloque que lleva al bitmap. Los bits en el bitmap sirven para indicar si está ocupado o libre.
- bg_inode_bitmap - Puntero del bloque que lleva al bitmap de los inodes. Los bits en el bitmap sirven para indicar si está ocupado o libre.
- bg_inode_table - Puntero del bloque que lleva al inicio de la tabla de los inodes.
- bg_free_blocks_count - El número de bloques dentro del grupo que están disponibles para el uso.
- bg_free_inodes_count - El número de inodes dentro del grupo disponibles para el uso.
- bg_used_dirs_count - El número de inodes del grupo utilizados para ficheros de directorio.
- bg_pad - Padding.
- pg_reserved[] - Padding.
Directorios - Directorios se utilizan para organizar ficheros a nivel del sistema operativo. El contenido del fichero de directorio es un array de estructuras de directorios. Cada fichero de directorio contiene el nombre del fichero dentro del mismo directorio y el inodel del fichero.
El formato de entradas de directorios en ext2 es el siguiente:---------------------------------------------------------------------------
struct ext2_dir_entry_2 {
__u32 inode; /* Número Inode */
__u16 rec_len; /* Tamaño de la entrada */
__u8 name_len; /* Tamaño del nombre */
__u8 file_type;
char name[EXT2_NAME_LEN]; /* Nombre del fichero */
};
---------------------------------------------------------------------------
- inode - El número inode del fichero dentro del directorio. Si el fichero ha sido eliminado, el número inode debe ser 0.
- rec_len - El tamaño de la entrada de directorio. Como el nombre puede ser cualquier cadena de más de 255 bytes, eso permite un uso de espacio más eficiente en el fichero de directorio.
- name_len - El tamaño del nombre del fichero. Puede ser hasta 255 bytes.
- file_type - El tipo de fichero, por ejemplo symlink, dispositivo, etc... Los siguientes son los valores válidos:
---------------------------------------------------------------------------
#define EXT2_FT_UNKNOWN 0
#define EXT2_FT_REG_FILE 1
#define EXT2_FT_DIR 2
#define EXT2_FT_CHRDEV 3
#define EXT2_FT_BLKDEV 4
#define EXT2_FT_FIFO 5
#define EXT2_FT_SOCK 6
#define EXT2_FT_SYMLINK 7
---------------------------------------------------------------------------
Eso concluye la descripción del nivel físico del sistema de ficheros ext2fs.
[Subir]
En el capítulo anterior se trataron los conceptos básicos de análisis forense y también se hizo una mención indirecta de algunos métodos de subversión del análisis, mientras que, de aquí para adelante, nos centraremos en el tema de evasión forense.
Evasión forense es un intento de mitigar la cantidad y calidad de información un investigador puede encontrar. Cada uno de los pasos del análisis puede ser explotado y subvertido. Este white paper se centra principalmente en la subversión de la fase de recolección de datos del sistema de ficheros durante la investigación.
Los mecanismos principales para alcanzar este objetivo son: técnicas de destrucción (1) y ocultación (2) de datos. A lo largo del white paper se hará referencia a la explotación de algunas vulnerabilidades del proceso de análisis y recolección de datos.
El estudio forense es extremadamente vulnerable a subversión cuando la información, en su estado básico (raw data image), se convierte en pruebas (por ejemplo emails). Cada paso de la conversión es vulnerable por la complejidad y procesos abstractos que se realizan sobre los datos. Cuando se trabaja con los datos cualquier despiste puede resultar en pérdida de detalles y los detalles en realidad son las partes más importantes del rompecabezas. Cuando los detalles desaparecen, se crean vacíos importantes que pueden ser explotados. El despiste no es la única fuente de errores, sino también los fallos en las herramientas forenses frecuentemente utilizadas. Bugs en las implementaciones de estas herramientas proporcionan mejores oportunidades de explotación para agentes evasivos.
Pocas cosas pueden ser hechas de forma remota por un agente evasivo a fin de prevenir que el sistema de ficheros se salve, asimismo nos centraremos en la siguiente fase del análisis forense - prevención de recogida de pruebas del sistema de ficheros. Se puede frenar la recogida de información a través de destrucción o ocultación de la misma. De estos dos mecanismos la destrucción de datos es la más fiable ya que no deja ninguna pista el investigador puede recoger y analizar. Esta técnica proporciona medios para la eliminación segura de huellas y pruebas existentes para cubrirse las huellas del atacante de forma más efectiva.
Ocultación de información sólo es efectiva cuando el analista no sabe dónde buscarla, siendo la integridad del medio de almacenamiento imposible de garantizar a largo plazo. Por esa razón, la ocultación de datos debe ser combinada con ataques a las fases de estudio de datos recogidos (por ejemplo formatos propietarios de ficheros) y de examen (por ejemplo cifrado). Técnicas de ocultación son útiles en caso de que los datos se tengan que guardar durante un periodo esencial de tiempo (por ejemplo fotos artísticas de señoritas posando).
Los dos toolkits incluidos en la siguiente sección del white paper proporcionan una demostración de las dos técnicas de evasión forense: destrucción de datos y ocultación. Utilizaremos estos toolkits para dar ejemplos detallados de destrucción y ocultación de datos a continuación. La primera técnica que examinaremos en detalle es la ocultación.
[Subir]
Aquellos hackers con conocimientos superiores que rozan la frontera de imaginación de los wannabes no dejan nada a la suerte y gracias a ellos han empezado existir series de herramientas de evasión o de encubrimiento de huellas. Si nos hubieran dicho por los años 1999 que aparte del zapper clásico existían herramientas que permitían borrar el rastro o por lo menos hacerlo tan confuso para el investigador, nos sorprenderíamos, pero no tanto como se sorprenden cada día miles de administradores de servidores cuando saben que hubo compromiso pero no encuentran huellas con las más avanzadas técnicas de investigación. En esta sección del whitepaper hablaremos sobre las herramientas más avanzadas y secretas que existen para encubrir huellas y daremos pistas de como detectar su uso.
[Subir]
Una de las herramientas más comúnes para el análisis forense del sistema de ficheros Unix es "The Coroner's Toolkit" desarrollada por Dan Farmer y Wietse Venema. A pesar de ser casí la única aplicación en la que han confiado los analistas forenses durante años, la herramienta podría ser mejorada a lo largo de años y los fallos que ocurrían en las primeras versiones siguien produciendose hoy en día. El sistema de ficheros más utilizada de Unix tiene un error que permite al atacante almacenar datos aleatorios en ubicaciones que TCT no puede ni localizar ni examinar.
El TCT falla a la hora de recrear las especificaciones de sistema de ficheros a la hora de analizar implementaciones de Berkley Fast File System (FFS o UFS), y Second Extended File system (ext2fs). El fallo consiste en asumir que ningún bloque de datos puede ser asignado al inode antes del root inode, fallando también a tener en cuenta los inodes de los bloques dañados.
Historicamente, el inode de bloques dañados fue utilizado para referenciar bloques que contienen sectores dañados en el disco duro, previniendo que estos bloques estén utilizados por el sistema operativo. El FFS dejó de utilizar este método, lo que evita la explotación de este error, pero ext2fs siguie utilizando la misma técnica de marcación.
La realización del ataque de ocultación al sistema de ficheros significa para un intruso la manipulación del sistema de ficheros dentro de las especificaciones implementadas de la herramienta de verificación de integridad del FS: fsck. Sería de interés saber que pocos investigadores han pensado en utilizar un fsck para detectarlo y intrusos incautos pueden haber sobrepasado el marco de seguridad de las especificaciones.
La versión de esa herramienta diseñada para funcionar con el sistema de ficheros ext2 todavía utiliza los inodes de bloques dañados para estos sectores en el disco, por lo tanto las especificaciones permiten tener un número ilimitado de bloques dañados, y este hecho no levanta sospechas a la hora de realizar un chequeo del disco. Desgraciadamente la parte del código de reconocimiento del sistema de ficheros en TCT no realiza verificación del inode de bloques dañados ya que no lo considera de interés alguno. El código de TCT así como de TASK realiza la siguiente verificación errónea:
/*
* Verificación de integridad
*/
if (inum <> ext2fs->fs.s_inodes_count)
error("invalid inode number: %lu", (ULONG) inum);
El primer inode que puede ser reservado en un sistema de ficheros ext2 es de hecho el inode de bloques dañados (inode 1) y no el inode de raíz (inode 2). Por razones de fallos en implementación es posible almacenar información en bloques marcados como bloques dañados, es decir referenciados por el inode de bloques dañados. Usando esa técnica se puede almacenar allí la información y tenerla oculta de cualquier analista que usa herramientas como TCT o TASK. Para ilustrar la gravedad de este tipo de ataques a continuación están algunos ejemplos que muestran como crear un espacio oculto, copiar allí la información y sacarla de allí cuando se necesite (ver también el código de la aplicación RuneFS adjunto).
Ejemplo de creación de espacio oculto:
# df -k /dev/hda6
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda6 1011928 20 960504 1% /mnt
# ./bin/mkrune -v /dev/hda6
+++ bb_blk +++
bb_blk->start = 33275
bb_blk->end = 65535
bb_blk->group = 1
bb_blk->size = 32261
+++
rune size: 126M
# df -k /dev/hda6
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda6 1011928 129196 831328 14% /mnt
# e2fsck -f /dev/hda6
e2fsck 1.26 (3-Feb-2002)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hda6: 11/128768 files (0.0% non-contiguous), 36349/257032 blocks
#
Este ejemplo demuestra la reserva de 126 mb. para el espacio oculto en el disco duro, demostrando que la pérdida de este espacio se queda registrada por el núcleo. Es evidente que el espacio oculto no viola las especificaciones ext2, por lo tanto fsck no se queja.
Ejemplo de uso del espacio oculto:
# cat readme.tools | ./bin/runewr /dev/hda6
# ./bin/runerd /dev/hda6 > f
# diff f readme.tools
#
Este segundo ejemplo muestra como datos pueden ser insertados y extraídos del espacio de almacenamiento oculto sin pérdida de datos. Mientras que este ejemplo no entra en detalle de técnicas de almacenamiento en el espacio oculto, es suficiente para presentar el uso de RuneFS.
Ejemplo de mala implementación de reconocimiento de sistema de ficheros ext2fs.
# ./icat /dev/hda6 1
/icat: invalid inode number: 1
#
Este ultimo ejemplo ilustra como un analista forense es incapaz de localizar el almacenamiento oculto con herramientas TCT. Es evidente que pueden haber muchos problemas cuando se examina el sistema de ficheros con herramientas con fallos.
Aunque los últimos ejemplos son realimente asombrosos, existen ciertos problemas con RuneFS. Esa versión de RuneFS que viene a continuación es bastante anticuada; Gnugq, el redactor del Phrack en que me baso para cumplimentar mi white paper, la ha escrito en Noviembre del año 2000. La versión actual de RuneFS tiene soporte para reserva de espacio dinámica, soporta cifrado y estructura de directorios y puede llegar a ser hasta 2 Gb. Afortunadamente el software de Gnugq es privado y no se distribuye al público.
Al fin y al cabo el uso la última versión de RuneFS tiene una mayor desventaja ya que el secreto y la técnica de implementación ya es de dominio público (obviamente, por el número de lectores Phrack, y espero de éste artículo). Esta desventaja subraya que técnicas de ocultación de datos se encuentran bastante anticuadas y no serán útiles si el analista sabe dónde buscar la información. La ocultación sólo puede ser utilizada en combinación con métodos de ofuscación y/o cifrado de datos.
[Subir]
El sistema de ficheros (supuestamente) contiene el seguimiento completo de operaciones de entrada y salida de datos del equipo. El analista forense involucrado en la investigación intenta extraer esa información para examinarla.
Aparte de las dificultades impuestas por los fallos en las implementaciones de herramientas forenses comúnmente utilizadas, el analista lo tendrá mucho más difícil todavía extrayendo la información del sistema de ficheros en caso de que simplemente no esté allí.
Esta sección cubrirá técnicas y herramientas utilizadas por los intrusos para eliminar cualquier evidencia de compromiso en el sistema de ficheros. Estas metodologías han sido reunidas en la aplicación “The Defiler’s Toolkit (TDT)” que puede ser descargada al final del artículo.
La mayor complicación con la reunión de pruebas es que deben estar allí para recogerlas. Los datos no existentes, obviamente, no pueden ser recogidos, siendo por lo tanto imposible sin estos datos seguir con la investigación.
La limpieza del sistema de ficheros es una de las prácticas de evasión utilizadas por los intrusos con un nivel alto de conocimientos. El resultado de la aplicación de ésta metodología resulta en la eliminación definitiva de las pruebas de borrado de ficheros existidos anteriormente. The Defiler’s Toolkit proporciona herramientas para eliminar huellas del sistema de ficheros con precisión quirúrgica, erradicando de forma selectiva la información que puede ser utilizada posiblemente como prueba. Utilizando este juego de herramientas el intruso puede frustrar desde el principio toda la investigación.
Dentro del sistema de ficheros Unix todos los siguientes elementos pueden contener pruebas de las actividades del intruso:
- Inodes
- Entradas de Directorio
- Bloques de Datos
Desgraciadamente las herramientas más avanzadas de eliminación de datos borran solo el contenido de bloques de datos, dejando intactos las entradas de directorio y inodes. Junto con este white-paper viene una versión del toolkit capaz de realizar una limpieza selectiva del disco duro. TDT consiste de dos aplicaciones: necrofile y klismafile que conjuntamente hacen un trabajo perfecto de eliminación segura de existencia de fichero. El objetivo de cada una de esas aplicaciones será descrito de forma individual a continuación.
[Subir]
Necrofile es una herramienta de detección y eliminación segura de inodes “borrados”. La aplicación puede ser utilizada para:
- Localizar a todos los inodes que cumplen con un criterio de fecha de eliminación.
- Realizar una limpieza exhaustiva dejando los inodes limpios.
Los inodes “vírgenes” no proporcionan ninguna información al investigador sobre la existencia o borrado del fichero manipulado por el intruso.
Necrofile también incluye la funcionalidad de erradicar de forma segura el contenido de los bloques de datos a los que hace referencia el inode. Sin embargo, en este momento no es conveniente utilizar esa funcionalidad por los conflictos con los procesos de lectura y escritura del disco controlados por el núcleo.
Al ejecutar la aplicación se le debe proporcionar un sistema de ficheros donde realizar la búsqueda y informar de como se debe proceder con los inodes “borrados” localizados en la partición. Necrofile verifica de forma reiterada todos los inodes del sistema de ficheros especificada y verificando el estado de cada uno de ellos. En caso de que la aplicación haya sido arrancada con la opción de limpieza Necrofile limpia el inode “borrado” y lo inserta en la tabla de inodes en su estado virgen.
[Subir]
Ejemplo de localización de inodes borrados utilizando TCT:
# ./ils /dev/hda6
class|host|device|start_time
ils|XXX|/dev/hda6|1026771982
st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_dtime|st_mode|\
st_nlink|st_size|st_block0|st_block1
12|f|0|0|1026771841|1026771796|1026771958|1026771958|100644|0|86|545|0
13|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|546|0
14|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|547|0
15|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|548|0
16|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|549|0
17|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|550|0
18|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|551|0
19|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|552|0
20|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|553|0
21|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|554|0
22|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|555|0
23|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|556|0
24|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|557|0
25|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|558|0
26|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|559|0
27|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|560|0
28|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|561|0
29|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|562|0
30|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|563|0
31|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|564|0
32|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|565|0
33|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|566|0
34|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|567|0
35|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|568|0
36|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|569|0
37|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|570|0
#
Ejemplo de utilización de Necrofile para localizar y limpiar los inodes borrados.
# ./necrofile -v -v -v -v /dev/hda6
Scrubbing device: /dev/hda6
12 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
13 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
14 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
15 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
16 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
17 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
18 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
19 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
20 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
21 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
22 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
23 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
24 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
25 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
26 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
27 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
28 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
29 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
30 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
31 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
32 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
33 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
34 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
35 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
36 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
37 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
#
Ejemplo de como TCT no es capaz de localizar ningún inode borrado:
# ./ils /dev/hda6
class|host|device|start_time
ils|XXX|/dev/hda6|1026772140
st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_dtime|st_mode|\
st_nlink|st_size|st_block0|st_block1
#
Se necesita poco comentario para acompañar los ejemplos. La utilidad “ils” que forma parte de TCT muestra los inodes borrados para su posible recuperación.
Necrofile se ejecuta en el modo más detallado soportado por la aplicación, para demostrar como se localiza y limpia los mismos inodes encontrados por ils.
El uso de esta herramienta puede ser más efectivo si se utiliza para eliminar las huellas dejadas en los periodos determinados de tiempo, de esta manera los forenses tienen dificultades detectando la limpieza intencionada de los inodes.
En caso de que Necrofile se utilice para limpiar todos los inodes “borrados” del disco y el forense encuentre que no hay ningún inode “borrado” se confirmará su sospecha del compromiso y eliminación intencionada de pruebas por un hacker.
Después de que los inodes “borrados” hayan sido convertidos en inodes “vírgenes” ils no es capaz de localizarles.
Una vez los meta-datos que forman parte del inode han sido limpiados con éxito el intruso procede a barrer sus huellas en otros lugares del sistema de ficheros - las entradas de directorios.
Klismafile permite borrar de forma segura las entradas de directorio borradas. Cuando el nombre del fichero o el enlace inode se termina, el contenido de la entrada de directorio no se sobrescribe, sino se añade al espacio de la entrada precedente. Klismafile realizará una búsqueda en el fichero de directorio para localizar las entradas eliminadas y las sobrescribirá. Las expresiones regulares pueden ser utilizadas para limitar el número de entradas quitadas.
Para ejecutar la herramienta se debe proporcionarla con un directorio dónde realizar la búsqueda, y también puede realizar búsqueda recursiva en todos los directorios que encuentre.
Klismafile intentará localizar dirents eliminados y una vez encontrados los comparará con la expresión regular ‘file_name’ proporcionada como argumento del programa. Por defecto el ‘file_name’ es ‘*’. La utilidad sobrescribirá los dirents que coinciden con la expresión regular con ceros.
Klismafile no es una herramienta totalmente segura, y puede ser detectada su utilización observando que la entrada del directorio precedente al eliminado tiene el campo rec_len mayor de lo que debería ser, por lo tanto se puede asumir que herramientas como Klismafile o similares han manipulado el contenido del fichero de directorio. Actualmente no existen herramientas para realizar esa detección de forma automática, pero no tardarán en aparecer.
Ejemplo: la utilidad fls proporciona el listado de entradas de directorio.
# ./fls -d /dev/hda6 2
? * 0: a
? * 0: b
? * 0: c
? * 0: d
? * 0: e
? * 0: f
? * 0: g
? * 0: h
? * 0: i
? * 0: j
? * 0: k
? * 0: l
? * 0: m
? * 0: n
? * 0: o
? * 0: p
? * 0: q
? * 0: r
? * 0: s
? * 0: t
? * 0: u
? * 0: v
? * 0: w
? * 0: x
? * 0: y
? * 0: z
#
Ejemplo de como Klismafile realiza la limpieza.
# ./klismafile -v /mnt
Scrubbing device: /dev/hda6
cleansing /
-> a
-> b
-> c
-> d
-> e
-> f
-> g
-> h
-> i
-> j
-> k
-> l
-> m
-> n
-> o
-> p
-> q
-> r
-> s
-> t
-> u
-> v
-> w
-> x
-> y
-> z
Total files found: 29
Directories checked: 1
Dirents removed : 26
#
Ejemplo de como fls no es capaz de encontrar ninguna entrada.
# ./fls -d /dev/hda6 2
#
Estos ejemplos demuestran claramente que la utilidad ‘fls’ – una parte de la caja de herramientas TCT-UTILS, sirve para examinar los ficheros de directorios. En el primer ejemplo el uso de la utilidad devuelve el listado de entradas de directorio borradas en el directorio raíz del sistema de ficheros.
Klismafile se ejecuta en modo detallado, visualizando y sobrescribiendo cada entrada de directorio que encuentra. Una vez acabado el trabajo de sobrescritura, fls no es capaz de mostrar ninguna entrada eliminada en el fichero de directorio.
Aviso: El núcleo de linux 2.4.x utiliza la técnica de cacheo del fichero de directorios en la memoria, por lo tanto si el intruso no tiene cuidado a la hora de utilizar esta herramienta sus cambios pueden no haberse realizado en la versión física del fichero sino sólo en la memoria (una razón más para desenchufar el equipo y no apagarlo de forma correcta).
fuente:www.loquefaltaba.com
Entradas
No hay comentarios:
Publicar un comentario