Imagens Forenses II

Fazendo a aquisição das imagens


Há várias formas de se realizar a aquisição ou captura de uma imagem forense. Vamos falar um pouco de cada uma.

RAW

A imagem RAW é a mais comum, e a que possui mais ferramentas disponíveis para a sua aquisição. No entando, antes de falar diretamente da aquisição, vamos falar da diferença entre imagem física e imagem lógica.

Um dispositivo de armazenamento ou mídia (um HD, um disquete ou até mesmo um pendrive) possui uma tabela interna que indica como o dispositivo está dividido nas partições. Disquetes e pendrive, na maioria das vezes, possuem apenas uma partição. HDs, por outro lado, comumente são particionados de forma a organizar melhor o armazenamento de arquivos.

Uma imagem lógica é uma imagem forense de uma partição apenas. Uma imagem física contém todas as partições do dispositivo mais a tabela de partições. Por exemplo, se temos um HD com 3 partições em uma máquina com Linux, carregando esse HD como um device hda, teríamos:

Imagem física => /dev/hda

Imagem lógica => /dev/hda1, /dev/hda2 ou /dev/hda3

Através do Helix, temos opção de usar tanto a linha de comando quanto interface gráfica para realizar a aquisição raw.

A maneira mais simples de fazer uma aquisição é usando o utilitário DD:


dd if=/dev/hda of=imagem.dd conv=noerrors,sync bs=512

Essa linha de comando fará a imagem do HD (device) conectado como hda para o arquivo imagem.dd, no diretório corrente.

Apesar de ser a maneira mais simples, o utilitário dd não oferece algumas funcionalidades importantes. Por conta disso, criaram alguns "primos" muito bons desse utilitário.

O dd_rescue, presente no Helix, serve para realizar aquisições de mídias com problemas. Em algumas situações, mesmo assinalando a opção conv=noerrors, o dd é interrompido ao encontrar erros na mídia. Nesse caso, recomenda-se usar o dd_rescue.

O sdd, também presente no Helix, realiza aquisições mais rápido do que o dd, quando o tamanho de bloco dos devices de origem e destino são diferentes. Você pode usar o tamanho de bloco default de cada device, mas se quiser, pode determinar o tamanho com o comando sfdisk -l . Veja o exemplo:

sfdisk -l /dev/hda

O dcfldd é o primo mais ilustre e conhecido do dd. Ele tem implementado algumas rotinas específicas para aquisição de imagens forenses. Por exemplo, ele possui um log de toda a operação, faz divisão da imagem (split) e permite verificar diretamente a integridade da operação através de vários algoritmos de hash. Também está disponível no Helix. Esse é o mais indicado quando se trata de imagens raw em linha de comando.

O rdd foi desenvolvido pelo Netherlands Forensic Institute (NFI) e sua documentação indica que ele é bem robusto em relação a tratamento de erros, divisão de arquivos (split) e hash. Ele não está disponível no Helix. Além de poder incluí-lo usando a técnica comentada anteriormente nesse blog, ele está disponível no pacote forense FCCU.

As interfaces gráficas são, em sua maioria, formadas para deixar que o investigador indique as opções da aquisição, e em seguida essas opções são passadas para um dos utilitários em linha de comando.

O Adepto, presente no Helix, oferece log sobre toda a operação e a possibilidade de se escolher entre usar o dcfldd (formato raw) ou ainda o AFF, para o formato Advanced Forensic Format, comentado no artigo anterior. Na interface também indicamos qual algoritmo de hash será usado para validar a operação e se queremos dividir o arquivo da imagem em porções menores (split). Ele permite também fazer a aquisição tendo como destino um dispositivo montado (local), um dispositivo SMB (Samba ou mesmo um compartilhamento Windows) ou então via netcat.

O Air, presente no Helix, não é tão completo quanto o Adepto em termos de log, e oferece captar a imagem através do dd ou do dcfldd. É possível determinar o algoritmo de hash (md5 e SHA-1) e enviar a imagem capturada através da rede com netcat ou cryptcat (netcat criptografado).

A versão 12 do FCCU, recém liberada (vou comentar no próximo post) traz uma nova interface gráfica para aquisições de imagem forense: o GuyMager. Ainda não testei, mas sua documentação indica que foi concebido para tirar vantagem de máquinas com mais de um núcleo de processamento, muito comuns hoje, tais como o Core 2 duo da Intel.

EWF

O formato EWF (Expert Witness, ou E01) é o formato proprietário do EnCase. Ele pode ser obtido com a ferramenta Linen, presente no Helix, ou com o GuyMager, comentado acima, presente no FCCU. O FTK Imager também pode ser usado na aquisição, diretamente da parte Windows do Helix.

AFF

O formato AFF pode ser obtido através do aimage, um utilitário disponibilizado pela afflib, presente no Helix. Ele é semelhante ao dd, e em sua forma mais simples pode ser usado como no exemplo a seguir:

aimage /dev/hda imagem.aff

