faro: ferramenta para análise forense … › theses › ferramenta_para_analise...forense...

Universidade Federal do Rio Grande do NorteCentro de Tecnologia

Curso de Engenharia de Computação

FARO: Ferramenta para Análise Forense Computacional em Sistemas Linux Vivos

Arthur Diego de Lira LimaOrientador: Prof. D.Sc. Sergio Vianna Fialho

Natal2009


Arthur Diego de Lira LimaOrientador: Prof. D.Sc. Sergio Vianna Fialho

Trabalho de Conclusão de Curso apresentado ao Curso de Engenharia de Computação do Centro de Tecnologia da Universidade Federal do Rio Grande do Norte, como requisito parcial para obtenção do título de Engenheiro de Computação.

Natal2009

Divisão de Serviços TécnicosCatalogação da Publicação na Fonte / Biblioteca Central Zila Mamede

Lima, Arthur Diego de Lira. Faro : ferramenta para análise forense computacional em sistemas Linux vivos / Arthur Diego de Lira Lima. – Natal, 2009. 53 p. : il. Orientador: Sergio Vianna Fialho. Monografia (Graduação) – Universidade Federal do Rio Grande do Norte. Centro de Tecnologia. Curso de Engenharia de Computação. 1. Forense computacional. 2. Sistemas vivos. 3. Linux (Sistema Operacional de computador). 4. Forense digital. I. Fialho, Sergio Vianna. II. Universidade Federal do Rio Grande do Norte. III. Título.

RN/UF/BCZM CDU 004.056


Arthur Diego de Lira Lima

Trabalho de Conclusão de Curso apresentado ao Curso de Engenharia de Computação do Centro de Tecnologia da Universidade Federal do Rio Grande do Norte, como requisito parcial para obtenção do título de Engenheiro de Computação.

Aprovado por:

Banca examinadora:

Prof. D.Sc. Sergio Vianna Fialho (UFRN)(Presidente)

Prof. D.Sc. Edson Moreira Silva Neto (UFRN)

Mário Sérgio de Araújo Silva (PoP-RN)

Natal2009

iii

A Oiran, cuja luta por um mundo mais livre não será esquecida.

iv

Agradecimentos

Agradeço ao Prof. Sergio Vianna Fialho, pela atenção e grande orientação. Sem dúvida, um extraordinário professor.

Aos membros da banca examinadora, pela contribuição na melhoria deste trabalho.

Aos familiares, pelo apoio irrestrito.

Aos estagiários e funcionários do PoP-RN, pela força.

Aos colegas de curso, que tanto ajudaram ao longo desses anos.

v

Resumo

Este trabalho apresenta o FARO, uma ferramenta desenvolvida no PoP-RN para análise forense computacional, baseada no modelo cliente-servidor, para investigação de máquinas em funcionamento (vivas) que utilizam o sistema operacional Linux. O objetivo do FARO é facilitar e automatizar a coleta de dados mais voláteis, armazenados na memória principal, tais como: usuários conectados, configurações de rede, serviços ativos, processos em execução e módulos de kernel carregados. Dessa forma, evidências mais voláteis podem ser coletadas, complementando a utilização das ferramentas voltadas apenas para a análise morta (off-line). A análise viva, além de ampliar o universo de obtenção de evidências, pode ser a única alternativa em certos casos, como, por exemplo, quando os discos rígidos estão criptografados. Outra funcionalidade presente é a coleta automática de evidências e envio à estação forense. Adicionalmente, o FARO possibilita que ferramentas seguras disponíveis na estação forense possam ser utilizadas, de forma transparente, na máquina investigada. A eficácia da ferramenta foi avaliada a partir de testes realizados na investigação de um computador comprometido com o rootkit ARK.

vi

SumárioAgradecimentos....................................................................................................................................vResumo................................................................................................................................................viÍndice de Figuras...............................................................................................................................viiiÍndice de Tabelas.................................................................................................................................ix1 – Introdução.......................................................................................................................................12 – Análise Forense Computacional.....................................................................................................3

2.1 - O que é a forense computacional?...........................................................................................32.2 - Metodologia de invasão de sistemas.......................................................................................7

2.2.1 - Rootkits............................................................................................................................92.3 - Coleta de evidências..............................................................................................................102.4 - Ocultamento de evidências e rotinas anti-forense.................................................................13

3 – Principais ferramentas existentes para análise forense computacional........................................163.1 – The Coroner's Toolkit...........................................................................................................16

3.1.1 - Grave-robber..................................................................................................................163.1.2 – Mactime........................................................................................................................203.1.3 - Unrm & Lazarus............................................................................................................20

3.2 – The Sleuth Kit.......................................................................................................................213.2.1 - Camadas do The Sleuth Kit ..........................................................................................22

3.3 – Autopsy Forensic Browser....................................................................................................233.4 - EnCase...................................................................................................................................253.5 – Comentários..........................................................................................................................26

4 – Especificação e Desenvolvimento do FARO................................................................................284.1 – Especificação........................................................................................................................28

4.1.1– Diagrama de casos de uso..............................................................................................284.1.2 – Descrição dos casos de uso...........................................................................................29

4.2 – Implementação......................................................................................................................384.2.1 – Servidor FARO..............................................................................................................384.2.1 – Cliente FARO................................................................................................................39

5 – Testes e Resultados.......................................................................................................................425.1 – Identificação de arquivos escondidos pelo ARK..................................................................435.2 – Listagem de conexões de redes ocultas................................................................................455.3 – Geração e envio de relatório de modificação do utilitários do sistema................................475.4 – Análise de evidências na imagem da memória principal......................................................48

6 – Conclusões....................................................................................................................................506.1 – Trabalhos Futuros.................................................................................................................51

7 – Referências Bibliográficas............................................................................................................52

vii

Índice de Figuras

Figura 2.1: Utilização do programa "nmap" para obter informações sobre uma máquina alvo...........8Figura 3.1: Arquivos criados pelo “grave-robber”.............................................................................17Figura 3.2: Trecho do arquivo "body", o banco de dados de "MAC Times" criado pelo "grave-robber"................................................................................................................................................19Figura 3.3: Criação de um "caso" no "Autopsy Forensic Browser"...................................................24Figura 3.4: Visão geral do Autopsy Forensic Browser.......................................................................25Figura 3.5: Fragmento da interface gráfica do EnCase......................................................................25Figura 3.6: Cabeçalho do arquivo de caso do EnCase.......................................................................26Figura 4.1: Diagrama de casos de uso do FARO................................................................................28Figura 4.2: Comparação entre o utilitário “ls” compilado estático e dinamicamente........................39Figura 4.3: Fluxograma da execução de ferramentas remotas pelo cliente FARO............................40Figura 4.4: Apresentação na tela do relatório do estado dos utilitários do sistema, ordenado por data de modificação....................................................................................................................................41Figura 5.1: Configurando o ARK para ocultar arquivos....................................................................43Figura 5.3: Preenchendo o comando remoto que será executado.......................................................44Figura 5.2: Menu principal do cliente FARO.....................................................................................44Figura 5.4: Preenchendo o endereço IP do servidor FARO................................................................44Figura 5.5: Resultado do “ls” seguro..................................................................................................44Figura 5.6: Configurando o ARK para ocultar serviços ativos e conexões de rede...........................45Figura 5.7: Opção “Exibir o estado das conexões de rede ativas”, do menu principal......................46Figura 5.8: Opções para o gerenciamento das conexões de rede.......................................................46Figura 5.9: O FARO mostrou corretamente as conexões de rede que foram ocultadas pelo ARK....46Figura 5.10: Opção “Analisar os utilitários do sistema e enviar o relatório ao servidor”..................47Figura 5.11: Relatório listando os últimos utilitários do sistema que foram modificados.................48Figura 5.12: Opção “Capturar a imagem da memória e enviar ao servidor”.....................................49Figura 5.13: Busca por palavra-chave na memória principal.............................................................49

viii

Índice de Tabelas

Tabela 2.1: Expectativa de vida de dados de acordo com a mídia de armazenamento........................5Tabela 4.1: Relação entre as funcionalidades do servidor FARO e as portas de comunicação utilizadas.............................................................................................................................................39Tabela 5.1: Descrição dos utilitários modificados pelo ARK.............................................................42Tabela 5.2: Relação entre as informações filtradas, arquivos de configuração e os utilitários afetados do ARK...............................................................................................................................................42

ix

1 – Introdução

A forense computacional é a área da ciência relacionada com a investigação da origem

de incidentes de segurança computacional. Uma das grandes dificuldades encontradas é a

coleta das evidências dos incidentes. Quanto mais detalhada for a investigação, mais provável

é modificar indevidamente as evidências. Por essa razão, os procedimentos tradicionais se

realizam com o sistema desligado (também chamado de sistema morto). Entretanto, a

investigação com o sistema em funcionamento (sistema vivo) é realizada com a finalidades de

coletar duas classes principais de evidências: as contidas na memória principal e aquelas

armazenadas em discos rígidos que se suspeita estar criptografados.

A constatação que não havia, no âmbito da RNP, soluções que possibilitassem a

investigação de computadores supostamente comprometidos e cujo desligamento era

indesejável motivou o desenvolvimento de uma ferramenta que suprisse essa necessidade. Os

principais objetivos dessa ferramenta, idealizada no PoP-RN, e que foram incorporados a esse

trabalho são:

• Permitir que utilitários disponíveis em uma máquina segura possam ser utilizados de

forma transparente em uma máquina investigada;

• Coletar evidências em um máquina investigada e enviá-las a uma máquina segura,

assegurando a integridade dos dados; e

• Consultar na tela evidências encontradas na máquina investigada.

Esse trabalho se encontra organizado da seguinte forma: o Capítulo 2 apresenta a

forense computacional, sua definição, a diferença entre as abordagens judiciais e corporativas,

a preservação do ambiente investigado, o processo de coleta de evidências, e em que ordem

isso deve ocorrer (a ordem de volatilidade), as dificuldades enfrentadas e as ferramentas e

metodologias empregadas na invasão de sistemas computacionais. No Capítulo 3 são

avaliadas algumas das principais ferramentas utilizadas na forense computacional. São

discutidas algumas funcionalidades presentes, bem como seus problemas. No Capítulo 4 se

apresenta inicialmente a modelagem da ferramente, onde são especificados os casos de uso e

1

os diagramas de casos de uso. Em seguida se descreve a implementação do FARO. O Capítulo

5 apresenta os testes realizados com o FARO é testado em um sistema comprometido com o

rootkit ARK. Finalmente, o Capítulo 6 apresenta as conclusões deste trabalho e se sugerem

alguns trabalhos futuros.

2

2 – Análise Forense Computacional

2.1 - O que é a forense computacional?

Nos últimos anos tem-se registrado um aumento significativo de crimes relacionados

com computadores, principalmente entre aqueles conectados à Internet. Esses crimes podem,

segundo [Graycar 2001], ser classificados em três categorias. A primeira compreende o uso de

computadores para crimes convencionais, por exemplo: fraude e extorsão. A segunda usa

ferramentas tecnológicas legítimas, como é o caso da criptografia, mas com finalidade

criminosa. Finalmente, a terceira engloba os crimes cometidos contra a tecnologia e seus

usuários, tais como invasão de sistemas e disseminação de programas maliciosos.

Quanto aos papéis que o computador pode desempenhar em um crime, [DEFG 2009]

os agrupa em três tipos, desempenhados isolada ou conjuntamente. Ele pode ser o alvo do

