sexta-feira, 30 de outubro de 2009

Caine 1.0

Ainda está quentinho do forno. Acabou de sair a versão mais nova do mais promissor live cd de Forense Computacional disponível no momento. O Caine 1.0, agora sob liderança de Nanni Bassetti, traz algumas novidades:

- WinTaylor, interface para uso no Windows, com vários utilitários úteis em Resposta a Incidentes
- Página HTML para executar os utilitários do Windows (útil quando por alguma razão o WinTaylor não funcionar)
- Atualização do Ntfs-3g para a versão 2009.1.1
- Nova opção de boot: text mode.
- Atualização dos pacotes do Ubuntu 8.04
- Firefox 3.0.14
- Gtkhash, interface gráfica para cálculo de hash de arquivos
- Novidades nos relatórios: Adicionado campos de nome do investigador e caso
- Relatório traduzido em vários idiomas: italiano, inglês, alemão, francês and português (minha contribuição ao projeto)
- Documentação dos utilitários em formato html, exibida no start do Firefox
- Novas ferramentas

Já estou baixando o arquivo .iso, e tão logo possa, eu postarei aqui uma análise dessa nova versão.

Alguém já está usando-a ?

Até o próximo post !

terça-feira, 27 de outubro de 2009

Treinamentos - Novas turmas

CFPF - Novas turmas

Trago boas notícias. O nosso treinamento em Forense Computacional - CFPF - está com novas datas e possibilidades. Além de turmas em horário integral e horário noturno, conseguimos expandir e agora oferecemos o treinamento em várias capitais.

Falando um pouco do treinamento, ele é baseado em software livre, em várias distrôs forenses como Helix, Caine e outros. Ministramos tanto a parte teórica quanto muitas práticas, além de abordar conteúdos de Forense Computacional e Resposta a Incidentes.

Clique no banner ao lado (ainda bem que não tento ganhar a vida como designer, hein ? hehehe) e verifique as datas e opções. Caso você tenha interesse, mas não tenha opções de datas interessantes, entre em contato comigo e podemos ver outras possibilidades, inclusive de treinamento on-site, para equipes inteiras de TI/InfoSec.

Até o próximo post !

segunda-feira, 26 de outubro de 2009

PeriBr

Tive uma grata surpresa ao ler um dos comentários no Forum Perícia Forense sobre o PeriBr, um live cd desenvolvido como trabalho de final de curso na UCB. Segundo Marcel Carvalho, que também é marido da criadora do PeriBr, Jaqueline Carvalho, o novo live CD possui as seguintes características:

* Estão embutidas ferramentas como PyFlag, PTK , Autopsy, Guymager e Dhash;
* O menu está todo categorizado de acordo com as fases de uma perícia;
* Embutido o menu USP (Ubuntu System Panel), traduzido para o pt_BR;
* Foram criados scripts para cada uma das ferramentas que exibe uma ajuda sobre elas;
* Não monta automaticamente dispositivos, e quando o faz por padrão fica com RO (read-only);

A grata surpresa vem pelos comentários, que transcrevo abaixo:

"Cabe aqui uma menção ao trabalho escrito da monografia em questão, que mostra um grupo de distribuições que foram usadas como base para o trabalho, entre elas o FDTK.
Uma diferença básica, e que está descrita como um problema da versão atual do FDTK, é o toolkit PyFlag que existia em versões anteriores e que na atual versão não está funcionando por problemas de incompatibilidade, outra diferença é o toolkit PTK que encontra-se
instalado no PeriBR e não no FDTK, mais algumas ferramentas da distribuição DEFT que foram incluídas no PeriBR e também não existem no FDTK.

Uma inclusão agradável, na minha opinião, foi o menu USP (ubuntu System Panel), que foi a base do MintMenu para quem conhece. Foi feita uma tradução para o pt-BR desta ferramenta, o que não existia ainda, e ela foi incluída no PeriBR. O MintMenu é muita mais agradável de se
operar, porém ele muda muito o Ubuntu, tentando transformá-lo no LinuxMINT ;)

Porém como disse anteriormente e é citado no trabalho escrito, a distribuição FDTK foi usada como base, além do DEFT, Helix, BackTrack, FCCU e o Caine. Também é feita uma referência elogiosa ao blog do Tony Rodrigues e ao seu trabalho em http://www.slideshare.net/tonyrodrigues/computacaoforense0800tony-rodriguesv1 de onde várias idéias foram tiradas.

