quarta-feira, 10 de fevereiro de 2010

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 !

sexta-feira, 5 de fevereiro de 2010

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 !

quinta-feira, 4 de fevereiro de 2010

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 !

sábado, 30 de janeiro de 2010

Fuzzy Hashset

Notícia curta mas muito boa.

Já conversamos algumas vezes aqui no blog sobre fuzzy hash. Uma das capacidades dessa implementação hash é a possibilidade de indicar conteúdos "parecidos", ou seja, podemos indicar quanto um arquivo é próximo de outro usando-os em um algoritmo de hash fuzzy. O utilitário que calcula esse hash é o já conhecido ssdeep, que está na versão 2.3, novinha em folha.

Apesar desse software ter grande utilidade para a Forense Computacional, havia algo que há muito sentíamos falta: Um conjunto de hashs de referencia, usando o algoritmo fuzzy. Pois bem, depois de muitos pedidos da comunidade e pesquisadores, o NIST ouviu as nossas preces e lançou uma variação da já conhecida biblioteca/hashset NSRL contendo milhares de hashs pré-calculados usando o ssdeep. Eu ainda recebi a notícia em primeira mão pelo Doug White, um dos especialistas responsáveis pela NSRL.

Entre outras coisas, esse novo hashset vai permitir a aplicação de comparações e filtragem por hashset, mas usando uma técnica ligeiramente diferente da que já existe, para fugir dos casos onde houver anti-forense sendo aplicada.

Planejo um artigo mais detalhado sobre o uso dessa biblioteca/hashset em breve.

Baixe aqui o conteúdo.

Comentários ??

Até o próximo post !

quarta-feira, 20 de janeiro de 2010

O XML nosso de cada dia

A tecnologia volta e meia aparece com modismos. O da vez pode ser considerado o Cloud Computing. Já perdi a conta de quantas vezes ouvi falar em palestras desse tema. Eu procurei, inclusive, ir à uma delas, e foi muito recompensadora, ministrada pelo guru do assunto, Cézar Taurion, da IBM.

O fato é que o modismo de hoje pode representar o nada de amanhã. Ou não ...
Algo que era um grande modismo há alguns anos hoje está plenamente estabelecido: XML. Havia um tempo que tínhamos XML no café da manhã, almoço e jantar. Colocava-se XML em tudo que se fazia, e houve de fato grandes evoluções nos sistemas de informação. Porém, como tudo na vida tende ou a amadurecer ou a desaparecer, o XML seguiu o caminho do bem e hoje quero falar de mais uma grande sacada dos pesquisadores: XML em Forense Computacional.

O autor dessa façanha já é um velho conhecido nosso. Simson Gafinkel já foi citado nesse blog várias vezes, principalmente pelo seu trabalho no poderoso formato AFF. Pois bem, não satisfeito com o bom trabalho de pesquisa que ele vem fazendo pela comunidade de Forense Computacional, Simson está lançando uma nova proposta de trabalho baseada em XML que pode trazer inúmeros benefícios.

A idéia é até muito simples: Ao invés de se constantemente operar com o Sleuth Kit sobre uma imagem, fazendo o parsing de seus outputs, ele propõe usar um programa que "passeia" pela imagem e a mapeia totalmente em um XML. A partir daí, ao invés de se gastar tempo em cada execução de utilitários do Sleuth Kit, você simplesmente percorre o XML gerado, buscando a informação desejada.

Entre vários pontos positivos da nova técnica, Simson destaca:

- Os outputs do TSK variam bastante, principalmente com a versão. Usando o XML, o seu programa fica menos vulnerável a essas mudanças;

- O XML facilita a transferencia de informações on-line, e por conta disso pode-se rodar o programa de mapeamento sobre uma imagem (ou mesmo live) remotamente, enviando o XML resultante pela internet. É a Forense Computacional Remota batendo à sua porta !

- É possível realizar redaction de uma imagem usando esse XML como base. Redaction é a técnica de eliminar informações sensíveis ou indesejáveis em um documento, deixando o restante dele disponível. Lembra daquelas famosas tarjas pretas em documentos oficiais liberados para o público ? Aquilo é redaction. Quando precisamos montar uma imagem para testes ou para fornecer a alunos, não é raro termos que apagar algumas informações importantes que não podem ir junto com a imagem. Para esse fim, há um programa/utilitário desenvolvido pela equipe do Simson que faz o redaction baseado em regras que lhe são passadas. Por exemplo, uma regra poderia ser "sobreescreva com 00h todos os setores onde for encontrado números na forma de cartão de crédito ou emails do domínio xxx.com.br";

- Criar um programa de análise a partir do XML, segundo Simson, é bem mais rápido do que criar chamadas aos utilitários do TSK e fazer o parse do output. Há algumas bibliotecas em python já prontinhas para uso;

- Há uma linha de pesquisa que vai produzir um programa de carving que se beneficia de análises realizadas a partir do XML da imagem forense;

- Há a possibilidade de criar pluging, que executarão durante a varredura que é feita na imagem, montando o XML. Um bom exemplo desses plugins são rotinas (sempre python) para extrair metadados específicos dos arquivos da imagem;

Veja um exemplo de nó XML para um arquivo da imagem forense:




O programa e a library que executam a varredura na imagem é o fiwalk, e pode ser encontrado no site da AFFLIB. Infelizmente, só tem versão para Linux até agora.

Alguém já usa o fiwalk e outros módulos ? Comente !

Até o próximo post !

sábado, 16 de janeiro de 2010

TSK Novo

Brian Carrier, o criador do SleuthKit, acabou de anunciar a mais nova versão do produto: 3.1.0.
Acompanhado de seu inseparável browser Autopsy 2.22, o open source mais famoso de Forense Computacional chega com algumas novidades":

• Suporte ao HFS+ (sistema de arquivos comum nos MAC)
• Suporte a mídias com tamanho de setor diferente de 512 bytes
• Informações sobre o SID de NTFS disponibilizadas (isso já era esperado há algum tempo)
• O conjunto de executáveis para Windows agora também vem com o mactimes
• Partições GPT e DOS são melhor detectadas
• Mais formatos da AFFLIB e suporte melhorado aos arquivos criptografados
• Sigfind consegue processar imagens fora do formato raw
• Suporte a blocos indiretos
• Muitos bugs corrigidos.

Essa deverá ser a versão que virá nos próximos Live CDs. Para quem precisa de alguma dessas novas funcionalidades e não pode esperar novas versões do seu live cd predileto, há algumas opções:

- Instalar o live cd e usar os comandos de atualização apt-get para gerar novos executáveis;
- Utilizar as novas versões para Windows, já compiladas e disponibilizadas.

Alguém gostaria de comentar sobre a novidade ?

Até o próximo post !

sexta-feira, 15 de janeiro de 2010

Turma do dia 25 de Janeiro confirmada

A próxima turma começa em 25 de janeiro, 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 !