quarta-feira, 15 de abril de 2009

Frag_Find

Recentemente, Simson Garfinkel, um dos papas da Forense Computacional mundial anunciou mais uma ferramenta que será de extrema utilidade para peritos e investigadores: o frag_find.

O conceito desse software, em si, é bastante simples. Ele recebe como parâmetros uma imagem forense e um arquivo. Baseado no tamanho de cluster da imagem, ele quebra o arquivo em pedaços do mesmo tamanho, calcula hashs de cada pedaço e por fim sai a procura desses hashs pela imagem. Para fazê-lo, ele usa um algoritmo de busca em conjuntos conhecido como filtro de Bloom.

A utilidade maior e imediata dessa ferramenta é determinar se um arquivo esteve (ou está) em uma imagem. Quando um arquivo é apagado, algumas situações distintas podem ocorrer:

- Ele pode estar completamente intacto, incluindo todas as suas entradas de metadados;
- Ele pode estar completamente intacto, mas algumas de suas entradas na camada de metadados do sistema de arquivos pode ter sido sobreposta;
- Ele pode estar órfão;
- Ele pode estar com partes de seus clusters sobrepostos;
- Ele pode já ter sido completamente sobreposto.

Com exceção da última situação, e que em discos grandes é a que tem a menor probabilidade de ocorrer, o frag_find pode ajudar em todas as demais. Obviamente que as primeiras situações é facilmente tratada por softwares que recompõem os metadados e refazem as ligações entre os dados, recuperando os arquivos. No entanto, isso já não é completamente possível em algumas situações, fora que alguns sistemas de arquivos eliminam informações importantes dos metadados quando um arquivo é apagado (ext3, por exemplo), tornando a recuperação de um arquivo uma tarefa MUITO complicada. No nosso caso, o objetivo não é recuperar o arquivo (até porque temos cópia dele, certo ?), mas sim determinar se ele está ou esteve na mídia.

Imagine um caso onde uma investigação conduziu a uma suspeita de que um indivíduo está mantendo conteúdo impróprio em sua máquina. Temos alguns desses conteúdos impróprios como amostragem, já que podem ter sido publicados por ele anonimamente em um fórum qualquer. O suspeito, sabendo que tem "culpa no cartório", apaga o conteúdo logo após o envio. Mesmo com uma alta frequência desse tipo de operação, o frag_find pode registrar e encontrar pedaços do arquivo procurado, indicando assim a existência prévia dele.

Outro exemplo: Há uma suspeita de que um funcionário descontente tenha desviado informações internas para um concorrente usando um pendrive. Ao vasculhar o pendrive, nada é encontrado, pois o tal funcionário já apagou o conteúdo e logo em seguida gravou outras coisas sem importância. Um conjunto dos arquivos suspeitos de terem sido copiados pode ser usado pelo frag_find para determinar se eles estiveram presentes no pendrive.

Alguém o utiliza ou já o utilizou e gostaria de compartilhar a experiência ?

Até o próximo post !

quinta-feira, 9 de abril de 2009

Anti-Forense ?

Há um post interessante sobre anti-forense no blog do Lance Mueller que vem bem a calhar sobre a nossa ultima discussão, falando de correlação. No post ele comenta acerca de um caso onde um atacante procurou usar técnicas de anti-forense para atrapalhar as investigações e encobrir alguns vestígios. O atacante trocou nomes e timestamps (datas de criação, modificação, etc) dos arquivos envolvidos no ataque. De maneira bastante divertida, Lance diz que não concorda com esse termo "anti-forense" e que isso é, na verdade, anti-administrador.

Por que ele disse isso ?

Primeiro porque um perito deve sempre verificar vários itens, independentemente do lugar que estão. Se estiverem no System, System32 ou Windows, mais atenção ainda deveremos ter. Em segundo lugar, porque o sistema era um Windows 2003, e o atacante usou timestamps de 2001.

Repare que, nos dois casos, o autor está usando correlação para chegar a uma conclusão a respeito do que aconteceu, e das técnicas de obfuscação usadas.

