Novo AIR no ar

Minha criatividade para títulos está em baixa nesta semana, como todos puderam notar ... Ainda assim, Nanni Bassetti, meu camarada de equipe do CAINE acaba de anunciar a novíssima versão do AIR, um GUI para aquisição de imagens forenses.

Criado pelo Steve Gibson há algum tempo, o AIR sempre foi uma espécie de patinho feio das interfaces para aquisição de imagens. No Helix, sempre ficou à sombra do ADEPTO, e mais recentemente, foi um mero coadjuvante no CAINE, escondido pelo GuyMager. Não que a interface não cumprisse o seu papel, mas porque os irmãos de função acabavam por o ofuscar, oferecendo algum diferencial que levava a preferência da maioria. Na versão 2.0.0, no entanto, isso pode mudar.

A grande novidade dessa versão está por conta do uso do DC3DD. Embora eu não tenha verificado, acredito que o AIR 2.0.0 seja o primeiro GUI a abrir mão do DCFLDD e utilizar o novíssimo (e muito melhor) DC3DD como base de linha de comando. Isso quer dizer que tudo que o usuário escolhe e indica na interface gráfica vira uma enorme linha de comando, fora de questão o entendimento para a grande maioria dos mortais. Essa é a beleza dos GUIs, pois transformam a linha-mostro em algo factível e com menor possibilidade de erros. Até então, os GUIs existentes (Adepto, Air, Guymager) estavam focados no dd e no dcfldd para a tarefa. Agora, o Air-patinho feio vai reagir. Os benefícios ? Procure aqui no blog mesmo pelo artigo que já escrevi sobre o dc3dd. Ele é muito mais otimizado, possui código renovado e várias opções que facilitam a vida na hora de duplicar uma mídia de maneira forense.

O uso do dc3dd não é a única melhoria dessa nova versão. O AIR traz ainda o cálculo de hash da mídia por dois algoritmos distintos. Apesar de já termos fechado a questão sobre a polêmica de MD5 servir ou não para confirmar a integridade de uma imagem forense, a tendência vai ser mesmo a de usar dois hashs distintos e tirar qualquer sombra de possibilidade de, em um futuro próximo, criarem um algoritmo para atacar esse modelo e forjar imagens adulteradas como se estivessem integras.

Além dessas novidades, o AIR conta com a possibilidade de quebrar imagens em pedaços (split image), enviá-la pela rede enquanto faz a aquisição (usando netcat) e até mesmo compactá-la usando gzip. Não é a mesma compactação que o formato EWF ou o AFF possuem, mas já é alguma coisa no sentido de gastar menos espaço. Nesse caso, para ser manipulada, a imagem precisará ser descompactada. Já ia me esquecendo: o log dele é bem detalhado e contém detalhes sobre a sessão de aquisição, muito importante para copiarmos para o relatório final, laudo ou parecer técnico.

Abaixo, algumas telas do novo AIR:



Compartilhe conosco suas experiências com o AIR. Comente !

Até o próximo post !

Imagens Forenses VI

Segue mais um capítulo da nossa emocionante novela a respeito das imagens forenses. Neste emocionante episódio, nosso protagonista, o formato .AFF (Advanced Forensic Format) vai ser testado em relação ao tamanho final de arquivo gerado e ao tempo total de geração da imagem.

Como já comentei em artigos anteriores, o formato aff permite compressão dos dados, e é possível indicar, durante a aquisição pelo aimage, o nível de compressão (através do parâmetro compression) e o algoritmo de compressão (ZLIB ou LZMA).

A idéia desse estudo é achar combinações ideais para esses dois parâmetros, através da aquisição de uma imagem forense do mesmo pen drive de 876 Mb (837 Mb reais), variando apenas esses dois parâmetros. Vamos aos resultados:


Ponto de comparação:

Compression	Tamanho da imagem	Tempo de aquisição
Sem compressão	837 Mb	1m36s

Usando ZLIB (default)

