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 inodeoriginal 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 Generation: 1159893987

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 Generation: 1159893987

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.

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