Conforme comentado acima, o Adepto é uma interface gráfica que permite selecionar o formato AFF como saída. Internamente, ele faz a chamada ao aimage, repassando os parâmetros selecionados.

SGZIP

Não há um utilitário de captura direta para o sgzip. Na verdade, o utilitário sgzip faz uma conversão do formato raw (dd) para o formato compactado sgzip. O que é feito normalmente, afim de evitar que seja gravado primeiro o formato raw, para depois ele ser convertido, é não indicar o parâmetro of (saída); dessa forma, a imagem vai para a saída padrão, e daí redirecionamos para a entrada do utilitário sgzip:

dd if=/dev/hda sgzip -v > imagem.sgz

Conversores

Existem várias formas de se converter um arquivo de imagem entre os formatos. Os mais comuns são:

sgzip: Converte formato raw (dd) para o formato sgz, que é um formato compactado. Disponibilizado pelo PyFlag. Também converte no sentido contrário, através do parâmetro -vd

afcat: Converte arquivos .aff para o formato raw (dd).

aimage: Pode ser usado para converter uma imagem raw (dd) em aff. Basta especificar o arquivo .dd como entrada, com a opção -E. Também é possível usar o utilitário afconverter para fazer essa operação diretamente.

ewfacquire: Permite converter uma imagem raw (dd) em um ewf (E01), ou também fazer a captura diretamente no formato ewf.

FTK Imager: Presente na parte Windows do Helix, tem menus com capacidade de converter imagens entre alguns formatos.

No próximo artigo, falaremos sobre como usar as imagens capturadas.

Até o próximo post !

Referências: Disk imaging

Imagens Forenses

Fazer a aquisição de uma imagem forense de um HD é, em muitos casos, o ponto de partida de uma investigação. A técnica conhecida como "dead analysis" determina que o HD a ser analisado deve ser clonado bit a bit e qualquer análise deve ser feita nessa cópia, de forma a manter o HD íntegro. Chamamos a cópia de imagem forense porque ela deve copiar todos os dados do HD, incluindo as partes não utilizadas.

Existem diversos utilitários para fazer uma imagem forense. A maioria deles implementa o mesmo formato, conhecido como raw. Esse é, literalmente, uma cópia fiel do HD, e é o formato gerado pelo utilitário dd. Entretanto, ele não é o único formato disponível.

Neste artigo, vamos falar um pouco dos formatos mais conhecidos e realizar uma breve comparação entre eles.

RAW

Como eu disse acima, esse ainda é o formato mais comum. É uma imagem literal do HD, cópia exata, bit a bit. É o formato de saída de vários utilitários, como o dd, o dcfldd e o sdd. Há também alguns utilitários GUI para Linux, que nada mais fazem do que usar a interface gráfica para que o usuário indique os parâmetros com os quais o utilitário de imagem vai ser executado. Como arquivos gerados podem ser muito grandes, alguns utilitário permitem que a imagem seja quebrada (split) em vários arquivos de tamanhos fixos.

Prós:

- Formato facilmente montado
Pode ser montado com comando mount usando loopback.

- Independe de ferramentas específicas
Na pior das situações, no mínimo o comando dd vai estar disponível.

- Muitas ferramentas disponíveis, tanto para linha de comando (CLI) quanto para interface gráfica (GUI).
dd, dcfldd e sdd são as ferramentas CLI mais comuns.
Adepto e AIR são muito usados como GUI.

- Há algumas formas de montagem do arquivo de imagem em sistemas Windows
É possível montar imagens raw de HDs no WIndows usando produtos free, permitindo uma série de análises específicas através de utilitários que só existem em Windows. Também é muito útil em análises de malware.

- Disponível em utilitários tanto para Linux quanto para Windows.
Além dos utilitários comentados acima, o dd está disponível para Windows no CD do Helix.

Contras:

- Não possui compactação
Os arquivos raw são muito grandes e não possuem nenhum tipo de compactação. Caso sejam compactados por algum utilitário de compactação (zip, gzip, tar, etc), eles não poderão ser montados dessa forma, requerendo que sejam descompactados antes de serem montados e usados.

- Não grava metadados
Não há uma previsão para se juntar dados da investigação ao arquivo raw. Todas as informações relativas ao caso ou ao arquivo devem ser armazenadas a parte, em outros arquivos.
- Não trata erros
Se o arquivo for corrompido, só saberemos se um hash for comparado ao resultado do hash tirao antes do arquivo ser corrompido. Ele não mantém internamente nenhum CRC ou outro esquema de recuperação em caso de ser corrompido.

- Não monta facilmente se estiver quebrado em pedaços.
Para se montar uma imagem de 80Gb dividida em 10 pedaços de 8Gb, os pedaços precisam ser concatenados antes e somente após isso podem ser montados via comando mount. Além de necessitar de uma grande quantidade de espaço livre disponível, não é incomum ver essa operação de concatenação corromper o arquivo. Apesar disso, existem utilitários que permitem montar os arquivos sem concatenar.