Um outro autor muito famoso no meio da Computação Forense, Harlan Carvey, costuma dizer que anti-forense não afeta os sistemas, mas sim as pessoas. Seria mais um anti-perito, pois o profissional atento vai correlacionar os dados que puder e vai concluir o que de fato ocorreu.

Comentários ?

Até o próximo post !

segunda-feira, 6 de abril de 2009

Correlação

Correlação é a palavra do momento, em se tratando de Forense Computacional. Há algum tempo já vinham percebendo que essa é a chave para várias questões não respondidas a cerca de várias técnicas e situações comuns na área.

Correlação diz respeito a interligação. Correlação indica que há uma relação estreita em tudo que acontece, não apenas em um computador, mas em tudo o mais na vida. Vamos a um exemplo prático.

Um homem é achado morto em uma casa. O legista afirma ser difícil precisar a hora da morte, por circunstâncias diversas. No entanto, a vítima era assinante de jornal, e segundo os vizinhos, tinha hábitos costumeiros, como acordar cedo, pegar o jornal na porta e tomar seu café lendo o jornal. O fato do jornal estar amontoado na porta há 3 dias diz alguma coisa para você ? Isso é correlação. Obviamente, um fato gera tantos artefatos (ou vestígios) que devem se correlacionar entre si (nem sempre é aparente). A reunião de todos eles reconta a história ou o fato que aconteceu. Se um vizinho disser que ouviu a vítima gritando ao telefone na véspera, a correlação direta com o jornal fica abalada, e precisa inclusive ser explicada.

Uma conta atrasada sobre a estante pode ser outro ponto de correlação, se a vítima nunca atrasava aquele tipo de conta. Enfim, correlacionar significa estar atento não só ao fato em si, mas relacionar tudo que está em volta ao fato; De certa forma, devemos enxergar tudo a volta como resultado do fato.

Entendido isso, temos um ponto importantíssimo a respeito da correlação.

1) Se você só tem um único vestígio, então não há caso. Isso significa dizer que não há como provar um fato baseado em apenas um único vestígio encontrado. Na prática até dá, mas a prova careceria de força suficiente, e pode levantar muitos questionamentos. Já li sobre algumas situações onde um americano, acusado de pedofilia, se defendeu afirmando que o conteúdo fora baixado sem seu conhecimento, por um trojan.

Esse caso, inclusive, ficou conhecido como Trojan Defense, já discutido aqui no blog, e deu origem a muitas linhas de defesa onde o suspeito alegava "Não fui eu, foi um vírus". Entretanto, a perícia do caso foi incapaz de correlacionar os vestígios da máquina para fortalecer a prova. Ao que tudo indica, o cidadão foi inocentado.

2) Se você consegue correlacionar devidamente os vestígios que estão localizados, não há MD5 que prove ser mais forte. Eu tenho levantado aqui no blog uma série de questões a respeito de dificuldades de apontarmos a integridade de algumas provas. Isso porque o hash, tido como a última palavra para determinar a integridade, fica comprometido sob vários aspectos. De maneira geral, temos dificuldades em comprovar um hash quando não fazemos uma imagem completa do disco, levando apenas arquivos.

A mesma dificuldade acontece quando estamos lidando com dumps de memória, ou mesmo quando a mídia está defeituosa. Mais recentemente, há de se usar uma enorme ginástica para trabalhar com discos criptografados, e o hash entra na situação como mais um item a incomodar. Para "chutar o pau da barraca", temos a alegação de que o MD5, algoritmo mais usado para hash em Forense Computacional, já foi quebrado a algum tempo (embora eu coloque isso na categoria Orelha de Frango: Todo mundo fala de Birthday Attack no MD5, mas eu não vi ninguém me mostrar um em uma imagem de HD até hoje).

O ponto é que, correlacionando, não tem como negar nada, com ou sem MD5. Você conseguiria derrubar uma imagem forense cujo hash não bate, mas que tem tudo perfeitamente encadeado ? Eu imagino que não.

