Turma do dia 8 de Março confirmada

A próxima turma começa em 8 de março, no Rio de Janeiro, com aulas no período integral. O curso tem duração de 40h com teoria e muita, muita prática, e ainda há algumas vagas disponíveis.

O conteúdo abrange Resposta a Incidentes na parte de captura e análise, e obviamente, Computação Forense em seus diversos aspectos. Neste ponto, o foco será na aquisição e na análise forense, com muitos exercícios práticos e estudos de caso. As práticas serão baseadas em software livre, principalmente em live CDs.

Para montar a ementa e o material, procurei aliar minha experiência como perito/investigador com minha experiência com ensino (já fui instrutor de cursos MOC, os cursos oficiais da Microsoft, já dei aula de banco de dados e, num passado distante, já montei um treinamento completo de Visual Basic, que na época ainda não era muito conhecido), e o resultado foi um material que está focado nas principais teorias e técnicas, tratando os assuntos com a profundidade na medida mais adequada à didática, e está recheado de exemplos e aplicações.

A TISafe, tradicional consultoria de Segurança de Informações do Rio de Janeiro com expertise diferenciado em criptografia e PKI, é minha parceira nesse treinamento. Ela também já oferece um treinamento de sucesso na área de formação de analistas de Segurança de Informações, o CFAS, do qual também sou instrutor, de forma que essa experiência será benéfica para o CFPF.

Se tiverem alguma dúvida, entrem em contato por email ou mesmo deixe um comentário aqui no blog.

Até o próximo post !

Brazuca no blog de forensics do SANS

Minha falta de criatividade em títulos continua e agora eu "roubei" o título do micro-post do meu camarada Alexandre Teixeira, que viu a novidade antes mesmo de mim :) .

Há algum tempo recebi um convite para escrever para o blog de Forense Computacional que eu considero o mais conceituado do mundo no momento. Há diversos blogs muito bons por aí, mas o da SANS se destaca, principalmente porque é escrito por uma comunidade de peritos e investigadores digitais ao invés de apenas um escritor, como na maioria.

Ao receber o convite, além de ficar bastante lisonjeado, ocorreu-me que eu não tenho o certificado GCFA, da SANS, mas a turma que dirige o blog me deixou bem à vontade quanto a isso.

Hoje o meu primeiro artigo foi para o ar.

Para nós, o assunto não é tanta novidade, já que eu publiquei recentemente o texto antes aqui (Hashset de malware). Ainda assim, foi um grande motivo de orgulho estar publicando no mesmo veículo que alguns monstros da Forense Computacional mundial, como Rob Lee, Scott Moulton, Eoghan Casey e Craig Wright, entre outros.

Vamos ver os próximos artigos em breve ! Conto com o suporte de todos os amigos que me acompanham aqui no blog.

Até o próximo post, agora também em versão internacional :D !

** Alteração em 20/3 **

E não é que o artigo deu ibope ??

Agradeço todos os hits e espero continuar postando um conteúdo de qualidade por lá também.

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 !

Hashset de Malware

Uma tecnica muito útil para um investigador ganhar tempo ou para ser alertado quanto a presença de arquivos maliciosos na máquina investigada é a filtragem por hashset.

De maneira muito resumida (já falamos nesse tópico aqui no blog), a filtragem por hashset permite, durante uma varredura pelos arquivos da imagem sendo periciada, eliminar do foco da investigação aqueles arquivos que são conhecidos e não poderiam ser relacionados com nenhum ponto ou problema da nossa investigação. Esses arquivos, conhecidos como known good, são os arquivos originais do sistema operacional, utilitários, programas e até mesmo imagens que fazem parte de pacotes comerciais ou não. Os arquivos known good podem ser reconhecidos através de um hashset, uma relação deles univocamente identificada pelo seu hash, em MD5 ou SHA-1. Durante a varredura, os arquivos cujo hash se encontram na base known good podem ser tranquilamente ignorados.

Por outro lado, seria interessante que durante essa mesma varredura pudéssemos ser alertados da presença inequívoca de um arquivo malicioso. Podemos atingir esse objetivo através de um hashset que reúna somente arquivos com reputação duvidosa, com malware, ferramentas hacker e códigos destrutíveis. Esse conjunto de hashs é comumente conhecido como known bad hashset, e a identificação também ocorre pelo hash do arquivo, em MD5 ou SHA-1.