crime, como um servidor de rede conectado à Internet, que pode ser invadido e ter suas

informações armazenadas roubadas ou mesmo destruídas. Ao ser comprometido, ele pode se

tornar um instrumento de novos crimes, conforme passa a ser controlado remotamente para

atividades indevidas, dentre os quais invasão, spam e ataques de negação de serviço. O

computador comprometido pode, ainda, servir como um depósito de provas de crimes, por

exemplo ao armazenar pornografia infantil, dados de cartões de créditos roubados e

ferramentas para invasão de sistemas.

No Brasil, a forense computacional não é regulamentada por normas específicas. O

que existe são regras gerais, constantes no Código de Processo Penal, que se aplicam a todos

os tipos de perícia. Dentre essas regras, indispensáveis para garantir o valor judicial das

provas eletrônicas, podem ser citadas a necessidade de, sempre que possível, se realizar

cópias assinadas digitalmente e se documentar as ferramentas utilizadas para fazer a análise.

No caso de perícias criminais, o profissional responsável pela investigação, denominado de

Perito Oficial, deve possuir curso superior e prestar concurso público para o cargo. Existe,

ainda, o perito ad hoc, um especialista contratado pelas partes, em casos cíveis, ou designado

por magistrados ou delegados de polícia em perícias criminais, quando não há Perito Oficial

disponível [Barros 2009].

3

A forense computacional consiste na utilização de métodos científicos para coletar,

restaurar, preservar, analisar e apresentar evidências que foram processadas eletronicamente e

armazenadas em meios computacionais [Noblett 2000]. Seu objetivo é inferir conclusões

sobre uma atividade indevida, podendo ser realizada em processos judiciais ou em ambientes

corporativos, quando se deseja identificar a origem de incidentes e formas de preveni-los

futuramente.

A finalidade da investigação, se judicial ou corporativa, influencia significativamente

nos procedimentos adotados. Quanto mais se extrai informação de um sistema, maior a

probabilidade de que modificações indevidas ocorram. Em um caso judicial, deve-se

preservar ao máximo o sistema investigado, o que pode limitar a coleta de evidências. Já em

uma perícia estritamente corporativa, a preocupação maior é com a obtenção de informações,

ainda que isso signifique a adoção de processos mais intrusivos. Verifica-se um paradoxo: a

maior compreensão do ocorrido, através da coleta mais extensa de informações do sistema,

pode introduzir modificações indevidas e tornar a investigação judicialmente questionável.

Um princípio fundamental na ciência forense é o Princípio da Troca de Locard. Esse

princípio enuncia que “qualquer um, ou qualquer coisa, que entra em um local de crime leva

consigo algo do local e deixa alguma coisa para trás quando parte” [Casey 2004]. Numa cena

de crime “tradicional", as evidências deixadas podem ser: impressões digitais, material

orgânico contendo DNA, dentre outras. Da mesma forma, nos crimes cibernéticos também

são deixados rastros, como, por exemplo, logs de acesso.

Para se elucidar esses crimes computacionais, são utilizadas as técnicas da forense

computacional, tendo como objetivo coletar, extrair e analisar informações das evidências

recuperadas nesses sistemas computacionais comprometidos. Pode-se perceber que, ao

contrário das demais áreas da computação, onde a prioridade é a velocidade, na forense

computacional a prioridade é a exatidão e a integridade das evidências.

Os conceitos da ciência forense continuam válidos na forense computacional. Entre

eles podemos citar a necessidade de se "congelar" (isolar) a cena examinada, ou seja, as

4

evidências devem ser coletadas o mais rapidamente possível e sem contaminação

(modificação indevida). O local deve ser documentado fotograficamente, registrando-se a tela

ativa, a traseira do computador (a localização dos fios e cabos), eventuais senhas anotadas nas

proximidades do computador, livros e outros documentos [DEFG 2009]. A história

cronológica da evidência deve ser documentada, no que é conhecido por cadeia de custódia.

Os procedimentos utilizados devem ser auditáveis, possibilitando que um segundo especialista

possa reproduzi-los, obtendo os mesmos resultados [Vacca 2005].

Uma característica importante na forense computacional é a ordem de volatilidade: os

dados devem ser coletados de acordo com a expectativa de vida, inicialmente os mais

voláteis. A razão disso é que é impossível coletar todos os dados armazenados em um sistema

de uma só vez, e também quando um dado é coletado, outro acaba sendo modificado. A

Tabela 1, descrita em [Farmer 2005], sugere uma ordem para coleta de dados.

Nos crimes "tradicionais", não é incomum a tentativa de remover os vestígios

deixados, ou mesmo a destruição casual de evidências ocasionada, por exemplo, pela presença

de policiais ou médicos que chegam a uma cena de crime violento. Analogamente, o mesmo

ocorre com os sistemas computacionais, também sujeitos à destruição proposital de

evidências, como remoção de logs, sobrescrita de arquivos ou encriptação de dados

incriminadores ou, ainda, quando um administrador de sistemas toma, inadvertidamente,

atitudes para solucionar um incidente de segurança, e causa a destruição de evidências

críticas.

Mídia Expectativa de vida

Registradores, memória de

dispositivos, periféricos, caches

nanosegundos

Memória principal nanosegundos

Estados de rede milisegundos

Processos em execução segundos

Discos minutos

Mídia de backup anos

CD-ROMs, impressões décadas

Tabela 2.1: Expectativa de vida de dados de acordo com a mídia de

armazenamento.

5

Essas situações de perturbação da cena do crime são razoavelmente comuns [Malin

2008] e são chamadas de dinâmica de evidência. A dinâmica de evidência é qualquer

influência que altera, muda de lugar, atrapalha ou remove uma evidência, independente da

intenção. A dinâmica de evidência é uma preocupação particular em incidentes

computacionais, uma vez que há evidências críticas na memória, que se perdem caso não

sejam preservadas rápida e corretamente.

Verificado que o sistema está ligado, existem três abordagens para a análise de um

computador investigado: desligar abruptamente, desligar administrativamente ou mantê-lo em

funcionamento. A adoção de qual metodologia é um dos assuntos mais controversos da

forense computacional. Os defensores do desligamento argumentam que a garantia da

integridade das evidências em disco compensa a perda daquelas em memória. Por outro lado,

aqueles que defendem a análise viva acreditam que o risco de perda de evidências em um

sistema em funcionamento é aceitável, diante das evidências que podem ser encontradas na

memória.

O desligamento abrupto (ou violento) é aquele em que o computador é desligado ao se

retirar o cabo de força da fonte de alimentação, sendo o mais apropriado quando se suspeita

que programas anti-forenses estejam em execução. Entretanto, nesse método há o risco do

corrompimento de arquivos. O desligamento administrativo (ou elegante) é o tradicionalmente

utilizado na maioria dos sistemas, digitando o comando halt ou clicando em um ícone

específico. A vantagem de se desligar o computador assim é que os discos (ou partições) são

devidamente desmontados e, com isso, os arquivos abertos não serão corrompidos. Entretanto,

os scripts de desligamento podem ativar programas anti-forenses.

Já a análise com o sistema em funcionamento, conhecida como análise viva, permite a

coleta de informações voláteis armazenadas na memória RAM; essencial nos casos em que

evidências estão encriptadas, a análise viva pode ser a única alternativa. Um exemplo dessa

situação ocorre quando discos rígidos criptografados estão montados: se forem desligados

tornam-se inacessíveis, ou pelo menos de acesso extremamente difícil. Como desvantagem, a

probabilidade de ocorrência de alterações indevidas é proporcional à interação do investigador

6

com o sistema, e esse é um motivo pelo qual o processo de coleta de evidências seja o mais

automatizado possível.

A coleta de informações em um sistema vivo, porém, está sujeita a alguns problemas,

tais como dados muito dinâmicos (na memória principal, por exemplo) e as alteração

decorrentes do próprio processo de coleta das evidências. O princípio da incerteza de

Heisenberg, que “o ato da observação afeta o observado” se aplica, analogamente, a esse caso.

Um dos principais problemas da análise viva é que os erros cometidos podem podem ser

irreparáveis, e com isso evidências importantes podem ser perdidas. Além disso, é possível

que programas anti-forenses (ou contra-forenses), que são aqueles dedicados à destruição de

possíveis evidências, estejam agendados ou sejam ativados remotamente pela rede.

Idealmente, uma investigação forense deveria "preservar tudo sem modificar nada".

Entretanto, em muitos casos, como na tradicional análise de DNA, onde ocorrem

modificações do material durante a coleta e a destruição das amostras durante o processo,

verifica-se que a solidez do método não decorre, necessariamente, da manutenção inalterada

da evidência original. Desde que haja uma correta documentação, indicando como a evidência

foi coletada e manipulada, além do emprego de uma metodologia amplamente aceitável pela

comunidade científica, a análise será admitida como legítima.

O mesmo ocorre com a forense computacional em sistemas vivos: ao utilizar qualquer

ferramenta para coleta de evidências, a memória principal será modificada. Ainda continua

válida a necessidade de se alterar o mínimo possível a evidência original, porém a analogia

com a análise de DNA é válida nesse caso: assegurando-se que o processo de coleta das

evidências represente com precisão o dado original e que sua autenticidade e integridade

possam ser validadas, a análise poderá ser considerada forensicamente confiável [Malin

2008].

2.2 - Metodologia de invasão de sistemas

A todo instante são descobertas novas vulnerabilidades que permitem a invasão de

sistemas computacionais. Facilmente, se encontra na Internet ferramentas que exploram essas

7

falhas, o que possibilita que usuários com capacidade técnica limitada comprometam sistemas

importantes. Na invasão desses sistemas é possível verificar uma certa metodologia, ou seja,

existem procedimentos que habitualmente são seguidos, independentemente do sistema

operacional em execução na máquina alvo. Esses procedimentos podem ser classificados em 4

etapas, e sua compreensão é essencial a uma boa investigação.

A primeira etapa é chamada de "reconhecimento ativo". Nessa fase é obtido o máximo

de informações sobre a máquina. Dois programas muito utilizados para essa finalidade são o

Nmap e o Nessus. Eles permitem identificar o sistema operacional e os serviços em execução

na máquina. O Nmap, mostrado na Figura 2.1, além das tradicionais funções de portscan, que

mostra a versão específica do sistema operacional e dos serviços ativos, também identifica

qual é o hardware da máquina (se é um PC, access point, dentre outros), o tempo em que o

sistema está em funcionamento e, até mesmo, é capaz de utilizar técnicas de evasão para

evitar que o firewall da máquina analisada detecte a varredura. Já o Nessus é um scanner de

vulnerabilidades que, adicionalmente às funcionalidades de portscan, mostra ao usuário os

ataques possíveis contra os serviços que estão em execução na máquina alvo.

Após adquirir o máximo de informações sobre o alvo, a etapa seguinte é identificar um

possível ponto de entrada no sistema. O que acontece através da exploração do sistema

operacional ou serviços desatualizados ou mal-configurados, adivinhação de senhas,

8

Figura 2.1: Utilização do programa "nmap" para obter informações sobre uma máquina alvo.

engenharia social, dentre outras técnicas. Uma vez com acesso ao sistema, ocorre a busca por

elevação de privilégios, tendo como objetivo ganhar permissão de acesso ilimitado (como

usuário root). Uma das plataformas de exploração de vulnerabilidades mais importantes

disponíveis atualmente é o Metasploit Framework. Desenvolvido especificamente para testes

de penetração, ele possui um banco de dados com centenas de exploits disponíveis para atacar

