Fechando o ano com certificação

Navegando por alguns sites, acabei achando uma certificação sobre Forense Computacional bastante interessante. É de graça, ainda por cima.

As questões são bem montadas, o assunto é coberto adequadamente, e o processo não chega a ser demorado. São 40 questões que cobrem diversos aspectos de Forense Computacional e ainda entra nos detalhes da lei americana.

Quer tentar ? Lá vai: http://www.brainbench.com/xml/bb/common/testcenter/taketest.xml?testId=2516

Clique no GET TEST, faça o cadastro e siga para as questões. Pode ser um bom termômetro de como você está indo em relação aos conhecimentos.

Boa prova, e até o próximo post !

Sem fio ...

Desde que conseguiram descobrir formas de burlar a lei e cometer crimes usando o computador, cada vez fica mais comum a situação onde investigadores e policiais são envolvidos em operações com mandados de busca e apreensão. Um dos objetivos é apreender os equipamentos que podem estar sendo usados nas atividades ilegais, e dessa forma obter mais informações e evidências para o processo.

Para fechar o ano contribuindo com os amigos invetigadores das forças policiais, vou tratar nesse post de alguns detalhes a observar quando da realização da busca. Parte desse artigo é baseado no artigo Examining Wireless Access Points and Associated Devices, do Sgt Christopher Then.

O objetivo da busca é apreender o máximo, senão todos os equipamentos que podem conter informações sobre o que está sendo investigado. Em épocas de computação móvel barata e redes sem fio, podemos alguns problemas nessa operação:

1) Será que estamos realmente apreendendo todos os equipamentos usados ?

2) E se for um carona ?

3) E se o suspeito estiver pegando carona ?

Vamos tratar de cada um deles separadamente.


Varredura nos equipamentos - Será que estamos realmente apreendendo todos os equipamentos usados ?

Nosso problema é garantir que estamos apreendendo todos os equipamentos. No caso de uma rede local, os pontos de rede e algumas configurações do servidor já darão mostra de quais equipamentos estão sendo usados. Porém, o perfil mais encontrado nesta situação ainda é o de um ambiente pequeno, e normalmente fazendo uso de um roteador com wireless e algumas portas para LAN. Abaixo, enumero alguns pontos importantes para considerar. Monte um check-list com as tarefas, para facilitar no momento da operação:

a) Localize e fotografe o que seria a topologia dos equipamentos.

Em geral, nesses casos temos um modem (cable modem ou ADSL), conectado ao roteador com interfaces para wireless e algumas portas LAN.

b) Determine a quantidade dos equipamentos.

Verifique se o modem é o único existente, se o roteador WiFi é o único existente, se todos os cabos ligados nele levam às estações.

c) De posse de uma estação forense com interface wireless (ou um notebook de investigação), faça uma verificação do roteador WiFi.

Essa etapa pode ser feita de algumas formas, e seria interessante que fosse feita de mais de uma forma, para termos resultados que se confirmam. Outro ponto importantíssimo: Todas as operações devem fazer parte de um procedimento, que deve ser seguido a risca. Os resultados obtidos precisam necessariamente poder ser reproduzidos por terceiros, seguindo os procedimentos, caso contrário o resultado poderá ser contestado quanto a sua integridade, já que não é reprodutível.

Forma i - Através da interface de rede

a) Reinicialize o notebook forense com o BackTrack. Esse é o melhor Live CD para testes de invasão existente, e um acessório fundamental para o Investigador Digital.

b) Conecte o cabo de rede no notebook e no roteador.

c) Verifique se o mesmo irá receber um IP, via DHCP. Se não receber, consiga as configurações de IP em uma máquina já conectada.

d) O IP do roteador WiFi deverá ser o indicado para default gateway da rede. Outra possibilidade é usar a suposição de que o IP do roteador está na mesma sub-rede que o IP recebido, mas com o último octeto igual a 1. Por exemplo, se o seu notebook forense recebeu o IP 192.168.1.103, então provavelmente o IP do roteador será 192.168.1.1

e) Abra um browser e informe o IP do roteador. Vamos acessar a console de gerenciamento dele. Esse acesso será bastante valioso, já que no roteador poderemos verificar diretamente várias informações importantes, como o seu MAC address, o MAC address de todas as máquinas conectadas a ele, seja atualmente, seja no passado, consultando os seus logs.

f) Ao ser acessado, precisaremos informar ao roteador o usuário e a senha. A melhor opção aqui é tentar usar a identificação padrão. Não é incomum que os usuários mantenham a autenticação com os valores de fábrica. Verifique no corpo do próprio roteador sua marca e modelo, e acesse http://www.governmentsecurity.org/articles/DefaultsLoginsandPasswordsforNetworkedDevices.php
g) Tendo sucesso na autenticação, prepare-se para armazenar o máximo de informações disponíveis. O principal aqui é determinar quantos equipamentos estão ou já estiveram conectados, para que sejam averiguados.

h) Na impossibilidade de autenticar-se no roteador, podemos realizar uma varredura na rede para tentar detectar os equipamentos conectados usando o nmap, disponível no BackTrack:

nmap -sP -v

Ex: nmap -sP -v 192.168.1.0/24 para verificar a subrede de 192.168.1.1 a 192.168.1.254

Esse método tem um problema: firewalls podem bloquear a resposta do nmap ...

Forma ii - Através da interface Wireless

a) Reinicialize o notebook forense com o BackTrack.

b) Confira se o sinal de WiFi está ligado.

c) Vamos observar o tráfego entre todas as máquinas associadas ao roteador-Access Point (AP). Para isso, usaremos o pacote AirCrack-ng, que está no BackTrack.

d) Execute o programa airmon-ng. Ele vai informar qual o nome da interface WiFi do seu notebook.

e) Execute o programa airodump-ng, passando o nome da interface obtido no passo anterior. Ex: airodump eth0

Dessa forma, o programa estará verificando todas as comunicações que estão ao alcance do seu notebook forense.

f) Veja a tela do airodump abaixo:





BSSID - é o MAC Address do roteador-AP. Você poderá pegar mais de um sinal disponível na área.
ESSID - é o SSID da conexão wireless. Dependendo da forma de criptografia utilizada (campo ENC), essa informação pode não estar acessível. O roteador também pode estar configurado para omitir o SSID no broadcast.
STATION - É o MAC Address de cada estação wireless conectada/associada ao roteador-AP indicado na coluna BSSID. No exemplo da figura, há apenas um AP identificado e apenas uma máquina conectada ao mesmo. Em geral, a lista acima fica bem maior.

Na busca, todas as STATIONs identificadas precisarão estar apreendidas.

E se for um carona ?

Uma das possibilidades que devemos levar em conta em algumas situações é a de que o maior suspeito não é realmente quem está cometendo o delito. Se, no endereço do suspeito, for encontrado um roteador WiFi aberto, é bem possível que essa informação mude completamente os rumos da situação. Para evitar expor a investigação, recomendo uma pré-operação em sigilo, usando o airodump nas redondezas para captar o sinal WiFi e determinar se ele é aberto (sem criptografia) ou não.

É possível, inclusive, ter a localização do roteador-AP através de uma placa de GPS adaptada ao notebook. Ele registra as coordenadas do AP com a possibilidade de repassá-las a programas que indicam em mapas a sua localização exata.

E se o suspeito estiver pegando carona ?

Em tempos onde muitos usam roteadores WiFi simplesmente tirando-o da caixa e usando-o com todas as configurações padrão, algo que devemos nos preocupar é que o verdadeiro autor do delito tenha condições de esconder as evidências do que está fazendo. Uma possibilidade é que o mesmo se associe a redes WiFi abertas na redondeza, e use as máquinas desprotegidas como passagem para disfarçar sua identidade ou até mesmo guardar informações comprometedoras lá. Um exemplo seria alguém que pratica a pedofilia associar-se a uma rede que está aberta na vizinhança, e sem conhecimento do dono, armazenar fotos ou figuras comprometedoras na máquina da pessoa. Existem diversas técnicas de obfuscação que podem ser usadas e com isso o material dificilmente seria notado.

Por conta disso, redes abertas com sinal acessível no ponto onde a busca está sendo realizada devem também ser averiguadas, para eliminar a possibilidade descrita acima.

Outros pontos importantes:

- Muitos equipamentos hoje podem disparar ataques e outras formas de fraude, e alguns deles possuem interface wireless. Por conta disso, não esqueça de verificar os PDAs (Palm, iPaq, SmartPhones, etc).

- Redes protegidas por criptografia com esquemas WEP ou WPA podem ter a sua chave quebrada, e a associação efetivada. Programas como o Airodump/Airocrack oferecem essas funcionalidades.

Alguém gostaria de compartilhar alguma história envolvendo buscas em rede sem fio ?

Até o próximo post !

Contra-argumentação

Enquanto espero pacientemente minha filha enjoar da Barbie e liberar meu notebook, para que eu possa fazer os testes finais do próximo post sobre wireless, vou adiantar algo sobre um artigo não tão novo, mas interessante.

O artigo, escrito por Jesse Kornblum para o International Journal of Digital Evidence de 2004, comenta e testa um problema do Linux, kernel 2.4.xxx, em ler o último setor de um HD, quando o mesmo é ímpar.

O artigo faz um estudo detalhado, compara resultados em vários HDs diferentes e conclui que o problema é realmente do Kernel e não das ferramentas do Linux. Tal problema foi resolvido no Kernel 2.6.xxx.

Como tenho acompanhado várias listas por aí sobre Forense Computacional e visto uma onda de criação de novos live-cds para forense, vale a pena reforçar através desse micro-post o seguinte:

1) Verifique, antes da aquisição da imagem do HD, qual a versão do Kernel do seu Linux. Se for inferior a 2.6, é roubada.

2) Preste bastante atenção quando você for avaliar o trabalho de um Assistente Técnico. Se a aquisição da imagem usou um Linux baseado no Kernel 2.4.xxx e o número de setores do HD é ímpar, é muito provável que o último setor do disco não tenha sido transferido para a imagem, e isso sem nenhuma msg de erro ...

Nas duas situações, é bom ficar bastante atento. Um detalhe desses e você pode invalidar a imagem como evidência.

Até o próximo post !

Ho Ho Ho

Se você foi um bom menino esse ano, não aguenta mais aquele amigo-oculto de Natal (sempre aquele presentinho básico... ), está pensando em alguma coisa nova mas nem que a vaca tussa você irá ao shopping, então esse artigo foi feito pensando em você !

5 lugares bem bacanas para mandar o Papai Noel providenciar o seu presente !

http://www.logicube.com/
A Logicube é uma das líderes em hardware de duplicação forense. Pense quanto tempo você vai economicar fazendo a duplicação daquele HD de 500Gb !

http://www.voomtech.com/
A Voom Technologies oferece, além de duplicadores de HD, um drive wiper excelente ! Um deles oferece a taxa de 8 Gb por minuto.

