Análise forense
Sessão de aprendizagem 5 Recuperação e análise de evidências
Sumário Recuperação e análise de evidências Estrutura do sistema de arquivos Recuperação de arquivos Recuperação de arquivos sobrescritos Recuperação de arquivos journaling
Recuperação e análise de evidências O processo de procurar evidências é cíclico, e o analista deve continuar procurando enquanto necessitar de evidências para comprovar a invasão e encontrar o responsável. As ferramentas vistas até agora são úteis apenas para procurar arquivos que ainda estejam disponíveis no sistema de arquivos. O que fazer, então, quando os arquivos foram apagados?
Recuperação e análise de evidências Invasores costumam apagar seus rastros quando percebem que estão sendo monitorados. É necessário utilizar ferramentas para recuperar arquivos apagados. A principal dificuldade para recuperar arquivos apagados é o fato de que os dados podem ter sido sobrescritos. Versões mais novas de alguns sistemas operacionais utilizam journaling file systems. Estes sistemas de arquivo têm um registro de todas as atividades realizadas no disco.
Estrutura do sistema de arquivos O sistema de arquivos do Linux é conhecido como Extended Filesystem (Ext) Existem dois padrões: Ext2 e Ext3 A principal estrutura do Ext2 é chamada de superblock O bloco de disco é a menor estrutura de armazenamento no sistema de arquivos, utilizado para armazenar o conteúdo dos arquivos O inode é a estrutura que armazena as informações sobre cada arquivo
Estrutura do sistema de arquivos Cada inode armazena diversas informações sobre um arquivo: Identificação do proprietário do arquivo Tipo de arquivo (regular, diretório, dispositivos etc) Permissões de acesso Número de hard links Tamanho do arquivo Tempos de acesso/modificação/status do arquivo Tabela de conteúdo (endereços dos blocos que armazenam os dados do arquivo)
Estrutura do sistema de arquivos
Estrutura do sistema de arquivos Ao apagar um arquivo em um sistema com Ext2, o sistema realiza as seguintes funções: O inode alocado ao arquivo é marcado como livre; Este inode é colocado na lista de inodes livres do superblock
O número de inodes livres é incrementado no superblock Os blocos de disco utilizados pelo arquivo são recolocados na lista de blocos livres O número de blocos livres é incrementado no superblock
Em nenhum momento, o conteúdo dos blocos ou do inode é apagado, o que permite a recuperação de arquivos apagados
Estrutura do sistema de arquivos Ext3 é um sistema de arquivos com journaling, que mantém um registro de todas as operações de leitura e escrita em disco . O problema do Ext3 é que o sistema trata de forma diferente o processo de apagamento de um arquivo: Blocos de disco agrupados em blocos. As tabelas de inodes também são associadas a estes grupos de blocos, e os inodes nestas tabelas são localizados sempre dentro do mesmo grupo. Quando um arquivo é criado, o sistema operacional aloca um inode e blocos para este arquivo dentro do mesmo grupo de blocos do diretório pai. Ao apagar um arquivo em um sistema Ext3, o kernel do Linux zera o tamanho do arquivo e o endereço da lista de blocos no inode.
Recuperação de arquivos Para recuperar arquivos, precisamos descobrir em qual inode o arquivo procurado estava armazenado Se não for possível descobrir o inode, talvez possamos recuperar apenas parte do arquivo Podemos utilizar ferramentas para analisar o disco e encontrar as informações necessárias sobre os arquivos apagados Em último caso, podemos utilizar ferramentas como grep e strings para descobrir onde a informação procurada está armazenada
Recuperação de arquivos Para recuperar um arquivo que não tenha sido sobrescrito, o procedimento é o seguinte: Encontre o inode onde o arquivo estava armazenado: fls –adpr /data/compromised/compromised_hda1.img
Descubra mais informações sobre o arquivo: istat /data/compromised/compromised_hda1.img 47147
Encontre o nome original do arquivo: ffind -a /data/compromised/compromised_hda1.img 47147
Recupere o arquivo armazenado no inode encontrado: icat /data/compromised/compromised_hda1.img 47147 > /data/compromised/s.tgz
Recuperação de arquivos sobrescritos Para recuperar arquivos que tenham sido sobrescritos, o procedimento é diferente: Para facilitar, precisamos extrair do disco todos os blocos não alocados para nenhum arquivo: # dls –f linux-ext2 /data/compromised/compromised_hda1.img > /data/compromised/compromised_hda1.img.dls
Descubra em que posição no arquivo está localizada a informação que procura: # grep –ab "rm -rf" /data/compromised/compromised_hda1.img.dls
Recuperação de arquivos sobrescritos Agora, descubra onde essa informação está localizada no disco original: # echo $((66511837/4096)) 16238 # dcalc –u 16238 /data/compromised/compromised_hda1.img 39342
Caso o bloco não esteja alocado por nenhum inode, recupere os blocos de dados que conseguir: # ifind –a –d 39342 /data/compromised/compromised_hda1.img Inode not found
Recuperação de arquivos sobrescritos Ao examinar o conteúdo do bloco, vemos que ele é parte de um arquivo TAR. Para tentar recuperar este arquivo, podemos recuperar bloco por bloco do disco até montar o arquivo completo. Primeiro, vamos analisar diversos blocos ao redor do bloco que achamos, para descobrir onde o arquivo termina: # dcat -f linux-ext2 /data/compromised/compromised_hda1.img 39341 1000
Procuramos por um texto que esteja próximo do fim do arquivo: # grep -ab './udhss -f ./s' /data/compromised/compromised_hda1.img.dls
Recuperação de arquivos sobrescritos Encontramos o bloco de disco que armazena esta informação e o número de blocos que devemos recuperar: # dcalc -u 16839 /data/compromised/compromised_hda1.img # echo $((39943-39341)) 602
Finalmente, recuperamos os blocos do arquivo: # dcat -f linux-ext2 /data/compromised/compromised_hda1.img 39341 602 > /data/compromised/recovered.tar
Recuperação de arquivos sobrescritos # tar tvf /data/compromised/recovered.tar tar: This does not look like a tar archive tar: Skipping to next header -rwxr-xr-x hack3r/hack3r 190 2001-04-15 14:56:20 rootkit/scan/.. /xdr -rwxr-xr-x hack3r/hack3r 840 2001-04-15 14:55:58 rootkit/scan/.. /rdx -rw-r--r-- hack3r/hack3r 7108 2000-04-08 18:38:47 rootkit/scan/.. /cl.sh ... -rw------- hack3r/hack3r 307200 2001-08-03 09:41:20 rootkit/core ... -rw-r--r-- hack3r/hack3r 64 2001-11-24 10:34:07 rootkit/ess-0.8.6/install -rwxr-xr-x hack3r/hack3r 624753 2001-11-24 10:17:54 rootkit/udhss tar: Skipping to next header -rwxr-xr-x hack3r/hack3r 158 2001-11-24 16:59:35 rootkit/rula tar: Error exit delayed from previous errors
Recuperação de arquivos journaling No Ext3, o processo para recuperar arquivos é mais difícil e muitas vezes não podemos recuperar totalmente o arquivo: A lista de blocos que apontam para o conteúdo dos arquivos é zerada quando o arquivo é removido. Vamos conhecer uma técnica para recuperar um arquivo em um sistema de arquivos Ext3. Para isso, vamos utilizar as informações gravadas no journaling do sistema de arquivos para recuperar as informações que foram apagadas do inode original.
Recuperação de arquivos journaling Quando é feita qualquer atualização no sistema de arquivos, o journaling guarda uma cópia completa do inode modificado no journal Como não queremos prejudicar nenhuma evidência na imagem que estamos utilizando, vamos realizar os exercícios a seguir no disco da máquina virtual de nossa estação forense Para isso, vamos criar um arquivo, apagá-lo do disco, e tentar recuperá-lo utilizando as informações do journal
Recuperação de arquivos journaling Criar o arquivo de exemplo e coletar informações: # gzip -9 -c /data/compromised/compressed.files > /data/compromised/test.gz # ls -li /data/compromised/test.gz 937288 -rw-r--r-- 1 root root 5252 Jan 17 12:06 /data/compromised/test.gz # istat /dev/sda5 937288 inode: 937288 Allocated Group: 58 Generation Id: 1159893987 uid / gid: 0 / 0 mode: -rw-r--r-size: 5252 num of links: 1 Inode Times: Accessed: Thu Jan 17 12:06:12 2008 File Modified: Thu Jan 17 12:06:13 2008 Inode Modified: Thu Jan 17 12:06:13 2008 Direct Blocks: 262651 262652
Recuperação de arquivos journaling Com istat descobrimos as datas de modificação e criação e os blocos onde o arquivo está armazenado: # rm -f /data/compromised/test.gz # ls -li /data/compromised/*.gz ls: /data/compromised/*.gz: No such file or directory # istat /dev/sda5 937288 inode: 937288 Not Allocated Group: 58 Generation Id: 1159893987 uid / gid: 0 / 0 mode: -rw-r--r-size: 0 num of links: 0 Inode Times: Accessed: Thu Jan 17 12:06:12 2008 File Modified: Thu Jan 17 12:09:54 2008 Inode Modified: Thu Jan 17 12:09:54 2008 Deleted: Thu Jan 17 12:09:54 2008 Direct Blocks:
Recuperação de arquivos journaling Utilizar as informações presentes no journal do sistema de arquivos para tentar recuperar a lista de blocos original do inode. Quando o arquivo foi removido, uma cópia do inode original foi copiada para o journal antes que as informações fossem zeradas. Se conseguirmos recuperar essa informação, poderemos recuperar o arquivo original. Ferramenta debugfs permite acessar o sistema de arquivos diretamente.
Recuperação de arquivos journaling # debugfs /dev/sda5 debugfs 1.39-WIP (10-Dec-2005) debugfs: logdump -i <937288> Inode 937288 is at group 58, block 1900546, offset 896 Journal starts at block 1, transaction 116 … FS block 1900546 logged at sequence 1143, journal block 6560 (inode block for inode 937288): Inode: 937288 Type: regular Mode: 0644 Flags: 0x0 User: 0 Group: 0 Size: 5252 … ctime: 0x478fa725 -- Thu Jan 17 12:06:13 2008 atime: 0x478fa724 -- Thu Jan 17 12:06:12 2008 mtime: 0x478fa725 -- Thu Jan 17 12:06:13 2008 Blocks: (0+2): 262651 FS block 1900546 logged at sequence 1145, journal block 6570 (inode block for inode 937288): Inode: 937288 Type: regular Mode: 0644 Flags: 0x0 User: 0 Group: 0 Size: 0 … ctime: 0x478fa802 -- Thu Jan 17 12:09:54 2008 atime: 0x478fa724 -- Thu Jan 17 12:06:12 2008 mtime: 0x478fa802 -- Thu Jan 17 12:09:54 2008 dtime: 0x478fa802 -- Thu Jan 17 12:09:54 2008 Blocks: No magic number at block 6578: end of journal.
Generation: 1159893987
Generation: 1159893987
Recuperação de arquivos journaling Utilizar comandos para recuperar os blocos de dados: # dcat /dev/sda5 262651 2 > /tmp/recover.gz # file /tmp/recover.gz /tmp/recover.gz: gzip compressed data, was "compressed.files", from Unix, max compression # ls -l /tmp/recover.gz -rw-r--r-- 1 root root 8192 Jan 17 12:26 /tmp/recover.gz
Recuperação de arquivos journaling O arquivo recuperado contém 8192 bytes e não o tamanho original de 5252 bytes O arquivo original pode ser recuperado com dd: # dd if=/tmp/recover.gz of=/tmp/test_recovered.gz bs=1 count=5252 5252+0 records in 5252+0 records out 5252 bytes (5.3 kB) copied, 0.034853 seconds, 151 kB/s # gzip -l -t /tmp/test_recovered.gz compressed uncompressed ratio uncompressed_name 5252 18067 71.1% /tmp/test_recovered
Conclusões Algumas vezes não é possível encontrar no disco as evidências necessárias para comprovar o caso de invasão As evidências podem ter sido apagadas ou sobrescritas Mesmo assim, existem ferramentas para recuperar estes dados Aprendemos também um pouco mais sobre a estrutura dos sistemas de arquivos do Linux, e também como recuperar arquivos em um sistema com journaling como o Ext3