A idéia de divisão por etapas da perícia foi baseada no trabalho do Aderbal e Neukamp, criadores do FDTK.

O trabalho de pós-graduação realizou a idéia dada por Tony Rodrigues: "Faça o seu". Ou seja, faça a sua distribuição com as ferramentas que te interessam. O objetivo final era criar uma distribuição com as ferramentas que o perito deseja ter. Mostrar que isso não era uma tarefa impossível, e passar um caminho a ser seguido aos que desejam criar seu próprio
conjunto de ferramentas."

Algo que eu disse e digo já faz algum tempo é que esse blog nasceu para ajudar. Ver que isso está de fato acontecendo, ao ponto de ser usado como referência para uma nova distrô forense e um trabalho de monografia, é mais que gratificante. É sentimento de missão cumprida.

O trabalho que foi referenciado pelo Marcel é uma compilação de vários estudos que fiz e coloquei aqui no blog. Ele acabou virando uma palestra, que inicialmente foi criada em inglês para uma conferência marcada para junho de 2009 em Lisboa, mas acabou não acontecendo. Por fim, eu a utilizei no CNASI do Rio de Janeiro, em março de 2009.

Eu aproveitei para enviar ao Marcel algumas sugestões para a versão 1.1:

1) Coloque o Wine e, a partir disso, vários utilitários Windows interessantes (nem todos funcionam; eu estou com uma idéia de um projeto para isso, seria bastante útil)
- Já falei aqui em um artigo recente de como o Wine pode ser usado com sucesso para permitir o uso de ferramentas Windows em ambientes Linux e, com isso, podermos unificar o conjunto de ferramentas de análise.

2) Compilar o SleuthKit com vários tipos de imagem (formatos) e sistemas de arquivos. O HFS está crescendo em uso e nem todas as ferramentas o compilaram
- A versão mais nova do Helix deu uma melhorada nisso, mas até bem pouco tempo, só se conseguia analisar imagens no formato AFF e Expert Witness no Caine.

3) Voltar com o SAMBA para o pacote. A maioria dos novos Live CDs o retirou.
- É muito útil nas trocas de arquivo via rede. Não é indispensável, mas sem ele ficamos sem uma opção interessante de captura de imagem para locais remotos.

4) Drivers de wireless. Isso vem sendo um problema para notebooks, já que na maioria das vezes nos conectamos via Wi-fi.
- É um grande problema. A maioria não carrega rede wireless.

5) Perl e Python + RegRipper e Volatility com plugins atualizados
- Nesses tempos modernos, Forense de Registry e de Memória são bastante úteis para um investigador.

Vou incluir mais uma que não coloquei no email: Suporte a teclado ABNT2. Quem comprou laptop no Brasil tem sempre um problema para ajustar o teclado ...

O projeto está hospedado no SourceForge. Clique aqui para baixar o arquivo .iso.

Em breve vou postar aqui uma análise do mais novo live cd brasileiro.

Comentários ? Algumas idéias a mais para o projeto ?

Até o próximo post !

quinta-feira, 15 de outubro de 2009

Anti-Anti-Forense

Esse é o tema sobre o qual estarei falando na 6a edição do mais importante evento Hacker do Brasil - o H2HC - Hacker-2-Hacker Conference. O evento será no final de semana de 28 e 29 de novembro, em São Paulo.

Já faz algum tempo que venho olhando esse assunto com atenção. A primeira vez que li sobre esse termo foi em uma palestra feita pela turma do projeto Metasploit. A palestra procurava expor fraquezas em algumas técnicas ou ferramentas usadas em Computação Forense.

Depois dessa palestra, anti-forense entrou para o abstrato. Tudo seria resolvido por anti-forense, e os peritos estavam com os dias contados. Não levaria muito tempo e todos aplicariam os conceitos que, por hora, apenas alguns Hackers Jedi conheciam. Com o passar do tempo, chegamos ao ponto de perceber uma certa disputa, quase um clima de guerra. Hackers que escrevem sobre o assunto desdenham dos investigadores e colocam as técnicas como imbatíveis. Os peritos, por outro lado, usam de grande ironia e expõem a questão como se fosse brincadeira de criança resolver qualquer coisa relacionada a isso. Vi muitos desses textos enquanto pesquisava alguns detalhes para a palestra.