- Algumas operações são mais lentas devido ao grande tamanho.
Como o arquivo não é compactado, ele costuma ser muito grande e operações triviais de cópia costumam demorar muito.

Para endereçar alguns dos problemas acima, outros formatos acabaram surgindo.

Expert Witness (E01)

É o formato proprietário do EnCase, um dos melhores programas de Forense Computacional que existe. Infelizmente, o EnCase não é free. Apesar disso, existem utilitários free que fazem a aquisição forense de um HD já no formato E01. O Linen, por exemplo, é oferecido no Helix.

Prós:

- É compactado
O esquema de compactação dele foge do usual. Os setores é que são compactados, e de forma tal que se consiga acesso fácil aos dados.

- Metadados
É possível armazenar informações relativas ao caso, ao HD, ao investigador, etc, dentro do arquivo de imagem.

- Arquivos divididos (split) podem ser usados mais facilmente
Os arquivos divididos podem ser usados (montados) sem antes terem de ser concatenados.

Contras:

- Tratamento de Erros
Não é muito eficiente, segundo alguns pesquisadores.

- É proprietário
Apesar de ser lido por algumas das ferramentas mais conhecidas, a compatibilidade ainda não é total, já que o formato é proprietário e o fabricante tem a liberdade de modificá-lo a cada nova versão. Necessita de bibliotecas específicas para ser montado no Linux, felizmente já disponíveis no Helix.

- Tamanho de arquivos
Limite de tamanho de arquivo = 2 Gb. Arquivo maiores exigem quebra.

- Metadados fixos
O conjunto de metadados que esse formato usa é fixo, e não pode ser modificado ou customizado.

SGZIP

O sgzip é um formato compactado usado pelo pyFlag. É baseado no gzip, mas com capacidade para ser montado e pesquisado. O utilitário sgzip, no pacote do pyFlag, é o responsável por converter entre imagens raw (dd) e o formato sgzip.

Prós:

- Boa taxa de compactação
Usa algoritmos de compactação com boa taxa final de compressão.

- Bom esquema de tratamento de erros
Problemas de arquivo corrompido não invalidam o arquivo inteiro.

- Não tem limite de tamanho de arquivos
Não possui o limite de 2 Gb do formato E01.

- Código aberto
Os fontes estão disponíveis aqui

Contras:

- Não permite metadados
Esse formato é, em resumo, um raw com compactação. Não possui especificação para metadados nele, até porque ele foi criado para o pyFlag, que armazena suas informações sobre os casos (Case Management) em sua base MySQL.

- Necessita de utilitários específicos para ser montado
Não é possível montá-lo sem um utilitário específico disponibilizado pelo pyFlag.

- Pouco difundido
Como é um formato que atende a um programa específico, ele não é tão conhecido como o raw (dd) ou o Expert Witness (E01). Também não tem suporte a ele nas principais ferramentas de Forense Computacional disponíveis, como o Sleuth Kit. Essa limitação foi quebrada por um utilitário do pyFlag, mas seria bem melhor se o suporte fosse nativo.

- Não monta em Windows
Para ser montado em Windows, teria que ser convertido em raw primeiro.

Advanced Forensic Format (AFF)

O formato AFF é, por assim dizer, o primeiro formato pensado em termos de padronizar o mercado, oferecendo uma solução de estrutura de arquivo de imagem que enderece vários problemas antigos. Ele é um formato novo, mas vem sendo amplamente aceito e eu apostaria dizer que é o formato que vai predominar daqui a alguns anos.

Prós:

- Compactação
Ele usa um algoritmo chamado LZMA, que oferece taxas de compactação superiores aos outros formatos

- Tratamento de Erros
Possui dispositivos que permitem isolar um erro, caso o arquivo de imagem seja corrompido, e recuperá-lo (mapas de paridade).

- Disponibilidade
Algumas das ferramentas mais usadas já estão aceitando o formato. Os autores também disponibilizaram bibliotecas e tutoriais para que a adaptação seja simplificada ao máximo.

- Metadados
Além de oferecer a capacidade de regitrar metadados, eles são configuráveis, ou seja, você pode colocar os metadados que quiser lá. Ele controla, inclusive, a cadeia de custódia da imagem diretamente pelos metadados. Outro ponto interessante é que ele já regitra hashes, para comparação e manutenção da integridade, em dois algoritmos diferentes. Há a possibilidade de serem assinados digitalmente também.

- Código aberto
O código dele e seu formato está todo aqui

- Sem limites de tamanho
Não tem a limitação de tamanho máximo de arquivos. Ainda por cima, oferece a possibilidade de fazer a divisão dos arquivos (split) e usá-los sem precisar concatenar antes.

- Suporte
O projeto partiu de alguns monstros da Forense Computação mundial, incluindo Brian Carrier e Simson Garfunkel.

Contras