Na verdade, o algoritmo nem precisa ser um desses dois. O que precisamos é ter a base de hashs (hashset) usando um determinado algoritmo de hash e varrer a imagem calculando o hash de cada arquivo neste mesmo algoritmo.

O problema surge exatamente aqui. A maior base pública de hashsets disponível é a NSRL, e curiosamente ela oferece, na mesma base, as duas classes: known good e known bad. Tomando como exemplo o sorter, se usarmos a base NSRL como known good, os arquivos maliciosos que porventura existirem na imagem serão ignorados. Por outro lado, se usarmos a base como known bad, seríamos alertados erroneamente em milhares de arquivos.

A solução desse impasse, enviada pelo colega Doug White do NIST, está em separar a base (que na verdade é composta por um conjunto de arquivos) em known good e known bad. Isso pode ser feito porque um dos arquivos que compoe a base possui um campo de classificação, e os arquivos known bad tem a classificação "Hacker Tool". Basta filtrarmos todos esses "Hacker Tool", jogando-os para um arquivo a parte, e teremos o Known Bad extraído da NSRL. Quem não tem essa classificação pode ser jogado em outro arquivo e será o Known Good.

Abaixo segue um código perl que fará a extração, conforme comentado:

#!/usr/bin/perl -w
# Extracts known good and known bad hashsets from NSRL
# uso: nsrlext.pl -n -p -g -b [-h]
#
# -n :nsrl files comma separated. Ex: -n c:\nsrl\RDA_225_A\NSRLFile.txt,c:\nsrl\RDA_225_B\NSRLFile.txt
# -p :nsrl prod files comma separated. Ex: -p c:\nsrl\RDA_225_A\NSRLProd.txt,c:\nsrl\RDA_225_B\NSRLProd.txt
# -g :known good txt filename. Ex: -g good.txt
# -b :known bad txt filename. Ex: -b bad.txt
# -h :help
#
#
use Getopt::Std;

my $ver="0.1";

#opcoes
%args = ( );
getopts("hn:p:g:b:", \%args);

#help
if ($args{h}) {
&cabecalho;
print << DETALHE ;
uso: nsrlext.pl -n nsrl_files_comma_separated -p nsrl_prod_files_comma_separated [-g known_good_txt] [-b known_bad_txt] [-h]

-n :nsrl files comma separated. Ex: -n c:\\nsrl\\RDA_225_A\\NSRLFile.txt,c:\\nsrl\\RDA_225_B\\NSRLFile.txt
-p :nsrl prod files comma separated. Ex: -p c:\\nsrl\\RDA_225_A\\NSRLProd.txt,c:\\nsrl\\RDA_225_B\\NSRLProd.txt
-g :known good txt filename. Ex: -g good.txt
-b :known bad txt filename. Ex: -b bad.txt
-h :help

DETALHE
exit;
}

die "Enter the NSRL hashset file list (comma delimited)\n" unless ($args{n});
die "Enter the NSRL product file list (comma delimited)\n" unless ($args{p});

die "Enter known good and/or known bad output filenames\n" unless (($args{g}) || ($args{b}));

my %hack;

&cabecalho;

#Prod files
my @prod = split(/,/, $args{p});

foreach $item (@prod) {
open(PRODUCT, "< $item");

while (< PRODUCT >) {
chomp;
my @line = split(/,/, $_);

#create a hash of hacker tool codes
$hack{$line[0]} = $item if ($line[6] =~ /Hacker Tool/);
}

close(PRODUCT);
}

#hashset files
my @hset = split(/,/, $args{n});

open(BAD, "> $args{b}") if ($args{b});

open(GOOD, "> $args{g}") if ($args{g});

my $i=0;

foreach $item (@hset) {
open(NSRL, "< $item");

while () {

#stdout feedback
print ">" if (($i % 10000) == 0);

my @line = split(/,/, $_);

if ($hack{$line[5]}) {
#is a hacker tool
print BAD $_ if ($args{b});
}
else {
print GOOD $_ if ($args{g});
}

$i++;
}

close(NSRL);
}

print "\nDone !\n";

close(BAD) if ($args{b});
close(GOOD) if ($args{g});

### Sub rotinas ####

sub cabecalho {
print << CABEC;

nsrlext.pl v$ver
Extracts known good and known bad hashsets from NSRL
Tony Rodrigues
dartagnham at gmail dot com
--------------------------------------------------------------------------

CABEC
}

#-----EOF-------


Comentários ?

Até o próximo post !

SQLJuicer

