O investigador que realizar a coleta de evidências digitais deve assegurar que as informações obtidas existem no computador suspeito e não foram alteradas durante a análise. Tratando-se de uma evidência digital, mantê-la íntegra é complicado devido ao seu alto grau de volatilidade, e um simples ato de ligar ou desligar o computador pode alterar ou destruir evidências.
É muito importante que os investigadores sigam procedimentos usados em uma análise forense, que devem ser coerentes com um conjunto de princípios legais e técnicos. Alguns desses princípios são:
• As ações do investigador não devem alterar as evidências;
• A evidência original deve ser preservada no estado mais próximo possível daquele em que foi encontrada;
• Todas as evidências digitais coletadas e as cópias produzidas devem ser autenticados por meio de hash criptográfico, para verificar sua integridade;
• O investigador não deve confiar nos programas e nem nas bibliotecas dinâmicas do sistema suspeito;
• Fazer uma imagem(cópia exata) da evidência original sempre que possível, para preservar a integridade deste;
• A cópia dos dados que serão examinados devem ser feitas para uma mídia “esterelizada”e sem defeitos;
• Toda evidência deve ser apropriadamente etiquetada, contendo por exemplo o nome do caso investigado, data e hora da coleta, entre outros;
• Todas as informações relativas à investigação devem ser documentadas;
• As ferramentas utilizadas na investigação devem ser aceitas pelos especialistas forenses e testadas para garantir sua operação correta e confiável.
1) Situação inicial do sistema
O investigador forense ao ser chamado para fazer uma análise, pode encontrar o computador ligado ou desligado. Caso o encontre desligado, ele irá fazer a imagem do disco da vítima e uma copia da imagem para começará a trabalhar em cima desta.
Dessa forma o investigador sempre que precisar, poderá fazer uma cópia da imagem criada, evitando assim que o original seja utilizado, podendo preservar de forma mais segura as evidências.
Já em uma situação que o sistema está ligado, é possível coletar dados voláteis como, processos em execução, conexões abertas, podendo conter informações relevantes à investigação. No entanto, a coleta dos dados voláteis deve respeitar a sua ordem de volatilidade, pois o tempo de vida de uma evidência digital varia de acordo com o local onde ela está armazenada.
A ordem de volatilidade segue abaixo:
• dispositivo de armazenagem do processador (registradores e caches);
• memória de periféricos (impressora, vídeo, por exemplo);
• memória principal do sistema;
• tráfego de rede;
• estado do sistema operacional (como por exemplo, estado dos processos e das conexões de redes, configurações do sistema);
• dispositivo de armazenagem secundária (disco rígido, CD-ROM, por exemplo)
As seções seguintes explicam como realizar esta coleta obecedendo a ordem descrita.
2) Dispositivos de armazenagem do processador
O simples ato de observar informações nos registradores do processador já pode alterá-las. Por isso tornam-se de mínima utilidade e sua captura é impraticável, assim como os dados em caches.
3) Memória de periféricos
Alguns periféricos como impressora e vídeo possuem suas próprias memórias.
Nelas podem estar armazenadas informações que não existam mais no sistema suspeito.
O comando xwd permite capturar informações da memória(dump) de vídeo, por exemplo. Numa situação em que o invasor utiliza um terminal ou console gráfico, o investigador pode capturar a tela corrente do invasor com o xwd.
Supondo que o invasor esteja na estação 192.168.0.1, pode-se capturar a sua tela assim:
#xwd -display 192.168.0.1:0 -root > terminal_invasor.xwd
A opção -display 192.168.0.1:0 serve para identificar o computador e o número do terminal gráfico da tela. Já o parâmetro -root especifica que tela inteira deve ser capturada.
O arquivo que contém a tela capturada (terminal_invasor.xwd) pode ser visualizado através do utilitário xwud:
#xwud -in terminal_invasor.xwd
4) Memória principal
A memória principal contém diversas informações voláteis do sistema, como por exemplo, dados sobre os processos que estão em execução, dados que ainda estão sendo manipulados e não foram gravados no disco rígido. Tais informações podem ser obtidas por meio de:
• Dumps da memória;
• Geração de core files;
• Diretório /proc
• Dump da memória
Dump da memória é nome do processo de capturar as informações da memória, e pode ser feito através do comando dd:
#dd < /dev/mem > mem.dump
#dd < /dev/kmem > kmem.dump
Sabendo que o sistema operacional GNU/Linux é trata tudo como arquivo, a própria memória principal do sistema e a memória virtual do kernel, são acessadas através dos arquivos /dev/mem e /dev/kmem respectivamente.
Ao fazer o dump, o investigador pode realizar buscas por palavras-chave através dos comandos grep e strings a fim de encontrar alguma evidência relevante.
#strings -a mem.dump | grep palavra-chave
No exemplo acima, o comando strings retorna todo conteúdo de texto do arquivo mem.dump e o grep filtra este resultado exibindo somente as palavras que contenham a string ‘palavra-chave’.
• Geração de core files
Core file ou core dump são arquivos que contêm a cópia exata da memória ocupada pelo processo quando este é terminado pelo sistema. Tais arquivos só são criados quando o processo recebe sinais cuja ação é terminar o processo e gerar o core dump como o SIGQUIT, SIGSEGV, entre outros.
Através do comando kill, por exemplo, é possível gerar um core file já que ele é responsável pelo envio de sinais a um processo.
Supondo que o processo script.sh esteja em execução com o número de identificação(PID) 4688:
#kill -s SIGSEGV 4688
O parâmetro -s especifica que o sinal a ser enviado é o SIGSEGV para o processo 4688, que será finalizado e um arquivo com nome “core”será criado. Para confirmar ou descobrir o sinal e o processo relacionado a este core file, pode utilizar-se do comando file:
#file core
core: ELF 32-bit LSB core file (signal 11), Intel 80386, version 1 (SYSV), from ’script.sh’
No exemplo anterior, o core file originou-se do processo script.sh que recebeu o sinal 11, o SIGSEGV
continua…
Deixe uma resposta.