Compression	Tamanho da imagem	Tempo de aquisição
-1 (default)	762 Mb = 8,96% menor	3m24s = 112,5% mais demorado
0	837 Mb = idêntico	1m51s = 15,63% mais demorado
1	764 Mb = 8,72% menor	3m11s = 98,96% mais demorado
2	764 Mb = 8,72% menor	3m11s = 98,96% mais demorado
3	763 Mb = 8,84% menor	3m12s = 100% mais demorado
4	763 Mb = 8,84% menor	3m20s = 108,33% mais demorado
5	762 Mb = 8,96% menor	3m22s = 110,42% mais demorado
6	762 Mb = 8,96% menor	3m24s = 112,5% mais demorado
7	762 Mb = 8,96% menor	3m24s = 112,5% mais demorado
8	762 Mb = 8,96% menor	3m34s = 122,92% mais demorado
9	762 Mb = 8,96% menor	3m48s = 137,5% mais demorado

Usando LZMA

Compression	Tamanho da imagem	Tempo de aquisição
-1 (default)	721 Mb = 13,86% menor	14m13s = 788,54% mais demorado
0	721 Mb = 13,86% menor	13m55s = 769,79% mais demorado
1	721 Mb = 13,86% menor	13m53s = 767,71% mais demorado
4	721 Mb = 13,86% menor	14m = 775% mais demorado
5	721 Mb = 13,86% menor	13m53s = 767,71% mais demorado

Conclusões
- Se tamanho não é problema, o jeito mais rápido de capturar uma imagem usando o aimage (ou o Adepto do Helix) é pedindo a opção de não-compactação.
- Se o tempo não é problema, o menor arquivo de imagem gerado é obtido usando-se o aimage com a opção -L (algoritmo LZMA). Como as opções de compress geram arquivos praticamente de mesmo tamanho, a melhor opção para usar com o -L seria o --compression=1 (ou =5).
- Se o principal é ter compactação, mas levando o tempo em consideração, então os algoritmos LZMA são proibitivos. O mais rápido nesse algoritmo foi quase 6 vezes mais demorado que o mais lento das opções do ZLIB.
- Indo nessa linha, de ter boa compactação, mas com tempos razoáveis, a melhor opção seria o algoritmo ZLIB (default) com a opção compression=5. Essa opção oferece a melhor taxa de compactação, e dentro dessa taxa, o melhor tempo, tudo isso levando-se em consideração os valores absolutos.
- Os que apresentaram maior/melhor taxa de transferência foram as opções compression=1 ou =2, com o algoritmo ZLIB (default). Esses são os que apresentaram a melhor relação custo x benefício, e são as indicadas para situações genéricas onde compactação é desejada e o tempo de aquisição deve ser optimizado.
- O algoritmo LZMA não pode ser setado pelo Adepto.


Comentários ?

Até o próximo post !

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

Nosso Amigo Hash - Parte III - Continuação

Hash aplicado na Forense Computacional - Prática

Quarto exemplo: Comprovando a integridade de uma imagem de um HD ou outra mídia

Comprovar a integridade de uma imagem através de hash é uso comum em dois momentos: quando se quer comprovar que a imagem é cópia exata da mídia original ou quando se quer comprovar que a manipulação aplicada sobre a imagem não introduziu qualquer mudança na mesma.

Neste exemplo, vamos trabalhar com algumas ferramentas fornecidas pelo live CD Helix.

Capturando imagem

A primeira situação, descrita acima, ocorre quando se faz a captura da imagem de uma mídia.
O procedimento de captura requer que a imagem obtida seja cópia fiel da mídia original (cópia bit a bit). Dessa forma, a análise da mídia, buscando evidências, garantidamente será feita sem prejuízo de sua integridade, como se fosse na própria mídia original.

É importante ressaltar que uma simples cópia ou uma imagem não-forense deixaria algumas partes da mídia original de fora (não seriam copiadas), e tais partes podem conter informações relevantes. Nesse tipo de imagem, a área não alocada da mídia não é copiada, por exemplo.

Somente com a comprovação da integridade da imagem podemos ter certeza de que o procedimento de captura não inseriu ou removeu artefatos que modificaram as conclusões.

Imagine:

1) Um caso onde um computador foi supostamente usado para cometer um crime. Imediatamente antes do computador ser confiscado, os arquivos (artefatos) que comprovariam o ocorrido são deletados. Se o procedimento de captura de imagem utilizado não for um procedimento forense, os dados contidos nas áreas não alocadas serão perdidos e não será possível comprovar a situação. Também podemos ter o contrário, onde os dados que refutariam a hipótese de participação (ou de culpabilidade) poderiam estar em arquivos recém apagados, prejudicando assim as conclusões.

2) Um caso onde um arquivo foi propositalmente adicionado à imagem para fraudulentamente indicar o envolvimento de alguém inocente em uma situação. Se o procedimento de captura utilizado incluir a verificação de integridade, essa manipulação fraudulenta será detectada.

Se fossemos fazer um paralelo da Forense Computacional com outras investigações não digitais, a captura de uma mídia através de procedimentos de imagem forense bit a bit é equivalente à exigência ao investigador de se usar luvas na cena de um crime para colher as impressões digitais.

dd

Existem várias formas de capturar uma imagem forense, mas sem dúvida a mais usada e difundida é o comando dd. Esse comando realiza a cópia exata (bit a bit) da origem para o destino. É possível, portanto, indicar como origem a path da mídia a ser capturada, e como destino um arquivo. Ao final da cópia, todo o conteúdo da mídia estará refletido nesse arquivo destino, incluindo ali seus espaços não alocados (arquivos deletados).

Ex: Para copiar um pendrive que está localizado em /dev/sda para um arquivo chamado imgblog.dd, usamos o seguinte:
dd if=/dev/sda of=/media/hda1/imagens/imgblog.dd conv=noerr bs=512

O comando acima criará a imagem, capturando-a de forma forense. Entretanto, ele está incompleto porque não faz a verificação de integridade. Essa verificação vai comprovar que a mídia não foi alterada durante o procedimento de cópia, e que o arquivo de saída (destino) é realmente a cópia exata da origem.

Para fazer a verificação de integridade, fazemos uso do utilitário de hash md5deep, que a semelhança do md5sum, computará o hash:

md5deep /dev/sda
dd if=/dev/sda of=/media/hda1/imagens/imgblog.dd conv=noerr bs=512
md5deep /media/hda1/imagens/imgblog.dd

Se o procedimento capturou a imagem corretamente, os valores de saída do primeiro md5deep, sobre a mídia, e do terceiro md5deep, sobre a imagem, serão idênticos e a integridade do procedimento está garantida.

Interface gráfica

Apesar de ser sempre interessante conhecer os pormenores das opções de linhas de comando, há boas interfaces gráficas para realizar a tarefa acima.

O utilitário Adepto, incluído no Helix, pode ser configurado para a captura através de uma tela amigável. O melhor disso é que o Adepto já traz opção para fazer a validação usando hash, sem necessidade de inserir comandos específicos. Basta um clique para acionar a opção e o hash da mídia será computado antes da captura e depois automaticamente comparado com o hash computado sobre a imagem. Uma mensagem de alerta será exibida no log caso os valores não coincidam. O log de utilização é bastante detalhado e traz detalhes da máquina onde o Adepto está sendo executado também.

Comprovando a integridade após a manipulação da imagem

Todo cuidado deve ser tomado durante a análise da imagem, para que a mesma não sofra qualquer tipo de alteração. Write-blockers são úteis, e para quem tem uma imagem a partir do dd, pode-se montá-la usando o loopback device com as opções de read-only.

Ainda assim, a comprovação de que a integridade da imagem continua preservada é feita através do cálculo do hash antes de montar a imagem, e imediatamente após. Os valores calculados precisam ser os mesmos se a imagem continua integra.

md5deep arquivoimagem.dd
mount arquivoimagem.dd /media/imagem -o ro,loop
... Faz as operações e análises ...
umount /media/imagem
md5deep arquivoimagem.dd

Uma advertência: O comando de montar imagem como read-only não previne alterações na imagem em caso de uso de sistemas de arquivo com journaling. O ext3, segundo li recentemente, tem esse recurso e introduz modificações na imagem mesmo quando montado com as opções read-only. Nesse caso, só mesmo um write-blocker.

Na próxima, vamos falar do uso prático de hashes na separação de arquivos conhecidos e desconhecidos.

Até o próximo post !