- Formato muito jovem
É, sendo um formato novo, algumas vezes podemos ter surpresas desagradáveis. Ainda assim, eu diria que é um formato a se apostar.

O TESTE

Resolvi criar imagens usando os formatos acima e realizar comparações simples. A bem da verdade, comparei apenas em termos de espaço utilizado.

Como os algoritmos de compactação utilizados exploram principalmente as semelhanças nos setores, usei dois pen-drives para a captação das imagens forenses:
- um Kingston que eu já usava há bastante tempo e que por vezes já teve seu espaço livre esgotado e apagado (sem formatar novamente), e;
- um Sandisk recem comprado, com vários Mbs livres e nunca escritos.

Obviamente, o tamanho do arquivo raw mostra a capacidade de cada um. Os resultados foram obtidos usando as opções defaults das ferramentas. Em vermelho, você pode acompanhar a taxa de compactação obtida.

Tipo de imagem	Kingston	Sandisk
raw (dd)	836Mb	974Mb
Expert Witness (EnCase E01)	767Mb (8,25%)	214Mb (78,03%)
sgzip (pyFlag sgz)	760Mb (9,09%)	213Mb (78,13%)
AFF (aff)	755Mb (9,69%)	210Mb (78,44%)

Podemos concluir, pelos resultados da tabela:

- A taxa de compactação será maior, de acordo com a área não utilizada do disco. Isso não significa que discos com mais espaço disponível compactarão melhor, pois se eles possuírem grandes quantidades de arquivos não alocados, o algoritmo de compactação não vai conseguir ser tão eficaz.

- O Advanced Forensic Format sem dúvida é o que alcançou as melhores taxas de compactação.

No próximo post, vamos conversar sobre como fazer a aquisição de uma imagem nos formatos acima.

Até o próximo post !

Seguem algumas referências:

Survey of Disk Image Storage Formats

ADVANCED FORENSIC FORMAT: AN OPEN, EXTENSIBLE FORMAT FOR DISK IMAGING

Acessing Forensic Imagens

Boas Notícias

Há alguns dias escrevi sobre a total falta de informações sobre um importantíssimo procedimento para a Forense Computacional, que é a Ata Notarial.

Hoje conversei com um funcionário do 26o Tabelionato de Notas de São Paulo. Além de muito prestativo, o Felipe Leonardo conhece bastante o procedimento, e falou com bastante detalhes como a Ata Notarial pode ser feita para diferentes casos de Forense Computacional.

Anote aí a referência, você pode precisar:

Felipe Leonardo Rodrigues
26º Tabelionato de Notas de S. Paulo
Tel.: (11) 3111.9722
Fax: (11) 3111.9744

Quer indicar mais alguém ? Use os comentários e divulgue quem presta bons serviços a comunidade de Forense Computacional.

Até o próximo post !

Trojan Defense

Trojan Defense é o termo utilizado para uma argumentação de defesa bastante usada nos EUA. O advogado de defesa levanta a tese que o réu não realizou o crime, mas sim um conteúdo malicioso instalado em sua máquina.

No livro Windows Forensic Analysis, Harlan Carvey fala do histórico dessa argumentação. No ano de 2002, um americano chamado Julian Green foi a julgamento por manter imagens ilícitas em sua máquina. Uma investigação forense computacional comprovou que ele possuía vários Trojans (cavalos-de-Tróia) que acessavam as páginas ilícitas toda vez que ele acionava o browser. No ano seguinte, um jovem inglês chamado Aaron Caffrey alegou que seu computador, infectado por Trojans, atacou outras máquina para se defender da acusação de ataque/cracker. Ele foi inocentado, mesmo depois de a análise forense de sua máquina não achar nenhum conteúdo malicioso. A defesa usou argumentos de que, mesmo não se achando nada, um rootkit pode estar ativo e criando problemas.

No Brasil, essa alegação está famosa nos casos de auto-fraude. Pessoas mal intencionadas alegam que suas contas foram roubadas porque um código malicioso capturou suas senhas bancárias.

Existem várias formas de lidar com esse tipo de argumentação. Vou citar as duas que acho mais eficientes:

1) Após a tradicional busca por códigos maliciosos, usando diversas ferramentas de anti-vírus e checagem de rootkits, uma verificação detalhada dos artefatos envolvidos na situação pode quebrar a teoria de que um Trojan realizou a ação. Assim, em um caso de fotos de pedofilia, a alegação de que as imagens foram baixadas por códigos maliciosos pode ser derrubada se for encontrada alguma lógica na organização nas fotos (separadas em diretórios por temas, por exemplo). Ou então, se for encontrado no registry, na parte do UserAssistant, indicações de comandos de cópia das imagens de um local para outro. Ou ainda, se for encontrado referência às fotos em atalhos no Recent. Isso sem falar em confrontar arquivos que foram apagados e recuperados com tabelas do Recycle Bin. Em todos esses casos, um código malicioso não deixaria esses artefatos.