Nem "rocket science" nem algo trivial. Anti-Forense deve ser visto como crítica construtiva e pode ajudar (e muito !) no combate aos crimes, uma vez que tira o perito de sua posição de conforto e o faz repensar nas suas técnicas e ferramentas. É com esse intuito que venho pesquisando algumas técnicas, principalmente como poderiam ser detectadas ou revertidas. O ponto comum nas técnicas de "contra-ataque" é que, em algum momento, algo aparece. Harlan Carvey costuma usar uma analogia com técnicas militares, onde mesmo o melhor e mais prudente snipper precisa fazer alguns movimentos, comer, dormir ... É nessa hora que ele pode se expor, e de forma análoga, quando o malware, o atacante ou o utilitário são usados, marcas e vestígios importantes aparecem. É só estar bastante atento a elas.

Espero vê-los por lá. Será uma boa oportunidade para conhecer a turma que acompanha o blog.

Até o próximo post !

sexta-feira, 9 de outubro de 2009

Tempos modernos

Esse post é quase off-topic. É um grande elogio e agradecimento à proximidade que a Internet nos trouxe.

Estava escrevendo um material para apresentar no H2HC quando tive uma dúvida. Postei a pergunta em dois fóruns internacionais que faço parte; Em um deles, fui atendido por um dos pesquisadores do NIST, Doug White, que entre outras coisas é responsável pela NSRL. A minha pergunta era exatamente sobre a NSRL oferecer ou não uma base de hashs fuzzy, já que eu tenho a base corrente, e só tem MD5 e SHA1 nela. Ele me informou que eles já tem os valores calculados, mas o hashset não está publicado por pouca demanda. Nós "conversamos" sobre isso e acho que vamos ter a base publicada. Comentei com ele sobre alguns detalhes da minha palestra e ele entendeu a importância e a relevância que a base terá. É só aguardar ...

Na outra lista, nova resposta ilustre. Quem me escreveu foi nada mais nada menos que Jesse Kornblum, o próprio criador do ssdeep e dos outros inúmeros "deeps" que temos. Além desse trabalho, Jesse também é o autor da Primeira Lei da Forense Computacional, que já tratamos aqui no blog.

Tanto um quanto o outro foram extremamente gentis e dispostos a ajudar. Não faz muito tempo, eu também estava trocando emails com Matthieu Suiche, autor de inúmeros utilitários de Forense de Memória, tais como o Sandman e o win32dd. Emails com o Harlan Carvey (o papa do Windows Registry) já se tornaram comuns e já escrevi aqui sobre ter consultado diretamente o pesquisador que quebrou o MD5 em um certificado digital.

Isso não é sensacional ? Ter ao alcance do teclado a opinião de verdadeiros gênios da nossa ciência ? A Internet faz mesmo o mundo ficar menor ...

Comentários ?

Até o próximo post !

segunda-feira, 5 de outubro de 2009

Bad Sectors

Li uma matéria bastante interessante na revista Digital Investigation. A matéria nem é tão nova assim (é de 2007) mas o assunto vale um reforço.


O sonho de todo Perito é chegar, depois de longas horas fazendo uma imagem forense, a uma tela informando que tudo terminou bem. Topar com bad sectors e/ou bad clusters pode ser uma grande dor de cabeça. O hash do dispositivo não vai bater com a cópia e ainda tem a possibilidade da operação parar e nos obrigar a fazer tudo de novo.


O artigo trata exatamente de um estudo a respeito do comportamento de algumas ferramentas de captura de imagem forense quando encontram bad sectors. O estudo foi feito por dois pesquisadores do NIST e usaram os seguintes critérios nos testes de ferramentas:


1) A ferramenta deve capturar todos os setores que não estejam ruins;

2) Ela deve identificar os setores que estão ruins na imagem;

3) Ela deve preencher com dados documentados os setores da imagem que são relativos aos setores ruins do dispositivo. Por exemplo, se um HD estiver com os setores 10,11 e 12 ruins (bad sectors), então esses mesmos setores da imagem deverão ser preenchidos com padrões reconhecidos e bem documentados.


Com esses critérios, a pesquisa realizou uma série de aquisições de imagens usando HDs com bad sectors devidamente mapeados. Vários utilitários foram usados nessas aquisições, e a forma de conectar o HD à estação forense também foi documentada (por firewire ou diretamente). O resultado não foi muito animador ...


