faro: ferramenta para análise forense … › theses › ferramenta_para_analise...forense...
Post on 28-Jun-2020
2 Views
Preview:
TRANSCRIPT
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
FARO: Ferramenta para Análise Forense Computacional em Sistemas Linux Vivos
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
FARO: Ferramenta para Análise Forense Computacional em Sistemas Linux Vivos
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.
Ator primário: Investigador.
Pré-condição: O investigador deve cadastrar o endereço IP do servidor
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.
Ator primário: Investigador.
Pré-condição: O investigador deve cadastrar o endereço IP do 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.
Sequência alternativa: Linha 2: caso o programa não seja executado pelo usuário
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.
Ator primário: Investigador.
Pré-condição: O investigador deve cadastrar o endereço IP do 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.
Sequência alternativa: Linha 2: caso o programa não seja executado pelo usuário
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.
Ator primário: Investigador.
Pré-condição: O investigador deve cadastrar o endereço IP do servidor
FARO.
O programa deve, preferencialmente, ser executado pelo
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.
Ator primário: Investigador.
Pré-condição: O investigador deve cadastrar o endereço IP do servidor
FARO.
O programa deve, preferencialmente, ser executado pelo
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.
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: 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.
Ator primário: Investigador.
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.
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: 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
Ator primário: Investigador.
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.
Ator primário: Investigador.
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.
Ator primário: Investigador.
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.
Ator primário: Investigador.
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.
Ator primário: Investigador.
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.
Ator primário: Investigador.
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.
Ator primário: Investigador.
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 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.
Ator primário: Investigador.
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.
Ator primário: Investigador.
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.
Ator primário: Investigador.
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.
Ator primário: Investigador.
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.
Ator primário: Investigador.
Pré-condição: O programa deve ser executado pelo usuário root.
Sequência típica de eventos: 1. O investigador seleciona a opção “Exibir a tabela de
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
[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
top related