2) Realizando a aquisição da RAM e, em seguida, a análise forense dela, dos arquivos de hibernação e da memória virtual. Um rootkit pode se esconder usando determinadas técnicas, mas é muito mais complicado obter sucesso em se esconder de uma análise forense da RAM. Essa análise também consegue determinar os processos ativos e suas imagens (executáveis na memória), o que permitiria uma busca atenta por códigos maliciosos.

O que você faria se tivesse que confrontar e mostrar que as ações investigadas não teriam sido executadas por um código malicioso, automaticamente ? Compartilhe conosco nos comentários.

Até o próximo post !

Manutenção no Helix - Parte II

Atualizando a parte Linux do Helix

Conforme mostrei no artigo anterior, o Helix é formado por uma parte Windows, voltada para Live Response/Incident Response. A parte "bootável" do Helix é realmente baseada em Linux, e é a parte principal do Live CD. Neste artigo, vamos ver como atualizar a parte Linux do Helix.

Vale a pena reforçar que as recomendações feitas no artigo anterior continuam válidas.

Da mesma forma que na parte Windows, temos a opção de usar um pen drive ou alterar diretamente o arquivo .iso. Vamos iniciar com foco no uso de um pen drive (ou mesmo HD externo) para as atualizações.

Preparando o pen drive ou HD externo

1) Carregue o Helix, dando boot pelo CD;
2) Com o pen drive/HD externo plugado na USB, execute o utilitário QTParted. Ele pode ser localizado pelo menu do Helix -> System Tools -> QTParted;
3) Crie a partição e formate com o filesystem ext2;
4) Monte o pen drive/HD externo;
5) Crie um diretório chamado utils;

Adicionando uma nova ferramenta

O Helix é um dos melhores Live CDs existentes, mas algumas boas ferramentas acabaram ficando de fora. Uma ferramenta muito boa para determinar os mactimes das chaves do Registry é a RegTimes. Esse tipo de informação é muito importante para determinar a cronologia de algo que ocorreu na máquina.

1) Faça o download dos fontes do Regtimes aqui no SourceForge (regtimes.0.1c.tar.gz)
2) Use o seguinte comando para descompactar os fontes: tar xzvf regtimes.0.1c.tar.gz
3) O comando anterior vai criar um diretório chamado regtimes-0.1c e descompactará os arquivos lá dentro. digite cd regtimes-0.1c para ir para o diretorio.
4) Você deveria procurar pelas instruções de instalação, que na maioria das vezes é apenas um comando make. No caso desse utilitário não há um comando make, então para compilar digite g++ regtimes.cpp nttime.cpp reglib.cpp -o regtimes
5) A operação acima vai criar um arquivo executável chamado regtimes. Confira digitando ./regtimes, o que emitirá instruções de uso do programa.
6) Como o único arquivo que importa para nós é o executável, copie-o para o diretório utils criado lá no pen drive/HD externo.

O Helix monta uma estrutura em memória, com um ramdisk, que permite você "alterar" conteúdos do CD. Ou seja, você consegue criar um arquivo novo, alterar um existente ou até mesmo apagá-lo, sendo que ele originalmente veio do CD. Logicamente, ao desligar a máquina essas alterações serão perdidas. Essa estrutura chama-se UnionFS.

Esse ponto é importante porque se deixarmos o executável apenas no diretório /utils, sempre precisaremos indicar a path para executá-lo. Podemos remover essa limitação criando um symlink para o executável dentro do diretório /KNOPPIX/usr/bin com o comando
cd /KNOPPIX/usr/bin; ln -sf /media/sda1/utils/regtimes regtimes
Assumindo que o mounting point do pen drive foi /media/sda1. Dessa forma, bastará digitar regtimes para usá-lo.

Um ponto importante: Esse symlink vai se apagar ao desligar a máquina. Convém criar um script com os comandos acima, um para cada utilitário ou nova ferramenta adicionada ao Helix no diretório utils. Esse script deve sempre ser executado logo depois de montar o pen drive.

Atualizando uma ferramenta

Os passos de atualização de ferramentas no Helix são muito semelhantes aos descritos anteriormente. Praticamente a mesma coisa. Iremos atualizar o readpst, um utilitário que transforma arquivos .pst do Outlook:

1) Faça o download dos fontes do libpst aqui nesse link (libpst-0.5.12.tar.gz)
2) Use o seguinte comando para descompactar os fontes: tar xzvf libpst-0.5.12.tar.gz
3) O comando anterior vai criar um diretório chamado libpst-0.5.12 e descompactará os arquivos lá dentro. digite cd libpst-0.5.12/src para ir para o diretório com os fontes.
4) Digite make para fazer a compilação.
5) A operação acima vai criar alguns arquivos executáveis. Confira um deles digitando ./readpst, o que emitirá instruções de uso do programa.
6) Como os únicos arquivos que importam para nós são os executáveis, copie-os para o diretório utils criado lá no pen drive/HD externo.
7) Para cada arquivo executável inclua comandos no script que criem symlinks no diretório /KNOPPIX/usr/bin

