Saiba Como Um Perito Trabalha Após Um Ataque

Computação Forense Parte II

Saiba como um perito trabalha após um ataque

A partir deste artigo, serão mostradas, na prática, as técnicas, ferramentas e metodologias empregadas na realização de análise forense. Neste artigo, mais especificamente na segunda parte, estaremos acompanhando o trabalho de um perito para analisar os traços deixados após um ataque a um sistema Linux. Trata-se de um caso real e, por motivos óbvios, algumas informações serão omitidas para preservar a vítima (endereços IP, por exemplo, não serão revelados).

O trabalho pericial baseou-se nas informações obtidas por arquivos de logs de um sniffer (poderia ser um IDS qualquer), registros de logins, informações temporais relacionadas aos arquivos do sistema e conteúdos dos sistemas de arquivos dos diversos computadores envolvidos no incidente. Estas diversas fontes de informações apresentam um cenário ideal para análise.

É fundamental, portanto, que os administradores implementem uma infra-estrutura de segurança capaz de oferecer subsídios para uma análise forense mais acurada e uma resposta a incidentes mais efetiva. Os diversos componentes de segurança devem gerar logs e armazená-los em repositórios protegidos contra escrita. Um sistema de detecção de intrusão pode ser usado para detectar ataques bem sucedidos em tempo real, eliminando o progresso de um ataque e oferecendo recursos valiosos para uma resposta a incidentes mais adequada.

Ferramentas Usadas

As ferramentas usadas pelo perito forense foram um sistema Linux confiável (pode-se garantir que não houve atividade intrusiva na máquina nem binários do sistema foram alterados), com o Coroner´s toolkit (TCT) instalado. Obviamente, leitores mais experientes em computação forense já ouviram falar, ou usaram, outras ferramentas de acordo com as suas necessidades.

Não há interesse em apresentar uma lista exaustiva de todas estas ferramentas. Entretanto, uma ferramenta que merece, e deve, ser destacada é o TASK. O TASK é um conjunto de ferramentas Open Source para análise de sistemas de arquivos Unix e Microsoft (FAT 12, FAT 16 e FAT 32). O suporte ao NTFS e PalmOS será incorporado futuramente. Além disto, ele conta com a ferramenta Autopsy para apresentação gráfica dos resultados, em HTML. É uma ferramenta bastante poderosa, com diversas características interessantes, possibilitando a criação de um sistema Linux dedicado à análise forense dos mais variados sistemas operacionais.

Criando uma imagem do objeto a ser analisado

Para evitar que provas sejam destruídas ou alteradas, a investigação de um perito forense deve ser executada usando uma cópia idêntica do sistema vítima. Caso ocorra alteração acidental, novas cópias podem ser feitas sem provocar maiores prejuízos. As partições, incluindo a partição de swap, devem ser copiadas bit a bit. Opcionalmente, pode-se gerar um hashing da imagem, usando MD5 ou similar, para garantir que a análise não seja feita usando uma cópia corrompida ou alterada. Esta cópia binária pode ser feita com o utilitário dd do Linux.

Exemplo:

Montando a partição do sistema de análise, que receberá a imagem do sistema vítima:

# mount -t ext2 /dev/hdb1 /mnt

Copiando a partição para o arquivo hdal.dd, usando o comando dd:

# /floppy/dd if= /dev/hda1 of=/mnt/hda1.dd

Calculando hashing, usando MD5:

# md5sum /mnt/hda1.dd > /mnt/checksum.hda1.dd

No exemplo acima, não foi usada, por razões óbvias, a cópia do utilitário existente no sistema comprometido. Para esta tarefa, foi usada uma cópia mais confiável, em floppy.

Criando um ambiente de análise

O sistema Linux apresenta algumas características muito interessantes para criação de ambientes de análise. Uma delas é a implementação do suporte de um grande número de tipos de sistemas de arquivos (umsdos, ext2, ext3, vfat são alguns exemplos). Isto permite a criação de ferramentas para a investigação de diversos sistemas operacionais em um mesmo sistema operacional.

Todo arquivo em um sistema, tem um inode associado, que armazena os atributos “MAC” (Modify/Access/Change) Times, mantendo informações de estado do arquivo. O atributo “Modify” mantém informação de quando um determinado arquivo é alterado pela última vez e quando um arquivo é acrescentado/deletado de um diretório. A atualização do atributo “Access” ocorre quando um arquivo é executado/aberto e quando um diretório é acessado. Por fim, a atualização do atributo “Change” ocorre quando as permissões, para um arquivo ou diretório, são modificadas. Em Linux, tais atributos podem ser obtidos usando o utilitário stat (experimente stat ). Os leitores estão convidados a utilizar esse utilitário e verificar as diversas situações em que os MAC times de um arquivo são alterados.

Uma outra importante característica de sistemas Linux, para finalidade de análise forense, é a implementação de um recurso conhecido como loopback devices, que permite a montagem e acesso de todas as partições de um disco, evitando que as informações de estados refletidas, nestes atributos, sejam alteradas durante análise. Vale lembrar que a cena do crime deve ser preservada para evitar que provas sejam acidentalmente perdidas. Muitas evidências importantes podem ser obtidas dos inodes de um sistema comprometido. É, portanto, indesejável que um perito altere os MAC times dos arquivos, por exemplo, durante uma análise. Usando este recurso, todavia, toda partição é montada como um arquivo especial e acessada sem modificar as informações nas tabelas internas do sistema de arquivos.

O trabalho é bem simples: deve-se fazer uma cópia bit a bit (dd) do objeto a ser investigado para o ambiente de análise, e montar somente para leitura (assegurar a integridade dos dados) o arquivo resultante, usando loopback devices. No exemplo abaixo, está sendo montada a imagem da partição c0t3d0s0 (c0t3d0s0.dd), recuperada em uma máquina Sun SPARC comprometida, no diretório /t da máquina de análise.

# mount -o ro,loop,ufstype=sun -t ufs c0t3d0s0.dd /t

Os arquivos podem ser acessados normalmente no diretório /t, sem alterar os MAC times nos inodes do sistema comprometido. Abaixo, o analista foi capaz de verificar a organização das partições no disco da máquina comprometida, onde a partição c0t3d0s0 é a partição root do