http://www.crimescene.com/
Mande o Bom Velhinho passar por esse site e reabastecer o seu estoque de sacos de evidências, um item fundamental para selar e guardar o HD, depois de duplicado. Ah, já vem com espaço para a cadeia de custódia !!!

http://www.forensicpc.com
A Forensic PC é uma espécie de loja virtual multimarcas. Lá você achará várias opções interessantes, desde as mais modernas estações forenses até produtos Tableau e ICS.

http://www.digitalintelligence.com/
Aqui temos sistemas forenses completos. São estações especializadas em captura e análise forense, com máquinas totalmente dedicadas e otimizadas para essas tarefas. Acho que aqui Noel vai ter que vender o trenó e as renas para levar seu presente. Aprecie com moderação ...

Boas compras e até o próximo post !

Em tempo: Costumamos dizer que nosso trabalho é trazer a verdade à luz. Que nosso Senhor possa fazer exatamente isso, trazer luz para você e todos os seus ! Brasil, olha prá cima !!

Paz !

Processo do Clã MacLeod

Estava lendo um artigo do Andreas Schuster, um dos Papas no assunto de Forense da Memória de sistemas Windows.

O artigo apresenta vários conceitos básicos não apenas a respeito da importância de se fazer forense da memória, mas também indicando que em alguns casos a memória será a única a conter o artefato que pode trazer luz ao caso sendo investigado.

Lá pelas tantas do artigo, Schuster abre um tópico sobre a persistência dos dados na memória principal. Ele mostra estudos e estatísticas de máquinas que ficaram com informações disponíveis até 14 dias após o processo ter terminado !

Sendo mais claro: Em muita situações, você poderá executar comandos e utilitários que farão um instantâneo da máquina. Esses comandos, muito comentados em operações de Resposta a Incidentes, falam da situação atual da máquina. Em geral, eles não estão preparados para dar informações sobre um processo que já foi finalizado, por exemplo. Imagine que o tal era exatamente o elo que você buscava e, descobrindo-o, todas as dúvidas a respeito do caso seriam resolvidas. Mas o problema continua, porque você só tem na mão a foto do sistema, que foi tirada no momento em que o processo vilão já tinha saído de cena.

O que o Schuster apurou é que, devido a forma como as memórias Windows são gerenciadas, ele conseguiu obter informações de processos depois de muito tempo que foram terminados. Na situação-exemplo acima, uma análise forense da imagem da memória iria revelar o processo vilão.

Não pense que o ilustre pesquisador ficou satisfeito. Ele sacou algo inicialmente dito pela dupla de também gurus da Forense Computacional Farmer e Venema, que nem todos os computadores zeram a memória principal quando estão reiniciando. Isso depende mais da codificação da BIOS do que do sistema operacional, mas não há especificação que obrigue a isso, embora a maioria o faça. Consequências ??? Simplesmente, em suas pesquisas, ele descobriu processos com datas anteriores ao reboot da máquina ! No artigo ele mostra um deles, que resistiu bravamente a três reinicializações.

Estamos frente a um processo Highlander !!! 8-))

Brincadeiras a parte, as informações sobre o processo ultrapassaram as reinicializações, o que aumenta o valor da investigação em imagens da memória, não ?

Gostaria de ver comentários a respeito disso. Você já pesquisou algo parecido ? Já encontrou resultados que apontassem isso em investigações ?

Até o próximo post !

Sparse Files

Li recentemente um artigo interessante, relacionando arquivos esparsos com possíveis problemas para Forense Computacional. Antes de comentar, vou explicar alguns detalhes do artigo.

Arquivos Esparsos

Presente em alguns sistemas de arquivos, tais como o NTFS, arquivos esparsos seriam arquivos muito grandes, mas com pouca informação. Ao marcar um arquivo com essas características como esparso, a parte do arquivo sem informação fica desalocada no sistema de arquivos.

Vamos usar como exemplo um grande arquivo criado com 500 Gb para servir de disco virtual. Logo nos primeiros momentos de uso desse arquivo, vamos supor que acrescentamos informações da ordem de 10Mb. Apesar do arquivo ter apenas essa quantidade de informação real, ele continuará alocando e gastando os 500 Gb. As partes não utilizadas deverão estar cheias de zeros.

No entando, se esse arquivo estiver marcado como esparso, a parte não utilizada será liberada para ser alocada. O espaço consumido real do arquivo será de 10Mb. Na prática, quando o sistema operacional lê um arquivo esparso na parte não utilizada (comumente chamada de "buraco"), ele retorna como se estivesse lendo zeros.

Os arquivos esparsos são comuns para implementação de discos virtuais, bancos de dados, logs e qualquer outro tipo de arquivo que pré-aloca uma grande quantidade de disco, mas não a usa imediatamente.

Problemas com Forense Computacional

O problema apresentado por essa funcionalidade, em relação a Forense Computacional, está ligado diretamente à comprovação de integridade. Explico: imagine dois arquivos de 500Gb, ambos com 10Mb idênticos criados, um deles normal e o outro criado como esparso.

Se extrairmos ambos os arquivos a partir do seu volume, montando-os setor a setor, os hashes que iremos obter a partir disso indicarão que os conteúdos são diferentes. Enquanto que a parte que não contém informação real de um arquivo normal contém zeros, essa mesma parte de um arquivo esparso contem informação que na verdade pode pertencer a outros arquivos.

Porém, se ao invés de extrairmos esses arquivos, nós aplicarmos algoritmos de hash diretamente pelo sistema de arquivos (acessando-os com a imagem montada), os hashes de ambos serão idênticos pelo que já mencionei acima: a parte que não contém informação real de um arquivo esparso é tratada como se estivesse zerada. Conclusão: os arquivos são diferentes, mas o hash de ambos, feito pelo sistema de arquivos, diz que eles são iguais.

Agora sim, as considerações

Após explicado os detalhes do artigo, o autor destaca dois possíveis problemas:

1) Perda de informações sigilosas: Alguém mal intencionado rouba informações sigilosas e cria dois arquivos grandes com elas, um esparso e outro não. Ele copia o arquivo esparso para um pen-drive e logo em seguida troca, na origem, o arquivo esparso pelo normal. Se, por algum motivo, a operação for descoberta, pode ser alegado que o arquivo jamais caberia em mídias transportadas, como um pendrive.

2) Denial-of-Service: Alguém pode criar um grande arquivo normal, e colocá-lo no servidor, consumindo seus recursos de disco e causando a parada do sistema. Logo depois, o atacante substitui o arquivo normal por uma versão esparsa e alega que criou um arquivo esparso.

Nas duas situações, o hash como verificador de integridade vai corroborar com as alegações.

Você consegue imaginar outras situações onde poderíamos ter problemas ?

Um outro ponto que me prendeu a atenção foi que esse é mais um dos problemas de Forense Computacional criados por novas funcionalidades dos sistemas de arquivo. Há muito já vem se falando das Alternate Data Streams, e agora mais essa. Gostaria de saber o que você acha que pode ser feito para ter mais arquitetos e engenheiros de software comprometidos não apenas com as funcionalidades e versatilidades milagrosas, mas também com a Segurança das Informações.

Aguardo comentários. Até o próximo post !

Até injeção na testa ...

Como diz o ditado, "de graça, até injeção na testa !", o software livre vem apresentando considerável contribuição na área de Forense Computacional. Não é somente o conforto na carteira ou na conta bancária. Há aplicações disponíveis livremente com funcionalidades que não encontramos nas mais poderosas aplicações comerciais.

Seguindo essa linha, de manter tudo disponível livremente, preciso realizar a migração dos códigos e procedimentos que postei por ocasião dos artigos sobre hash. Eles são baseados em banco de dados para fornecer soluções de filtragem de arquivos usando hashsets. Os códigos e procedimentos funcionam no SQL Server, mas gostaria de manter a linha de usar software livre sempre que for possível, e portá-los para o MySQL seria uma ótima estratégia.

Problema: Ainda não entendo uma vírgula de MySQL. Alguém poderia ajudar e portar os códigos e procedimentos ? Eu publicarei aqui os novos códigos, com os créditos do autor, logicamente.

Quem se habilita ??

Até o próximo post !

Spybot

Bem, estou de volta depois de uma longa série de viagens. Acredito que vou conseguir escrever com mais regularidade a partir de agora.



Por enquanto, estou pegando ainda alguns pequenos assuntos para postar, mas também estou me preparando para alguns artigos mais práticos, na linha do que fiz falando de hash.



Quem nunca ouviu falar do software acima ? O Spybot é um utilitário de busca de malwares sem custo. Quando ele começou, o projeto oferecia exatamente isso, a máquina de busca de malwares. Hoje, na versão 1.5, ele conta com tradução para várias línguas, incluindo o Português do Brasil e tem outros apetrechos muito interessantes.

Neste ponto, você deve estar se perguntando o que isso tem a ver com Forense Computacional. Bom, além de obviamente ser uma boa ferramenta para busca de malware nas imagens, achei uma opção bem interessante nele, que o faz buscar por logs e outros elementos sobre privacidade na máquina. Já percebeu, né ? Esse grande utilitário pode varrer nossos artefatos de maneira rápida e eficiente. Além do mecanismo de busca que permite localizar vários logs diferentes no sistema (fora o tradicional - cookies, temp, etc), ele tem um "triturador", que faz remoções seguras dos arquivos indicados.

Isto posto, acrescente os seguintes pontos importantes nos seus procedimentos de busca:

1) Localizar qualquer instalação do Spybot.
2) Na total inexistência de logs, vale o corolário do HC, que já citei antes: "Ausência de evidências é uma evidência". O usuário pode ter usado as tais funcionalidades do triturador.
3) Os dados que ele registra ficam em Documents and Settings\All Users\Application Data\Spybot - Search & Destroy.
4) Verifique o arquivo Statististics.ini. Localize a chave [Log] e veja a data da última busca na chave LastFound. A chave LastRemoved indica a data da última vez que o usuário apagou os logs.
5) A string Tracks.uti=1 na chave [FileSets] do arquivo Configuration.ini indica que as trilhas de logs, cache, temp, cookies, etc estava selecionada para serem localizadas.
6) No arquivo Overview.ini do diretório Documents and Settings\All Users\Application Data\Spybot - Search & Destroy\Recovery você poderá localizar identificações de arquivos e dados que foram sanitizados, com datas e localizações originais. É uma boa informação para cruzar com as citadas anteriormente.
7) No diretorio Documents and Settings\All Users\Application Data\Spybot - Search & Destroy\Logs você achará grupos de logs das operações realizadas, com detalhes. Os arquivos tem nome

• Checks.aammdd-hhnn.txt, onde as letras são ano,mês, dia-hora,minutos
• Fixes.aammdd-hhnn.txt, onde as letras são ano,mês, dia-hora,minutos

Ambos registram praticamente a mesma coisa. A diferença é que o Fixes indica que o usuário mandou corrigir o que foi examinado e localizado (constando do Checks). Inclusive, lá indica se o fix realmente teve sucesso.