É possível alterar diretamente o .iso e criar um novo CD, como no lado Windows ?

Sim. Entretando, a operação é bem mais complicada. Basicamente, dentro do diretório /KNOPPIX do CD há um arquivo chamado HELIX que é um filesystem compactado. É dessa forma que consegue-se colocar tanta coisa dentro de um CD. Verifique aqui instruções de como alterar um Live CD, copiando o arquivo HELIX e aplicando nele os procedimentos descritos.

Os passos de compilação das ferramentas também são válidos aqui, com a diferença de que o processo precisa ser seguido, e os executáveis compilados devem ser colocados novamente dentro do arquivo HELIX. Com esse arquivo já alterado, use o Iso Commander para atualizar o .iso, conforme descrito no artigo anterior.

Comentários ? Sugestões ?

Até o próximo post !

Manutenção no Helix

O Helix é um dos melhores "live CDs" disponíveis para a comunidade de Forense Computacional. Ele reúne um ambiente com dezenas de utilitários importantíssimos não apenas para o trabalho de aquisição da imagem forense, mas também para o trabalho posterior de análise. Como se isso não bastasse, ele tem uma parte de Incident Response para Windows.


Um Live CD é algo muito útil. É prático, seguro e contém, no caso do Helix, a palavra mágica "free". Isso significa que você realmente não precisa de um mega investimento para começar sua vida de Investigador Forense Computacional. Entretanto, tudo na vida tem um preço, mesmo quando se trata de coisas "free". Na maioria das vezes, no caso de softwares, o preço é não contar com atualizações constantes ou um suporte adequado.


O Helix tem um fórum bem interessante que pode ajudar, e em geral nossos questionamentos vão estar mais ligados nas ferramentas que o Helix disponibiliza do que propriamente em algo dele. Ainda assim, o fórum é razoável. Já tive perguntas respondidas em alguns poucos dias e já tive perguntas que nunca receberam resposta. O pior, com relação ao preço a se pagar, não é isso. Como o Helix não tem uma equipe trabalhando em tempo integral, as atualizações demoram um bocado. Em geral, são anuais. A versão atual, 1.9a, é de julho de 2007 e a anterior era de outubro de 2006. Em resumo, as novas versões dos utilitários e ferramentas são disponibilizadas com mais frequência, e ficamos um tempão sem elas. Daí, vem a pergunta: Está cansado de esperar pela nova versão do seu Live CD preferido ????


Seus problemas acabaram !!!


Vamos discutir neste artigo algumas técnicas para atualizar suas ferramentas sem depender da turma do live cd.


Atualizando o Helix - Parte Windows


Como comentei anteriormente, o Helix disponibiliza uma parte do CD para ser usada em uma operação de Resposta a Incidentes (ou até mesmo em uma Live Response). Nesse caso, para atualizar seu grupo de ferramentas, temos duas situações e duas opções de abordagem.


Situação 1 - Vamos incluir um produto que não está disponível no Helix;

Situação 2 - Vamos atualizar (fazer um upgrade) a versão da ferramenta disponível.


As duas opções de abordagem são:


Opção a) Tudo que for atualizado ficará em um pen drive;

Opção b) Tudo que for atualizado será implementado direto no CD.

IMPORTANTE: Sempre verifique os detalhes de licenciamento da ferramenta que você está atualizando. Algumas só podem ser livremente usadas em determinadas condições. Outras dependem de um registro prévio que libera funcionalidades.

A opção a) é mais fácil. Ela consiste em manter um pen drive com os programas devidamente instalados, e prontos para serem usados em um caso de Incident Response, junto com as demais ferramentas do Helix. Entretanto, como ponto negativo, ela insere alterações no sistema sendo analisado. Quando o investigador inserir o seu pen drive, o registry criará uma chave contendo alguns dados relativos a esse pen drive. Se você optar por essa técnica, recomendo verificar esses dados criados na chave LocalMachine/System/CurrentControlSet/Enum/USBSTOR do registry e indicar todas essas informações nos seus procedimentos. Dessa forma, com a alteração devidamente documentada, não há problemas. Fazer isso seria semelhante a tomar as impressões digitais de uma pessoa que entrou em uma cena de crime para socorrer uma vítima. De acordo com o Princípio da Troca de Locard, essa pessoa introduziu modificações na cena e elas precisam estar previstas de forma a serem isoladas.

Um dos problemas da opção a) é que, sendo o pen drive uma mídia com possibilidade de escrita, você o expõe a softwares maliciosos instalados na máquina sendo tratada. Nesse caso, não tem muito jeito, o melhor seria adaptar um USB Write Blocker e ficar tranquilo. Só lembrando, esse pen drive não conseguiria ser usado para coletar nada, já que o Write Blocker não deixará nada ser gravado nele.

A opção b) é um pouco mais complicada, e envolve o uso de um software comercial (eu procurei bastante uma opção free, mas não achei). Apesar disso, você estará usando diretamente a partir do CD, o que o deixará despreocupado em relação aos problemas da opção a).