Finalmente, o projeto sobre Forense de SQL Server andou e já tem até nome: SQLJuicer. No contra-exemplo do irmão SAMJuicer, que é uma ferramenta hacker que implementa técnicas anti-forenses, o SQLJuicer nasceu para ajudar a turma que topa com banco de dados em suas investigações e perícias.

O projeto está hospedado no Google Code e já tem uma equipe trabalhando nele. Apesar de estarmos nos primeiros passos, e ainda não estarmos com a ferramenta disponibilizada para todos, a ideia é lançar uma versão aberta tão logo façamos alguns testes com o time.

A título de refresh, já que eu comentei sobre esse projeto em um post recente, a idéia dele é obter informações sobre as operações CRUD (insert, delete e update) em um banco de dados a partir do Transaction Log. Em um primeiro momento, deixamos de fora as operações DDL, mas elas serão incluidas em breve.

Assim que estivermos prontos para publicar a primeira release, avisarei aqui. Se você quiser nos ajudar e contribuir com o trabalho, há espaço para todos. Precisamos de programadores Perl e Testers que conheçam SQL Server. Ainda que você não tenha um desses conhecimentos, pode ser útil no projeto, principalmente na organização e documentação.

Entre em contato comigo para maiores detalhes.

Até o próximo post !

Guymager

Até bem pouco tempo, poderíamos dizer que havia duas ferramentas liderando o ranking das mais usadas na hora H da Forense Computacional, o momento da duplicação forense do HD (ou de outra mídia). Sem levar em consideração os softwares comerciais, onde o FTK e o EnCase vão liderar com vantagem, podemos dizer que há:

- DCFLDD na categoria CLI;
- ADEPTO na categoria GUI.

O dcfldd é uma variante turbinada do dd, e está aos poucos perdendo o seu trono para o novíssimo dc3dd, de Jesse Kornblum. Além das mesmas funcionalidades do dcfldd, o dc3dd permite algumas outras e já foi alvo de discussões anteriores aqui no blog, quando do seu lançamento. Entretanto, quero manter o foco dessa discussão na área gráfica: Para quem curte a facilidade de um ambiente GUI à linha de comandos, o Adepto do Helix é a pedida perfeita. Permite fazer a duplicação tanto usando o formato raw (sem formatação, para ser mais correto) ou o formato AFF. Através de algumas perguntas no início do processo, monta ao final da duplicação uma ficha de cadeia de custódia onde constam dados do investigador/perito, do caso e também da aquisição, inclusive indicando o hash calculado.

O grande problema é que o Helix não está mais tão confiável como Live CD como era antes. Depois da grande reviravolta no início de 2008, quando o mais famoso Live CD de Forense Computacional passou a ser software comercial, a estratégia da turma da e-fense passou a ser discutível. Provavelmente por conta de feedback recebido da comunidade que usava o produto, o Helix voltou a ser disponibilizado, mas a desconfiança está no ar desde então. Como diz um amigo meu "A natureza odeia vácuos", meio que de repente passamos a contar com várias opções ao que era oferecido no Helix. O Adepto agora tem um "concorrente" a altura, que atende pelo nome de Guymager.

Este novo utilitário GUI de captura de imagens forenses está muito bem bolado. Faz uso de multi-threading, o que coloca o produto com alguma vantagem sobre os demais quanto a velocidade de operação. Permite obter informações sobre os dispositivos conectados ao computador, e faz tanto a duplicação em formato EWF (EnCase) quanto AFF, além de raw, é claro. Há um extenso log da operação de captura, inclusive contendo alguns campos informados no início da operação. Esses campos também serão gravados como metadados (menos para raw).

Como nem tudo é notícia boa, o Guymager ainda precisa de algumas implementações. Peguei o endereço do criador do produto e mandei para ele algumas sugestões. Veja:

- Criar imagem forense de partições. Atualmente, o utilitário só cria imagens físicas;
- Montar uma ficha de cadeia de custódia, como no Adepto;
- Permitir enviar o conteúdo da imagem capturada via rede, mesmo que seja usando o netcat.

As duas primeiras, segundo Guy, já estavam sendo estudadas e ele me enviou uma versão beta que já contém a solução para a primeira sugestão. A última pode demorar um pouco mais, porém o autor me garantiu que vai implementar.

O Guymager está disponível tanto no CAINE quanto no DEFT, e também no FCCU. Há também pacotes .Deb para implementação dele fora dos Live CDs.

O que acham do produto ? Alguém que já o tenha utilizado gostaria de compartilhar comentários ?

Até o próximo post !