Interessante seria escrever um script que automatizasse a busca desses itens na imagem e nos arquivos removidos. Alguém se habilita ?

Até o próximo post !

Investigador de Forense Computacional

O papo estava bom hoje em torno do assunto de como se tornar um perito em Forense Computacional, na lista PericiaForense.

Achei interessante reproduzir aqui a resposta que postei lá. Segue:

O curso da Axur é muito bom.

O conteúdo é amplo o suficiente e aborda itens que não vi nenhuma outra ementa abordar, até pq não estão presos a uma ferramenta específica. Só não alimente a esperança de sair de lá (ou de qq outro treinamento) um perito. Isso requer tempo, MUITO estudo e dedicação. É uma tecla que o amigo Jossérgio bate o tempo todo, às vezes um pouco mais contundente, mas com toda a razão.

Na primeira semana de dezembro fará um ano que fiz o curso e obtive a certificação. De lá prá cá já devo ter lido para mais de 20 livros de Forense Computacional. Artigos lidos, incluindo blogs e apresentações em conferências internacionais, eu perdi a conta. Devo ter lido, sem exagero, muito mais que cem deles, em geral usando 3 a 4 horas de estudo diário. Parte desses artigos, volta e meia, eu comento no meu próprio blog. No final das contas, a cada novo artigo continuo com a sensação que tem uma ameba ao olhar para o topo de um edifício de 30 andares hehehe. Como ainda temos coisas a aprender ...

Imagino que tenhamos que sacar bem o seguinte:

- A idéia geral de Forense Computacional
- Detalhes muito técnicos de vários sistemas operacionais
- Detalhes muito técnicos de vários file systems de vários SOs
- Detalhes muito técnicos de vários softwares de vários SOs
- Escrever um bom relatório (tem muita gente dando mole aqui)
- Algum embasamento jurídico, principalmente no modelo brasileiro de coleta e apresentação das evidências
- Coletar evidências em situações diversas (dead acquisition/live acquisition, usando HD externo, pen drive, via rede, de PDAs, telefones celulares, etc). Tem até Xbox passando por Forense ...
- Técnicas anti-forenses
- É necessário uma lógica investigativa apurada. Quem já foi desenvolvedor já usou muito isso "catando" bugs em programas. Alguns analistas de infraestrutura idem, buscando onde estão indo parar os pacotes da rede. O curso da Axur aborda uma metodologia legal para ajudar nessa etapa.
- Algumas vezes vai ter que lidar com prazos curtos. É o caso dos peritos policiais, por exemplo.

E, no fim das contas, há novos SOs saindo com novas estratégias, logs, formas de uso, chaves de registry, etc ...

E a lista, com certeza, não está completa ... :)

Gostaria que a turma comentasse a lista. Tenho certeza de que muitos lembrarão de outras competências necessárias.

Até o próximo post !

Obrigado

Recebi várias mensagens, pela lista CISSPBR, parabenizando-me pelo blog.

Fiquei muito contente com o fato, primeiro porque percebo estar atingindo o objetivo, ainda que bem devagar, que é o de disseminar o conhecimento sobre Forense Computacional no Brasil. Em segundo, porque a lista CISSPBR concentra os melhores profissionais do Brasil envolvidos com Segurança de Informações. Receber elogios de caras como BSDaemon e Fábio Ramos me fizeram sorrir de orelha a orelha. Espero continuar merecedor das palavras bacanas desse pessoal.

Grande abraço a todos !

E até o próximo post !

Um pouco sobre Leis

Não é o que você está pensando. Não vamos conversar aqui sobre nosso sistema jurídico e como ele se relaciona com a Forense Computacional.

Este tópico miúdo (é, sei que estou devendo algo mais de peso) está na minha pauta a algum tempo, e como minha consciência anda me cobrando um (PELO MENOS UM !!!) artigo neste mês, vamos falar de leis. Outras leis ...

A idéia é comentar sobre algumas leis que tem sido ligadas a Forense Computacional. São elas a Primeira Lei de Forense Computacional, o Corolário de Harlan, o Princípio de Locard e o Princípio da Incerteza. Vamos lá:

A Primeira Lei da Forense Computacional foi proposta por Jesse Kornblum, um dos papas da Forense Computacional mundial e pesquisador renomado na área de Carving. Ele tem em seu curriculum nada menos que o utilitário md5deep, usado por 11 entre 10 investigadores forenses :)

A lei diz o seguinte:

Toda ação gera uma evidência

Essa lei é uma aplicação direta do Princípio de Locard. Ela afirma que qualquer ação tomada na área computacional deixará artefatos a serem analisados e poderão constituir evidências. Os mais céticos com relação a isso se apressam em dizer, nesse ponto, que há vários itens não logados no sistema operacional. Quando argumentaram isso com Kornblum, ele habilmente contra-argumentou que devemos levar em conta não apenas o sistema ou a máquina onde a ação foi feita, mas tudo que pode ser relevante a ponto de ser analisado e, em conjunto, revelar os fatos. A correlação de eventos, muito em moda nos monitoramentos de ambientes, é a chave para se entender isso. Vamos a um exemplo ?

Não há, pelo menos sem ajuda de produtos à parte, um log no SO que indique que os arquivos X, Y e Z foram copiados para um pen drive ou de um pendrive. Porém, se tivermos o pen drive, podemos deduzir pelos MAC times em ambos (no HD da máquina e no pen drive) a direção da cópia. Se o pen drive for do padrão U3, há um meio de saber exatamente a hora em que foi plugado/desplugado, corroborando as evidências do MAC times. Também é possível corroborar essas datas com o MAC times das entradas de registro a cerca do pen drive.

Um ponto importante é que a Lei não garante que vamos encontrar essa evidência. Se determinada ação gerou artefatos, mas os mesmos foram habilmente removidos por técnicas anti-forenses, pode ser que realmente estejamos encrencados. Isso não contraria essa Lei. Em algum momento, a ação gerou uma evidência.

Corolário de Harlan

Harlan Carvey, um dos melhores autores de Forense Computacional para Windows, apóia-se no que Jesse disse e preparou o seguinte:

Uma vez compreendido quais condições criam ou alteram um artefato, então a completa ausência de artefatos é por si mesma um artefato.

É semelhante a você chegar na cena de um crime e não achar nenhuma digital. Isso é evidência de que o criminoso limpou a cena. (Ok, talvez seja uma conclusão simplista, mas é por aí mesmo).

Trazendo para nossa realidade, se você está analisando uma imagem com pouquíssimos arquivos recuperados na área não alocada, e todos eles completamente zerados, acrescente a investigação, como artefato, que o usuário conhecia técnicas de descarte seguro de informações e/ou técnicas anti-forenses. Para esse usuário, vale a pena aumentar o cerco ...

Princípio de Locard

Já bastante difundido em nosso meio, o também conhecido como Princípio de Troca de Locard afirma que:

Sempre há troca de material quando dois itens interagem

Nesse lógica, sempre haverá evidências deixadas na cena de um crime, e os investigadores também introduzirão mudanças, ao realizarem seu trabalho. Nesse caso, é imperativo que seus procedimentos sejam bem documentados e seus resultados previstos, para que toda troca causada por eles seja reduzida ao mínimo necessário, e sempre com resultados previsíveis. Esse é, por exemplo, o ponto onde muitos defensores (eu também !) da captura da memória para fins de análise. Quem é contra afirma que a própria captura introduz mudanças. Quem defende aceita que as mudanças ocorrerão, mas defendem que, se reduzidas e bem documentadas, são aceitáveis e que a relação custo x benefício para a investigação é muito boa.

Princípio da Incerteza de Heisenberg

Usado originalmente na Física Quântica, define que:

Não é possível determinar ao mesmo tempo a posição correta e o momentum de uma partícula

O conceito original acabou sendo tomado emprestado para definir a mesma dificuldade de algumas situações em Forense Computacional, como o Live Acquisition. Quando optamos por essa técnica, é fato que não será possível obter o dado ao mesmo tempo confirmando a sua integridade, pois como a mídia está em uso, no momento seguinte a leitura do dado o estado da mídia já foi alterado, impossibilitando as técnicas de hash usadas com essa finalidade.

Imagino que existam outras leis sendo adaptadas para aplicação na Forense Computacional. Você conhece alguma outra ? Poderia compartilhar conosco ?

Outro ponto para discussões: Já perceberam o quanto ainda falta para que a Forense Computacional possa mesmo chegar ao status de Ciência, como é hoje a Medicina Legal ?

Até o próximo post !

Área Protegida/Privada

Tenho um pen drive da Kingston com uma capacidade de separar um tanto de sua capacidade para uma área protegida. Essa área só se torna acessível depois de autenticada por um programa (SecureTraveler).

É possível formatar o pen drive através dele, indicando o quando queremos de espaço para essa área protegida. O restante fica para a área pública.

Em meus testes de Forense Computacional, fiz algumas imagens desse pen drive. Em meio aos estudos, me ocorreu que em nenhum momento a tal área protegida foi detectada, por nenhum dos softwares utilizados para a captura da imagem forense.

Por conta disso, percebi que seria possível a um usuário usar esse tipo de artifício para esconder artefatos e evidências. Pior, dependendo do que a Kingston "aprontou", essa mesma técnica pode ser portada para HDs, e teremos aí um ponto de preocupação. Isso porque, para o invertigador atento, não é difícil perceber que o tamanho da imagem não bate com a capacidade escrita no label do pen drive (a maioria afirma sua capacidade externamente, indicando pen drive marca xxx, 512Mb, por exemplo). Porém, a dificuldade nesses casos seria muito maior em caso de HDs, já que nem sempre o acessamos fisicamente para fazer a imagem, de forma a ler suas etiquetas e saber que nominalmente o HD em nossas mãos tem 100Gb, e não 80Gb, como a imagem obtida.

Bom, uma vez pontuada a minha preocupação, fui a caça de entender o que o tal programa faz. Não cheguei muito longe, confesso. Consegui verificar que ele mantém um MBR com apenas uma partição, corretamente indicando seu tamanho previamente setado. Quando chamamos o programa SecureTraveler, ele nos pede a senha, e após a autenticação, o programa fecha automaticamente a janela que exibia arquivos da área publica do pen drive. Ao abrir novamente o explorer (ou outro file manager), já nos deparamos com o conteúdo da área privada. Analisei o pen drive novamente, e verifiquei que ali havia um MBR corretamente setado, com uma partição indicando valores corretos para o tamanho de área privada que eu havia setado anteriormente.

Outros fatos observados:

- Enquanto logado na área privada, o tal programa SecureTravaler fica sempre na memória. Para sair dessa área, retornando a área publica, usa-se um atalho para o próprio programa.
- Como esse sistema e a autenticação funciona em qualquer máquina, a senha obviamente fica armazenada no próprio pen drive.
- Retirei o pen drive sem usar o procedimento de logoff da área privada. A máquina tinha reinicializado, e no seu retorno, a área pública veio disponibilizada. Imagino que isso aponte para uma estratégia onde o programa, na memória, faz todas as traduções entre o que está lá, fisicamente, e o que se pediu, logicamente.
- Um passo interessante poderia ser desassemblar o código para aprender mais sobre a estratégia. Não cheguei nesse passo.
- Como há uma afirmação nos guides do produto, indicando que não é possível setar 100% da capacidade para a área protegida (o máx é 90%), e isso vale para qualquer tamanho de pen drive, podemos supor que realmente o programa deve utilizar alguns setores pré-marcados para guardar as configurações, a senha e o hint dela.