Não importando qual das opções você escolher, tenha sempre em mente:


1) Mantenha uma cópia do arquivo .iso original do Helix;

2) Crie seu próprio label de versionamento, de forma que você identifique corretamente o cd que está trabalhando;
Por exemplo, a versão atual do Helix é a 1.9a. Criei algo como 1.9aTR1, significando que é a minha primeira alteração do Helix 1.9a. Logicamente, esse ponto é válido para a nossa opção b), apenas.

3) Monte um ChangeLog bastante rígido;
Um ChangeLog é um arquivo onde você indica todas as modificações feitas naquela versão. Isso é muito importante porque você vai precisar de algo para comparar quando a próxima versão do seu Live CD for lançada.

4) Atualize seu inventário de ferramentas e o hashset delas.
É importantíssimo para um Perito manter um inventário de todas as ferramentas que ele usa, suas respectivas versões/releases e seus hashes. Isso sempre deve ser incluído como um dos anexos do relatório/parecer do Perito. É dessa forma que você poderá evitar questionamentos como:

- A ferramenta usada possui publicada uma falha exatamente no item sendo analisado. Como os resultados obtidos através dela podem ser dignos de crédito ?

- Como pode ser garantido que o programa usado não foi adulterado para exibir um resultado que mais convém ?

Identificando correntamente as versões de todas as ferramentas usadas e adicionando os seus respectivos hashes à documentação mantém os questionamentos acima respondidos de acordo. Esse tipo de inventário e seus hashes são fornecidos pelo Helix. Você deverá atualizá-los sempre que gerar uma nova versão particular do Live CD.


Agora vamos a prática.


Uma ferramenta bastante interessante para investigações diretamente no Windows é o WFA, e ele não está presente na parte Windows do Helix.


O WFA reúne visualizações de alguns itens importantes do Windows, incluindo arquivos thumbs.db e os arquivos do Recycle bin. Não vou entrar em muitos detalhes de como fazer em relação a opção a), já que basta copiar o utilitário para um diretório e ele estará pronto para ser usado. Vamos falar um pouco mais da opção b).

Adicionando uma nova ferramenta ao CD do Helix


1) Faça uma cópia do arquivo .iso da última versão disponível do Helix. Nomeie o novo arquivo .iso adicionando o seu código de versionamento. No exemplo que dei acima, ficaria Helix_V1.9-07-13a-2007-TR1.iso


2) Compre um ISO Editor (é, isso mesmo, compre ... Não consegui achar nenhum software free que fizesse edição de arquivos .iso. Se você souber de algum, indique nos comentários, por favor). Dos que eu verifiquei, o Iso Commander é um dos melhores e mais simples de serem usados. Faça o download e a instalação do mesmo.


3) Crie um diretório chamado MiTec logo abaixo do diretório IR, que está na raiz do CD. MiTec é o fabricante do WFA.

4) Copie para lá o WFA.exe.

5) Salve o trabalho. Seu .iso está pronto para ser gravado em um CD.

Note que estamos falando da situação 1 descrita lá em cima, que é adicionar um novo programa ao CD. Entretanto, para a situação 2, basta fazer os mesmos passos, jogando o novo utilitário no mesmo diretório onde está a versão a ser substituída.

Viu como é simples ? O mais trabalhoso acaba sendo manter a documentação toda atualizada.

No artigo seguinte, iremos explorar atualizações no lado Linux do Helix.

Até o próximo post !

Product ID

Um dos peritos da lista Perícia Forense trouxe na semana passada uma necessidade interessante. Ele precisava levantar o Product ID (o serial) de cada programa instalado em um grupo de máquinas, de forma não invasiva.

Esse número fica no registry, e isso é a única coisa em comum nos softwares. De resto, cada um tem um formato diferente e é armazenado em uma chave distinta.

Todas as opções que a turma comentou cumpriam bem o ponto, menos no quesito mais importante: elas vasculhavam o registry ativo, e isso não atendia, pois seria um procedimento invasivo.

Basicamente, o que precisamos aqui é de um programa que acesse arquivos de registry e localize os seriais de cada programa instalado. Como não há um formato único nem padrão de localização, precisamos de uma base de conhecimento que nos indique onde procurar. É exatamente aí que entra a sugestão de um dos participantes. Um programa chamado Product Key Explorer faz exatamente isso, ele vasculha o registry procurando os seriais, sendo que ele tem uma base com a localização de onde cada programa guarda o seu serial number. Porém, novamente esse programa não atende ao nosso colega, já que ele faz sua busca no registry ativo.

Harlan Carvey disponibilizou há algum tempo uma rotina em Perl que faz o parse do registry, e como ela o faz sem usar as bibliotecas do Windows, essa rotina funciona em Linux e, logicamente, em qualquer arquivo de registry que você achar na imagem do hd.