Bom, falando específicamente sobre correlações, vou dar alguns exemplos e uma sugestão ao final.

1) Uma correlação fantástica é usar o log de antivírus e o de restore point para determinar se houve alteração na data/hora da máquina. Tanto um quanto o outro são sequenciais, portanto não podem ter data/hora fora de ordem.

2) Em análises de arquivos de link (atalhos), achar apontamentos para um mesmo disco rígido com diferentes MAC Addresses pode indicar troca de placa de rede ou, o que é mais comum, que o HD já pertenceu a outra máquina.

3) O número de boots pode ser aproximado com o número de execuções de alguns itens indicados no Prefetch

4) Um arquivo PDF que teve seu MAC Times forjado pode ser descoberto se verificarmos em seus metadados a versão do PDF e correlacionarmos com a data de lançamento dessa versão. Se o atributo de Creation for anterior a tal data, convém verificar esse arquivo melhor.

Uma base de conhecimento sobre correlações seria um bom projeto para os nossos investigadores e peritos em Forense Computacional. Algo como uma Wiki, com links para programinhas que verificariam a correlação sobre uma imagem (montada ou não). Seria útil para todos e daria bastante visibilidade. Alguém se habilita ? Já temos 4 correlações simples para iniciar.

Até o próximo post !

sexta-feira, 3 de abril de 2009

Emails Corporativos

É muito comum em um trabalho da nossa área toparmos com servidores de email corporativos. Entre os casos mais comuns estão aqueles onde um ex-funcionário processa outro por brincadeiras de mau gosto, que podem ser enquadradas como difamação (às vezes, dependendo do tom da suposta "brincadeira", até em racismo). Uma das provas mais usadas nestes casos é o email enviado, que na maioria das vezes, partiu do servidor da própria empresa.

Embora o assunto seja ligeiramente diferente deste, há um bom artigo que aborda emails corporativos no site do Jones Dykstra (Escritório formado por Keith Jones e Brian Dykstra, dois monstros da Computer Forensics). Desse escritório saiu nada mais nada menos que o grupo de ferramentas pasco, galetta e rifiuti, além do menos conhecido eindeutig.

O artigo referido faz um apanhado dos servidores de email mais comumente encontrados nos ambientes corporativos, e trata de algumas estratégias mais voltadas para eDiscovery, que é uma etapa do processo americano que envolve captação de provas eletrônicas. Apesar desse detalhe, o texto é muito bom e explica vários detalhes a respeito dessas ferramentas.

O artigo vale os minutos gastos para lê-lo.

Ao final, fiquei com uma dúvida e não consegui satisfazê-la, e vou dividi-la aqui com os leitores.

Há uma série de ferramentas open source, ou free, que fazem a conversão dos arquivos PST ou DBX, do Outlook e Outlook Express, respectivamente. Esse tipo de conversão é bastante útil para acessarmos alguns detalhes de um email específico. Entretanto, nâo encontrei nenhuma ferramenta nestes mesmos moldes para converter bases Notes (.NSF) para qualquer outro formato. Sei que há vários conversores comerciais, e há também conectores para que o Exchange acesse um NSF, mas o que seria interessante é termos uma ferramenta que pegue um .NSF como entrada e gere na saída as mensagens e anexos que estão lá dentro.

Alguém conhece uma ferramenta free que faça isso ? Compartilhe conosco !

Até o próximo post !

quinta-feira, 2 de abril de 2009

Palestra no Instituto Infnet

Pessoal, estarei no próximo dia 27 de abril, segunda feira, palestrando no Instituto Infnet, no Rio de Janeiro. A palestra será sobre o uso de software livre em Computação Forense, mostrando um comparativo entre as diversas opções que temos disponíveis para trabalho. A palestra começa às 18h30.

Quem quiser comparecer, é só se inscrever no site da Infnet. A boa notícia é que a palestra é gratuita.

Aguardo vocês por lá.

Até o próximo post !