Não estou a par de nenhum caso real onde essa estratégia, ou alguma semelhante, esteja sendo aplicada em HDs. Ainda assim, creio que vale a pena pesquisarmos isso, e tentar mapear uma forma de descobrir se o HD sendo capturado está vindo inteiro.

Alguém já teve conhecimento desse tipo de estratégia ? Gostaria de ver comentários sobre isso, ou talvez alguma discussão de pontos a observar.

Até o próximo post !

**** Editado em 4 de fevereiro de 2008 ***

Má notícia: Estava passeando pela web esses dias e dei de cara com um software que faz exatamente o que esse faz, mas é genérico e também atua em HDs externos, anexados via USB. Isso confirma as minhas suspeitas ...

Modelos Forenses

Li um excelente artigo sobre modelos forenses, assinado por Venansius Baryamureeba e Florence Tushable, ambos da Universidade Makerere, de Uganda.

O artigo analisa alguns modelos forenses atuais e propõe um novo modelo, que seria a extensão do já conhecido modelo IDIP.

Vou listar resumidamente algumas informações sobre os modelos, mas a minha intenção ao comentar o artigo deles aqui é ilustrar algo que comentei no post anterior, sobre termos definido e bem documentado todos os procedimentos a serem utilizados não apenas durante a aquisição da imagem forense, mas também dos procedimentos de análise e até dos procedimentos anteriores ao incidente. A busca de modelos estruturados para Forense Computacional ajuda, na prática, a separar cada etapa do processo de resposta e investigação de incidentes computacionais. Dessa forma, a atividade fica devidamente documentada e estruturada, e as conclusões finais se tornam mais embasadas.

É fundamental que esses modelos sejam estudados e aplicados. Forense Computacional chama para si o status de ciência, mas ainda estamos há quilômetros de distância disso. Ainda assim, não custa dar passos na direção de corrigir isso. Adotar procedimentos estruturados através de modelos é um bom passo nesse sentido.

Mas vamos aos modelos ...

Modelo de Processo Forense
- Modelo de 4 fases publicado pelo Departamento de Justiça americano: Coleta, Exame, Análise e Reporte.
- Algumas críticas são feitas pela forma como as fases de Exame e Análise foram definidas.

Modelo Abstrato de Forense Digital
- Bom modelo composto de 9 fases: Identificação, Preparação, Estratégia de Abordagem, Preservação, Coleta, Exame, Análise, Apresentação e Retorno das evidências.
- Bem mais completo que o anterior, mostra a preocupação com procedimentos mesmo antecedentes ao incidente. Também dedica uma fase para o retorno das evidências ao proprietário.
- De certa forma, esse modelo espelha muito bem as etapas envolvidas no processo de Forense Computacional. Há algumas críticas envolvendo a definição das fases de montagem da estratégia de abordagem e da preparação. Há quem diga que elas poderiam ser transformadas em apenas uma fase com o objetivo de preparar a resposta ao incidente e analisar qual a melhor abordagem para o mesmo. Há quem sugira que o termo Preparação estaria mais ligado a preparar o time de resposta a incidentes para estar pronto para atuar. Seria uma fase anterior a Identificação, e envolveria atividades de conscientização e treinamento da equipe (ou do Investigador, que seja).

Modelo Integrado de Investigação Digital (IDIP)
- Proposto por Brian Carrier, é muito parecido com o modelo anterior.
- Organiza os processos em 5 grupos e 17 fases.
- Dá maior atenção aos processos anteriores à identificação do incidente, detalhando ainda mais o que chamamos de Preparação nos comentários acima.
- O coração do modelo é o grupo de fases Investigação da Cena do Crime Digital. É composta por 6 fases muito parecidas com o modelo Abstrato de Forense Digital.
- É o único que especifica uma fase para revisão da investigação, de forma a estabelecer pontos de melhoria.

Aaron Walters comentou sobre o IDIP e outros aspectos de Live Forensics em sua apresentação para a Black Hat. Vale a pena dar uma lida nisso também.

Seria interessante receber comentários sobre os modelos adotados pelos colegas, se adotam algum, é claro !

Aguardo os comentários. Até o próximo post !

Cuidados no local

Achei interessante destacar aqui alguns comentários que li em uma apostila para o curso de Forensics da universidade americana Kennesaw (KSU).

Papéis a serem exercidos no local - cena do crime.

a) Olhos
Precisamos ter a preocupação de visualizar todo o local e procurar indicações de onde poderíamos encontrar evidências. Isso vai desde, obviamente, o micro, até um pen drive em uma gaveta ou um servidor a quem o micro se conecta.

b) Mãos
O texto, literalmente, diz que apenas uma delas pode ser usada para tocar itens da cena. Eu não vou considerar isso literalmente, já que no nosso caso, os artefatos e evidências estão em meio digital. Entretanto, o ensinamento continua válido no seguinte sentido: Todas as nossas intervenções, e procedimentos, em toda a cena, precisam estar previamente documentadas e seus efeitos conhecidos.
Há várias discussões sobre isso nos fóruns de forense computacional, incluindo sobre se podemos ou não utilizar artefatos obtidos a partir da memória RAM. Minha opinião é que, nas circunstâncias atuais, se nossos procedimentos puderem ser totalmente validados e estiverem documentados a ponto de podermos indicar a que ponto eles podem interferir nos artefatos, então é realmente possível usá-los.

c) Escriba
Todas as ações devem ser documentadas. As evidências colhidas devem ser devidamente armazenadas e a cadeia de custódia deve ser mantida.

Outro grande ponto do texto:

Trate todas as investigações como se fossem terminar em juízo. Vale mais a pena gastar mais tempo, montando devidamente a Ata Notarial, seguindo os procedimentos de captura de imagem e armazenando tudo de acordo com as normas, do que depois o problema acabar em juízo e todas as conclusões serem colocadas em dúvida, ou questionadas porque os procedimentos não foram seguidos. No caso da lei brasileira, isso não acarretaria imediata perda do processo, como nos EUA, mas ainda assim, não vale a pena arriscar.

Comentários ?

Até o próximo post !

Esteganografia

A conscientização das pessoas em relação à Segurança de informações é algo muito bom. Vem acontecendo a passos lentos, é verdade, mas aos poucos podemos perceber que as pessoas estão se inteirando mais dos assuntos, procurando entender melhor qual seria o comportamento ideal ao navegar pela Web.

Na vida, entretanto, nem tudo são flores. O efeito colateral que tenho percebido no aumento da conscientização é que as técnicas para driblar a vigilância digital, ou ainda para esconder as pistas digitais, estão ficando mais comuns. Nos EUA, por exemplo, as técnicas de esteganografia são bastante utilizadas. Aqui em nossas terras ainda é possível ouvir um "estego o quê ???" ao falar sobre isso.

Mas não vai demorar muito.

E é fundamental que o bom investigador de Forense Computacional esteja preparado para esse momento. Por isso imaginei ser importante dar uma breve palhinha sobre esse assunto ( e que vai puxar outros semelhantes).

Estego o quê ????

Esteganografia. Basicamente, é uma escrita escondida. Esteganografia é esconder uma mensagem, usando algumas técnicas, para que somente o seu destinatário possa reconhecê-la. Lembro-me da época de moleque, quando brincávamos de escrever usando certos componentes, e logo tudo ficava invisível. A mensagem só aparecia se esfregássemos um pedaço de batata. Isso é esteganografia. Nos meios militares também há muita utilização, e muitas vezes chamada de covert channels.

Um ponto importante é não confundir esteganografia com criptografia. Na primeira, apenas escondemos a mensagem. Se pesquisado com atenção, ou conhecendo-se o método, facilmente chega-se a mensagem. No caso da criptografia, o texto cifrado só pode ser revelado se estivermos de posse da chave para descriptografar. A mensagem cifrada pode, e em geral, circula totalmente visível, mas seu significado fica conhecido apenas a quem tem a chave.

Algumas formas de esteganografia:

Técnica: Usa métodos científicos para esconder a mensagem. A brincadeira da tinta invisível é uma delas.

Linguistica: Esconde a mensagem no meio portador. Pode ser sub-classificada em Semagramas ou Código Aberto

Semagramas: Usa símbolos e sinais para esconder a mensagem. Um Semagrama visual usa um objeto aparentemente inocente, do dia a dia, para passar a mensagem. Por exemplo, colocar um porta retratos na esquerda da mesa pode indicar uma resposta afirmativa e na direita negativa. Um Semagrama de texto pode esconder uma mensagem simplesmente alterando características do texto, como o tamanho da fonte, o tipo, ou a existência de espaços extras em uma frase.

Código Aberto: Esconde a mensagem em um portador legítimo de forma a passar despercebido para um observador normal. Vemos alguns exemplos desse tipo de comunicação em vários filmes, como por exemplo "O Bom Pastor". Essa classificação também pode ser dividida em Códigos de Jargão ou Cifradores Fechados ou Encobertos.

Códigos de Jargão: É o uso de expressões que só farão sentido para um determinado grupo, ou que só terão o sentido correto para o grupo alvo. Para os outros, será uma mensagem comum. Esse jargão pode ser pré-combinado. Um dos exemplos desse caso são comunicações de rádios-amadores, que conversam sobre assuntos específicos em códigos criados para só fazer sentido ao grupo realmente envolvido.

Cifradores Encobertos escondem a mensagem no portador de forma a somente serem descobertas por quem conhece o método. Nesse grupo está a forma de passar uma grande mensagem, parentemente inócua, mas se tomadas as primeiras letras de cada palavra da frase, formamos a mensagem real escondida. Uma outra forma é a de montar um modelo a ser aplicado sobre uma mensagem inócua. O modelo separa quais letras formarão a mensagem secreta. No filme Con Air, um dos presos recebe uma carta aparentemente inócua, mas a mensagem origianl era obtida pelas letras que ficavam visíveis ao por, sobre a carta, uma figura da Santa Ceia que tinha buracos nos olhos.

A esteganografia que dá mais dor de cabeça para os investigadores computacionais é realmente essa ultima. Usando como portadores arquivos, principalmente figuras jpg e sons mp3 ou wav, vários usuários estão escondendo outros arquivos (que funcionam como sendo as mensagens).

A equação fica: Arquivo-mensagem + arquivo-portador => Arquivo resultado.

Em geral, as alterações são tão bem feitas que ficam praticamente imperceptíveis. Ou seja, após o uso da esteganografia, a figura do arquivo-portador fica praticamente inalterada. As poucas diferenças são praticamente imperceptíveis a olho nu. Também não é fácil perceber, ao escutar um arquivo de som alterado por esteganografia, que o mesmo agora contém uma mensagem escondida.