o sistema alvo.

Uma vez que o sistema for comprometido e o invasor possuir privilégios ilimitado, dá-

se início à quarta etapa, quando o invasor precisa garantir seu retorno ao sistema da maneira

mais disfarçada possível e, então, remover os vestígios da sua presença. Para garantir esses

objetivos, o invasor costuma utilizar programas maliciosos denominados de rootkits. O

invasor também pode inspecionar os mecanismos de seguranças para assegurar sua

invisibilidade e, além disso, corrigir as vulnerabilidades exploradas, evitando que o sistema

seja comprometido por outra pessoa.

2.2.1 - Rootkits

Rootkits são programas desenvolvidos com o objetivo de encobrir a presença de um

invasor no sistema, evitando que o administrador perceba qualquer tipo de anomalia

decorrente da invasão. Uma vez instalados, os rootkits costumam ocultar os processos

maliciosos, de forma que os utilitários do sistema (como o ps ou o top) não mostrem a sua

execução, esconder os acessos do invasor, bem como garantir a elevação de privilégios,

tornando-se administrador.

Os rootkits de primeira geração, também conhecidos por rootkits de nível de aplicação

ou de modo usuário, substituem os aplicativos essenciais do sistema por aplicativos

infectados, para que não exibam determinados nomes de arquivos, processos, conexões de

rede ou configurações. Já os rootkits de segunda geração, ou de nível de biblioteca, em vez de

modificar os aplicativos do sistema, substituem as bibliotecas críticas (como a libc) por um

wrapper, que “filtra” os dados obtidos pela biblioteca original, antes deles serem retornados

para a aplicação que os solicitou.

9

Na abordagem mais sofisticada, conhecida como de terceira geração ou de nível do

kernel, as modificações são feitas no núcleo do sistema operacional. O Linux dispõe de

módulos de kernel, chamados LKM (Loadable Kernel Modules), carregados em tempo de

execução, para que o kernel não precise ser recompilado sempre que um novo hardware for

utilizado. Essa é justamente a tecnologia mais utilizada pelos rootkits mais sofisticados: em

vez de instalar os wrapper em aplicativos ou em bibliotecas, a filtragem dos dados que serão

escondidos se dá diretamente durante as chamadas ao sistema.

Algumas variações de rootkits de terceira geração instalam os wrapper não através dos

LKM, mas alterando a tabela de chamadas ao sistema na memória do kernel, enquanto ele

está em execução. Outra alternativa é modificar a imagem do kernel em disco (é o que ocorre,

por exemplo, ao recompilá-lo), substituindo-a por uma comprometida. Dessa forma, da

próxima vez que o sistema for iniciado, o rootkit será carregado. Vale notar que, em todos os

casos, as evidências existem no sistema, mas em algum ponto no kernel o dado é filtrado para

remover entradas específicas.

Os métodos para detectar a infecção por rootkits de primeira e segunda geração se

baseiam, de uma maneira geral, em comparar certas informações dos aplicativos e bibliotecas

do sistema com as armazenadas em uma base de dados segura. A detecção, porém, torna-se

significativamente mais complicada com rootkits que atuam no nível do kernel, pois não

existe ainda uma solução definitiva. Algumas ferramentas comparam as entradas na tabela de

chamadas do sistema com o endereço dessas chamadas. Eventuais divergências podem

representar indícios de rootkits, mas também patches legítimos. Assim como a detecção, não

existe um método definitivo de remover um rootkit. O que se costuma fazer para isto é tentar

inverter o processo de infecção, restaurando os aplicativos, bibliotecas e kernel

comprometidos, mas ainda há o risco de restar algum vestígio não identificado.

2.3 - Coleta de evidências

A coleta de evidências, se feita de forma indevida, pode comprometer completamente

a investigação forense. Devido à grande volatilidade dos dados, um ato simples como desligar

10

o computador pode destruir ou modificar evidências. Os procedimentos a serem adotados são

essenciais para garantir que não haja contaminação ou destruição de dados. Na abordagem

mais tradicional, chamada análise morta, o computador é desligado, obtêm-se a imagem do

disco rígido e depois se analisa essa imagem. Já com a análise viva, evidências são coletadas

com o sistema em funcionamento.

Independente do objetivo da investigação forense, alguns princípios para garantir a sua

credibilidade são universais: não se deve modificar as evidências (contaminação, no jargão da

ciência forense), a análise deve ser feita sobre cópias (permitindo a repetição do processo),