Sabendo disso, minha sugestão é de implementar alterações nessa rotina, fazendo-a listar todos os seriais encontrados em um determinado arquivo de registry. Para isso, podemos usar o RegMon da SysInternals para monitorar o Product Key Explorer. Listaremos cada chave procurada, e passaremos a lista para o programa Perl.

Dá até para criar um script shell que monte (usando o loopback) todas as imagens em um diretório e extraia delas os arquivos de registry (use file e grep para isso). Aplique a rotina Perl em cada arquivo de registry extraído.

Pronto !

A idéia está dada. Alguém se habilita ?

A tal rotina do Harlan, inclusive, pode ser ponto de partida para vários outros itens de busca importantes, e já há quem fale sobre uma nova disciplina surgindo, como um grande subconjunto de conhecimento de Forense de Windows. Seria a Forense de Registry.

Quem finalizar o processo, por favor deixe uma nota nos comentários desse artigo, para que possamos divulgá-la.

Até o próximo post !

Rapidinha II

Um par de dias atrás, estava eu andando a procura de um restaurante quando dei de cara com um Cartório de Notas. Pensei "muito bom tem um desses por perto, vou lá me informar sobre as rotinas deles". Entrei:

Tony: - Bom dia.

Funcionário do Cartório: - Bom dia, senhor.

Tony: - Gostaria de ter informações de vocês. É sobre Ata Notarial, mais especificamente.

Funcionário do Cartório: - Ata o quê ???????? (A vida devia ter trilha sonora. Tenho certeza de que ouviríamos aquele famoso "toing" vindo de algum lugar nesse momento) :O

Fiquei um pouco assustado ao perceber que demoramos quase cinco minutos para achar a única funcionária que conhecia o termo, já que o Tabelião estava fora. Esse processo é de responsabilidade dele, apenas.

Mais assustado ainda foi o que ela me disse. Além de ser muito raro, a Ata Notarial nem sequer figura na relação das custas.

Temos que trabalhar mais, no sentido de divulgar nossa área e Ciência, não ???

Ou será que quase não tem acontecido trabalhos litúrgicos ???

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

Rapidinha I

Acabei de ver no Slashdot que há uma projeto de lei nos EUA (South California, para ser mais exato) para que somente quem possuir uma habilitação de Investigador Privado, ou trabalhar para uma agência privada de Investigações, possa realizar perícias computacionais.

Aparentemente, quem for pego fazendo perícias computacionais poderá ser processado criminalmente, e as provas só valerão se forem coletadas/investigadas por um investigador privado habilitado.

Já pensou se essa moda pega aqui ? O que você acha ? Comente.

Até o próximo post !

Projeto Sem Nome

Nada como começar o ano falando de desafios.

Forense Computacional é algo caro. Na maior parte das vezes, é realmente muito mais fácil usar um software totalmente desenvolvido para esse fim, com milhares de características úteis, e tudo junto e interligado. Apesar do que Harlan Carvey costuma dizer muito no seu blog, de que a Era Nintendo de Computação Forense acabou, ainda assim esses softwares ajudam um bocado.

Só que são caros. Muito caros. Entre outras coisas, porque logo na largada o software no Brasil é algo realmente caro. Além disso, é um investimento que assusta a quem quer começar, e isso ainda vai se somar a outras coisas, como um bloqueador de escrita no HD e um notebook bem de processador para fazer as análises.

A opção para os softwares caros é contar com o software livre. Eu tenho partido por essa linha e ela tem se provado adequada. Lógico, não é a mesma coisa, mas consigo chegar lá. Isso, aliás, é importantíssimo, porque em matéria de Forense Computacional, você PRECISA chegar aos mesmos resultados se usar diferentes ferramentas. É mandatório. Não obstante, dá muito mais trabalho.

Estive observando essa dificuldade, e somado ao fato de que:
i. As conclusões são baseadas em itens diversos e depois de muitos detalhes analisados.
ii. Cada detalhe analisado pode ser a saída, um relatório gigante, de uma ferramenta qualquer.
iii. Haverá vários desses relatórios para se avaliar e tirar conclusões.
iv. O processo leva MUITO tempo, em geral, e depende do tamanho das imagens sendo analisadas.

Onde eu quero chegar ? Bem, com tudo disposto acima, imagino o quanto não é dispendioso em termos de tempo ficar executando ferramenta após ferramenta, perseguindo o objetivo. Pensei que poderia ser interessante criar uma ferramenta baseada em software livre que fizesse uso de banco de dados para registrar os resultados e facilitar a nossa vida. Rodaria em Linux, lógico.

Minha primeira idéia é reunir pessoas que estariam dispostas a trabalhar nesse projeto. A proposta é criar um projeto no sourceforge, e conversarmos via e-mail sobre a estrutura e o que se poderia implementar. Minha idéia é bem simples, nada muito rebuscado. Lembra da famosa frase "O ótimo é inimigo do bom" ?

É isso. Aguardo adesões e dúvidas nos comentários.

Até o próximo post !