Por isso, não está sendo incomum encontrar conteúdos impróprios inseridos em arquivos de fotos ou sons. Alguns usuários o fazem para poderem livremente mandar arquivos pelo e-mail da empresa, sabendo que o mesmo é monitorado, e dessa forma poder sair com informações privilegiadas sem perigo de ser descoberto. Há casos de pedófilos que guardam suas fotos criminosas inseridas em arquivos de fotos comuns.

Embora, como disse no início do artigo, ainda não seja tão frequente aqui no Brasil, esse tipo de estratégia já é muito comum lá fora. Minha sugestão é que todo investigador computacional busque e avalie pela existência de arquivos com possível conteúdo inserido via esteganografia.

É possível achar ?

É. Bom, pelo menos até agora. Como tudo em tecnologia e Segurança de Informações nunca é definitivo, e sempre há alguém para criar uma técnica que quebre a que criamos, que quebrava a de alguém, o grande segredo é ficar antenado nas novas técnicas e verificar meios de combatê-las.

As técnicas atuais de esteganografia podem ser detectadas pela análise do arquivo. Em geral, é feita uma análise estatística da distribuição dos bytes. Os que tem essa distribuição fora do que seria considerado normal são contabilizados como portadores de mensagens escondidas. Logicamente, há falsos positivos, e enquanto os pesquisadores do bem trabalham para diminuir os falsos positivos, os caras do mal trabalham em como piorar essa situação. Existem programas que escondem os bits da mensagem (ou arquivo a ser escondido) respeitando a distribuição estatística do arquivo portador, de forma a não cair na verificação. É, vai ser sempre assim, gato e rato mesmo.

Dentro de minha linha de ficar sempre que possível no software livre, vou indicar os softwares do Niels Provos. O OutGuess é encontrado já pronto para uso no Helix, e além de usá-lo para a esteganografia, você pode tentar o StegDetect a partir do raiz da sua imagem montada, mandando-o achar quem supostamente poderia ter mensagens escondidas.

Você verá que o número de falso positivos não é baixo, de forma que uma boa sugestão é filtrar antes os arquivos, e aplicar o stegdetect apenas nos Unknown Files (veja o artigo sobre isso aqui mesmo nesse blog).

Seria interessante que alguém pudesse compartilhar estatísticas do que tem sido encontrado escondido na forma de esteganografia, aqui no Brasil. Quem pode ajudar ?

Um abraço e até o próximo post !

Profiling

Um post recente na lista Pericia Forense, sobre como lidar com um possível cyber crime perfeito, me fez lembrar de um artigo interessante.

Na lista, argumentou-se sobre o que fazer caso um crime usasse como instrumento um computador inicializado a partir de um live CD, e além disso estivesse se protegendo com ferramentas como o TOR.

No fundo, essa argumentação indica uma preocupação que eu já vi em alguns blogs americanos e australianos, de que o pessoal que se aproxima demais da parte técnica da investigação e forense computacional sofre uma tentação enorme de ficar por ali, apenas. O assunto é mesmo instigante e envolvente. Eu costumo dizer que finalmente apareceu algo em TI que é tão interessante e instigante quanto programar. Opinião pessoal, claro, mas afinal é para isso que servem os blogs :D

O "fenômeno" observado pelos nossos colegas do Tio Sam e dos cangurus é que, ligados demais nos aspectos de tecnologia, o pessoal acaba não percebendo que há um mundo todo de artefatos e evidências fora dela, e que precisa ser explorado e, mais ainda, precisa corroborar o que analisamos e descobrimos no mundo digital.

O assunto da lista apontou para isso. O problema foi proposto como um crime beirando a perfeição, e que supostamente seria irrastreável. As respostas focaram sempre no ponto onde poderia ser possível achar alguma pista, talvez o provedor, ou ainda entradas do DHCP ... O que comentei lá, e que vou repetir aqui, é que apesar de existirem várias possibilidades de atrapalhar e obfuscar o trabalho de investigação computacional, com alguns mecanismos, há sempre que se considerar o todo, incluindo análises de motivações, entrevistas com suspeitos, acareações, e todo o resto que compõe já a caixa de instrumentos de um investigador.

Nessa linha, achei um trabalho muito interessante de um pesquisador da área de Forense Computacional. Dr Neil Krawetz, da Hacker Factor, fez uma exposição brilhante em uma das Black Hats, sobre Técnicas de Forense Não Convencional, e o assunto sobre Profiling foi muito bem abordado.

Em termos forenses, uma análise precisa trazer a verdade a luz, indicando fatos. Um investigador precisa cientificamente deduzir a arma do crime, a forma de atuar, baseado em fatos e evidências. Da mesma forma, um investigador de Forense Computacional o faz através de métodos científicos, levantando evidências para corroborar ou negar as hipóteses levantadas. Sempre baseada em fatos e artefatos que configuram-se em evidências. Em uma análise forense computacional, por exemplo, é muito difícil sem margem alguma de erro indicar que Fulano é o criminoso porque sua conta estava com a sessão aberta (logada) na máquina que foi usada para cometer um crime. É comum afirmarmos apenas que a máquina X foi usada para cometer o crime, que não foram encontrados indícios de códigos maliciosos na máquina que poderiam realizar as ações criminosas de forma automática e sem conhecimento do usuário corrente, em sessão, e que da conta em sessão partiram as ações criminosas. Esses são os fatos. Em resumo, a análise Forense Computacional deve ser direta.

Ainda assim, é possível usar técnicas não tão diretas e que podem contribuir para trazer a verdade a luz. São técnicas que, apesar de não serem determinísticas, podem direcionar uma investigação e ajudar a limitar o escopo, acelerando a busca pelo resultado. Essas técnica são chamadas de Profiling, e são comentadas na palestra. Krawetz, inclusive, disponibiliza uma de suas ferramentas diretamente na internet. Essa ferramenta realiza algumas análises estatísticas no estilo e nas palavras de um texto e identifica, com margem razoável de acertos, o sexo do autor do texto. Há análises semelhantes para deduzir se o texto tem mais de um autor, se foi adulterado, se foi copiado de outro local, etc.

Fiquei me perguntando se existe alguma pesquisa sobre esse assunto para textos em português. A técnica é parecida, mas obviamente as estruturas da linguagem pesam nos resultados.

Alguém se habilita ? Seria interessante algo assim para nossas polícias.

Até o próximo post !

Nosso Amigo Hash - Parte VI - Complemento

Hash Aplicado na Forense Computacional - Prática

Usando Banco de Dados e hash parcial

Este é um complemento do artigo anterior, onde estudamos o uso do utilitário ssdeep, que calcula hashes parciais dos arquivos, para fazer a classificação dos arquivos entre conhecidos e desconhecidos, ou ainda para localizar na imagem forense possíveis arquivos maliciosos ou criminosos, mas que receberam algum tipo de alteração para serem descaracterizados.

A técnica, inicialmente, seria substituir o uso da base NSRL (que só contém hashes MD5 e SHA-1) por uma criada por nós, onde o hash dos arquivos seriam computados pelo ssdeep. Essa base tem a tendência de crcescer cada vez mais (e quanto maior melhor, certo ?), porém o utilitário teria problemas de performance e de memória para realizar a operação. Esses problemas já são conhecidos nossos e falamos deles em um artigo passado (Parte V).

A idéia agora é aplicar o mesmo princípio, mas com algumas dificuldades a mais, porque enquanto a comparação com hashes MD5 ou SHA-1 é imediata (se são ou não iguais), a comparação dos hashes parciais precisa de um cálculo entre ambos, indicando o score de proximidade entre os arquivos. Por conta disso, estudei os fontes do ssdeep e converti as partes correlacionadas à nossa necessidade do C para o Transact SQL.

Vamos ao procedimento.

1) Montando uma base de hashes ssdeep:

A base pode ser obtida executando o utilitário ssdeep sobre os arquivos que quisermos catalogar. O comando é:
C:\catalogar>ssdeep -l * > base.txt

Esse comando deve ser usado na primeira vez que estiver carregando a base, e em todas as vezes que for necessário adicionar hashes a base.

2) Importando a base de hashes parciais:

O procedimento de importação é o seguinte (Antes de iniciar, remova a tabela Aux, se existir):

1) Clique com o botão direito sobre Tables e em seguida, clique na opção Import Tables.
2) Indique que o Data Source é um arquivo texto, e indique o arquivo base.txt
3) Deixe as opções default do File Format, mas marque First Row Has Column Names, pois a prmeira linha do arquivo base.txt é um cabeçalho.
4) Clique em Next, e marque Comma como delimitador.
5) Clique em Next e em Next novamente. Troque o nome da tabela destino para Aux.
6) Clique em Next e finalize o processo, importando os dados.

A tabela Aux será criada com os registros importados. Logo em seguida, faça o seguinte:

a) Se essa for a primeira importação da base, execute as seguintes queries no Query Analyser:

select
block=left(ssdeep,charindex(':',ssdeep)-1),
outro=substring(ssdeep, charindex(':',ssdeep)+1, 255),
nome=[1.0--blocksize:hash:hash]
into
#x
from
aux

select
block,
hash1=left(outro,charindex(':',outro)-1),
hash2=substring(outro, charindex(':',outro)+1, 255),
nome
into
sshash
from
#x

Após ser executado, o código acima cria a tabela sshash com a primeira importação dos hashes parciais.

b) Se essa NÃO for a primeira importação da base, execute as seguintes queries no Query Analyser:

select
block=left(ssdeep,charindex(':',ssdeep)-1),
outro=substring(ssdeep, charindex(':',ssdeep)+1, 255),
nome=[1.0--blocksize:hash:hash]
into
#x
from
aux

Insert
sshash
select
block,
hash1=left(outro,charindex(':',outro)-1),
hash2=substring(outro, charindex(':',outro)+1, 255),
nome
from
#x

Após ser executado, o código acima adiciona à tabela sshash os hashes parciais recém importados.

3) Calculando os hashes ssdeep de uma imagem:

Após a imagem montada, deve-se ir para o diretório raiz da mesma e executar o seguinte comando:
/media/mnt>ssdeep -r * > /reports/sshashes.txt

Esse comando calculará os hashes de todos os arquivos em todos os diretórios da imagem.

4) Importando o arquivo de hashes

Esse processo é idêntico ao procedimento 2 em relação a Importação do arquivo para a tabela Aux.

As queries a serem aplicadas logo após são:

a) Caso seja a primeira vez que esse processo estiver sendo usado:

select
block=left(ssdeep,charindex(':',ssdeep)-1),
outro=substring(ssdeep, charindex(':',ssdeep)+1, 255),
nome=[1.0--blocksize:hash:hash]
into
#x
from
aux

select
[case] = 'Codigo-do-caso',
block,
hash1=left(outro,charindex(':',outro)-1),
hash2=substring(outro, charindex(':',outro)+1, 255),
nome
into
sshashComp
from
#x