Apesar de terem testado poucas ferramentas, fica nítido a falta de capacidade do dd e seus genéricos atenderem ao que foi especificado. Os que melhor saíram no teste foram o IXimager, do iLook e o dd do BSD. Os outros todos deixaram de ler setores bons que estavam nas proximidades dos setores ruins. Além disso, os setores da imagem relativos aos setores ruins do HD foram preenchidos com lixo pelo dd do FreeBSD (os utilitários dd baseados no Linux preenchem com zeros, corretamente).


A questão de não ler setores bons nas proximidades de setores ruins tem relação com tamanho do bloco de leitura. Imagine que o dd foi configurado para ler blocos de 4k e o HD sendo capturado possui um setor danificado de 512 bytes. Em determinado momento, a requisição de leitura irá falhar porque dentro do bloco de 4k lido estará o setor defeituoso de 512b. No fim das contas, todo o bloco de 4k na imagem receberá zeros, e não apenas os 512b realmente defeituosos. Dos oito setores dentro de um bloco, apenas um estava defeituoso mas todos os outros sete ficaram desperdiçados. Nesses sete blocos desperdiçados podemos ter dados importantíssimos para o caso, definindo-o.

O estudo não contemplou outras ferramentas, mas gostaria de citar que há um conjunto especialmente desenvolvido para tratar erros de leitura em bad sectors:

- RDD
- DD_Rescue
- ddrescue

Além de realizarem as operações normais de captura (dd), essas ferramentas podem trabalhar com tamanhos de blocos de leitura que podem variar, se encontrarem um bad sector. Dessa forma, no exemplo anterior, a ferramenta tentaria ler o bloco de 4k e ao receber o erro de leitura, ela tentaria novamente, agora com um bloco da metade do tamanho (2k). Se conseguir, ela avança com o processo; se não, continua a dividir o tamanho do bloco até que tenha sucesso na leitura ou chegue no tamanho mínimo de 512b. Pela lógica, a ferramenta não lerá apenas os setores que realmente estiverem danificados.

Além disso, as ferramentas podem ser configuradas para iniciarem a operação em sentido inverso, dos últimos setores para o primeiro. Em alguns casos, mesmo alguns setores ruins conseguem ser lidos dessa forma.

Comentários ? Alguém quer compartilhar suas experiências com essas ferramentas ou com bad sectors ? Participe !

Até o próximo post !

quinta-feira, 1 de outubro de 2009

Recupera ou não recupera ?

Um assunto balançou recentemente as estruturas de uma lista de discussões sobre Forense Computacional. Foi sobre um artigo e uma entrevista do CEO da Techfusion, uma empresa especializada em recuperação de dados. Nessa entrevista, o CEO alega terem conseguido recuperar dados apagados e sobre-escritos de um disco. Obviamente, isso causou um grande burburinho, primeiro porque foi em um caso famoso, onde os dados foram apagados enquanto estavam sob custódia da Polícia. Além disso, já há bastante "snake-oil" sobre esse assunto, muita gente diz que dá para recuperar e quem é especialista no assunto dizendo que não dá.

Esse assunto foi trazido na lista de discussões, e os especialistas lá conversaram sobre a entrevista. Dentre os comentários mais interessantes, cabe destacar:

- A opinião de todos é unânime em afirmar que não se consegue recuperar conteúdo sobre-escrito;
- O entrevistado, por ser um CEO, não tinha muito domínio técnico, e por vezes cometeu pequenas gafes técnicas;
- Alguns falaram sobre usar aquecimento/resfriamento como parte das técnicas, mas o Dr Craig Wright, experiente no assunto, negou que isso realmente ajude em recuperar arquivos sobre-escritos. Pode ser que ajude na recuperação de HDs que não leem por algum motivo, mas não recupera dados sobre-escritos.
- Além da re-afirmação de que não dá para recuperar dados sobre-escritos, um dos comentários mais interessantes foi o de que recuperar arquivos sobre-escritos pode ser possível. Apesar de tal recuperação não ser possível a partir de dados sobre-escritos, pode ser possível localizar fragmentos de um arquivo temporário que passara por um wipe. Por exemplo, um arquivo Word pode ser recuperado, mesmo depois de um Wipe, através do temporário que é aberto e depois apagado (aqueles arquivos que começam com um ~). Ou seja, não se recupera o dado sobre-escrito, mas é possível achar conteúdo que pertenceu ao temporário do arquivo, solto pelo disco.
- Ainda assim, o Dr Craig afirma que não seria o caso se um disco fosse passado por um processo completo de Wipe, já que dessa forma mesmo os fragmentos seriam também sobre-escritos.

Comentários ?


Até o próximo post !