garantia de integridade (autenticidade e integridade garantidas por algoritmos de hash como o

MD5 (Message Digest 5) e SHA-1 (Secure Hash Standard), além de, opcionalmente,

armazenar os dados em mídias confiáveis que permitam somente a leitura (como DVD-

ROM), utilizar ferramentas e procedimentos amplamente aceitos pela comunidade científica e

documentar rigorosamente todas as ações tomadas.

Uma restrição importante ao se realizar uma investigação é que não se deve confiar

plenamente no sistema analisado, pois, quando comprometidos, é habitual o invasor instalar

rootkits que substituem ou modificam programas, bibliotecas dinâmicas e mesmo o kernel do

sistema operacional, com o intuito de ocultar certas informações. Por isso, as ferramentas de

coleta de informações devem utilizar programas estaticamente compilados, ou seja,

programas que contém todas as bibliotecas necessárias à sua execução, não dependendo de

bibliotecas dinâmicas (eventualmente comprometidas) para funcionar.

Um dos mecanismos mais utilizados para se assegurar que os dados coletados não

sejam modificados é calcular sua função de hash. Um algoritmo de hash é uma função que só

pode ser utilizada em um sentido, gerando uma “impressão digital” de tamanho fixo, um

identificador único para cada entrada distinta. Se o hash de um dado coletado coincidir com o

do original, pode-se dizer que não houve alterações durante a coleta. Os algoritmos de hash

mais utilizados são o MD5 e o SHA-1, sendo o primeiro mais utilizado e rápido que o último,

apesar de menos seguro.

Apesar do SHA-1 ser mais seguro que o MD5, existem publicações documentando a

11

produção de colisões, isto é, entradas distintas com a mesma “impressão digital”, em ambos.

Essas vulnerabilidades comprometem a utilização desses algoritmos em determinadas

situações, como em alguns mecanismos criptográficos. Por outro lado, pesquisas da

[AccessData 2006] indicam que esses algoritmos ainda são seguros para estabelecer a

integridade das evidências, no caso de uma investigação forense. Preventivamente, pode-se,

ainda, calcular o hash das evidências utilizando ambos os algoritmos, já que nesse caso uma

colisão simultânea é de probabilidade ínfima.

Além de estabelecer a autenticidade da evidência digital, será necessário estabelecer

sua integridade; uma vez que a evidência digital pode ser facilmente alterada, é necessário

precauções especiais para assegurar que não haja modificação durante sua coleta, análise e

armazenamento. O método mais utilizado para garantir a integridade é calcular o hash de cada

evidência antes e depois da sua análise, garantindo que não houveram modificações durante a

análise e a integridade foi mantida.

Certificadas a integridade e a autenticidade das evidências coletadas, toda a análise

deve ser feita sobre as cópias, minimizando qualquer interação com as informações originais.

Por exemplo, na análise morta isso significa que é realizado o espelhamento (cópia bit a bit)

do disco rígido, calculado o hash do original e da imagem, e só então é feita a análise sobre a

cópia. Isso é essencial, não só para evitar modificações indesejáveis, mas também para

possibilitar a repetição do processo, caso haja qualquer questionamento, comum em processo

judiciais.

Já numa análise viva (etapa precedente à análise morta, conforme o princípio da ordem

de volatilidade), devido à natureza dinâmica da memória principal, esse procedimento não

pode ser repetido, pois a memória se modifica continuamente a cada instante (refletindo em

hashes distintos). Entretanto, o que ocorre na análise viva é similar ao que acontece em casos

que envolvem dados coletados na Internet, amplamente aceitos em tribunais. A credibilidade

da análise será assegurada pela reputação do perito, dos procedimentos (se cientificamente

aceitos) e das ferramentas utilizadas (se possuem código-fonte disponível, se são amplamente

utilizadas e outros).

12

2.4 - Ocultamento de evidências e rotinas anti-forense

Existem várias técnicas que podem ser utilizadas para ocultar evidências em um

sistema ou podem, indiretamente, representar uma dificuldade adicional à investigação. É

possível citar a remoção de arquivos, criptografia de dados, a esteganografia, a modificação

do sistema de arquivos, a compactação de arquivos e a mudança de extensão. Elas são

analisadas adiante.

O modo mais intuitivo de se apagar um arquivo é solicitar sua exclusão ao sistema

operacional. Quando isso é feito, ocorre a chamada remoção lógica: o sistema de arquivos

marca como livre a área do disco utilizada pelo arquivo "removido". Ou seja, o sistema não

apaga fisicamente os dados que estão armazenados, apenas desaloca a área para ser utilizada

por outros arquivos. Com isso, caso a área do disco anteriormente utilizada não seja

sobrescrita, os dados continuam normalmente armazenados lá, possibilitando a recuperação

dos arquivos removidos pelo usuário. Essa recuperação de arquivos torna-se ainda mais

simples na medida em que a tecnologia aumenta a capacidade de armazenamento dos discos

rígidos, já que cada vez menos há sobrescrita dos blocos de dados utilizados por arquivos

removidos, ou mesmo há a menor necessidade de se excluir arquivos.

A criptografia é uma das maneiras mais eficientes de se ocultar uma informação,

representando uma importante ferramenta para a segurança de sistemas e mesmo para a

privacidade da comunicação mas, por outro lado, também pode ser utilizada em atividades

criminosas. A criptografia compreende um conjunto de técnicas, com o objetivo de tornar uma

informação incompreensível a qualquer um, exceto a seu destinatário. É um modo eficaz de,

por exemplo, proteger do acesso não-autorizado o disco rígido de computadores portáteis,

mais suscetíveis a roubo. Ou, ainda, pode ser a única forma segura de jornalistas ou ativistas

políticos se comunicarem em países de governos autoritários.

O princípio básico da criptografia é que uma informação original, chamada de texto

simples (que pode ser uma mensagem ou um arquivo), é codificada através de um algoritmo

de encriptação e uma chave secreta, no que resulta um texto cifrado, incompreensível a

terceiros. Para obter o texto original, o algoritmo de decriptação deverá ser aplicado ao texto

13

cifrado, acompanhado da devida chave secreta.

Os dois métodos de criptografia mais comuns são o de chave simétrica e o de chave

assimétrica. Os algoritmos de chave simétrica utilizam a mesma chave secreta para encriptar e

decriptar a mensagem. Já os algoritmos de chave assimétrica, utilizam chaves distintas para

encriptação (chave pública) e decriptação (chave privada).

Descriptografar um arquivo sem o conhecimento prévio da chave pode levar muito

tempo, quando utilizado um bom algoritmo criptográfico e uma boa chave secreta. Para

contornar essa situação são utilizadas técnicas como: ataque de força bruta (testando todas as

chaves possíveis, o que pode levar séculos), ataque de dicionário (usando palavras comuns,

assuntos relacionados aos documentos encontrados na máquina, histórico de navegação,

dentre outros), capturar o que o usuário digita (keylogger), usar um banco de dados contendo

hashes pré-computadas (rainbow tables), ou verificar se a chave secreta não está armazenada

na memória. Técnicas mais avançadas utilizam DNA (Ataque de Rede Distribuído) ou, ainda,

dispositivos dedicados como ASICs (Application-Specific Integrated Circuit) e FPGAs

(Field-Programmable Gate Array), ambos combinados com força bruta ou ataque de

dicionário.

Assim como a criptografia, a compactação de arquivo também altera o conteúdo do

dado de entrada, porém com um propósito diferente. A compactação objetiva reduzir o

tamanho do arquivo de entrada (já a criptografia, aumenta), mas sem o objetivo de ocultar

informações, por isso não utiliza chave secreta. Apesar disso, pode aumentar a complexidade

da forense computacional, por exemplo, ao impossibilitar a busca por string em um arquivo.

A esteganografia é a técnica que permite ocultar informações em arquivos de mídia,

seja de imagem, áudio ou vídeo. Esses dados ficam “camuflados” em arquivos aparentemente

inofensivos, quando, então, são colocadas na web, enviadas por e-mail ou mesmo

armazenadas no próprio disco rígido. Existem muitos algoritmos de esteganografia, alguns

muito eficientes que, principalmente quando utilizados conjuntamente com a criptografia,

dificultam a extração de informações, ou mesmo a possibilidade de detectar que elas estão

ocultas.

14

Em uma análise forense computacional, em que se deseje buscar indícios do uso da

esteganografia, deve-se procurar por arquivos de mídia duplicados (mas com hashes

distintos), programas de esteganografia instalados e utilizar ferramentas específicas que

buscam assinaturas de utilização dessa técnica em arquivos de mídia.

Uma prática primitiva, mas ainda utilizada, para esconder arquivos é renomear sua

extensão, o que evita a sua detecção por software forenses que buscam arquivos dessa

maneira. Um exemplo disso seria renomear uma imagem com extensão “.jpg” para se

assemelhar a um arquivo de configuração (“.conf”). Porém, esses arquivos podem ser

facilmente detectados analisando-se seus cabeçalhos.

Já uma técnica mais complexa é modificar o sistema de arquivos, marcando como

defeituosos (bad blocks) os blocos de dados utilizados pelos arquivos que se deseja ocultar.

Com isso, os arquivos ficarão invisíveis ao sistema operacional e não serão sobrescritos.

Porém, apesar de inacessível numa análise lógica (quando é utilizado o sistema operacional),

as informações escondidas serão reveladas por uma análise física dos disco rígido (ou da sua

imagem bit a bit). Métodos similares utilizam áreas normalmente utilizadas somente pelos

controladores dos discos rígidos para armazenar dados, mas também podem ser descobertos

com as ferramentas apropriadas.

15

3 – Principais ferramentas existentes para análise forense computacional

3.1 – The Coroner's Toolkit

O The Coroner's Toolkit (TCT) é uma coleção de ferramentas utilizadas para coleta de

evidências em sistemas UNIX e afins, mais especificamente: Solaris, FreeBSD, OpenBSD,

SunOS, Linux e BSD/OS. O TCT está disponível gratuitamente, e possui como pré-requisito,

basicamente, que o sistema a ser examinador possua um interpretador da linguagem Perl.

O TCT é composto de 4 módulos principais: grave-robber, unrm & lazarus, mactime,

possíveis de serem utilizados de forma independente, e mais um conjunto de ferramentas

escritas em C e Perl, denominado C Tools que, basicamente, é empregado pelos demais

módulos. A seguir, essas ferramentas são descritas mais detalhadamente.

3.1.1 - Grave-robber

O grave-robber é um arcabouço (framework) encontrado no TCT, responsável pela

coleta de informações no sistema examinado. Ele obedece ao princípio da ordem de

volatilidade e, por isso, inicialmente são coletadas as informações mais efêmeras (dados sobre

processos e conexões de rede), depois ele tenta descobrir informações sobre o hardware e,

finalmente, os arquivos críticos do sistema (arquivos de configuração, logs, dentre outros).

Como muitas dessas informações são restritas, para o pleno funcionamento do grave-robber é

necessário que ele seja executado como usuário root. Caso contrário, apenas os dados

acessíveis ao usuário comum serão coletados.

As principais funcionalidades do grave-robber são:

•Ele calcula o hash MD5 de todos os dados coletados (sejam arquivos ou saída de comandos).

Na maioria das vezes, o hash dos arquivos coletados é armazenado em um arquivo individual,

do tipo arquivo.md5, mas também há casos onde é criado um arquivo, chamado MD5_all, que

contém os hashes de todos as informações coletadas.

•É feito o dump de todos os arquivos em execução, e esses arquivos são salvos com o nome

16

contendo o PID (identificador de processos) e o timestamp.

•Os comandos são executados não através do shell, mas por um módulo Perl, chamado

command.pl. O histórico dos programas executados é registrado em um arquivo de log e, além

disso, é criado um arquivo de texto individual contendo o resultado de cada um desses

comandos.

•A saída de cada programa executado é armazenada em um arquivo de texto individual,

contendo no cabeçalho o timestamp da execução.

•Os comandos executados pelo TCT são sujeitos a um limite de tempo. Se este for excedido, o

processo é morto. Isso impede que, por exemplo, o grave-robber entre um laço infinito de

execução ao manipular certos arquivos de dispositivos (como o /dev/random).

A cada execução, o grave-robber cria alguns sub-diretórios e arquivos com os dados

coletados da máquina, são eles: body, body.S, command_out, conf_vault, coroner.log,

error.log, icat, proc, removed_but_running, trust e user_vault, visualizados na Figura 3.1 e

cuja finalidade é descrita a seguir.

•body: esse arquivo, apresentado na Figura 3.2, armazena informações detalhadas sobre todos

os arquivos do sistema, e os “MAC times” coletados. A documentação desses campos é

escassa e, devido a importância desse arquivo, eles são apresentados a seguir:

◦md5: o hash MD5 do arquivo;

◦file: nome do arquivo;

◦st_dev: número do dispositivo onde o arquivo está armazenado;

◦st_ino: número do inode, estrutura de dados onde o sistema de arquivos armazena as

informações dos arquivos e diretórios;

◦st_mode: flags com as propriedades do arquivo (st_mode), isto é, o tipo, se ele é um arquivo

comum, diretório, dispositivo orientado a caractere ou orientado a blocos, FIFO (semelhante a

um pipe), e as permissões associadas a esse arquivo;

◦st_ls: permissões de acesso, em um formato legível ao usuário (ao contrário do st_mode,

17

Figura 3.1: Arquivos criados pelo “grave-robber”.

que necessita de máscaras de bits para extrair essas informações), do tipo "-rwxr-xr-x";

◦st_nlink: número de hard links para o arquivo;

◦st_uid: identificador (UID) do dono do arquivo;

◦st_gid: identificador (GID) do grupo de usuários do dono do arquivo;

◦st_rdev: no caso de arquivos de dispositivos, esse valor indica o tipo, ou seja, os campos

major e minor;

◦st_size: tamanho total do arquivo, em bytes;

◦st_atime: data do último acesso, em segundos, desde a zero hora, do dia 1º de janeiro de

1970 (momento conhecido como "época Unix"). É importante notar que, para reduzir a

quantidade de acessos ao disco e, dessa forma, melhorar o desempenho, nem todos os

sistemas atualizam esse campo (o que é feito utilizando o parâmetro noatime do comando

mount);

◦st_mtime: data da última modificação, desde a época Unix;

◦st_ctime: data da criação do arquivo ou da última modificação do status (feito por comando

como chmod, chown, chgrp), desde a época Unix;

◦st_blksize: tamanho do bloco definido pelo sistema de arquivos (tamanhos maiores

aumentam o desempenho, porém aumentam o desperdício de armazenamento); e

◦st_blocks: quantidade de blocos alocados ao arquivo, em unidades de 512 bytes.

•body.S: armazena as mesmas informações que o arquivo body, porém somente para arquivos

SUID. O flag SUID é definido em alguns arquivos que necessitam de permissões de super-

usuário, ou seja, mesmo que um usuário comum o execute, o sistema atribui privilégios de

root àquele programa.

•coroner.log: registra todos os comandos efetuados pelo grave-robber.

•error.log: registra os erros que eventualmente hajam ocorrido durante a execução do grave-

robber.

•command_out/: diretório que guarda o resultado dos comandos executados, bem como os

hashes MD5 correspondentes.

•icat/: contém as imagens dos processos que já foram executados, mas cujos binários ainda

estão armazenados no disco, isto é, que não foram apagados. Além das imagens, nesse

diretório estão os hashes MD5 dos arquivos coletados. Informações importantes podem ser

obtidas quando as imagens do processo são visualizadas com ferramentas apropriadas, como o

18

aplicativo strings.

•proc/: similar ao icat/, porém armazena os dumps dos processos em execução e cujos

executáveis ainda estão armazenados em disco.

•removed_but_running/: semelhante ao icat/, mas guarda as imagens de processos cujos

binários foram apagados do disco.

•conf_vault/: armazena os arquivos que o grave-robber considera importantes. A definição

dos arquivos que serão coletados é feita nos arquivos de configuração save_these_files,

coroner.cf e grave-robber.cf.

•user_vault/: semelhante ao conf_vault/, porém apenas arquivos importantes dos usuários são

coletados, tais como: o histórico de comandos digitados (.bash_history), as chaves

criptográficas (.ssh/ e .pgp/) e redirecionadores de e-mail (.forward).

O grave-robber é de grande valor ao automatizar a coleta de evidências com apenas

um comando, o que reduz a probabilidade de erro, significativa quando se trata de sistemas

em funcionamento. Por padrão, ele coleta os "MAC times", que são informações muito

voláteis, mas muito importantes na reconstrução da linha temporal de eventos. Outro ponto

positivo é que o grave-robber coleta os dados de acordo com a ordem de volatilidade, ou seja,

primeiro os mais efêmeros. Porém, existem duas importantes desvantagens: em primeiro

lugar, ele utiliza utilitários do sistema examinado na coleta de evidências. Entretanto, esses

programas costumam ser modificados por rootkits, o que pode resultar em resultados

incorretos. Além disso, o grave-robber não permite que as evidências coletadas sejam

enviadas através da rede, restando ao investigador utilizar algum dispositivo externo

conectado fisicamente ao computador (disco rígido externo, por exemplo) para evitar

sobrescrita de dados.

19

Figura 3.2: Trecho do arquivo "body", o banco de dados de "MAC Times" criado pelo "grave-robber".

3.1.2 – Mactime

O "mactime" é o módulo responsável pela coleta dos "MAC times" dos arquivos e,

principalmente, pela filtragem desses valores. Os "MAC times" são as datas de criação ou

mudança de status (ctime) e último acesso (atime) e modificação (mtime). Esses valores são

muito efêmeros, uma vez que praticamente qualquer operação (leitura, escrita, dentre outras)

sobre o arquivo costuma modificá-los. Uma das únicas exceções é a chamada de sistema

stat(), responsável pela obtenção desses dados. O mactime é invocado pelo grave-robber na

criação do arquivo body, o banco de dados com os "MAC times" dos arquivos do sistema.

3.1.3 - Unrm & Lazarus

O unrm é a ferramenta responsável pela coleta dos dados do espaço não alocado do

sistema de arquivos. Os dados coletados são, ao final, armazenados em um arquivo específico

para uma análise posterior. Por exemplo, numa partição de 100 GB, se apenas 20 GB

estiverem em uso, o unrm gerará um arquivo contendo os 80 GB da área de disco não

utilizada. Uma restrição importante do unrm é que o arquivo com os dados recuperados deve

ser armazenado num sistema de arquivos distinto do examinado. Caso contrário, haverá

sobrescrita de informações.

Apesar do unrm facilitar a coleta do espaço não alocado do sistema de arquivos, ele

não permite a coleta da imagem do disco, caso em que deve-se usar o utilitário dd. Um fator

significativo é que com o contínuo aumento da capacidade de armazenamento dos discos

rígidos, a utilização do unrm pode gerar arquivos enormes e, consequentemente, muito

difíceis de serem analisados.

Já o lazarus é responsável por organizar de maneira compreensível ao usuário a

informação contida no arquivo gerado pelo unrm. Ele examina o arquivo gerado pelo unrm

em busca de informações sujeitas à recuperação, podendo ser: arquivos apagados, memória

virtual, dentre outros. Existe, ainda, um opção ("-h") para gerar um relatório em HTML

(HyperText Markup Language), o que permite consultar no navegador web o resultado da

análise. A documentação do lazarus afirma que ele foi testado nos sistemas de arquivos Ext2

20

(second extended filesystem), UFS (Unix File System), FAT32 (File Allocation Table de 32

bits) e NTFS (New Technology File System), mas que ele pode ser utilizado em, virtualmente,

qualquer sistema de arquivos, somente dependendo da forma como a informação é

armazenada no disco.

Uma importante dificuldade enfrentada pelo lazarus é que os sistemas de arquivos

utilizados no UNIX foram projetados para maximizar o desempenho, o que, frequentemente,

ocorre em detrimento da possibilidade de recuperação de arquivos apagados. Ao remover um

arquivo, o mesmo acontece com várias informações que o sistema mantém sobre ele. Com

isso, para cada arquivo removido, é necessário examinar toda a área não alocada do disco,

principalmente quando há muita fragmentação, o que demanda muito tempo para concluir a

análise.

3.2 – The Sleuth Kit

O The Sleuth Kit (TSK) é uma ferramenta de análise forense, gratuita, de código fonte

aberto, para plataformas Windows e UNIX (FreeBSD, Linux, Mac OS X, OpenBSD e

Solaris), com suporte a vários sistemas de arquivo (FAT32, NTFS, UFS, Ext2 e Ext3). Ele é

composto de vários aplicativos de linha de comando, muitos deles baseados no The Coroner's

Toolkit (TCT), mas modificados para serem mais independentes do sistema operacional (o

TCT foi desenvolvido com ênfase em sistemas UNIX). A ênfase do TSK é a análise morta,

tipicamente sobre imagens de disco. Entretanto, ele foi projetado para evitar modificações

indesejáveis (contaminação) durante a sua execução, o que permite a análise do sistema de

arquivos com o computador em funcionamento (o que, ainda assim, é desaconselhável).

O TSK é, geralmente, utilizado juntamente com o Autopsy Forensic Browser (também

chamado de Autopsy), uma interface web desenvolvida para facilitar seu uso. Com o Autopsy

é possível realizar diversas tarefas de maneira simplificada: consultar os resultados gerados

pelo TSK, visualizar e buscar por palavras-chave nas imagens de disco, verificar sua

integridade (através do hash MD5), dentre outras funções automatizadas.

As principais funcionalidades do The Sleuth Kit são:

21

•Recuperar arquivos apagados, quando possível;

•Exibir detalhes do sistema de arquivos e seus meta-dados (inodes, por exemplo);

•Gerar linhas de tempo de acesso e modificação dos arquivos; e

•Filtrar os arquivos de acordo com o tipo (se imagem, executável, documentos, dentre outros).

3.2.1 - Camadas do The Sleuth Kit

A análise do TSK é baseada em camadas, havendo para cada uma delas um conjunto

específico de ferramentas. Essas camadas são: camada do sistema de arquivos, camada de

dados, camada de meta-dados e camada de arquivos.

Os discos rígidos (ou qualquer outra mídia) são divididos em uma ou mais partições, e

para cada uma delas há um sistema de arquivos, uma estrutura lógica de armazenamento e

organização de dados. A camada de sistema de arquivos do TSK é a responsável por

manipular essas estruturas de dados. O conjunto de aplicativos dessa camada são identificados

facilmente pelo nome, iniciado por "fs". Uma dos mais importantes é o fsstat, responsável por

mostrar informações como: nome do volume, estrutura, tamanho, data da última montagem,

além de outros detalhes.

A camada de dados é aquela em que os arquivos e diretórios são armazenados. Quando

o sistema operacional necessita de espaço em disco, ele aloca unidades de dados (tipicamente,

chamadas de bloco ou cluster). Estas estruturas costumam ter o tamanho em uma potência de

2, tal como 512 ou 1024 bytes. As ferramentas do STK específicas para essa camada são

identificadas por começar com a letra "d". O dcat exibe o conteúdo de uma unidade de dados

(análogo ao comando cat, do UNIX), o que permite visualizar dados ocultos em áreas não

utilizadas normalmente pelo sistema de arquivos; o dls mostra o conteúdo das áreas de disco

não alocadas; o dstat mostra informações de uma unidade de dados de maneira amigável; e o

dcalc é utilizado quando um dado é recuperado pelo dls em uma área não alocadas e se deseja

calcular sua "posição" no sistema de arquivos.

As informações dos arquivos e diretórios, descrita pelos inodes nos sistemas UNIX ou

22

pelos MTF (Master File Table) em sistemas NTFS, são de responsabilidade da camada de

meta-dados. Entre essas informações, estão os tempos de acesso, tamanho e os endereços de

armazenamento dos dados no disco. Os aplicativos referentes a essa camada começam com a

letra "i". O ils lista as informações de um dado inode (ou de outro meta-dado, no caso de

sistemas diferentes do UNIX). Por padrão, ele irá listar apenas os arquivos removidos. O icat

mostra o conteúdo de um arquivo a partir do seu inode e, combinado com o ils, pode ser

utilizado na recuperação de arquivos apagados. O istat exibe informações sobre um

determinado inode, tais como tamanho, "MAC times" e identificadores do proprietário, e o

ifind retorna o inode associado a um dado arquivo ou diretório.

Finalmente, a camada de arquivos (também conhecida por camada da interface

humana) permite uma interação com os arquivos de forma mais cômoda do que a camada de

mata-dados. As ferramentas relacionadas a essa camada são identificadas pela letra "f". O fls

lista os arquivos e diretórios em uma imagem de disco, mesmo aqueles apagados; o ffind faz o

oposto do ifind, isto é, a partir de um inode ele identifica o nome do arquivo que é

referenciado.

3.3 – Autopsy Forensic Browser

O Autopsy Forensic Browser (também chamado, simplesmente, de Autopsy) é uma

interface web para o The Sleuth Kit, que é baseado em programas de linha de comando. Com

ele é possível realizar a maioria das tarefas a partir de uma interface que se assemelha a um

gerenciador de arquivo, em que todas as funções são acessíveis pelo navegador. Outra

funcionalidade importante é que todas as ações são registradas em arquivos de log, o que

permite auditar posteriormente a investigação. Além disso, o Autopsy é capaz de gerar

relatórios referentes ao sistema de arquivos e aos dados lá armazenados.

A cada sistema periciado, o Autopsy requer que seja criado um "caso", como

apresentado na Figura 3.3, contendo o nome dos investigadores, da máquina e das imagens

adquiridas correspondentes. Para cada caso, o Autopsy cria uma estrutura de arquivos e

diretórios contendo informações como relatórios, logs e outros dados relevantes.

23

Para garantir a integridade das imagens e dos demais arquivos criados, o Autopsy

calcula o hash (o MD5 é o padrão, mas também pode-se utilizar o SHA-1) desses dados

sempre que necessário. Uma funcionalidade interessante é que o Autopsy utiliza o banco de

dados de hashes da National Software Reference Library (NSRL), um órgão do governo

norte-americano.

Existem duas categorias de hashes no banco de dados da NSRL: o Ignore Database e

o Alert Database. O Ignore Database contém hashes de arquivos legítimos. Dessa forma, se o

valor no banco de dados corresponde ao hash de um arquivo do sistema investigado, isso

significa que o arquivo é verdadeiro e o investigador pode ignorá-lo. O Alert Database

funciona de forma análoga, porém contém hashes de arquivos indevidos (por exemplo,

rootkits), e que merecem atenção.

As demais funções são, essencialmente, as mesmas apresentadas para o The Sleuth Kit,

porém apresentadas de forma mais amigável. Pode-se citar a criação de linha tempo de

acesso/modificação de arquivos (a partir dos "MAC times"), a visualização de conteúdo

(numa interface de gerenciador de arquivos) e a busca por palavras-chave (em forma de string

ou de expressões regulares).

Conforme já mencionado, o The Sleuth Kit é uma ferramenta poderosa para a análise

morta, além da capacidade de aquisição de algumas informações com o sistema em

24

Figura 3.3: Criação de um "caso" no "Autopsy Forensic Browser".

funcionamento. O TSK possui funcionalidades compatíveis com sistemas comerciais, com a

vantagem de ser gratuito e possuir código fonte disponível. Apesar da utilização de suas

diversas ferramentas ser bastante complexa, isso se torna bem mais fácil quando utilizado

conjuntamente com o Autopsy, mostrado na Figura 3.4.

3.4 - EnCase

O EnCase é, provavelmente, a ferramenta de análise forense computacional mais

utilizada no mundo. Desenvolvida para o ambiente Windows, na linguagem de programação

C++, ela é uma das mais completas disponíveis comercialmente, além de contar com uma

interface gráfica muito intuitiva, apresentada na Figura 3.5. Sua ênfase é similar ao The Sleuth

Kit: a análise de arquivos em disco.

25Figura 3.5: Fragmento da interface gráfica do EnCase.

Figura 3.4: Visão geral do Autopsy Forensic Browser.

Assim como Autopsy Forensic Browser, o EnCase é organizado em "casos" para cada

sistema investigado, porém cada caso é registrado num arquivo distinto, e não em uma

estrutura de diretórios. Esses arquivos de casos são compostos por cabeçalho, blocos de dados

e verificadores de integridade. O cabeçalho, exposto na Figura 3.6, contém as informações

sobre o caso, que são comprimidas e tem a integridade garantida pela função de hash CRC

(Cyclic Redundancy Check). Os dados do caso são divididos em blocos de, por padrão, 32

KB, e para cada um é calculado seu hash CRC. Por fim, é calculado o hash MD5 do conjunto

dos blocos de dados (excluindo-se os códigos CRC).

Entre as funcionalidades do EnCase pode-se citar: criação de imagens de disco bit a

bit, montagem dessas imagens em modo somente leitura, verificação de integridade de dados

(calculando o hash MD5), recuperação de arquivos removidos, visualização do arquivo de

memória virtual, classificação dos arquivos de acordo com o tipo, busca de palavras-chave,

pré-visualização de alguns tipos de arquivos no próprio programa, dentre outras. Muitas das

funções propiciadas pelo EnCase estão disponíveis em outras ferramentas como o The Sleuth

Kit, entretanto nele existem duas vantagens importantes: ampla documentação, havendo até

livros dedicados a seu uso, como [Bunting 2008], e facilidade de uso.

3.5 – Comentários

As ferramentas avaliadas possuem importantes funcionalidades que podem ser

empregadas em uma perícia forense, principalmente para recuperação de arquivos removidos.

26

Figura 3.6: Cabeçalho do arquivo de caso do EnCase.

No TCT e no TST, há diversos aplicativos, cada um com uma função específica. Para realizar

algumas tarefas simples, às vezes é necessário combinar vários comandos, o que não acontece

de forma intuitiva. Essa dificuldade é superada no EnCase, que possui uma interface gráfica

muito fácil de utilizar.

O TCT possui a vantagem de centralizar em apenas um arquivo todos os tempos de

acesso ("MAC times") dos arquivos, o que permite facilmente criar uma linha de tempo de

acordo com os arquivos que foram acessados ou modificados. Além disso, ele foi o único

software que apresentou funcionalidades úteis na realização de uma análise viva.

Principalmente, com os criadores de imagens dos processos em execução, incluindo aqueles

que já foram apagados do disco.

Ao comparar as ferramentas, verificou-se que a sua ênfase é na análise forense de

sistemas mortos. Em virtude disso, elas possuem diversas funcionalidades relacionadas à

recuperação de arquivos removidos. Além disso, percebeu-se a ausência de mecanismos que

possibilitassem o envio, através da rede, das evidências encontradas na máquina investigada

para a estação forense.

27

4 – Especificação e Desenvolvimento do FARO

4.1 – Especificação

4.1.1– Diagrama de casos de uso

28

Figura 4.1: Diagrama de casos de uso do FARO.

O diagrama de casos de uso representa os requisitos (funcionalidades) do sistema

proposto e a relação destes com os atores (os usuários, no caso, o investigador). Na

especificação do presente trabalho, foi realizada uma análise de requisitos a partir de

entrevistas com os administradores da rede do PoP-RN, resultando nos casos de uso

apresentados na Figura 4.1.

4.1.2 – Descrição dos casos de uso

Nesta seção são descritos os casos de uso apresentados no diagrama da

Figura 4.1.

Caso de uso: Executar comandos remotos

Visão geral: O usuário utiliza programas seguros e compilados

estaticamente disponíveis no servidor FARO. Útil em casos

onde se suspeita que os utilitários do sistema podem ter sido

modificados por rootkits.

Objetivo: Possibilitar que o usuário utilize programas seguros

disponíveis no servidor.

Ator primário: Investigador.

Pré-condição: O investigador deve cadastrar o endereço IP do servidor

FARO.

Sequência típica de eventos: 1. O investigador escolhe a opção “Executar comandos a

partir de um servidor seguro”.

2. O investigador digita o comando que deseja executar.

3. O comando é copiado do servidor.

4. O comando é executado e o resultado aparece na tela.

Sequência alternativa: Linha 3: Caso o comando já tenha sido executado antes, ele

estará em cache e não será copiado do servidor.

Caso de uso: Coletar e enviar evidências

Visão geral: Automatiza o processo de coleta de evidências de um

máquina periciada. Dessa forma, reduz a interação do

29

investigador com a máquina e, consequentemente, a

probabilidade de contaminação.

Objetivo: Coletar automaticamente informações sobre o estado do S.O.

e enviar o resultado para o servidor FARO.



FARO.

O programa deve, preferencialmente, ser executado pelo

usuário root.

Sequência típica de eventos: 1. O investigador escolhe a opção “Coletar evidências do S.O.

e enviar ao servidor”.

2. O cliente FARO coleta e envia informações ao servidor

sobre o sistema examinado.

3. O servidor armazena as informações recebidas, juntamente

com os hashes correspondentes, em um diretório específico

para o caso investigado.

Sequência alternativa: Linha 2: caso o programa não seja executado pelo usuário

root, mensagens de erro aparecerão, indicando que as

evidências não puderam ser coletadas.

Caso de uso: Enviar imagem da memória

Visão geral: Envia uma imagem da memória para o servidor. Isto

possibilita que evidências importantes, tais como senhas e

chaves criptográficas, sejam encontradas em uma investigação

posterior.

Objetivo: Copiar a memória principal do computador investigado e

enviar ao servidor.



FARO.

O programa deve ser executado pelo usuário root.

Sequência típica de eventos: 1. O investigador escolhe a opção “Coletar a imagem da

memória e enviar ao servidor”.

30

2. O cliente FARO envia uma cópia da memória do sistema

investigado ao servidor FARO.

3. A imagem da memória e seu hash criptográfico são salvos

no servidor, em um diretório específico para o caso

investigado.


root, uma mensagem de erro será exibida.

Caso de uso: Enviar imagem de disco

Visão geral: Envia uma imagem de disco para o servidor, o que possibilita

que evidências armazenadas em disco sejam investigadas

posteriormente.

Objetivo: Copiar a imagem do disco rígido do computador investigado e

enviar ao servidor.



FARO.

O programa deve ser executado pelo usuário root.

Sequência típica de eventos: 1. O investigador escolhe a opção “Coletar a imagem de disco

e enviar ao servidor”.

2. O cliente FARO envia uma cópia do disco rígido do sistema

investigado ao servidor FARO.

3. A imagem do disco e seu hash criptográfico são salvos no

servidor, em um diretório específico para o caso investigado.


root, uma mensagem de erro será exibida.

Caso de uso: Gerar relatório dos utilitários do sistema

Visão geral: As propriedades dos utilitários do sistema, tais como tempos

de acesso e modificação, hash, tamanho e inode, são

compiladas em um relatório, ordenados por data de

modificação.

31

Objetivo: Gerar um relatório contendo as propriedades dos utilitários do

sistema.



FARO.


usuário root.

Sequência típica de eventos: 1. O investigador escolhe a opção “Analisar os utilitários do

sistema e salvar em um arquivo”.

2. O cliente FARO analisa as propriedades dos utilitários do

sistema.

3. O resultado é compilado em um arquivo de texto.

4. O conteúdo do arquivo é apresentado na tela.

Sequência alternativa: Linha 2: Caso o programa não seja executado pelo usuário

root, mensagens de erro serão mostradas, indicando que

determinados arquivos não puderam ser abertos.

Caso de uso: Gerar relatório dos utilitários do sistema

Visão geral: As propriedades dos utilitários do sistema, tais como tempos

de acesso e modificação, hash, tamanho e inode, são

compiladas em um relatório, que, então, é enviado ao servidor

para análise futura.

Objetivo: Gerar um relatório contendo as propriedades dos utilitários do

sistema e o envia ao servidor.



FARO.


usuário root.

Sequência típica de eventos: 1. O investigador escolhe a opção “Analisar os utilitários do

sistema e enviar o relatório ao servidor”.

2. O cliente FARO analisa as propriedades dos utilitários do

sistema.

32

3. O resultado é compilado em um arquivo de texto.

4. O relatório é enviado ao servidor.

5. O servidor salva o relatório em um diretório específico para

o caso investigado.




Caso de uso: Verificar acessos por ordem cronológica

Visão geral: Todos os acessos dos usuários ao sistema são mostrados em

ordem cronológica, indicando quando e quanto tempo

passaram conectados.

Objetivo: Mostrar os acessos dos usuários ao sistema.


Sequência típica de eventos: 1. O investigador seleciona a opção “Mostrar na ordem

cronológica todos os acessos dos usuários”.

2. O cliente consulta os registros de acessos dos usuários ao

sistema.

3. O relatório com a listagem dos acessos do usuário é

apresentado na tela.




Caso de uso: Exibir últimos acessos dos usuários

Visão geral: Apresenta quando foi a última vez que cada usuário acessou

remotamente o sistema investigado.

Objetivo: Mostrar o último acesso remoto dos usuários


Sequência típica de eventos: 1. O investigador seleciona a opção “Exibir quando foi o

último acesso de todos os usuários remotos”.

2. O cliente consulta os registros de acessos remotos dos

usuários ao sistema.

33

3. O relatório com a listagem dos últimos acessos por usuário

é apresentado na tela.

Caso de uso: Mostrar tentativas de acesso mal-sucedidas

Visão geral: Indicar o usuário, data e origem das tentativas de acesso que

foram mal-sucedidas.

Objetivo: Verificar as tentativas de acesso frustradas.


Sequência típica de eventos: 1. O investigador seleciona a opção “Consultar últimas

tentativas de acesso local sem sucesso”.

2. O cliente consulta os registros de acessos frustrados dos

usuários ao sistema.

3. O relatório com a listagem das últimos tentativas de acesso

é visto na tela.

Caso de uso: Consultar usuários conectados

Visão geral: Listar os usuários conectados ao sistema, a origem da

conexão, momento do acesso, consumo de recursos de

processamento e as tarefas que eles estão realizando.

Objetivo: Apresentar os usuários conectados e suas processos.


Sequência típica de eventos: 1. O investigador seleciona a opção “Visualizar os usuários

logados atualmente na máquina”.

2. O cliente verifica quais usuários estão conectados e o que

eles estão fazendo.

3. O relatório com informações sobre os usuários conectados é

exibido na tela.

Caso de uso: Verificar todos os serviços ativos

Visão geral: Lista todas as conexões de rede, tanto os serviços ativos,

quanto as conexões já estabelecidas.

Objetivo: Apresentar os serviços de rede que estão esperando conexões.


34

Sequência típica de eventos: 1. O investigador seleciona a opção “Mostrar todas as

conexões (TCP e UDP) abertas”.

2. O cliente verifica o estado das conexões de rede.

3. O relatório contendo todos serviços ativos e conexões de

rede estabelecidas é mostrado na tela.

Caso de uso: Consultar as interfaces de rede

Visão geral: Mostra a configuração de todas as interfaces de rede, estejam

ativas ou inativas, presentes na máquina investigada.

Objetivo: Apresentar todas as interfaces de rede da máquina.


Sequência típica de eventos: 1. O investigador seleciona a opção “Consultar as interfaces

de rede (ativas e inativas)”.

2. O cliente verifica a configuração das interfaces de rede.

3. A configuração de todas as interfaces de rede é apresentada

na tela.

Caso de uso: Exibir a tabela de roteamento

Visão geral: Mostra as entradas na tabela de roteamento do protocolo IP.

Objetivo: Consultar a tabela de roteamento IP.


Pré-condição: O sistema investigado deve possuir rotas configuradas.

Sequência típica de eventos: 1. O investigador seleciona a opção “Exibir a tabela de

roteamento”.

2. O cliente verifica as rotas configuradas pelo kernel do

sistema.

3. A configuração das entradas da tabela de roteamento é

mostrada na tela.

Caso de uso: Exibir cache da tabela de roteamento

Visão geral: Mostra a cache das entradas na tabela de roteamento do

protocolo IP, utilizada para melhorar o desempenho do

roteamento.

35

Objetivo: Consultar a cache da tabela de roteamento IP.


Pré-condição: O sistema investigado deve possuir rotas configuradas.


roteamento”.

2. O cliente verifica a cache das rotas já consultadas pelo

sistema.

3. A configuração da cache das entradas da tabela de

roteamento é exibida na tela.

Caso de uso: Exibir a cache do protocolo ARP

Visão geral: Consultar a cache do protocolo ARP (Address Resolution

Protocol).

Objetivo: Mostrar o conteúdo da cache do protocolo ARP. Ou seja, os

endereços IP e seus correspondentes endereços MAC.


Pré-condição: O sistema investigado deve possuir uma rede local ativa.

Sequência típica de eventos: 1. O investigador seleciona a opção “Exibir a cache do

protocolo ARP”.

2. O cliente verifica a cache com os correspondentes

endereços MAC dos endereços IP já consultados pelo sistema.

3. Os endereços IP e MAC armazenados na cache do

protocolo ARP são mostrados na tela.

Caso de uso: Listar processos

Visão geral: Mostra todos os processos que estão em execução, juntamente

com informações de dono, consumo de recursos de memória e

processamento, identificador e estado.

Objetivo: Listar os processos em execução no sistema.


Sequência típica de eventos: 1. O investigador seleciona a opção “Listar os processos

rodando atualmente”.

2. O cliente verifica quais são os processos em execução,

36

identificando suas informações complementares.

3. A listagem dos processos é apresentada na tela.

Caso de uso: Listar os módulos do kernel carregados

Visão geral: Mostra o estado de todos os módulos de kernel (drivers) em

uso pelo sistema.

Objetivo: Consultar os módulos do kernel ativos.


Sequência típica de eventos: 1. O investigador seleciona a opção “Listar os módulos de

kernel carregados”.

2. O cliente verifica quais são os módulos em uso pelo kernel

do sistema operacional.

3. O estado dos módulos de kernel ativos é visto na tela.

Caso de uso: Mostrar tarefas agendadas

Visão geral: Apresenta todas as tarefas programadas na tabela de

agendamento do daemon Cron.

Objetivo: Consultar as tarefas agendadas pelo serviço Cron.


Pré-condição: O programa deve, preferencialmente, ser executado pelo

usuário root.

O serviço Cron deve estar ativo.

Sequência típica de eventos: 1. O investigador seleciona a opção “Consultar as tarefas

agendadas através do Cron”.

2. O cliente verifica as tabelas de agendamento do Cron.

3. As tarefas com execução agendada no Cron são exibidas na

tela.

Sequência alternativa: Linha 2: caso o programa seja executado por um usuário

comum, apenas a tabela de agendamento deste será acessada.

Caso de uso: Consultar a tabela de partições

Visão geral: Mostra as informações do nome de dispositivo, setores de

início e fim e o sistema de arquivos da tabela de partições.

37

Objetivo: Consultar a tabela de partições do disco rígido.


Pré-condição: O programa deve ser executado pelo usuário root.


partições dos discos”.

2. O cliente verifica a tabela de partição do disco rígido.

3. As informações sobre a tabela de partições do disco rígido

são apresentadas na tela.

Sequência alternativa: Linha 2: caso o programa seja executado por um usuário

comum, essa informação não poderá ser acessada.

4.2 – Implementação

O FARO é composto de dois módulos: um servidor e um cliente. O servidor é

executado na estação forense (uma máquina segura, destinatária das evidências) e o cliente é o

módulo utilizado na máquina investigada.

4.2.1 – Servidor FARO

O servidor é o módulo responsável por prover ao cliente um conjunto de ferramentas

de uso freqüente, composto por: arp , cksum , dd , du , find , free , ifconfig , kill , lsof , ls ,

md5sum , netstat, ps , route , sha1sum , sha256sum , sha512sum , ssh , stat , su , sysctl , top ,

uptime , who e w [Nemeth 2006]. Dessa forma, no lado cliente, o investigador pode optar por

executar esses comandos a partir do servidor, em vez de utilizar aqueles disponíveis na

máquina sob suspeita, que supostamente estão comprometidos.

Adicionalmente, o servidor possui a funcionalidade de recepção de evidências

remotas. Essas evidências são classificadas em quatro tipos: evidências gerais (configurações

da rede, usuários conectados, arquivos abertos, mensagens do kernel, dentre outras), imagem

da memória principal, relatório do estado dos utilitários do sistema e imagem do disco rígido.

Com a finalidade de possibilitar a recepção simultânea de evidências, o servidor aguarda cada

uma delas em uma porta distinta, conforme apresentado na Tabela 4.1. Uma vez recebidas as

38

evidências, o servidor calcula seus respectivos hashes MD5 e, então, armazena as evidências

e seus hashes no diretório do caso, nomeado no formato <hostname-investigado>-<data e

hora>.

Funcionalidades Portas de

comunicação

Recepção de evidências gerais 9000 a 9013

Recepção da imagem de disco 9097

Recepção do relatório de análise de arquivos 9098

Recepção da imagem de disco 9099

Canal de controle 9100

Transferência das ferramentas seguras 9200

Tabela 4.1: Relação entre as funcionalidades do servidor

FARO e as portas de comunicação utilizadas

4.2.1 – Cliente FARO

O cliente é o módulo responsável pela coleta de evidências na máquina investigada.

Essas evidências podem ser consultadas na tela ou enviadas ao servidor para análise futura.

Para coletá-las, o cliente é dotado de ferramentas compiladas estaticamente (ou seja, não

utilizam bibliotecas externas), conforme mostrado na Figura 4.2, o que evita a utilização dos

utilitários do sistema suspeito. Além disso, é possível utilizar ferramentas adicionais que

estejam disponíveis no servidor, cujo processo está ilustrado na Figura 4.3.

39

Figura 4.2: Comparação entre o utilitário “ls” compilado estático e dinamicamente.

Como apresentado na seção anterior, há quatro tipos de evidências: evidências gerais,

imagem da memória principal, relatório do estado dos utilitários do sistema, e imagem do

disco rígido. Cada tipo de evidência é coletada separadamente, por solicitação do usuário.

Essa opção de separar cada processo, em detrimento da automatização completa, dá

flexibilidade ao investigador de avaliar se a profundidade da coleta compensa o tempo

despendido para realizá-la (por exemplo, a criação da imagem de disco pode levar horas,

enquanto a coleta de evidências gerais demora poucos segundos).

As evidências gerais coletadas são as seguintes:

• Cache da tabela do protocolo ARP;

• Tabela de tarefas agendadas;

• Espaço utilizado do disco;

40

Figura 4.3: Fluxograma da execução de ferramentas remotas pelo cliente FARO.

• Mensagens do kernel;

• Tabela de partições;

• Configurações das interfaces de rede;

• Histórico de acesso dos usuários;

• Listagem de arquivos abertos;

• Listagem dos processos em execução;

• Tabela de roteamento;

• Estado dos parâmetros do kernel possíveis de serem alterados em tempo de execução;

• Usuários conectados; e

• Listagem dos módulos do kernel carregados.

O relatório do estado dos utilitários do sistema analisa os arquivos contidos nos

diretórios /usr/sbin , /usr/bin , /sbin , /bin , /usr/local/sbin e /usr/local/bin, compilando as

seguintes informações referentes a cada um:

• Nome do arquivo;

• Hash MD5;

• MAC times (datas da última modificação, acesso e mudança de status);

• Proprietário;

• Grupo;

• Permissões;

• I-node (índice) do sistema de arquivos; e

• Tamanho do arquivo (em bytes).

Esse relatório pode, não somente ser enviado ao servidor, mas também ser consultado

no próprio cliente, ordenado pela data de modificação, como visto na Figura 4.4. Assim, é

possível estabelecer uma linha de tempo na alteração do sistema.

41

Figura 4.4: Apresentação na tela do relatório do estado dos utilitários do sistema, ordenado por data de modificação.

5 – Testes e Resultados

Nos testes realizados, uma máquina foi comprometida instalando-se o ARK

(Ambient's RootKit), versão 1.0. O ARK é um dos rootkits mais utilizados para se garantir o

acesso a uma máquina após comprometê-la. Ele é composto de diversos utilitários do sistema,

modificados para possibilitar o ocultamento de informações referentes a logs, processos em

execução, conexões de rede ativas e arquivos armazenados no disco. Esses utilitários são: du,

killall, login, ls, netstat, ps, pstree e syslogd, apresentados na Tabela 5.1. Além disso, há uma

backdoor, chamada sshd, que se disfarça como um servidor do protocolo SSH (Secure SHell).

Utilitário Função

du Verificar o espaço utilizado por arquivos e diretórios.

killall Matar processos a partir do nome.

login Controlar o acesso ao sistema, solicitando o nome de usuário e a senha.

ls Listar as informações sobre os arquivos dos diretórios.

netstat Mostrar informações sobre as conexões de rede.

ps Apresentar informações sobre os processos ativos.

pstree Exibir a árvore de processos em execução.

syslogd Gerenciar os logs do sistema e as mensagens do kernel.

Tabela 5.1: Descrição dos utilitários modificados pelo ARK.

As informações que serão filtradas precisam ser configuradas em arquivos específicos.

Por exemplo, para se ocultar conexões de rede, deve-se configurar o arquivo /dev/ptyxx/.addr.

Dessa forma, o aplicativo netstat comprometido não mostrará as conexões referentes às

entrada configuradas neste arquivo. A Tabela 5.2 relaciona essas informações.

Informação filtrada Arquivo de configuração Utilitários afetados

Arquivos /dev/ptyxx/.file du, ls

Conexões de rede /dev/ptyxx/.addr netstat

Entradas dos logs do sistema /dev/ptyxx/.log syslogd

Processos em execução /dev/ptyxx/.proc killall, ps, pstree

Tabela 5.2: Relação entre as informações filtradas, arquivos de configuração e os

utilitários afetados do ARK.

42

5.1 – Identificação de arquivos escondidos pelo ARK

No primeiro teste, apresentado na Figura 5.1, o ARK foi configurado para ocultar

arquivos com nomes específicos. As etapas realizadas foram as apresentadas abaixo:

• Passo 1: Os arquivos do diretório /home/arthur/ark-1.0 foram listados em uma

máquina limpa.

• Passo 2: O ARK foi configurado para ocultar os arquivos README e login-shadow e

o arquivo ls do sistema foi substituído por uma versão modificada.

• Passo 3: Ao repetir o procedimento do Passo 1, verificou-se que os arquivos definidos

no Passo 2 não aparecem mais na listagem do sistema comprometido, indicando o

devido funcionamento do ARK.

O FARO foi, então, utilizado para listar o mesmo diretório. Os passos realizados foram

os seguintes:

1. O servidor FARO foi ativado em uma máquina segura.

2. Na máquina investigada foi executado o cliente FARO.

3. No menu principal, foi selecionada a opção “Executar comandos a partir de um

servidor seguro” (Figura 5.2).

4. Se executou o comando “ls-remoto -F /home/arthur/ark-1.0” (no campo apresentado

na Figura 5.3). Os comandos disponíveis no servidor foram adicionados do sufixo “-

remoto”, desta forma para executar, por exemplo, o “ifconfig” deve-se digitar

“ifconfig-remoto”, e assim sucessivamente.

5. O endereço IP do servidor FARO onde os comandos estavam disponíveis foi

preenchido (Figura 5.4).

6. O resultado (Figura 5.5) obtido indicou corretamente os arquivos contidos no

diretório.

43

Figura 5.1: Configurando o ARK para ocultar arquivos.

44

Figura 5.3: Preenchendo o comando remoto que será executado.

Figura 5.4: Preenchendo o endereço IP do servidor FARO.

Figura 5.5: Resultado do “ls” seguro.

Figura 5.2: Menu principal do cliente FARO.

5.2 – Listagem de conexões de redes ocultas

No segundo teste (Figura 5.6), o ARK foi empregado para ocultar determinadas

conexões de rede, o que na prática acontece, por exemplo, para disfarçar o funcionamento de

backdoors. Os procedimentos efetuados são descritos a seguir:

• Passo 1: As conexões de rede foram listadas através do comando “netstat -ant”.

Verifica-se dois serviços ativos: o SSH na porta 22 e o protocolo IPP (Internet Printing

Protocol) na porta 631, além disso há três conexões SSH originadas do endereço IP

192.168.160.1.

• Passo 2: o utilitário netstat do sistema foi substituído pelo correspondente do ARK.

• Passo 3: o ARK foi configurado para ocultar as conexões originadas do endereço IP

192.168.160.1.

• Passo 4: o ARK foi configurado para esconder os serviços ativos na porta 631.

Então, o FARO foi utilizado para listar os serviços ativos e as conexões de rede que

foram ocultados pelo rootkit ARK. As etapas efetuadas são vistas abaixo:

1. No menu principal do cliente foi escolhida a opção “Exibir o estados das conexões

de rede ativas” (Figura 5.7).

2. A opção “Mostrar as conexões TCP abertas” foi selecionada (Figura 5.8).

3. O FARO apresentou corretamente as conexões de rede escondidas pelo ARK

(Figura 5.9).

45

Figura 5.6: Configurando o ARK para ocultar serviços ativos e conexões de rede.

46

Figura 5.9: O FARO mostrou corretamente as conexões de rede que foram ocultadas pelo ARK.

Figura 5.7: Opção “Exibir o estado das conexões de rede ativas”, do menu principal.

Figura 5.8: Opções para o gerenciamento das conexões de rede.

5.3 – Geração e envio de relatório de modificação do utilitários do sistema

Neste cenário, todos os utilitários do ARK (Tabela 5.1) foram instalados no sistema,

através do próprio instalador, denominado “ark”. Após instalado, o cliente FARO foi utilizado

para gerar um relatório dos utilitários do sistema e enviar uma cópia ao servidor FARO. As

etapas realizadas foram as seguintes:

1. No menu principal do cliente foi escolhida a opção “Analisar os utilitários do sistema

e enviar o relatório ao servidor” (Figura 5.10).

2. O endereço IP do servidor foi configurado (Figura 5.4).

3. O relatório gerado e armazenado pelo servidor no diretório

“faro_server/ultimo_caso/arquivos_recebidos/analise_arquivos” foi visualizado

(Figura 5.11).

Pode-se perceber a modificação de diversos utilitários no dia “2009-12-14” (após o dia

“2009-12-11”), o que representa um forte indicador de comprometimento do sistema. Esta

opção é especialmente útil, quando se suspeita que algum incidente de segurança ocorreu em

determinado intervalo de tempo.

47

Figura 5.10: Opção “Analisar os utilitários do sistema e enviar o relatório ao servidor”.

5.4 – Análise de evidências na imagem da memória principal

Neste cenário, na máquina comprometida pelo ARK, o FARO foi utilizado para gerar a

imagem da memória principal e enviá-la ao servidor seguro. Então, posteriormente, essa

imagem foi investigada em busca de evidências. No caso, foi realizada uma busca utilizado

como palavra-chave o provedor de e-mail do desenvolvedor do ARK (Hotmail). Os passos

realizados são os apresentados abaixo:

1. No menu principal do cliente foi escolhida a opção “Capturar a imagem da memória e

enviar ao servidor” (Figura 5.12).

2. O endereço IP do servidor foi configurado (Figura 5.4).

3. Se buscou na imagem gerada e armazenada pelo servidor (no diretório

“faro_server/ultimo_caso/arquivos_recebidos/RAM” ) pela palavra-chave

“@hotmail.com”. O resultado pode ser visto na Figura 5.13.

O que se encontrou foi um trecho de código que envia para um endereço de e-mail

suspeito o endereço IP da máquina investigada, o que representa uma evidência significativa

do comprometimento do sistema.

48

Figura 5.11: Relatório listando os últimos utilitários do sistema que foram modificados.

49

Figura 5.12: Opção “Capturar a imagem da memória e enviar ao servidor”.

Figura 5.13: Busca por palavra-chave na memória principal.

6 – Conclusões

A quantidade de incidentes computacionais relatados tem aumentado

significativamente ao longo dos últimos anos. Com isso, são diversos os casos em que é

necessário investigar indícios do comprometimento de sistemas computacionais, gerando uma

demanda por serviços e ferramentas de forense computacional. A maioria das ferramentas

disponíveis tem como alvo a análise de discos rígidos, característica das metodologias

forenses tradicionais, e somente funcionam na plataforma Windows. A maior parte da

bibliografia disponível também segue esse padrão, havendo pouco material publicado na área

da forense computacional para sistemas Linux e menos ainda para sistemas vivos. As poucas

ferramentas que funcionam em ambiente Linux são difíceis de utilizar e algumas chegam a

contaminar a máquina durante a execução, ou mesmo, dependem de utilitários do sistema que

podem estar comprometidos.

Foi a partir desse cenário que se originou esse trabalho, tendo como diretrizes

principais: funcionar em ambiente Linux (utilizado em diversos serviços de rede do PoP-RN),

com o sistema em execução e que fosse de uso intuitivo. Ao longo do seu desenvolvimento,

percebeu-se que o sistema poderia se tornar ainda mais interessante ao abordar um novo

paradigma: um sistema de análise forense baseado em uma arquitetura cliente-servidor. Dessa

forma, na máquina investigada se utiliza o módulo cliente, que por usa vez interage com o

módulo servidor, instalado em uma máquina segura (estação forense). Além disso, foi

implementada mais um funcionalidade ausente nas demais ferramentas pesquisadas: o FARO

é capaz de gerar a imagem da memória principal e enviá-la ao servidor para análise posterior.

A investigação da memória principal, sem dúvida, revela evidências indispensáveis, como,

por exemplo, a existências dos rootkits mais sofisticados. Além disso, em tese, torna possível

extrair qualquer tipo de senha ou chave criptográfica que esteja em utilização ou que tenham

sido utilizadas recentemente.

Os testes até agora realizados indicam que o FARO cumpriu com os objetivos

propostos, chegando até a ampliar o escopo inicial, ao propor metodologias ainda não

encontradas em ferramentas afins. Entretanto, testes mais amplos são necessários.

50

Atualmente, a equipe do Núcleo de Operações Especiais de Segurança (NOE) do PoP-RN

mantém contato com o Centro de Atendimento de Incidentes de Segurança da Rede Nacional

de Ensino e Pesquisa (CAIS-RNP), para a realização de testes em cenários de

comprometimento reais. Dessa forma, está previsto a utilização do FARO em novos

ambientes de teste a partir das próximas semanas.

6.1 – Trabalhos Futuros

Algumas funcionalidades importantes que não foram possíveis de implementar no

FARO até a conclusão deste trabalho e devem ser registradas:

• O FARO somente cria a imagem do disco inteiro. Seria interessante que houvesse a

seleção da partição em que se deseja realizar essa tarefa.

• Os diretórios em que os utilitários são investigados estão definidos previamente

(/usr/sbin , /usr/bin , /sbin , /bin , /usr/local/sbin , /usr/local/bin). Entretanto, algumas

distribuições do Linux costumam utilizar outros diretórios. Talvez fosse melhor

utilizar o “path” do sistema. Além disso, na geração do relatório, os links são

considerados como arquivos, gerando entradas duplicadas.

• O FARO confia plenamente no horário do sistema investigado. Sugere-se que esse

horário seja comparado com o de um servidor de tempo (NTP), possibilitando linhas

de tempo mais confiáveis.

• Os rootkits costumam fazer uso intensivo dos diretórios especiais do sistema /proc e

/dev, porém o FARO não explora essa possível e importante fonte de evidências. No

caso do /proc, a documentação escassa e desatualizada dificultou a sua utilização. Já

no caso do /dev, houve dificuldade em se manipular os dispositivos especiais.

• Apesar de fugir ao escopo, a inclusão de ferramentas de análise de disco no FARO

poderia complementar o sistema.

• Sugere-se que, adicionalmente à captura da imagem da memória principal, seja

possível realizar o dump dos processos em execução.

• As evidências encontradas na imagem da memória principal são significativas. A

utilização de filtros ou mecanismos análogos pode potencializar a detecção de

software maliciosos no sistema.

51

7 – Referências Bibliográficas

[AccessData 2006] – MD5 Collisions - The Effect on Computer Forensics. AccessData. White

Paper. Extraído em outubro de 2009 de http://www.accessdata.com/media/en_us/print/papers/

wp.md5_collisions.en_us.pdf.

[Autopsy] - Autopsy Forensic Browser. Extraído em novembro de 2009 de

http://www.sleuthkit.org/autopsy.

[Barros 2009] – BARROS, G. Elementos Básicos de Perícia Forense Computacional.

Extraído em dezembro de 2009 de http://www.mpm.gov.br/mpm/servicos/assessoria-de-

comunicacao/anexos/pericia_forense_computacional_conceitos.pdf.

[Bunting 2008] – BUNTING, S. EnCase Computer Forensics - The Official EnCE EnCase

Certified Examiner Study Guide. Indianapolis: Wiley Publishing, 2008.

[Casey 2004] CASEY, E. Digital Evidence and Computer Crime: Forensic Science,

Computers, and the Internet. San Diego: Academic Press, 2004.

[Chisum 2000] CHISUM, W. J., TURVEY, B. Evidence Dynamics: Locard’s Exchange

Principle & Crime Reconstruction, Journal of Behavioral Profiling, v. 1, n, 1, 2000.

[Cooper 2005] COOPER, M. Advanced Bash-Scripting Guide: An in-depth exploration of the

art of shell scripting. Extraído em novembro de 2009 de

http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/index.html.

[DEFG 2009] Digital Evidence Field Guide. Extraído em outubro de 2009 de

http://www.rcfl.gov/downloads/documents/FieldGuide_sc.pdf.

[Farmer 2005] – FARMER, D., VENEMA, W. Forensic Discovery. [s.l] Addison-Wesley:

2005.

52

http://www.rcfl.gov/index.cfm?fuseAction=Public.T_CEfieldGuide

http://www.rcfl.gov/index.cfm?fuseAction=Public.T_CEfieldGuide

[Graycar 2001] GRAYCAR, D. New Crimes or New Responses. In: 4th National Outlook

Symposium on Crime in Australia, 2001, Canberra, Australia. [Proceedings] Canberra,

Australia: june 2001.

[Malin 2008] MALIN, C. H., CASEY, E., AQUILINA, J. M. Malware Forensics:

Investigating and Analyzing Malicious Code . [s.l.] Syngress Media, 2008.

[Nemeth 2006] NEMETH, E., SNYDER, G., HEIN, T. Linux Administration Handbook. [s.l.]

Addison-Wesley, 2006.

[Reis 2003] REIS, M. A. Forense computacional e sua aplicação em segurança imunológica.

São Paulo: CPG/Unicamp, 2003. Dissertação (M. Sc. Ciência da Computação) Programa de

Pós-Graduação do Instituto de Computação, Universidade de Campinas, janeiro 2003.

[Reyes 2007] REYES, A., WILES, J., The Best Damn Cybercrime and Forensics Book

Period. Burlington: Syngress, Publishing Inc, 2007.

[RFC3227] BREZINSKI, D., KILLALEA, T. Guidelines for Evidence Collection and

Archiving, Internet RFC 3227, Fevereiro, 2002.

[Silva 2009] SILVA, G. M., LORENS, E. M. Extração e análise de dados em memória na

perícia forense computacional. Procedings of The Fourth International Conference of

Forensics Computer Science (IcoFCS), v. 1, p. 21-28, 2009.

[TCT] – The Coroner's Toolkit. Extraído em novembro de 2009 de http://www.porcupine.org/

forensics/tct.html.

[TSK] – The Sleuth Kit. Extraído em novembro de 2009 de

http://www.sleuthkit.org/sleuthkit.

[Vacca 2005] VACCA, J. R. Computer Forensics: Computer Crime Scene Investigation.

Boston: Charles River Media, 2005.

53

faro: ferramenta para análise forense … › theses › ferramenta_para_analise...forense...

Documents