b) Se essa NÃO for o primeiro caso a ser verificado, execute as seguintes queries no Query Analyser:

select
block=left(ssdeep,charindex(':',ssdeep)-1),
outro=substring(ssdeep, charindex(':',ssdeep)+1, 255),
nome=[1.0--blocksize:hash:hash]
into
#x
from
aux

Insert
sshashComp
select
[Case] = 'Codigo-do-caso'
block,
hash1=left(outro,charindex(':',outro)-1),
hash2=substring(outro, charindex(':',outro)+1, 255),
nome
from
#x

5) Comparando os arquivos da imagem:

Execute no Query Analyser a rotina sscompara. O primeiro parâmetro é o código do caso e o segundo é o score mínimo que desejamos acusar como arquivos próximos.
Ex:
exec sscompara '2007-001', 80

O comando acima vai separar os arquivos do caso 2007-001 que tenham no mínimo 80 de score de proximidade com os arquivos cadastrados, indicando qual é o arquivo na imagem e qual é o arquivo cadastrado.

Ilustrando ...

Imagine que você trabalhe para algum órgão de investigação contra a pedofilia e tenha um diretório cheio de imagens e vídeos com esse conteúdo, capturados e catalogados. Seguindo os passos acima, você poderá criar e manter uma base de hashes parciais, e ao analisar uma imagem forense de um hard disk suspeito, verificar se há algum arquivo na imagem que se assemelhe aos existentes em sua base. Note que se o suspeito usou algum tipo de descaracterização dos vídeos e imagens (troca de bits, crop, etc), ainda assim o método descrito irá indicar a semelhança.

Sugestões de melhoria

- Criar índices nas tabelas
- Criar stored procedures para os comandos após a carga, listados acima.
- Adaptar a rotina sscompara para dar como saída os arquivos da imagem que não tem proximidade nenhuma com a base. Essa alteração é bem simples e vai permitir anular a técnica de Anti-Forense comentada no artigo Parte VI.

Um estudo interessante seria apurar a média do score obtido entre uma imagem original e imagens alteradas a partir dessa, para situações onde apenas um bit é modificado, uso de crops diversos, modificações na resolução, tamanho, ou até mesmo inserção de informações por esteganografia. Alguém se habilita ?

Até o próximo post !

Fontes dos SQLs e Stored Procedures:

CREATE Procedure dbo.eliminate_sequences @seq varchar(255) OUTPUT
as

Declare @ret varchar(255),
@i int,
@j int,
@len int

Set @ret = substring(@seq,1,3)

IF (@ret ='')
return

Set @len = Len(@seq)

Set @i = 4
Set @j = 4

While (@i <= @len) Begin
IF (substring(@seq,@i,1) <> substring(@seq,@i-1,1)) Or
(substring(@seq,@i,1) <> substring(@seq,@i-2,1)) Or
(substring(@seq,@i,1) <> substring(@seq,@i-3,1)) Begin
Set @ret = @ret + substring(@seq, @i,1)
Set @j = @j + 1
End

Set @i = @i + 1
End

Set @seq = @ret

Return

GO

----------------------------------------------------------------------------
Create Procedure dbo.has_common_substring @s1 varchar(255), @s2 varchar(255)
as

If (Len(@s1) <>
Return 0

If (Len(@s2) <>
Return 0

Declare
@i int

Set @i = 1

While (@i <= (Len(@s1)-6)) Begin
If (charindex(substring(@s1,@i,7), @s2) > 0)
Return 1

Set @i = @i + 1
End

Return 0
go

-------------------------------------------------------------------------------
CREATE PROCEDURE dbo.edit_distn @from varchar(255), @from_len int,
@to varchar(255), @to_len int
as

Declare
@row int,
@col int,
@indice int,
@radix int,
@low int,
@swp_int int,
@swp_char varchar(255),
@menor int,
@valor int,
@prim int,
@seg int,
@ter int

Declare @buf table (indice int, valor int)

/* Handle trivial cases when one string is empty */
If ((@from = '') Or (@from_len = 0)) Begin
If ((@to = '') Or (@to_len = 0))
Return 0
Else
Return @to_len
End
Else
If ((@to = '') Or (@to_len = 0))
Return @from_len

Set @radix = 2 * @from_len + 3

If ((@from_len > @to_len) And (@from_len > 2000)) Begin
Set @swp_int = @to_len
Set @to_len = @from_len
Set @from_len = @swp_int

Set @swp_char = @to
Set @to = @from
Set @from = @swp_char
End

Set @indice = 0
If (substring(@from,1,1) = substring(@to,1,1))
Set @menor = 0
Else
Set @menor = 2

Insert @buf values (@indice, @menor)

Set @indice = @indice + 1
Set @low = @menor

Set @col = 1
While (@col < @from_len) Begin
If (substring(@from,@col+1,1) = substring(@to,1,1))
Set @menor = @col
Else
Set @menor = @col + 3

If (@menor > (@col+2))
Set @menor = @col+2

Select @valor = valor from @buf where indice = (@indice-1)

If (@menor > (@valor+1))
Set @menor = @valor + 1

Insert @buf values (@indice, @menor)

If (@menor < @low)
Set @low = @menor

Set @indice = @indice + 1
Set @col = @col + 1
End

/* Now handle the rest of the matrix */

Set @row = 1
While (@row < @to_len) Begin
Set @col = 0
While (@col < @from_len) Begin
If (@row = 0)
Set @prim = @col
Else
If (@col = 0)
Set @prim = @row
Else
Select @prim = valor from @buf where indice = ((@indice + @from_len + 2) % @radix)

If (substring(@from,@col+1,1) != substring(@to, @row+1,1))
Set @prim = @prim+3

If (@row = 0)
Set @seg = @col+1
Else
Select @seg = valor from @buf where indice = ((@indice + @from_len + 3) % @radix)

Set @seg = @seg+1

If (@col = 0)
Set @ter = @row+1
Else
Select @ter = valor from @buf where indice = ((@indice + @radix - 1) % @radix)

Set @ter = @ter+1
Set @menor = @prim

If (@seg < @menor)
Set @menor = @seg

If (@ter < @menor)
Set @menor = @ter

Insert @buf values (@indice, @menor)

If ((substring(@from,@col+1,1) = substring(@to,@row,1)) And
(@col > 0) And
(substring(@from, @col, 1) = substring(@to, @row+1,1))) Begin
If ((@row-1) = 0)
Set @prim = @col-1
Else
If ((@col-1) = 0)
Set @prim = @row-1
Else
Select @prim = valor from @buf where indice = ((@indice + 1) % @radix)

Set @prim = @prim+5

If (@menor > @prim)
Set @menor = @prim

Insert @buf values (@indice, @menor)
End

Select @valor = valor from @buf where indice = @indice

If ((@valor < @low) Or (@col = 0))
Set @low = @valor

Set @indice = (@indice+1) % @radix
Set @col = @col + 1
End

If (@low > 100)
Break
Set @row = @row+1
End

Select @row = valor from @buf where indice = ((@indice+@radix-1) % @radix)

Return @row

Go
---------------------------------------------------------------------------------
CREATE PROCEDURE dbo.score_strings @s1 varchar(255), @s2 varchar(255), @bloco int
as

Declare
@score int,
@len1 int,
@len2 int,
@menor int,
@ret int

Set @len1 = len(@s1)
Set @len2 = len(@s2)

if (@len1 > 64) Or (@len2 > 64)
Return 0

exec @ret = has_common_substring @s1, @s2

If (@ret = 0)
Return 0

exec @score = edit_distn @s1, @len1, @s2, @len2

Set @score = (@score * 64)/(@len1+@len2)

Set @score = (100 * @score) / 64

If (@score >= 100)
return 0

Set @score = 100 - @score
Set @menor = @len1

If (@len2 < @len1)
Set @menor = @len2

if (@score > (@bloco/3 * @menor))
Set @score = (@bloco/3 * @menor)

Return @score
go

----------------------------------------------------------------
CREATE PROCEDURE dbo.spamsum @bloco1 int, @hash11 varchar(255), @hash12 varchar(255), @bloco2 int, @hash21 varchar(255), @hash22 varchar(255)
as

Declare @score int,
@score1 int,
@score2 int

Set @score = 0

IF ((@bloco1 <> @bloco2) AND
(@bloco1 <> (@bloco2*2)) AND
(@bloco2 <> (@bloco1*2)))
return 0

exec eliminate_sequences @hash11 OUTPUT
exec eliminate_sequences @hash12 OUTPUT
exec eliminate_sequences @hash21 OUTPUT
exec eliminate_sequences @hash22 OUTPUT

IF (@hash12 = '') OR (@hash22 = '')
Return 0

If (@bloco1 = @bloco2) BEGIN
exec @score1 = score_strings @hash11, @hash21, @bloco1
exec @score2 = score_strings @hash12, @hash22, @bloco2

Set @score = @score1

IF (@score2 > @score)
Set @score = @score2

END
ELSE
IF (@bloco1 = @bloco2*2)
exec @score = score_strings @hash11, @hash22, @bloco1

ELSE
exec @score = score_strings @hash12, @hash21, @bloco2

return @score
go

------------------------------------------------------------------------------------
-------------------------------------------------------------------
Create Procedure dbo.sscompara @caso varchar(255), @minscore int
as
-- Separa quem tem algum match, obedecendo o score mínimo

Declare @tabCaso Cursor,
@tabBase Cursor,
@score int,
@lbloco1 int,
@lhash11 varchar(255),
@lhash12 varchar(255),
@filename varchar(255),
@lbloco2 int,
@lhash21 varchar(255),
@lhash22 varchar(255),
@nome varchar(255)

Declare @saida table (score int, arq1 varchar(255), base varchar(255))

Set @tabBase = Cursor Fast_Forward
For
Select block, hash1, hash2, [nome] from sshash

Set @tabCaso = Cursor Scroll Read_only
For
Select block, hash1, hash2, nome from sshashComp where [case] = @caso

Open @tabBase
Open @tabCaso

Fetch Next from @tabBaseinto @lbloco1, @lhash11, @lhash12, @filename
While (@@Fetch_Status = 0) Begin

Fetch First from @tabCaso
into @lbloco2, @lhash21, @lhash22, @nome
While (@@Fetch_Status = 0) Begin
exec @score = spamsum @lbloco1, @lhash11, @lhash12, @lbloco2, @lhash21,
@lhash22

if (@score >= @minscore)
Insert @saida values (@score, @nome, @filename)

Fetch Next from @tabCaso
into @lbloco2, @lhash21, @lhash22, @nome
End

Fetch Next from @tabBase
into @lbloco1, @lhash11, @lhash12, @filename

End

Close @tabBase
Close @tabCaso

Deallocate @tabBase
Deallocate @tabCaso

Select * from @saida

go

Nosso Amigo Hash - Parte VI

Hash Aplicado na Forense Computacional - Prática

Contra-ataque contra técnicas de Anti-Forense

Estamos chegando ao final da nossa série sobre o uso de hash nas investigações computacionais. Mas vamos fechar a série com chave de ouro. A idéia desse último artigo é falar de como podemos contra-atacar uma técnica de Anti-Forense de descaracterização bastante discutida em alguns seminários da Black Hat.

Classificando os arquivos - Anti-Forense.

Primeiro, vamos a uma definição. O que é exatamente Anti-Forense ?

Anti-Forense são técnicas que tem por finalidade reduzir a quantidade ou a qualidade das evidências. Na prática, para cada técnica conhecida para análises e investigações, pode haver uma técnica contrária, montada para quebrar a análise em algum ponto.

Vou exemplificar isso fora da Forense Computacional. Um indivíduo que, logo após cometer um crime, limpa todos os materiais presentes na cena para retirar suas digitais, está usando uma técnica de Anti-Forense, justamente porque isso vai reduzir ou eliminar a existência de digitais, e isso é uma das técnicas usadas na análise da cena do crime. Usar luvas para manipular a arma também seria outro bom exemplo.

Saindo do CSI e voltando a nossa realidade de Investigadores Computacionais (será que algum dia lançam uma série sobre a gente ? :D ), há várias técnicas conhecidas hoje com o objetivo de eliminar artefatos ou criar condições artificiais que atrapalhem as técnicas de análise mais conhecidas.

Uma das técnicas mais conhecidas é fazer a Linha de Tempo (Timeline) dos arquivos na imagem e a técnica Anti-Forense criada contra a Linha de Tempo é fazer uso de softwares que alteram ou destroem as informações conhecidas como MAC times. Essas informações são a base para a montagem da Linha de Tempo dos arquivos.

Falamos nos posts passados sobre como classificar os arquivos entre conhecidos e desconhecidos. Essa técnica, baseada em comparar o hash dos arquivos da imagem contra uma base de hashes, é muito útil porque nos permite reduzir sensivelmente o número de arquivos a analisar, focando nos arquivos desconhecidos. Na maioria das vezes, a redução ocorre porque um percentual grande dos arquivos de um HD é composto por arquivos executáveis e arquivos de suporte a aplicações e/ou ao sistema operacional.

Pois bem. Existe uma técnica de Anti-Forense que pega todos os arquivos executáveis, DLLs, etc e altera uma pequena porção deles, em geral inócua para a execução. Ou seja, o executável continua funcionando normalmente. No entanto, mesmo com a mudança de um mero byte, o hash do arquivo muda completamente.

Um exemplo: Os arquivos executáveis de Windows têm em seu header algumas palavras em inglês, indicando que o executável é para ser rodado apenas em Windows ("This program cannot be run in DOS mode"). É possível construir um utilitário para alterar especificamente o byte onde se lê "in DOS mode" para "on DOS mode". Não muda nada para o programa, mas o hash fica completamente diferente.

O resultado disso, se aplicado em todos os executáveis, é que a operação de classificação por hashes vai gerar um número de arquivos desconhecidos muito grande, aumentando o tempo necessário para a análise; em alguns casos, tornando-a inviável por questões de prazo.

Vamos a um pouco de prática:

Calculamos o hash do arquivo md5deep.exe

C:\Forensics\SoftwareWin\teste>md5deep md5deep.exe

7b17a3c9c31de090e59e275795b68df3 C:\Forensics\SoftwareWin\teste\md5deep.exe

Agora calculamos o hash de uma cópia do arquivo md5deep.exe com uma alteração de apenas um byte:

C:\Forensics\SoftwareWin\teste>md5deep md5deep2.exe

17dd22393903da269e54bb5b086dc32f C:\Forensics\SoftwareWin\teste\md5deep2.exe

Repare como o resultado (hash) é completamente diferente.

Uma Nova Esperança ...

Há pouco tempo um pesquisador da área de Resposta a Incidentes - Jesse Kornblum, o mesmo criador do md5Deep - lançou um utilitário que faz um cálculo de hash levando em consideração apenas partes do arquivo. Além de calcular o hash usando essa nova técnica, esse utilitário, conhecido como ssdeep, permite comparar o hash calculado contra uma base de hashes, fornecendo um score entre 0 e 100 que indica o grau de proximidade dos arquivos. Quanto maior o score, mais parecidos serão os arquivos. Score 100 significa que os arquivos são completamente iguais.

Vamos a alguns exemplos:

Primeiro, vamos calcular o hash do arquivo md5deep.exe:


C:\Forensics\SoftwareWin\teste>ssdeep md5deep.exe

ssdeep,1.0--blocksize:hash:hash,filename
768:lHNpDqU/EDXgEzayDYldcJummjytKBNjTe6wV8:FWuEz5kGOytKBNne6w6,"C:\Forensics\SoftwareWin\teste\md5deep.exe"


Agora, vamos verificar o hash do arquivo md5deep2.exe, que conforme já comentamos, é cópia do md5deep.exe com um byte modificado, apenas:


C:\Forensics\SoftwareWin\teste>ssdeep md5deep2.exe

ssdeep,1.0--blocksize:hash:hash,filename
768:bHNpDqU/EDXgEzayDYldcJummjytKBNjTe6wV8:LWuEz5kGOytKBNne6w6,"C:\Forensics\SoftwareWin\teste\md5deep2.exe"

Veja que o resultado é expresso em dois blocos de hash, e nos dois blocos, o valor de saída para md5deep.exe e md5deep2.exe são muito semelhantes.

Agora vamos criar uma forma do próprio utilitário indicar o grau de proximidade entre os dois arquivos.
Primeiro, vamos calcular o hash do md5deep.exe e vamos gravar o resultado no arquivo hash.txt:

C:\Forensics\SoftwareWin\teste>ssdeep md5deep.exe > hash.txt

Agora, vamos calcular o hash do arquivo md5deep2.exe, comparando-o com o hash calculado anteriormente, armazenado no arquivo hash.txt:

C:\Forensics\SoftwareWin\teste>ssdeep -m hash.txt md5deep2.exe

C:\Forensics\SoftwareWin\teste\md5deep2.exe matches C:\Forensics\SoftwareWin\teste\md5deep.exe (99)

O resultado indica que os arquivos são 99% similares, o que comprova a situação, já que modificamos apenas um byte.

Vamos fazer o mesmo teste, agora com o arquivo md5deep.exe (o próprio):

C:\Forensics\SoftwareWin\teste>ssdeep -m hash.txt md5deep.exe

C:\Forensics\SoftwareWin\teste\md5deep.exe matches C:\Forensics\SoftwareWin\teste\md5deep.exe (100)



O resultado indica que ambos são iguais (de fato).



Aplicabilidade do ssdeep



Esse utilitário pode ser aplicado na classificação de arquivos da imagem quando há suspeita de que técnicas anti-forenses foram utilizadas para descaracterizar os arquivos. O único problema para isso hoje é que não há (bem, pelo menos ainda não conheço nenhuma) bases distribuídas de hashes para os arquivos conhecidos, como a base NSRL, que contém hashes MD5, SHA-1.
Se não houver uma referência para os arquivos, precisaremos criar nossas próprias bases. Isso não é tão difícil assim, mas é trabalhoso. Basta usar como base o seu próprio sistema e digitar no raiz:
ssdeep -r -l * > basehash.txt

A opção -r vai caminhar recursivamente pelos diretórios e o -l vai eliminar a path do nome dos arquivos.

Logicamente, convém retirar linhas relativas aos arquivos que não pertecem ao SO ou às aplicações.



Essa base pode ser calculada para vários SOs e softwares e os arquivos concatenados. Porém, há um problema com essa abordagem. Esse utilitário tem a mesma estrutura de comparação que o md5deep (não é a toa, já que foram feitos pelo mesmo desenvolvedor). Por conta disso, o arquivo que funciona como base será carregado para a memória primeiro antes da comparação efetivamente começar. Se você tem acompanhado os artigos sobre hash aqui no blog, vai lembrar do que estamos falando. A memória estoura antes da brincadeira começar ...

Há pelo menos mais duas aplicações interessantes para o ssdeep. É sabido que os códigos maliciosos existentes na internet tem seus fontes disponíveis em vários locais. Isso faz com que muitos lammers editem pequenas partes de códigos de worms e relancem o tal, como uma variação. Em muitas vezes, por ser lançado em pequena escala (em âmbito local), restrito a apenas um país ou estado, as assinaturas dos anti-virus demoram para chegar, e é bem possível que o novo código malicioso, recém modificado, não seja detectado pelo anti-virus. Para resolver isso, podemos criar uma base com os hashes calculados pelo ssdeep sobre os virus, worms e outros códigos maliciosos existentes. Com essa base, poderíamos classificar/detectar os arquivos com códigos maliciosos em uma imagem, mesmo que eles tenham sofrido alterações do virus/worm original.

Outra aplicação interessante, principalmente para nossos colegas da Polícia Federal, seria manter uma base de hashes para cada fotografia apreendida na internet com algo sobre pedofilia. É sabido que localização desse tipo de fotografia através de algoritmos de hash convencionais não é adequada, pois facilmente o usuário pode alterar um simples byte e tornar o hash da figura totalmente diferente. É provável que já existam utilitários que façam essas pequenas alterações. Se a figura for usada em esteganografia, ela continuará praticamente igual, e seu hash será completamente diferente. Por outro lado, se montarmos uma base com os hashes calculados a partir do ssdeep, as figuras alteradas ainda serão detectadas pelo utilitário.

Em ambas as sugestões, teremos o problema de performance e estouro de memória quando a base começar a ficar grande.

A solução para isso virá no próximo capítulo dessa série Nosso Amigo Hash. Será um bônus, já que eu tinha me programado a fechar a série com esse artigo aqui.

Até o próximo post !

Nosso Amigo Hash - Parte V

Hash Aplicado na Forense Computacional - Prática

Classificação de arquivos usando banco de dados

Enfim, cheguei ao tão falado post. Minha cara de pau já estava além da conta, mas realmente foi impossível escrever antes ...

Um ponto importante: Esse artigo é uma adaptação do artigo escrito pelo Mark McKinnon em seu blog.

Apenas relembrando o final do último artigo sobre hash, nosso objetivo maior é classificar cada arquivo em nossa imagem a ser analisada, de forma a indicar se o arquivo é conhecido ou não. Com essa classificação, conseguimos reduzir a ação de análise forense e focar em arquivos que podem realmente ter relevância para o processo. Quem nos apoiará na classificação é a base de hashes (conhecida também por hashset) do NSRL.

Pois bem, o problema é que as ferramentas disponíveis não são eficientes com bases grandes como a do NSRL. Tanto pelo fato da memória lotar com a base (que é realmente gigantesca e é carregada para a memória antes da primeira comparação/classificação) quanto pelo próprio algoritmo de busca na base não ser o melhor para esse fim.


Vamos melhorar isso acrescentando mais uma ferramenta importante à nossa equação: Um banco de dados. A estratégia é dividir o problema em três fases:

1) Vamos criar uma base de dados e popular ela com os hashes da NSRL

2) Vamos passar o MD5Deep na imagem (ela precisará estar montada) e carregar os hashes obtidos em uma outra tabela da base.

3) A classificação dos arquivos poderá ser facilmente obtida com queries SQL a partir daí.


Note que:

- Há um notável ganho com essa solução, principalmente se levarmos em conta que o tempo levado para obter o resultado por uma segunda vez (uma repetição da classificação, por exemplo) é muito pequeno, compreendendo apenas a fase 3.

- A base de hashes da NSRL não é normalizada e repete arquivos com frequência, porque ela registra os arquivos conforme a aplicação que os arquivos pertencem, e é muito comum um arquivo pertencer a mais de uma aplicação ou versão.

- Na verdade, não nos importa saber de qual aplicação, versão ou SO específico é o arquivo em questão. Queremos apenas dizer se o arquivo é conhecido ou não. Isso vai nos facilitar bastante o tratamento, e a base NSRL ficará bastante reduzida.

- Vamos nos ater ao MD5, mas o SHA-1 poderá ser usado, a gosto ;)



Fase 1



Vamos criar a base de dados e carregar a base NSRL. Estou considerando que os quatro discos com a base NSRL já se encontram descompactados e disponíveis. Usarei como servidor de banco de dados o SQL Server, mas o processo pode ser facilmente adaptado para outros SGBDs.


1) Usando a ferramenta Enterprise Manager (ou o Query Analyser, para quem prefere usar DDLs SQL diretamente), crie uma base de dados. Escolha um nome para a base e use as opções default.

2) Abra a base, clique em tables com o botão direito, depois All Tasks e em seguida em Import Table.

3) Na primeira tela do Wizard, escolha para Data Source o text file. Informe, na caixa de texto Filename, o nome do arquivo NSRLFiles.txt. Clique em Next.

4) Deixe as opções default dessa tela, e marque também a check box First Row has Column Name. Clique em Next.

5) Nessa tela, novamente ficaremos com as opções default (delimiter = comma). Clique Next.

6) Na tela Destination, mantenha as opções default. Clique Next.

7) Na tela Select Source Table and Views, permaneça com o nome sugerido para a nova tabela (nsrlfile, o mesmo nome do arquivo a ser carregado). Clique Next.

8) Essa é a ultima tela. Clique Next.


O arquivo será carregado e gerará a tabela nsrlfile. Esse nome já aparecerá na relação de tabelas do banco.


Esse processo deverá ser repetido para o arquivo nsrlfile.txt de cada um dos quatro diretórios (ou discos) da base NSRL. A cada carga, o arquivo será importado e seus dados serão adicionados a tabela nsrlfile criada.


No final do processo, essa tabela estará com milhares de registros, muitos deles duplicados. Tenha em mente que é necessário ter bastante espaço em disco para essa carga inicial. Ela também consome bastante tempo.

Como nosso interesse é apenas indicar se o arquivo é conhecido ou não, podemos retirar todas as duplicações, e ainda por cima podemos retirar também alguns campos da tabela.

Entre no utilitário Query Analyser, conecte-se ao banco recem criado e digite a seguinte query:
Select distinct [md5], [sha-1], FileName into NSRL from nsrlfile

A query acima vai criar uma tabela nova somente com os campos de hash md5 e sha-1, mais o nome do arquivo. Cada registro só aparecerá uma única vez.

Para melhorar ainda mais o acesso no futuro, é interessante criar índices para os campos md5 e SHA-1. Esses índices podem ser criados diretamente com DDL SQL ou na interface do Entreprise Manager. Se optar por essa forma, você deve:
- Clicar com o botão direito sobre o nome da tabela NSRL e clicar no menu Design Table.
- Em seguida, clique no segundo botão da esquerda para direita (Table and Index Properties).
- Ao abrir a janela de propriedades, clique na aba Indexes/Keys e no botão NEW para criar um novo índice.
- Indique o campo MD5 na lista Column Name. Aceite o nome sugerido para o indice.
- Clique novamente no botão NEW, indique o campo SHA-1 na Column Name. O nome sugerido para o índice deve ser mantido.
- Clique em Close e logo em seguida no primeiro botão da esquerda para direita, para salvar as alterações.

Lembre-se que essa operação pode demorar bastante, já que a tabela é bem grande. Aqui, nós estamos criando dois índices distintos para facilitar as consultas posteriores.

Ao final dessa fase, temos a base NSRL completamente carregada, sem duplicações, e indexada na tabela NSRL. Vamos para a próxima fase, mas antes exclua a tabela nsrlfile.

Fase 2

O objetivo dessa fase é obter um conjunto de hashes da nossa imagem, e em seguida carregá-los para nosso banco. Na fase 3 faremos a classificação propriamente dita.

O conjunto de hashes é obtido através do uso do MD5Deep (ou o SHA1Deep). Vamos manter nosso foco para o MD5, mas os passos para o SHA-1 são análogos.

- Inicialmente, monte a imagem sendo analisada. Provavelmente, você estará com um Live CD de análise de forense computacional, como o Helix ou o FCCU.

- Vá para a raiz da imagem montada e use o comando MD5Deep -r * > resultado.txt

Esse comando faz com que todos os arquivos tenham seu hash calculado, desde a raiz, e de forma recursiva. Toda a saída do comando é jogada para o arquivo resultado.txt. Lembre-se que essa operação pode ser demorada, de acordo com o tamanho da imagem e do número de arquivos nela.

O próximo passo é carregar esse arquivo para uma tabela na nossa base. Não vou entrar em detalhes novamente, pois o processo é o mesmo de quando carregamos os arquivos nsrlfile.txt. Apenas leve em conta que, nesse caso, nao há nomes de campos na primeira linha e como separador de campo indique dois espaços. Observe que o próprio programa de carga já mostra as primeiras linhas carregadas, com nomes de colunas col001 e col002. Confira se está tudo certinho e indique aux como nome da tabela a ser criada com esse resultado. Novamente, essa operação será longa, dependendo do tamanho do arquivo a ser carregado.

Ao final dessa operação, teremos uma nova tabela chamada aux com duas colunas (Col001 e Col002). Vamos ao Query Analyser rodar um comando SQL que vai criar uma nova tabela a partir dessa, acrescentando um campo para o código do caso. Com esse código, sempre poderemos guardar as informações relativas ao caso e consultar quantas vezes quisermos.

Select [Caso] = '2007-001', [md5] = Col001, Arq = Col002 into Hashes from Aux

Confira se o conteúdo da tabela Hashes está igual ao da tabela Aux. Exclua a tabela Aux (vamos salvar espaço, certo ?) e crie índice para o campo MD5 da tabela Hashes.

Ao final dessa fase, nós temos uma base de dados com duas tabelas: a NSRL, com toda a base de hashes da nsrl, sem duplicações e campos desnecessários, e a tabela hashes, já carregada com os hashes da imagem do nosso primeiro caso. Todas devidamente indexadas.

Vamos para a próxima fase ...

Fase 3

Essa é a hora da verdade ... Vamos executar duas queries. Uma imprimirá os arquivos conhecidos e a outra os não conhecidos. Usando o Query Analyser:

Select CONHECIDOS=Arq from hashes h left outer join nsrl n on h.md5 = n.md5
where
caso = 'codigo do caso'
and
n.md5 is not null

Select DESCONHECIDOS=Arq from hashes h left outer join nsrl n on h.md5 = n.md5
where
caso = 'codigo do caso'
and
n.md5 is null

A saída de cada um pode ser usada em análises mais minuciosas. Ela equivale à saída do comando MD5Deep com as opções comentadas no último post sobre hashes.

Comentários e melhorias

- As duas queries acima podem ser gravadas como stored procedures, passando o código do caso por parâmetro. Ficará mais fácil para re-executar as classificações

- O tamanho da base ficará enorme, mas pouco utilizado. Um comando de Shrink Database é interessante para recuperar o espaço.

- Backup é fundamental. Faça um backup logo após o término de cada fase, para garantir.

- Uma abordagem alternativa é fazer o Shrink Database logo após o término da Fase 1. Faça um backup em seguida, e assim ganhará mais tempo e gastará menos espaço no backup.

- A fase 3 será executada todas as vezes que você quiser reclassificar os arquivos. Melhor do que fazer isso é gravar as duas saídas ...

- Se quiser adicionar os hashes de um novo caso/imagem, a operação é bem simples. Obtenha o arquivo com os hashes (como no caso do resultado.txt). Carregue-o para uma tabela aux, como no processo da fase 2. Logo em seguida, no Query Analyser, execute a seguinte query:

Insert hashes select Caso = 'codigo do novo caso', [md5] = Col001, Arq = Col002 from aux

Esse comando SQL vai inserir a tabela recem carregada para a tabela de hashes definitiva. Exclua a tabela aux, ao final. A partir daqui, execute as queries da fase 3 para classificar os arquivos.

- O processo explicado acima pode ser feito em uma passada só, diretamente na carga. Se você conhece o SQL Server, vá em frente !

- A NSRL libera versões novas 4 vezes por ano. A fase 1 precisará ser refeita todas as vezes, se você quiser se manter atualizado com as versões.

- Uma boa opção é montar uma base própria de hashes contendo figuras, musicas e outros itens. Recomendo colocar esses em uma tabela a parte, carregando-a da mesma forma que os arquivos anteriores. As queries da fase 3 precisarão de uma adaptação, pois a classificação será feita a partir de uma union da tabela NSRL com a tabela criada por você.

- É possível inserir mais um nível de classificação: Quebrar os arquivos conhecidos em bons e maus. Basta criar mais um campo na tabela NSRL com o default de ser bom. Na tabela acima, com seus próprios hashes como base, sempre que um arquivo for reconhecido como mau, o tal campo deve ser setado de acordo.

Finalmente ...

Demorou, mas chegamos ao fim dessa parte do artigo. Vou parar por aqui comentando o seguinte:

1) Você aprendeu que a classificação de arquivos é muito importante, pois com ela diminuímos os arquivos a serem analisados, tornando a investigação viável e mais focada.

2) Você aprendeu também que se modificamos apenas um mero bit em um arquivo, o resultado da computação do hash dele vai ser completamente diferente do original. Veja bem ... Estamos falando de mudar um mísero bit !

De posse das duas informações acima, pense junto comigo o que alguém poderia fazer para piorar a vida de um Investigador Computacional...

Certo, você percebeu ! Se um usuário mal intencionado trocar apenas um bit, ou byte, de todos os arquivos no HD, a classificação desse HD diria que todos os arquivos são desconhecidos. Isso inviabilizaria (ou tornaria muito difícil) a investigação. Essa técnica é conhecida como Anti-Forensics (é uma das técnicas usadas, na verdade), e pode atrapalhar um bocado a nossa investigação.

Mas nem tudo está perdido !

No próximo artigo sobre hash, vamos falar de uma solução bastante nova para esse problema.

Até o próximo post !