O bom velhinho passou pela área de Forense Computacional e tirou do saco um bom presente. Trata-se da mais nova versão da excelente library do formato Advanced Forensic Format, a AFFLIB. Segundo Simson Garfinkel, a nova versão (3.5.5) tem as seguintes funcionalidades:
* Acesso transparente aos formatos AFF, E01 (EnCase) e split-raw;
* Integração transparente com o sistema Amazon S3;
* Criptografia real das imagens forenses usando passphrases ou PKI;
* Assinatura digital das imagens forenses;
* Suporte ao MD5, SHA-1 e SHA-256;
* Uso de arquivos de paridade a fim de permitir a recuperação de erros.
A nova versão roda (e foi testada) em MAC, Windows e diferentes sabores de Linux. Ela pode ser baixada aqui.
Alguém já usa esse formato e gostaria de comentar ? Eu penso que é o formato mais robusto e prático que existe no mercado, mas por algum motivo, ainda é bastante desconhecido.
Até o próximo post !
sábado, 26 de dezembro de 2009
quinta-feira, 24 de dezembro de 2009
Ho Ho Ho
Desejo a toda a turma que acompanha esse blog um Feliz Natal, cheio de evidencias e vestígios comestíveis, e que tudo constitua uma prova forte de uma família abençoada e saudável ! Que todos possamos determinar o 5W1H de como cada presente sob a árvore apareceu e, no fim das contas, trazer o amigo-oculto à luz ! :D
Grande abraço,
Tony Rodrigues
Grande abraço,
Tony Rodrigues
terça-feira, 15 de dezembro de 2009
Café - parte III - DECAF
A polêmica do COFEE continua. Na verdade, agora não exatamente por ele.
Um grupo acabou de lançar o DECAF, um utilitário que monitora a máquina e faz uma série de coisas caso detecte a tentativa de uso do COFEE. A alegação inicial da turma é sempre a mesma: prover instrumentos de manutenção da privacidade. No caso, o COFEE estaria do lado dos vilões, ironicamente.
A versão disponibilizada é a 1.02 e depende do utilitário devcon, da MS. Com ele, o DECAF retira do ar o que quiser, cancela conexões de rede, remove acesso a drivers, limpa o log de eventos e informações nos caches. Enfim, faz uma enorme bagunça.
É lógico supor que vai existir um modo de perceber o DECAF e evitar que ele se esconda do COFEE.
O jogo de gato e rato vai continuar ...
Há dois pontos causando polêmica sobre esse DECAF que gostaria de comentar aqui:
* Um deles é que alguns não consideram o DECAF uma ferramenta de anti-forense. Entretanto, apesar de sua finalidade principal ser obfuscar o uso do COFEE, ele nitidamente vai, se acionado, destruir provas, o que o faz entrar na categoria de anti-forense, com certeza.
* O segundo ponto é relativo às técnicas usadas. O aparecimento do DECAF promete trazer a tona uma série de novas ferramentas que, como os rootkits, escondem as evidências em real-time. Isso pode provocar um pensamento errado de que não é eficiente realizar o procedimento comum de busca de informações voláteis. Há até alguns papers que comparam esse procedimento com o dump de memória e afirmam que somente este último é necessário.
Eu discordo dessa linha de pensamento. Imagino que atualmente há tantas ameaças a uma investigação que tudo que pudermos usar para correlacionar os vestígios é válido. Logicamente que o tempo para fazê-lo e o conhecimento de quem estará na "cena do crime" precisam ser levados em conta. Mas acredito ser temerário tirar conclusões específicas.
Durante a minha palestra no H2HC, comentei sobre uma técnica anti-forense que utiliza rootkit de kernel para se esconder e é poderoso a tal ponto de detectar que um dump de memória está acontecendo e, literalmente, se esconder do dump. Como o código está no nível do kernel, ele simplesmente pode analisar tudo que ocorre e filtrar-se do dump. Essa técnica foi parar em um excelente artigo na Hakin9, escrito pelos amigos Rodrigo BSDaemon e Filipe Balestra, organizadores do H2HC.
Para lidar com essa técnica, sugeri que além do dump de memória, seja feita a aquisição do disco também. Caso exista comportamentos não explicados, a imagem da máquina pode ser usada em uma máquina virtual, bootando-a pelo disco. Quando a máquina virtual estiver a pleno valor, ela deve ser pausada e o arquivo da memória analisado. Dessa forma, o possível malware não teria como se esconder e apareceria na análise.
Essa técnica demonstra que imagem de disco ou de memória, por si só, não fornecem uma técnica completa. Ele enganaria o perito em uma Live Analysis também. No entanto, também não quero insinuar que, para cada caso, teremos que fazer milhares de procedimentos e depois sair correlacionando tudo. Acredito que alguns procedimentos devem ser feitos por padrão e se, durante a análise, a correlação com outros vestígios mostrar que algumas peças estão fora do quebra-cabeças, pode ser necessário retornar ao ponto de partida e obter mais informações, talvez finalmente desligando o micro e partindo para uma dead analysis.
Enfim, não há receita de bolo. Temos que ficar atentos e verificar se podemos parar na Live Acquisition/Analysis, ou avançamos para a análise post-mortem, ou ainda se a análise do dump de memória já basta.
Comentários ?
=== Atualização em 18/12/2009 ====
Os criadores da ferramenta participaram de uma entrevista no Cyberspeak, famoso podcast, e também estava na mesma edição o Ovie Carroll, Diretor de Cybercrime do DoD. Não escutei o pod ainda, mas parece que a ferramenta foi imediatamente retirada do ar pelos seus criadores ...
=== Atualização em 29/12/2009 ====
É, ao que parece, não foi por conscientização que a ferramenta foi retirada. A nova versão, 2.0, já está no ar e há também um press release, indicando os motivos pelos quais a ferramenta foi removida. Nesta nova versão, o DECAF saiu do pé do COFEE e está agora atuando também contra o Helix, o EnCase e alguns outros. O CAINE e o DEFT, que também tem módulos para Resposta a Incidentes, estão fora da lista dessa versão do DECAF. Alguém já baixou o código, produziu alguma análise e gostaria de compartilhar ?
Até o próximo post !
Um grupo acabou de lançar o DECAF, um utilitário que monitora a máquina e faz uma série de coisas caso detecte a tentativa de uso do COFEE. A alegação inicial da turma é sempre a mesma: prover instrumentos de manutenção da privacidade. No caso, o COFEE estaria do lado dos vilões, ironicamente.
A versão disponibilizada é a 1.02 e depende do utilitário devcon, da MS. Com ele, o DECAF retira do ar o que quiser, cancela conexões de rede, remove acesso a drivers, limpa o log de eventos e informações nos caches. Enfim, faz uma enorme bagunça.
É lógico supor que vai existir um modo de perceber o DECAF e evitar que ele se esconda do COFEE.
O jogo de gato e rato vai continuar ...
Há dois pontos causando polêmica sobre esse DECAF que gostaria de comentar aqui:
* Um deles é que alguns não consideram o DECAF uma ferramenta de anti-forense. Entretanto, apesar de sua finalidade principal ser obfuscar o uso do COFEE, ele nitidamente vai, se acionado, destruir provas, o que o faz entrar na categoria de anti-forense, com certeza.
* O segundo ponto é relativo às técnicas usadas. O aparecimento do DECAF promete trazer a tona uma série de novas ferramentas que, como os rootkits, escondem as evidências em real-time. Isso pode provocar um pensamento errado de que não é eficiente realizar o procedimento comum de busca de informações voláteis. Há até alguns papers que comparam esse procedimento com o dump de memória e afirmam que somente este último é necessário.
Eu discordo dessa linha de pensamento. Imagino que atualmente há tantas ameaças a uma investigação que tudo que pudermos usar para correlacionar os vestígios é válido. Logicamente que o tempo para fazê-lo e o conhecimento de quem estará na "cena do crime" precisam ser levados em conta. Mas acredito ser temerário tirar conclusões específicas.
Durante a minha palestra no H2HC, comentei sobre uma técnica anti-forense que utiliza rootkit de kernel para se esconder e é poderoso a tal ponto de detectar que um dump de memória está acontecendo e, literalmente, se esconder do dump. Como o código está no nível do kernel, ele simplesmente pode analisar tudo que ocorre e filtrar-se do dump. Essa técnica foi parar em um excelente artigo na Hakin9, escrito pelos amigos Rodrigo BSDaemon e Filipe Balestra, organizadores do H2HC.
Para lidar com essa técnica, sugeri que além do dump de memória, seja feita a aquisição do disco também. Caso exista comportamentos não explicados, a imagem da máquina pode ser usada em uma máquina virtual, bootando-a pelo disco. Quando a máquina virtual estiver a pleno valor, ela deve ser pausada e o arquivo da memória analisado. Dessa forma, o possível malware não teria como se esconder e apareceria na análise.
Essa técnica demonstra que imagem de disco ou de memória, por si só, não fornecem uma técnica completa. Ele enganaria o perito em uma Live Analysis também. No entanto, também não quero insinuar que, para cada caso, teremos que fazer milhares de procedimentos e depois sair correlacionando tudo. Acredito que alguns procedimentos devem ser feitos por padrão e se, durante a análise, a correlação com outros vestígios mostrar que algumas peças estão fora do quebra-cabeças, pode ser necessário retornar ao ponto de partida e obter mais informações, talvez finalmente desligando o micro e partindo para uma dead analysis.
Enfim, não há receita de bolo. Temos que ficar atentos e verificar se podemos parar na Live Acquisition/Analysis, ou avançamos para a análise post-mortem, ou ainda se a análise do dump de memória já basta.
Comentários ?
=== Atualização em 18/12/2009 ====
Os criadores da ferramenta participaram de uma entrevista no Cyberspeak, famoso podcast, e também estava na mesma edição o Ovie Carroll, Diretor de Cybercrime do DoD. Não escutei o pod ainda, mas parece que a ferramenta foi imediatamente retirada do ar pelos seus criadores ...
=== Atualização em 29/12/2009 ====
É, ao que parece, não foi por conscientização que a ferramenta foi retirada. A nova versão, 2.0, já está no ar e há também um press release, indicando os motivos pelos quais a ferramenta foi removida. Nesta nova versão, o DECAF saiu do pé do COFEE e está agora atuando também contra o Helix, o EnCase e alguns outros. O CAINE e o DEFT, que também tem módulos para Resposta a Incidentes, estão fora da lista dessa versão do DECAF. Alguém já baixou o código, produziu alguma análise e gostaria de compartilhar ?
Até o próximo post !
quinta-feira, 10 de dezembro de 2009
PeriBr
Já falei brevemente sobre essa que é a mais nova distro brasileira em Live CD para Forense, comentando sobre alguns detalhes que li sobre a ferramenta. Agora é hora de passar as primeiras impressões, depois de alguns testes.
O boot tem opção de ir direto para o modo texto, o que pode facilitar aos mais avançados (e mais apressados também). Mesmo com a opção de boot pelo modo gráfico, achei a carga bem mais rápida que outras versões por aí.
Ele está baseado no Ubuntu, com kernel 2.6.28-15. O Gnome está na versão 2.26.1 e, como diferencial nessa parte gráfica, há um charmoso menu USP com tradução total para o português tupiniquim, o que vai facilitar muita gente. O teclado veio configurado corretamente para o meu US International. Não tenho aqui o ABNT2 para testar, e esse é o grande problema quando se fala em teclado, pois a maioria tem dificuldades com ele. Ainda assim, a exemplo do que a turma do CAINE implementou, há um atalho no desktop que permite a troca de teclado rapidamente.
O menu do PeriBr me impressionou positivamente. Há praticamente uma entrada para cada utilitário forense instalado. Mesmo se linha de comando, o menu abre uma tela com as options do utilitário, e em algumas vezes, abre também a página man. Além disso, um terminal root fica a disposição para que o comando escolhido seja digitado. A disposição do menu, além de separar por grupo de funcionalidades, também fornece um "tip" indicando o que a ferramenta faz. Isso é fantástico, já que não há Mb de cérebro que resista a quantidade de ferramentas que temos hoje na Computação Forense.
As melhores e mais conhecidas ferramentas estão presentes. Desde os xxxdeep, para hash, até o ssdeep, que nem todos os live cds trazem, temos Ophcrack, Wireshark, Guymager, dc3dd GUI e outros. Há vários utilitários para cada tarefa. Um ou outro está faltando nessa boa lista, incluindo o exiftool e alguma ferramenta para atividade de browser que não o IE. Falando em browser, o Firefox está a todo vapor, turbinando alguns dos melhores pacotes integrados disponíveis em Open Source: o Pyflag. Tudo bem que, para usá-lo bem, o live cd precisará ser instalado, mas isso vem sendo algo comum. Interessante que, na época do Helix baseado em Knoppix, era considerado sacrilégio instalá-lo ... Novos tempos ...
No melhor estilo dos comerciais das organizações Tabajara, podemos ainda dizer "Mas não é só isso !" ... Porque, além do Pyflag, a turma que construiu o PeriBr nos trouxe o PTK, o novíssimo browser/interface para o TSK. É o Icing on the cake ...
Pontos Positivos:
* Ferramentas em abundância;
* Menus em PT-BR;
* Política de montagem de volumes em coerência com as proteções de software forense;
* Pyflag e PTK, mesmo exigindo instalação.
Pontos Negativos:
* Versão 1.0 ... Isso chega a ser um fantasma. Será que o projeto vai romper a barreira e continuar ?
* Falta um site adequado, como no projeto do CAINE ou do DEFT;
* Roadmap divulgado. Isso pode ser um luxo para a versão 1.0, mas já seria uma boa forma de tranquilizar os usuários, dando mostras de que o projeto vai continuar;
* Ausência de suporte a ferramentas Python, ao RegRipper e o Volatility.
Espero que esse novo produto rompa com a barreira do 1.0 e vire um trabalho muito além de um trabalho de fim de curso. Toda a comunidade vai agradecer imensamente !
Comentários ?
Até o próximo post !
O boot tem opção de ir direto para o modo texto, o que pode facilitar aos mais avançados (e mais apressados também). Mesmo com a opção de boot pelo modo gráfico, achei a carga bem mais rápida que outras versões por aí.
Ele está baseado no Ubuntu, com kernel 2.6.28-15. O Gnome está na versão 2.26.1 e, como diferencial nessa parte gráfica, há um charmoso menu USP com tradução total para o português tupiniquim, o que vai facilitar muita gente. O teclado veio configurado corretamente para o meu US International. Não tenho aqui o ABNT2 para testar, e esse é o grande problema quando se fala em teclado, pois a maioria tem dificuldades com ele. Ainda assim, a exemplo do que a turma do CAINE implementou, há um atalho no desktop que permite a troca de teclado rapidamente.
O menu do PeriBr me impressionou positivamente. Há praticamente uma entrada para cada utilitário forense instalado. Mesmo se linha de comando, o menu abre uma tela com as options do utilitário, e em algumas vezes, abre também a página man. Além disso, um terminal root fica a disposição para que o comando escolhido seja digitado. A disposição do menu, além de separar por grupo de funcionalidades, também fornece um "tip" indicando o que a ferramenta faz. Isso é fantástico, já que não há Mb de cérebro que resista a quantidade de ferramentas que temos hoje na Computação Forense.
As melhores e mais conhecidas ferramentas estão presentes. Desde os xxxdeep, para hash, até o ssdeep, que nem todos os live cds trazem, temos Ophcrack, Wireshark, Guymager, dc3dd GUI e outros. Há vários utilitários para cada tarefa. Um ou outro está faltando nessa boa lista, incluindo o exiftool e alguma ferramenta para atividade de browser que não o IE. Falando em browser, o Firefox está a todo vapor, turbinando alguns dos melhores pacotes integrados disponíveis em Open Source: o Pyflag. Tudo bem que, para usá-lo bem, o live cd precisará ser instalado, mas isso vem sendo algo comum. Interessante que, na época do Helix baseado em Knoppix, era considerado sacrilégio instalá-lo ... Novos tempos ...
No melhor estilo dos comerciais das organizações Tabajara, podemos ainda dizer "Mas não é só isso !" ... Porque, além do Pyflag, a turma que construiu o PeriBr nos trouxe o PTK, o novíssimo browser/interface para o TSK. É o Icing on the cake ...
Pontos Positivos:
* Ferramentas em abundância;
* Menus em PT-BR;
* Política de montagem de volumes em coerência com as proteções de software forense;
* Pyflag e PTK, mesmo exigindo instalação.
Pontos Negativos:
* Versão 1.0 ... Isso chega a ser um fantasma. Será que o projeto vai romper a barreira e continuar ?
* Falta um site adequado, como no projeto do CAINE ou do DEFT;
* Roadmap divulgado. Isso pode ser um luxo para a versão 1.0, mas já seria uma boa forma de tranquilizar os usuários, dando mostras de que o projeto vai continuar;
* Ausência de suporte a ferramentas Python, ao RegRipper e o Volatility.
Espero que esse novo produto rompa com a barreira do 1.0 e vire um trabalho muito além de um trabalho de fim de curso. Toda a comunidade vai agradecer imensamente !
Comentários ?
Até o próximo post !
quinta-feira, 3 de dezembro de 2009
Tudo (ou quase tudo) que você sempre quis saber sobre Anti-Forense, mas não teve tempo de perguntar na palestra
Vamos conversar um pouco mais sobre Anti-Forense e algumas maneiras de tratá-la. Esse assunto rende muito e, para falar sobre ele em 45 min, muita coisa tem que ser passada bem rapidamente.
Esculhambando as MAC Times
Um dos mais úteis instrumentos de investigação é a linha de tempo. Ordenar cada um dos eventos e sequenciá-los pode indicar o que aconteceu e ajudar também a chegar na causa de um incidente. É como ler um diário de bordo, só que nesse caso, quem o escreve são os programas do computador.
A timeline mais comum é aquela baseada no que chamamos de MAC times, atributos de data e hora relacionados com eventos de arquivos. O M diz respeito a data/hora da última modificação do arquivo; O A é relativo a data/hora do último acesso e o C é relativo a data/hora de criação do arquivo. Vale a pena reforçar duas coisas:
1) Isso vale para o NTFS. Outros sistemas de arquivos podem não ter esses atributos;
2) Há ainda um outro atributo, conhecido por E e se refere a data/hora da última alteração de atributos do arquivo.
Como a maioria das ações em uma máquina corre por acessar, alterar e criar arquivos, levantar e ordenar essas ações dão uma linha de tempo excelente. Pense em casos de invasão ou infecção por vírus. Uma linha de tempo com foco em uma faixa de datas aproximada pode indicar a causa, o vetor de entrada e até mesmo arquivos afetados que nem imaginaríamos.
Como a Anti-Forense tem por objetivo principal acabar com as técnicas, processos e ferramentas de Computação Forense, uma técnica bem específica foi moldada para "esculhambar" com a já famosa e muito utilizada timeline. Imagine o seguinte:
1) Alguém liga para o Service Desk da empresa e avisa que sua máquina está com um comportamento muito estranho. São 9h00;
2) A turma responsável dá uma olhada, determina que houve uma infecção por malware, não capturado pelo Antivírus instalado na máquina. Para verificar a extensão do dano e saber quantos arquivos foram danificados pelo vírus, uma timeline é montada;
3) A timeline revela que a infecção se alastrou depois de um certo arquivo ser criado na máquina, às 8h30. Esse arquivo foi "baixado" por engano pelo próprio usuário, que caiu em um phishing;
4) Ainda usando a timeline, filtrando-a entre 8h30 e 9h, soube-se que os arquivos X, Y e Z foram afetados pelo mesmo malware.
A situação acima ficaria fora de controle se o malware usasse a técnica de Anti-Forense descrita. Logo de início, a turma de investigação veria que há um download suspeito por volta de 8h30, mas esse arquivo está com data de criação de 3 anos atrás. A mesma data está registrada no último acesso e última modificação. Ele ficou de fora da linha de tempo montada com foco entre 8h30 e 9h. Os vários arquivos X, Y e Z também, já que inexplicavelmente, eles tem suas datas indicando o ano de 1601 como data/hora dos atributos.
Nesse cenário com uso de Anti-Forense, por outras técnicas poderíamos chegar ao vetor inicial e a causa da infecção, mas provavelmente os arquivos corrompidos X, Y e Z não seriam detectados.
Falando especificamente de Windows e NTFS, a turma da Anti-Forense Metasploit Project liberou um utilitário para esse fim. O Timestomp permite tanto zerar as datas dos atributos quanto modificar para um valor específico todos ou apenas alguns dos atributos.
Anti-Anti-Forense
Alguns pontos podem ser levantados para indicar a presença de técnicas Anti-Forense. Principalmente, leva-se em conta que a ação de subverter das datas dos atributos não leva em consideração que o atacante terá tempo suficiente para pesquisar e setar uma data falsa, mas que ainda mantenha a lógica dos valores. Por isso, algumas idéias:
1) O NTFS mantém os mesmos 4 atributos de data/hora em dois lugares. Há os MACE times gravados no Standard Information Attribute (SIA) e há os MACE times gravados no FileName Attribute (FN). Embora eu não tenha localizado uma documentação que claramente estabeleça a diferença entre as duas e quando uma ou outra é alterada, fiz vários testes de comportamento desses atributos e pude perceber que o comportamento lógico deles (ou seria ilógico) é que, em quaisquer das operações setadas, os atributos da FN são trabalhados primeiro que os da SIA. Portanto, é lógico que as datas/hora do FN sejam mais antigas que as do SIA
2) A resolução de horas dos atributos vão até os milissegundos. É muito comum que, ao subverter uma data, o atacante informe uma data/hora até, no máximo, os segundos. Dessa forma, os atributos ficam com os milissegundos zerados. Isso pode ser usado como característica de detecção. Não é uma técnica definitiva, pois alguns produtos, ao criarem arquivos, também escrevem horas indo até os segundos, e nesse caso, também ficam com os milissegundos zerados.
3) As datas de criação de um arquivo ordinário, em geral, não podem ser mais antigas que a data de formatação do sistema de arquivos (ou seja, a data de quando o disco foi formatado). Há alguns casos onde arquivos copiados/movidos de outras mídias podem ferir essa regra.
4) As datas dos arquivos não podem estar no futuro. Alguns atacantes se confundem ao setar a data, com as posições de dia e mês, e acabam por colocar a data do arquivo no futuro. Normalmente, isso nem seria notado, mesmo em uma linha do tempo, que em geral também é limitada nas datas onde acreditamos que o incidente tenha acontecido.
5) Quando a opção de data zerada do timestomp é usada, isso deixa o Encase sem indicar data alguma. No caso de acesso via utilitários, é comum que o ano apareça como de 16o1. Essa é a maior marca de que a máquina foi vítima de Anti-Forense. Esse é um dos poucos casos onde não conheço possibilidade de falso positivo.
6) O conceito de linha do tempo precisa ser expandido. Há muitos eventos acontecendo em uma invasão ou outro incidente, não podemos ficar focados apenas no que os arquivos dizem. Seguindo essa lógica, todas as fontes de informação que registram ações com data/hora devem ser alinhadas e ordenadas em uma linha de tempo, principalmente as fontes externas à maquina suspeita, onde o atacante teria menos controle e recebem menos atenção. Linhas de tempo bem completas podem incluir acionamento de arquivos executáveis e DLLs vindos de um Prefetch, uso de arquivos obtidos pelo Registry, logs diversos, eventos do Windows, etc. Tem data/hora, então pode ser útil. Um exemplo da aplicação desse conceito:
- O atacante usa o reg para baixar o SAM da máquina para um arquivo SAM.txt, sendo que ele falha na primeira tentativa. Ele o abre, verifica o conteúdo, e o envia para um servidor remoto via HTTP. Em seguida, o atacante remove o arquivo SAM.txt e usa o timestomp, zerando os MAC times do reg.exe.
Nesse contexto, uma linha de tempo que englobe os atalhos de Recent, o log de acesso do proxy e
o log de eventos do Windows pode colocar no devido lugar a ação de gerar um arquivo que foi acessado e enviado, mas não existe mais.
Eu criei uma rotina que verifica os atributos MACE dos arquivos e indica os que são suspeitos de Anti-Forense. Baixe-a no conjunto de rotinas do Byte Investigator.
Comentários ? Alguém que já tenha encontrado alguma dessas situações em uma investigação e gostaria de compartilhar como tratou o problema ?
Até o próximo post !
Esculhambando as MAC Times
Um dos mais úteis instrumentos de investigação é a linha de tempo. Ordenar cada um dos eventos e sequenciá-los pode indicar o que aconteceu e ajudar também a chegar na causa de um incidente. É como ler um diário de bordo, só que nesse caso, quem o escreve são os programas do computador.
A timeline mais comum é aquela baseada no que chamamos de MAC times, atributos de data e hora relacionados com eventos de arquivos. O M diz respeito a data/hora da última modificação do arquivo; O A é relativo a data/hora do último acesso e o C é relativo a data/hora de criação do arquivo. Vale a pena reforçar duas coisas:
1) Isso vale para o NTFS. Outros sistemas de arquivos podem não ter esses atributos;
2) Há ainda um outro atributo, conhecido por E e se refere a data/hora da última alteração de atributos do arquivo.
Como a maioria das ações em uma máquina corre por acessar, alterar e criar arquivos, levantar e ordenar essas ações dão uma linha de tempo excelente. Pense em casos de invasão ou infecção por vírus. Uma linha de tempo com foco em uma faixa de datas aproximada pode indicar a causa, o vetor de entrada e até mesmo arquivos afetados que nem imaginaríamos.
Como a Anti-Forense tem por objetivo principal acabar com as técnicas, processos e ferramentas de Computação Forense, uma técnica bem específica foi moldada para "esculhambar" com a já famosa e muito utilizada timeline. Imagine o seguinte:
1) Alguém liga para o Service Desk da empresa e avisa que sua máquina está com um comportamento muito estranho. São 9h00;
2) A turma responsável dá uma olhada, determina que houve uma infecção por malware, não capturado pelo Antivírus instalado na máquina. Para verificar a extensão do dano e saber quantos arquivos foram danificados pelo vírus, uma timeline é montada;
3) A timeline revela que a infecção se alastrou depois de um certo arquivo ser criado na máquina, às 8h30. Esse arquivo foi "baixado" por engano pelo próprio usuário, que caiu em um phishing;
4) Ainda usando a timeline, filtrando-a entre 8h30 e 9h, soube-se que os arquivos X, Y e Z foram afetados pelo mesmo malware.
A situação acima ficaria fora de controle se o malware usasse a técnica de Anti-Forense descrita. Logo de início, a turma de investigação veria que há um download suspeito por volta de 8h30, mas esse arquivo está com data de criação de 3 anos atrás. A mesma data está registrada no último acesso e última modificação. Ele ficou de fora da linha de tempo montada com foco entre 8h30 e 9h. Os vários arquivos X, Y e Z também, já que inexplicavelmente, eles tem suas datas indicando o ano de 1601 como data/hora dos atributos.
Nesse cenário com uso de Anti-Forense, por outras técnicas poderíamos chegar ao vetor inicial e a causa da infecção, mas provavelmente os arquivos corrompidos X, Y e Z não seriam detectados.
Falando especificamente de Windows e NTFS, a turma da Anti-Forense Metasploit Project liberou um utilitário para esse fim. O Timestomp permite tanto zerar as datas dos atributos quanto modificar para um valor específico todos ou apenas alguns dos atributos.
Anti-Anti-Forense
Alguns pontos podem ser levantados para indicar a presença de técnicas Anti-Forense. Principalmente, leva-se em conta que a ação de subverter das datas dos atributos não leva em consideração que o atacante terá tempo suficiente para pesquisar e setar uma data falsa, mas que ainda mantenha a lógica dos valores. Por isso, algumas idéias:
1) O NTFS mantém os mesmos 4 atributos de data/hora em dois lugares. Há os MACE times gravados no Standard Information Attribute (SIA) e há os MACE times gravados no FileName Attribute (FN). Embora eu não tenha localizado uma documentação que claramente estabeleça a diferença entre as duas e quando uma ou outra é alterada, fiz vários testes de comportamento desses atributos e pude perceber que o comportamento lógico deles (ou seria ilógico) é que, em quaisquer das operações setadas, os atributos da FN são trabalhados primeiro que os da SIA. Portanto, é lógico que as datas/hora do FN sejam mais antigas que as do SIA
2) A resolução de horas dos atributos vão até os milissegundos. É muito comum que, ao subverter uma data, o atacante informe uma data/hora até, no máximo, os segundos. Dessa forma, os atributos ficam com os milissegundos zerados. Isso pode ser usado como característica de detecção. Não é uma técnica definitiva, pois alguns produtos, ao criarem arquivos, também escrevem horas indo até os segundos, e nesse caso, também ficam com os milissegundos zerados.
3) As datas de criação de um arquivo ordinário, em geral, não podem ser mais antigas que a data de formatação do sistema de arquivos (ou seja, a data de quando o disco foi formatado). Há alguns casos onde arquivos copiados/movidos de outras mídias podem ferir essa regra.
4) As datas dos arquivos não podem estar no futuro. Alguns atacantes se confundem ao setar a data, com as posições de dia e mês, e acabam por colocar a data do arquivo no futuro. Normalmente, isso nem seria notado, mesmo em uma linha do tempo, que em geral também é limitada nas datas onde acreditamos que o incidente tenha acontecido.
5) Quando a opção de data zerada do timestomp é usada, isso deixa o Encase sem indicar data alguma. No caso de acesso via utilitários, é comum que o ano apareça como de 16o1. Essa é a maior marca de que a máquina foi vítima de Anti-Forense. Esse é um dos poucos casos onde não conheço possibilidade de falso positivo.
6) O conceito de linha do tempo precisa ser expandido. Há muitos eventos acontecendo em uma invasão ou outro incidente, não podemos ficar focados apenas no que os arquivos dizem. Seguindo essa lógica, todas as fontes de informação que registram ações com data/hora devem ser alinhadas e ordenadas em uma linha de tempo, principalmente as fontes externas à maquina suspeita, onde o atacante teria menos controle e recebem menos atenção. Linhas de tempo bem completas podem incluir acionamento de arquivos executáveis e DLLs vindos de um Prefetch, uso de arquivos obtidos pelo Registry, logs diversos, eventos do Windows, etc. Tem data/hora, então pode ser útil. Um exemplo da aplicação desse conceito:
- O atacante usa o reg para baixar o SAM da máquina para um arquivo SAM.txt, sendo que ele falha na primeira tentativa. Ele o abre, verifica o conteúdo, e o envia para um servidor remoto via HTTP. Em seguida, o atacante remove o arquivo SAM.txt e usa o timestomp, zerando os MAC times do reg.exe.
Nesse contexto, uma linha de tempo que englobe os atalhos de Recent, o log de acesso do proxy e
o log de eventos do Windows pode colocar no devido lugar a ação de gerar um arquivo que foi acessado e enviado, mas não existe mais.
Eu criei uma rotina que verifica os atributos MACE dos arquivos e indica os que são suspeitos de Anti-Forense. Baixe-a no conjunto de rotinas do Byte Investigator.
Comentários ? Alguém que já tenha encontrado alguma dessas situações em uma investigação e gostaria de compartilhar como tratou o problema ?
Até o próximo post !
domingo, 29 de novembro de 2009
H2HC 2009 - Segundo dia
O segundo e último dia foi bastante cheio. Em meio a turma que assistia às palestras e aos multi-tarefas que assistiam e ainda participavam do CTF desse ano, ainda havia um ou outro sorteio patrocinado pela turma de expositores.
Aliás, antes que eu comente sobre o dia, esqueci de falar sobre o grande sucesso que foi ontem o H2CSO. Segundo os organizadores, havia mais de 600 inscritos na sala virtual do evento. Um grande passo no amadurecimento e na profissionalização do nosso segmento;
- Novamente, perdi a primeira palestra e acabei chegando na palestra do Paulo Roizman sobre Ciber terrorismo. A palestra comentou, inclusive, sobre casos no Brasil;
- José Milagres veio logo em seguida com uma super palestra sobre legislação, hackers e ética nas questões periciais. Além de instrutiva, ao final dela tinha uma multidão querendo tirar dúvidas com ele. Isso é mais uma prova de como a turma está interessada nessas questões;
- Outros destaques ainda para a segunda parte da palestra do Nelson Brito, a palestra sobre W3af do Andrés Riancho e o outro ponto alto do dia, com o franco-carioca Jonathan Brossard e sua técnica "sinixxxtra" de patching para brute-forcing do truecrypt.
Aguardo comentários sobre o evento, principalmente sobre algumas palestras que eu não estive. Comentem !
Até o próximo post !
Aliás, antes que eu comente sobre o dia, esqueci de falar sobre o grande sucesso que foi ontem o H2CSO. Segundo os organizadores, havia mais de 600 inscritos na sala virtual do evento. Um grande passo no amadurecimento e na profissionalização do nosso segmento;
- Novamente, perdi a primeira palestra e acabei chegando na palestra do Paulo Roizman sobre Ciber terrorismo. A palestra comentou, inclusive, sobre casos no Brasil;
- José Milagres veio logo em seguida com uma super palestra sobre legislação, hackers e ética nas questões periciais. Além de instrutiva, ao final dela tinha uma multidão querendo tirar dúvidas com ele. Isso é mais uma prova de como a turma está interessada nessas questões;
- Outros destaques ainda para a segunda parte da palestra do Nelson Brito, a palestra sobre W3af do Andrés Riancho e o outro ponto alto do dia, com o franco-carioca Jonathan Brossard e sua técnica "sinixxxtra" de patching para brute-forcing do truecrypt.
Aguardo comentários sobre o evento, principalmente sobre algumas palestras que eu não estive. Comentem !
Até o próximo post !
sábado, 28 de novembro de 2009
H2HC 2009 - Primeiro dia
O evento desse ano começou impressionando pelo lugar. O hotel tem uma boa estrutura e localização. Há mais expositores e a sala de palestras é de muito bom nível, iluminação e som.
Como é de praxe, nem sempre dá para estar em todas as palestras. Vou comentar algumas:
- O Gustavo Scotti comentou sobre a arquitetura 64-bit e como algumas coisas não são tão seguras como se anuncia por aí. Foi uma palestra bastante técnica e mais voltada para a turma escovadora de bits.
- Bruno Oliveira matou a turma de tanto rir com seus casos de pentest usando Engenharia Social. A palestra não ficou só nisso, mas englobou também as grandes falhas/negligências encontradas no dia a dia e que acabam por invalidar a segurança do todo. Conclusão final: "People Sux" ...
- Weber Ress, também camarada da CISSPBR, falou sobre a história do Kernel e dos detalhes do Kernel do Windows. Foi uma boa palestra, mas confesso que não consegui prestar tanta atenção depois que meu camarada Filipe Balestra me pediu para adiantar a minha palestra, do Domingo pela manhã, para logo após a do Weber. Ou seja, enquanto o Weber falava, eu estava tentando lembrar dos pontos chaves de cada abordagem.
- A minha palestra veio em seguida. Falei sobre técnicas que subvertem a Computação Forense e como podemos detectá-las ou anulá-las. Fiquei surpreso ao reparar a quantidade de gente que ficou na sala, pois imaginava que esse assunto não daria tanto ibope assim. A receptividade foi boa, consegui passar o assunto todo e ainda deu para responder uma excelente pergunta do Dr José Milagres. Em seguida, almoço.
- Na parte da tarde, tivemos a palestra do Anderson Ramos, falando muito bem sobre privacidade e suas implicações no mundo de hoje.
- Nelson Brito fez a primeira parte de sua palestra e mostrou exploits para algumas vulnerabilidades antigas, mas com algumas modificações bastante interessantes. As musicas e o visual da palestra dele já valem.
- Sebastian Porst falou sobre o uso de REIL, uma espécie de meta linguagem que permite, entre outras coisas, facilitar a análise de códigos via reengenharia. Ajuda, inclusive, fazendo desobfuscação de código.
- Cesar Cerrudo veio da Argentina para mostrar uma novidade: A exploração de tokens como forma de aumentar os privilégios em um sistema. Não confunda esses tokens com os utilizados em 2-factor authentication. Estamos falando sobre códigos internos passados entre chamadas de funções do Windows e que indicam o nível de autorização recebido.
- Carlos Sarraute mostrou uma modelagem matemática formal para ajudar a priorizar ações em uma possível exploração de vulnerabilidades. Esse é o trabalho de tese de doutorado dele. Cálculos e mais cálculos depois, o Rodrigo completou dizendo que esse estudo dele já está sendo usado como forma de indicar para as empresas qual a vulnerabilidade que trará mais retorno para ser tratada/comprada.
- Nicolas Waisman comentou sobre a exploração de heap via bitmask. Essa foi mais uma bastante escovação de bit.
Saldo positivo no fim do dia, com bastante coisa na bagagem e a sensação de que "quanto mais sei, sei que nada sei" ...
Comentários ? Dê a sua opinião a respeito das palestras e do evento !
Até o próximo post !
Como é de praxe, nem sempre dá para estar em todas as palestras. Vou comentar algumas:
- O Gustavo Scotti comentou sobre a arquitetura 64-bit e como algumas coisas não são tão seguras como se anuncia por aí. Foi uma palestra bastante técnica e mais voltada para a turma escovadora de bits.
- Bruno Oliveira matou a turma de tanto rir com seus casos de pentest usando Engenharia Social. A palestra não ficou só nisso, mas englobou também as grandes falhas/negligências encontradas no dia a dia e que acabam por invalidar a segurança do todo. Conclusão final: "People Sux" ...
- Weber Ress, também camarada da CISSPBR, falou sobre a história do Kernel e dos detalhes do Kernel do Windows. Foi uma boa palestra, mas confesso que não consegui prestar tanta atenção depois que meu camarada Filipe Balestra me pediu para adiantar a minha palestra, do Domingo pela manhã, para logo após a do Weber. Ou seja, enquanto o Weber falava, eu estava tentando lembrar dos pontos chaves de cada abordagem.
- A minha palestra veio em seguida. Falei sobre técnicas que subvertem a Computação Forense e como podemos detectá-las ou anulá-las. Fiquei surpreso ao reparar a quantidade de gente que ficou na sala, pois imaginava que esse assunto não daria tanto ibope assim. A receptividade foi boa, consegui passar o assunto todo e ainda deu para responder uma excelente pergunta do Dr José Milagres. Em seguida, almoço.
- Na parte da tarde, tivemos a palestra do Anderson Ramos, falando muito bem sobre privacidade e suas implicações no mundo de hoje.
- Nelson Brito fez a primeira parte de sua palestra e mostrou exploits para algumas vulnerabilidades antigas, mas com algumas modificações bastante interessantes. As musicas e o visual da palestra dele já valem.
- Sebastian Porst falou sobre o uso de REIL, uma espécie de meta linguagem que permite, entre outras coisas, facilitar a análise de códigos via reengenharia. Ajuda, inclusive, fazendo desobfuscação de código.
- Cesar Cerrudo veio da Argentina para mostrar uma novidade: A exploração de tokens como forma de aumentar os privilégios em um sistema. Não confunda esses tokens com os utilizados em 2-factor authentication. Estamos falando sobre códigos internos passados entre chamadas de funções do Windows e que indicam o nível de autorização recebido.
- Carlos Sarraute mostrou uma modelagem matemática formal para ajudar a priorizar ações em uma possível exploração de vulnerabilidades. Esse é o trabalho de tese de doutorado dele. Cálculos e mais cálculos depois, o Rodrigo completou dizendo que esse estudo dele já está sendo usado como forma de indicar para as empresas qual a vulnerabilidade que trará mais retorno para ser tratada/comprada.
- Nicolas Waisman comentou sobre a exploração de heap via bitmask. Essa foi mais uma bastante escovação de bit.
Saldo positivo no fim do dia, com bastante coisa na bagagem e a sensação de que "quanto mais sei, sei que nada sei" ...
Comentários ? Dê a sua opinião a respeito das palestras e do evento !
Até o próximo post !
quarta-feira, 18 de novembro de 2009
Caine 1.5
A turma do CAINE não me deixa descansar :)
Mal anunciei a nova versão 1.0 e suas funcionalidades e já temos a versão 1.5 - Shinning - com mais algumas turbinadas. A versão irmã para pendrive, NBCaine, também foi liberada.
Algumas ferramentas foram atualizadas, tanto no lado Windows como no Linux, incluindo algumas velhas dívidas, como era o caso do md5deep. O Kernel agora é o 2.6-24.25.
O Desktop recebeu uma cara nova e a possibilidade de troca de teclado mais facilmente, sem ter que digitar o comando. Um atalho também leva do desktop diretamente a um conjunto de scripts bastante úteis, alguns deles criados pela própria equipe do CAINE.
O Xteg (detecta esteganografia), Photorec e TestDisk foram parar no menu Forensics. O TSK já tinha sido atualizado na 1.0 junto com o Autopsy, mas este ultimo continua fora da path. O menu Altro recebeu o TkDiff, para comparações em arquivos texto, e o UUDeview, útil nas decodificações MIME.
Em relação à ultima avaliação que fiz, o CAINE continua mantendo os pontos positivos, enquanto que a equipe fez um compensado esforço para cobrir os pontos que consideramos negativos. A documentação vem cada vez melhor, o teclado é configurável, o boot pode ser direto em modo texto e as ferramentas disponíveis estão muito boas. Há ainda a falta de algumas, como por exemplo o RegRipper, Gigolo, Antivirus e o Volatility, mas eu conversei com o grupo e há razões para isso. Uma delas é que o custo de manter a parte de resposta a incidentes (WinTaylor) é alto, já que ocupa bastante espaço do CD. Pelo que conversamos, uma boa estratégia é montar mais de uma versão, fazendo com que sejam direcionadas. Para aquisição, podemos manter tudo em um Live CD com algumas ferramentas de preview e aquisição de disco e memória. Para análise, provavelmente estaremos indo para um Live DVD com muitas opções e ferramentas, incluindo as duas citadas mais o Xplico e outras disponíveis na web. A versão 2.0 já está sendo ansiosamente aguardada ...
Pontos Positivos:
- Atualizações constantes;
- TSK compilado com suporte a vários formatos;
- Muitas ferramentas disponíveis;
- Política de montagem de mídias formalizada;
- Facilmente instalável;
- Facilidade de entrada em modo texto;
- Pode ser usado pelo pendrive e complementado, se for o caso, pelo Perito.
Pontos Negativos:
- Ausência de algumas ferramentas de análise importantes (RegRipper, Jtr, ssdeep, Volatility, ferramentas de network forensics, etc) ;
- Documentação no site poderia conter um Roadmap.
Como podem ver, há poucos pontos negativos e a tendência é que cada vez mais essa distro melhore e tome o lugar de ferramenta free mais utilizada para Forense Computacional.
Comentários ?
Até o próximo post !
Mal anunciei a nova versão 1.0 e suas funcionalidades e já temos a versão 1.5 - Shinning - com mais algumas turbinadas. A versão irmã para pendrive, NBCaine, também foi liberada.
Algumas ferramentas foram atualizadas, tanto no lado Windows como no Linux, incluindo algumas velhas dívidas, como era o caso do md5deep. O Kernel agora é o 2.6-24.25.
O Desktop recebeu uma cara nova e a possibilidade de troca de teclado mais facilmente, sem ter que digitar o comando. Um atalho também leva do desktop diretamente a um conjunto de scripts bastante úteis, alguns deles criados pela própria equipe do CAINE.
O Xteg (detecta esteganografia), Photorec e TestDisk foram parar no menu Forensics. O TSK já tinha sido atualizado na 1.0 junto com o Autopsy, mas este ultimo continua fora da path. O menu Altro recebeu o TkDiff, para comparações em arquivos texto, e o UUDeview, útil nas decodificações MIME.
Em relação à ultima avaliação que fiz, o CAINE continua mantendo os pontos positivos, enquanto que a equipe fez um compensado esforço para cobrir os pontos que consideramos negativos. A documentação vem cada vez melhor, o teclado é configurável, o boot pode ser direto em modo texto e as ferramentas disponíveis estão muito boas. Há ainda a falta de algumas, como por exemplo o RegRipper, Gigolo, Antivirus e o Volatility, mas eu conversei com o grupo e há razões para isso. Uma delas é que o custo de manter a parte de resposta a incidentes (WinTaylor) é alto, já que ocupa bastante espaço do CD. Pelo que conversamos, uma boa estratégia é montar mais de uma versão, fazendo com que sejam direcionadas. Para aquisição, podemos manter tudo em um Live CD com algumas ferramentas de preview e aquisição de disco e memória. Para análise, provavelmente estaremos indo para um Live DVD com muitas opções e ferramentas, incluindo as duas citadas mais o Xplico e outras disponíveis na web. A versão 2.0 já está sendo ansiosamente aguardada ...
Pontos Positivos:
- Atualizações constantes;
- TSK compilado com suporte a vários formatos;
- Muitas ferramentas disponíveis;
- Política de montagem de mídias formalizada;
- Facilmente instalável;
- Facilidade de entrada em modo texto;
- Pode ser usado pelo pendrive e complementado, se for o caso, pelo Perito.
Pontos Negativos:
- Ausência de algumas ferramentas de análise importantes (RegRipper, Jtr, ssdeep, Volatility, ferramentas de network forensics, etc) ;
- Documentação no site poderia conter um Roadmap.
Como podem ver, há poucos pontos negativos e a tendência é que cada vez mais essa distro melhore e tome o lugar de ferramenta free mais utilizada para Forense Computacional.
Comentários ?
Até o próximo post !
terça-feira, 17 de novembro de 2009
DEFT 5 ! parte II
Finalmente consegui dar uma olhada na mais nova versão do DEFT. Não vou redigir novamente o que escrevi sobre ele, pois seria repetitivo. Você pode fazer uma simples busca e ver que já avaliei o DEFT 4.1, logo no início de 2009.
O primeiro teste falhou. Estranhamente, ele não subiu na VM que tenho configurada para a versão anterior, no QEMU. Tive de fechar e abrir uma VM no VMWare Server, e rodou prontamente.
Essa nova versão começa impressionando positivamente, já que o boot é bem rápido e cai direto no modo texto. Isso sinaliza que a ferramenta continua não destinada a novatos, mas isso não é um problema. Até porque perito não pode ser newbie, tem que saber se virar mesmo ... Outro bom ponto no boot é que se pode escolher o idioma e o layout de teclado, e isso ajuda quem está com o ABNT2 ou não manda tão bem no inglês.
O desktop foi mesmo completamente atualizado, está mais limpo e sem aqueles milhões de ícones das versões anteriores, que poluiam muito a tela. O menu está bem condensado e tem algumas das principais ferramentas.
A novidade da separação do Xplico vai permitir que existam versões especializadas. Uma delas vai ser mais aplicada a Disk Forensics, enquanto que a DEFT Vx5 vai ter o Xplico e será mais aplicada em Network Forensics. Como eu já falei recentemente, essa parece ser mesmo a nova tendência.
Pontos Positivos:
* Entra no modo texto e só carrega o GUI se for comandado. Isso faz o boot mais rápido e auxilia os mais acostumados;
* As atualizações continuam constantes. O bug lançado com a versão 4.2 foi corrigido bem rapidamente;
* Continua lançando produtos novos (SciTE e TrID), incluindo agora uma versão separada para Network Forensics;
* Vários utilitários ausentes na última avaliação foram instalados, como o Pasco, Galleta e Vinetto;
* O TSK está com suporte full aos formatos Expert Witness e AFF, e é a versão mais recente até agora disponível;
* A conexão via smb voltou ! O nome é bem sugestivo ... Gigolo.
É bom reparar que a maioria dos pontos positivos continuam sendo citados. Isso é uma boa característica.
Pontos Negativos:
* A versão em USB é cobrada. Não ficou claro para mim se o valor é para alguém que quer comprar um pendrive com o produto ou se é apenas para baixar o produto. Depois do Helix ter passado a software comercial (eles voltaram a disponibilizar uma versão free, acredito que perceberam o erro de estratégia), acho que fiquei um pouco neurótico com esses possíveis movimentos. Não é que não se possa cobrar por eles (o valor do DEFT é até muito acessível), a questão é que você se acostuma à maneira de trabalhar com a ferramenta, faz propaganda, valida, e de repente, ela não está mais lá ...
* Alguns utilitários importantes ainda estão ausentes. O ssdeep é um exemplo;
* Forense de memória e de Registry deveriam estar por ali também.
Abaixo, segue a listagem dos utilitários e ferramentas que estão disponíveis nessa versão ou estarão na DEFT Vx5:
Até o próximo post !
O primeiro teste falhou. Estranhamente, ele não subiu na VM que tenho configurada para a versão anterior, no QEMU. Tive de fechar e abrir uma VM no VMWare Server, e rodou prontamente.
Essa nova versão começa impressionando positivamente, já que o boot é bem rápido e cai direto no modo texto. Isso sinaliza que a ferramenta continua não destinada a novatos, mas isso não é um problema. Até porque perito não pode ser newbie, tem que saber se virar mesmo ... Outro bom ponto no boot é que se pode escolher o idioma e o layout de teclado, e isso ajuda quem está com o ABNT2 ou não manda tão bem no inglês.
O desktop foi mesmo completamente atualizado, está mais limpo e sem aqueles milhões de ícones das versões anteriores, que poluiam muito a tela. O menu está bem condensado e tem algumas das principais ferramentas.
A novidade da separação do Xplico vai permitir que existam versões especializadas. Uma delas vai ser mais aplicada a Disk Forensics, enquanto que a DEFT Vx5 vai ter o Xplico e será mais aplicada em Network Forensics. Como eu já falei recentemente, essa parece ser mesmo a nova tendência.
Pontos Positivos:
* Entra no modo texto e só carrega o GUI se for comandado. Isso faz o boot mais rápido e auxilia os mais acostumados;
* As atualizações continuam constantes. O bug lançado com a versão 4.2 foi corrigido bem rapidamente;
* Continua lançando produtos novos (SciTE e TrID), incluindo agora uma versão separada para Network Forensics;
* Vários utilitários ausentes na última avaliação foram instalados, como o Pasco, Galleta e Vinetto;
* O TSK está com suporte full aos formatos Expert Witness e AFF, e é a versão mais recente até agora disponível;
* A conexão via smb voltou ! O nome é bem sugestivo ... Gigolo.
É bom reparar que a maioria dos pontos positivos continuam sendo citados. Isso é uma boa característica.
Pontos Negativos:
* A versão em USB é cobrada. Não ficou claro para mim se o valor é para alguém que quer comprar um pendrive com o produto ou se é apenas para baixar o produto. Depois do Helix ter passado a software comercial (eles voltaram a disponibilizar uma versão free, acredito que perceberam o erro de estratégia), acho que fiquei um pouco neurótico com esses possíveis movimentos. Não é que não se possa cobrar por eles (o valor do DEFT é até muito acessível), a questão é que você se acostuma à maneira de trabalhar com a ferramenta, faz propaganda, valida, e de repente, ela não está mais lá ...
* Alguns utilitários importantes ainda estão ausentes. O ssdeep é um exemplo;
* Forense de memória e de Registry deveriam estar por ali também.
Abaixo, segue a listagem dos utilitários e ferramentas que estão disponíveis nessa versão ou estarão na DEFT Vx5:
Até o próximo post !
- sleuthkit 3.01, collection of UNIX-based command line tools that allow you to investigate a computer
- autopsy 2.21, graphical interface to the command line digital investigation tools in The Sleuth Kit
- dhash 2, multi hash tool
- aff lib 3.5.2, advanced forensic format
- gpart, tool which tries to guess the primary partition table of a PC-type hard disk
- guymager 0.4.2-1, a fast and most user friendly forensic imager
- dd rescue 1.13, copy data from one file or block device to another
- dcfldd 1.3.4.1, copy data from one file or block device to another with more functions
- linen 6.01, Linux version of the industry- standard DOS-based EnCase acquisition tool
- foremost 1.5.6, console program to recover files based on their headers, footers, and internal data structures
- photorec 6.11, easy carving tool
- mount manager 0.2.6, advanced and user friendly mount manager
- scalpel 1.60, carving tool
- wipe
- hex dump, combined hex and ascii dump of any file
- outguess, a stegano tool
- ophcrack 3.3.0, Windows password recovery
- Xplico 0.6 DEFT edition, advanced network analyzer
- Wireshark 1.2.2, network sniffer
- ettercap 0.7.3, network sniffer
- nessus 4, vulnerability and security scanner, client
- nessusd 4, vulnerability and security scanner, server
- nmap 5, the best network scanner
- kismet 2008.05 R1, sniffer and intrusion detection system that work with any wireless card
- dmraid, discover software RAID devices
- testdisk, tool to recover damaged partitions
- vinetto, tool to examine Thumbs.db files
- trID 2.02 DEFT edition, tool to identify file types from their binary signatures
- readpst 0.6.41, a tools to read ms-Outlook pst files
- snmpwalk
- chkrootkit, Checks for signs of rootkits on the local system
- rkhunter 1.3.4, rootkit, backdoor, sniffer and exploit scanner
- john 1.7.2, john the ripper password cracker
- clam, antivirus 4.15
DEFT extra 2.0:
- System Information
- Drive Manager
- Reg Scanner
- Win Audit
- ReSysInfo
- USB Deview
- Bluethoot View
- User Assist view
- WRR
- My Event View
- MSI
- Curr Proces
- Live Acquisition
- FTK imager
- Winen
- MDD
- Forensics Tool
- WFT
- Zero View
- WFA
- File Alyser
- Nigilant32
- USB history
- Shell command
- PC on/off time
- Password Recovery
- Asterix logger
- PassworFox
- Chrome Pass
- IE PassView
- Wireless Key View
- Mail pass view
- Incredimail Message Extractor
- Networking
- Web Browser
- IE Cookie View
- IE History View
- Mozilla Cookie View
- Mozilla History View
- Mozilla Cache view
- Opera Cache View
- Chrome Cache View
- Index.dat Analyzer 2.0
- Historian
- FoxAnalisis
- Utility tool
- Skype Log View
- Home Keylogger
- HexEdit
- SDHash
- WipeDisk
- USBWriteProtector
- Testdisk
- LTF View
- AVI screen
- Hower Snap
- VNC Viewer
- Sumatra PDF
- Putty
- Pre-Search
- Photorec
- Notepad++
- WinMD5sum
- Abiword
- Undelete Plus
- Hash calc
- IP Net Info
- SysInternal
- Access Enum
- autoruns
- diskView
- Regmon
- WinOBj
- Filemon
- ProceXp
- TCPView
- Rootkit Revealer
DEFT v5 features list:
- incorruptibility of the partitions
- incorruptibility of the swap spaces
- linux Kernel 2.6.31
- LXDE
- apt-get system
- vino
- rdesktop
- samba client
- open SSH client & server
- ntfs3g
- lvm support
- brasero
- record my desktop
- wicd network manager
- speedcrunch
segunda-feira, 16 de novembro de 2009
Mais café ...
O assunto COFEE continua rendendo nas listas de discussão internacionais e também nacionais. Em uma das mensagens, Rob Lee (SANS, Mandiant) revela que conversou diretamente com alguém da equipe de desenvolvimento da ferramenta. Ao que parece, o motivo de colocar a ferramenta com distribuição apenas a LE não foi uma tentativa de "segurança por obscuridade", como muitos acreditaram (e que comentei aqui no blog). Dentre o grupo de ferramentas do COFEE há algumas destinadas a obter passwords da máquina, com ação comparável ao conhecido pwdump. A estratégia da Microsoft foi fazer a limitação por conta de evitar embaraços legais e processos pela existência dessas ferramentas. Ainda que o conteúdo tenha vazado, a estratégia aparentemente garante a defesa.
Outros pontos comentados:
- A ferramenta não é "Forensically Sound", ou seja, não trabalha dentro de métodos forenses aceitáveis em juízo. Isso não é nenhuma surpresa, até porque a ferramenta é destinada a Resposta a Incidentes, o que torna certas críticas sem sentido;
- Alguns a estão chamando de "Sysinternals Reloaded", mencionando que é apenas uma reunião de utilitários da Sysinternals. Vimos na avaliação anterior que não é apenas isso;
- Muitos comentam da inabilidade do COFEE de usar a rede para mandar as informações coletadas, assim como comentamos. O uso de um pendrive também é criticado, já que ele deixa marcas no registry. Particularmente, não apoio a questão da preferência por CDROM ao invés de pendrive. Um drive de CDROM nem sempre está disponível em máquinas, ao passo que praticamente todas tem entrada USB. Além disso, a existência da entrada no registry pertencente ao pendrive da investigação é facilmente documentável, do mesmo modo como precisamos inserir um processo na memória quando precisamos capturá-la. Se tudo está bem documentado, então pode ser logicamente explicado.
Alguém gostaria de complementar, comentando ?
Apenas para reforçar, gostaria de deixar claro que este artigo não tem, em nenhum momento, a intenção de induzir pessoas a procurar o produto, baixá-lo e usá-lo. Como a licença é LE, ao fazê-lo não sendo de uma força policial, o uso poderia ser considerado irregular e pirataria.
Até o próximo post !
Outros pontos comentados:
- A ferramenta não é "Forensically Sound", ou seja, não trabalha dentro de métodos forenses aceitáveis em juízo. Isso não é nenhuma surpresa, até porque a ferramenta é destinada a Resposta a Incidentes, o que torna certas críticas sem sentido;
- Alguns a estão chamando de "Sysinternals Reloaded", mencionando que é apenas uma reunião de utilitários da Sysinternals. Vimos na avaliação anterior que não é apenas isso;
- Muitos comentam da inabilidade do COFEE de usar a rede para mandar as informações coletadas, assim como comentamos. O uso de um pendrive também é criticado, já que ele deixa marcas no registry. Particularmente, não apoio a questão da preferência por CDROM ao invés de pendrive. Um drive de CDROM nem sempre está disponível em máquinas, ao passo que praticamente todas tem entrada USB. Além disso, a existência da entrada no registry pertencente ao pendrive da investigação é facilmente documentável, do mesmo modo como precisamos inserir um processo na memória quando precisamos capturá-la. Se tudo está bem documentado, então pode ser logicamente explicado.
Alguém gostaria de complementar, comentando ?
Apenas para reforçar, gostaria de deixar claro que este artigo não tem, em nenhum momento, a intenção de induzir pessoas a procurar o produto, baixá-lo e usá-lo. Como a licença é LE, ao fazê-lo não sendo de uma força policial, o uso poderia ser considerado irregular e pirataria.
Até o próximo post !
domingo, 15 de novembro de 2009
IEF, JPEG Finder e más notícias
Há poucos dias surgiu uma questão bastante interessante sobre capturar as conversas em MSN. Havia alguma dúvida se era possível ou não capturar os históricos se eles tivessem sido apagados ou não marcados. Falamos sobre a ferramenta IEF, que captura esse e outros artefatos específicos de Internet, e virou um papo bastante interessante e vale ser reproduzido aqui também:
Essa ferramenta (IEF) opera sobre vários artefatos produzidos em programas web, dentre eles as conversas de chat de alguns produtos. Esses artefatos possuem características que são semelhantes aos magic numbers. Com isso, é possível rastreá-los em qualquer stream de dados: - Em arquivos de um fs montado (nesse caso, os arquivos deveriam estar intactos e não apagados). Esse é o exemplo mais fácil e que, na verdade, nem requer detecção. - Em arquivos de dump de memória - No pagefile e no hyperfil.sys - Em pacotes pcap (com alguma adaptação do código ou trabalho posterior) E, finalmente, em imagens forense no formato raw. O ponto é que, ao renderizar o conteúdo para exibir na sua janela, o software permite que o conteúdo toque o disco, e depois o apaga. Nesse caso, as conversas (ou fragmentos dela) e todos os outros artefatos localizados (ou fragmentos) estariam nos espaços não alocados do disco, que constam da imagem forense. No fim das contas, esse software é apenas um carving mais esperto, pq é direcionado para itens que até então ninguém sabia como eram estruturados. Ele os localiza e monta. Se for somente para localizar, é possível que alguns desses artefatos sejam localizados por uma busca simples na imagem, usando o TSK. A dificuldade está em montar o que foi achado. Quem já pesquisou espaços não alocados e achou trechos de emails recebidos/enviados pelo gmail sabe do que eu estou falando. É tudo formatado, cheio de "]", "<", e tal ... Não é html puro como em alguns outros webmails por aí ... Em relação ao trabalho do Galileu, realmente é a mesma coisa. A diferença é que ele focou no WLM, e busca por vários artefatos além das mensagens. O IEF busca artefatos de vários outros programas, mas do WLM só traz as conversas. Eu estava no ICCyber de 2008, quando o Galileu apresentou o trabalho. Foi excelente, sem dúvida.
Logo depois desse texto, coincidentemente, o site do IEF anunciou uma nova versão ainda mais poderosa do IEF e um novo utilitário, o Facebook JPEG Finder. Eu já fiz alguns testes com esse último, e ele funciona muito bem se o Facebook for acessado pelo IE. Abaixo, um exemplo do relatório dele:
Funcionou certinho, o perfil é o meu, realmente.
Entretanto, fiz o mesmo teste usando o Firefox, e nada foi encontrado. Vou reportar o bug.
Como nem tudo são flores, no mesmo momento também vi que a empresa que fornece o IEF passou o software para comercial. Da versão 3 em diante, quem quiser tem que pagar alguns dólares. É bem barato, mas infelizmente é mais um software que era livre e agora virou comercial. Se essa moda pegar ...
Comentários ?
Até o próximo post !
Essa ferramenta (IEF) opera sobre vários artefatos produzidos em programas web, dentre eles as conversas de chat de alguns produtos. Esses artefatos possuem características que são semelhantes aos magic numbers. Com isso, é possível rastreá-los em qualquer stream de dados: - Em arquivos de um fs montado (nesse caso, os arquivos deveriam estar intactos e não apagados). Esse é o exemplo mais fácil e que, na verdade, nem requer detecção. - Em arquivos de dump de memória - No pagefile e no hyperfil.sys - Em pacotes pcap (com alguma adaptação do código ou trabalho posterior) E, finalmente, em imagens forense no formato raw. O ponto é que, ao renderizar o conteúdo para exibir na sua janela, o software permite que o conteúdo toque o disco, e depois o apaga. Nesse caso, as conversas (ou fragmentos dela) e todos os outros artefatos localizados (ou fragmentos) estariam nos espaços não alocados do disco, que constam da imagem forense. No fim das contas, esse software é apenas um carving mais esperto, pq é direcionado para itens que até então ninguém sabia como eram estruturados. Ele os localiza e monta. Se for somente para localizar, é possível que alguns desses artefatos sejam localizados por uma busca simples na imagem, usando o TSK. A dificuldade está em montar o que foi achado. Quem já pesquisou espaços não alocados e achou trechos de emails recebidos/enviados pelo gmail sabe do que eu estou falando. É tudo formatado, cheio de "]", "<", e tal ... Não é html puro como em alguns outros webmails por aí ... Em relação ao trabalho do Galileu, realmente é a mesma coisa. A diferença é que ele focou no WLM, e busca por vários artefatos além das mensagens. O IEF busca artefatos de vários outros programas, mas do WLM só traz as conversas. Eu estava no ICCyber de 2008, quando o Galileu apresentou o trabalho. Foi excelente, sem dúvida.
Logo depois desse texto, coincidentemente, o site do IEF anunciou uma nova versão ainda mais poderosa do IEF e um novo utilitário, o Facebook JPEG Finder. Eu já fiz alguns testes com esse último, e ele funciona muito bem se o Facebook for acessado pelo IE. Abaixo, um exemplo do relatório dele:
Funcionou certinho, o perfil é o meu, realmente.
Entretanto, fiz o mesmo teste usando o Firefox, e nada foi encontrado. Vou reportar o bug.
Como nem tudo são flores, no mesmo momento também vi que a empresa que fornece o IEF passou o software para comercial. Da versão 3 em diante, quem quiser tem que pagar alguns dólares. É bem barato, mas infelizmente é mais um software que era livre e agora virou comercial. Se essa moda pegar ...
Comentários ?
Até o próximo post !
sábado, 14 de novembro de 2009
CFIR
Uma tendência muito comum em TI é ver plataformas crescerem demais e gerarem subdivisões, cada uma mais especializada. Não posso dizer que esse é o caso do que vou apresentar aqui, mas a ideia é a mesma.
Uma turma da Malásia acabou de lançar um novo Live CD para forense, chamado de CFIR (Computer Forensics and Incident Response). Pelo que foi passado pelos autores, o Helix era a ferramenta que o grupo usava mais, só que estava cada vez maior e não atendia quando pegavam uma máquina antiga ou com poucos recursos. Ainda por cima, segundo eles, há muita coisa desnecessária. Conclusão: Criaram uma versão Linux super-reduzida em Live CD direcionada para coleta e análise.
Algumas das características do CFIR realmente impressionam. Ele levou aqui na minha máquina algo entre 8 e 12 segundos para reinicializar. No Helix, você coloca para reinicializar e depois pode ir tranquilo a uma lanchonete lotada pedir aquele chá daquelas plantas que só cresce durante o verão russo, espera irem lá colher, fazerem o chá e na sua volta, dois anos depois, a máquina ainda vai estar entrando no modo gráfico.
É realmente um ponto interessante que não precisamos de todas as ferramentas disponíveis em um Live CD em cada trabalho. Seria interessante que tivéssemos Live CDs com foco no que precisamos, separados em XXX-Captura, XXX-Análise e , por que não, o XXX-Live, onde teríamos uma possibilidade de contar com todas as ferramentas. Esse seria mais exigente, talvez.
O CFIR não é a oitava maravilha do mundo, mas está nascendo agora, e nessa linha podemos ter alguns avanços muito bons. Ele está na versão 1.2, tem kernel 2.6.26 com base no Red Hat, e seu super-fast boot cai direto no modo texto. Digite startx e uma interface gráfica bem simples aparece, com algumas opções no menu. Tudo bem enxuto.
Não há documentação alguma do produto, mas dei uma boa olhada e, dentre algumas características, posso acrescentar:
- Browser Mimos-V
- PCMan File Manager
- GCView para visualizar imagens
- xpdf viewer, Hex Editor lfhex
- regviewer (browser de registry)
- antivirus
- wireshark
- nessus
- TSK 2.52
Há outras ferramentas de linha de comando, incluindo o dcfldd, o dd e o md5sum, mas a distro é realmente bem enxuta, com pouco mais de 100 Mb. É tão enxuta que nem o "more" colocaram, o que eu acho ruim. Está configurada para o teclado americano, ou seja, se você tem ABNT2, vai sofrer um bocado. Também detectei um problema com o Autopsy, se for acionado pelo menu da interface gráfica. Pelo terminal funciona corretamente. O Linen, pela interface, não deu o ar da graça e ainda por cima travou o terminal ...
Pontos Fortes:
* Boot extremamente rápido;
* Ocupa pouco espaço, fácil de baixar e atualizar;
* Direcionado para aquisição/coleta de imagens;
* Roda bem em máquinas antigas ou com pouca memória;
* Cai direto em modo texto, o que facilita para usuários avançados;
* Sem frescuras;
* Não monta automaticamente nenhuma partição
Pontos Fracos:
* Ausência de comandos importantes, como setxkbmap e more;
* Ausência de documentação;
* Não há uma versão "irmã" voltada para análise
* Voltado quase que exclusivamente para Dead Acquisition.
Alguém já está usando e gostaria de comentar ?
Até o próximo post !
Uma turma da Malásia acabou de lançar um novo Live CD para forense, chamado de CFIR (Computer Forensics and Incident Response). Pelo que foi passado pelos autores, o Helix era a ferramenta que o grupo usava mais, só que estava cada vez maior e não atendia quando pegavam uma máquina antiga ou com poucos recursos. Ainda por cima, segundo eles, há muita coisa desnecessária. Conclusão: Criaram uma versão Linux super-reduzida em Live CD direcionada para coleta e análise.
Algumas das características do CFIR realmente impressionam. Ele levou aqui na minha máquina algo entre 8 e 12 segundos para reinicializar. No Helix, você coloca para reinicializar e depois pode ir tranquilo a uma lanchonete lotada pedir aquele chá daquelas plantas que só cresce durante o verão russo, espera irem lá colher, fazerem o chá e na sua volta, dois anos depois, a máquina ainda vai estar entrando no modo gráfico.
É realmente um ponto interessante que não precisamos de todas as ferramentas disponíveis em um Live CD em cada trabalho. Seria interessante que tivéssemos Live CDs com foco no que precisamos, separados em XXX-Captura, XXX-Análise e , por que não, o XXX-Live, onde teríamos uma possibilidade de contar com todas as ferramentas. Esse seria mais exigente, talvez.
O CFIR não é a oitava maravilha do mundo, mas está nascendo agora, e nessa linha podemos ter alguns avanços muito bons. Ele está na versão 1.2, tem kernel 2.6.26 com base no Red Hat, e seu super-fast boot cai direto no modo texto. Digite startx e uma interface gráfica bem simples aparece, com algumas opções no menu. Tudo bem enxuto.
Não há documentação alguma do produto, mas dei uma boa olhada e, dentre algumas características, posso acrescentar:
- Browser Mimos-V
- PCMan File Manager
- GCView para visualizar imagens
- xpdf viewer, Hex Editor lfhex
- regviewer (browser de registry)
- antivirus
- wireshark
- nessus
- TSK 2.52
Há outras ferramentas de linha de comando, incluindo o dcfldd, o dd e o md5sum, mas a distro é realmente bem enxuta, com pouco mais de 100 Mb. É tão enxuta que nem o "more" colocaram, o que eu acho ruim. Está configurada para o teclado americano, ou seja, se você tem ABNT2, vai sofrer um bocado. Também detectei um problema com o Autopsy, se for acionado pelo menu da interface gráfica. Pelo terminal funciona corretamente. O Linen, pela interface, não deu o ar da graça e ainda por cima travou o terminal ...
Pontos Fortes:
* Boot extremamente rápido;
* Ocupa pouco espaço, fácil de baixar e atualizar;
* Direcionado para aquisição/coleta de imagens;
* Roda bem em máquinas antigas ou com pouca memória;
* Cai direto em modo texto, o que facilita para usuários avançados;
* Sem frescuras;
* Não monta automaticamente nenhuma partição
Pontos Fracos:
* Ausência de comandos importantes, como setxkbmap e more;
* Ausência de documentação;
* Não há uma versão "irmã" voltada para análise
* Voltado quase que exclusivamente para Dead Acquisition.
Alguém já está usando e gostaria de comentar ?
Até o próximo post !
segunda-feira, 9 de novembro de 2009
DEFT 5 !
Tem DEFT novo na área !
A turma acabou de indicar a nova release, bastante esperada desde a ultima, que corrigiu um bug bastante perigoso e foi comentado aqui no blog.
A estrutura mudou, de acordo com o site: Está baseado no XUbuntu com kernel 2.6.31, mas agora traz no mesmo CD o DEFT Extra, a parte Windows para Resposta a Incidentes, semelhante ao Helix. Há mais do que uma repaginação do desktop, já que ele agora usa LXDE como base. As ferramentas estão atualizadas com destaque para o TSK, que recebeu a versão mais nova até agora disponível.
A poderosa ferramenta de network forensics Xplico agora vem acompanhada de mais algumas muito boas, entre elas o Kismet e o nmap, além do sempre presente Wireshark. A mudança é que estes estarão disponíveis apenas na versão DEFT Vx5, que será especializada para network forense, e ainda não está disponível. Há também uma versão em pendrive, mas está não é free ...
Segue um screenshot da nova versão:
Em breve vou colocar algo mais completo sobre essa nova release.
Até o próximo post !
A turma acabou de indicar a nova release, bastante esperada desde a ultima, que corrigiu um bug bastante perigoso e foi comentado aqui no blog.
A estrutura mudou, de acordo com o site: Está baseado no XUbuntu com kernel 2.6.31, mas agora traz no mesmo CD o DEFT Extra, a parte Windows para Resposta a Incidentes, semelhante ao Helix. Há mais do que uma repaginação do desktop, já que ele agora usa LXDE como base. As ferramentas estão atualizadas com destaque para o TSK, que recebeu a versão mais nova até agora disponível.
A poderosa ferramenta de network forensics Xplico agora vem acompanhada de mais algumas muito boas, entre elas o Kismet e o nmap, além do sempre presente Wireshark. A mudança é que estes estarão disponíveis apenas na versão DEFT Vx5, que será especializada para network forense, e ainda não está disponível. Há também uma versão em pendrive, mas está não é free ...
Segue um screenshot da nova versão:
Em breve vou colocar algo mais completo sobre essa nova release.
Até o próximo post !
domingo, 8 de novembro de 2009
Derrubaram Café na mesa
As listas de Segurança de Informações e Perícia foram sacudidas nesses dias com a notícia do "vazamento" do COFEE. Esse produto foi criado pela Microsoft e distribuído sem custo para Law Enforcement (basicamente, polícias). O vazamento acabou com a enorme aura que foi criada em torno desse produto.
No início, o burburinho era tanto que se acreditava que a Microsoft tinha criado uma super ferramenta para policiais, com tecnologia super nova e avançada. Segundo alguns, a restrição para distribuição apenas a LE era para impedir que detalhes da solução chegassem aos criminosos, e com isso pudessem impedir que contramedidas fossem criadas. Como diz o velho ditado de que segredo só é segredo enquanto apenas dois sabem, a estratégia de segurança por obscuridade provou não ser eficaz novamente. Por algum modo ainda não claro, o COFEE caiu na rede e está em tudo que é torrent por aí.
Esse episódio gerou uma grande quantidade de críticas assim que as pessoas puseram as mãos no produto. Findo o encanto, descobriram que não se trata de uma super-tecnologia nem algo de outro planeta, e agora passam a criticar o produto, taxando-o de simplório. Na minha opinião, quem o critica não entendeu bem o objetivo do produto. Para demonstrar isso, vou comentar um pouco mais de como ele funciona.
Para início de conversa, o COFEE realmente não é nada de novo. Pelo menos na sua idéia mais básica, já existem outros produtos que fazem a mesma coisa. O COFEE é, na sua essência, um produto para serializar comandos e colher os resultados, para depois serem analisados. O foco desses comandos é o que chamamos de dados voláteis, onde procuramos relacionar o estado da máquina e, posteriormente, analisar o resultado em busca de entender o ocorrido. Olhando dessa forma, o COFEE pode ser facilmente comparado a vários produtos estudados aqui no blog, incluindo o WFT e o FRUC/FSP. Todos rodam uma série de comandos e utilitários, captam as informações voláteis e geram reports finais para serem analisados. Onde o COFEE se diferencia ?
- O COFEE possui dois módulos. Um deles, com interface gráfica, é um módulo de administração. Possui duas funções principais: a geração de ferramentas e a exibição dos relatórios colhidos. A parte de geração de ferramentas é bastante inteligente. Enquanto que o WFT e o FSP configuram as ferramentas e comandos através de arquivos de configuração, o COFEE faz isso nessa interface gráfica. Com isso, é possível gerar um pendrive específico para cada caso a ser tratado, fazendo o seu uso na hora do incidente muito mais direcionado do que os outros. É lógico que esse mesmo comportamento pode ser obtido nos outros através da edição dos arquivos de configuração, mas no COFEE isso é muito mais automatizado e simples. Os comandos e utilitários podem, inclusive, ser alterados, e novos podem ser cadastrados;
- A montagem de grupos de comandos e utilitários pode ser salva no que o COFEE chama de Profiles. Com isso, pode-se selecionar rapidamente um profile específico a um incidente, criar o pendrive e usá-lo. Por exemplo, o time de policiais vai realizar uma operação que envolve apreender computadores de uma quadrilha que faz phishing; um profile específico para isso, contendo ferramentas que busquem vestígios de criação de phishing, deve ser elaborado e selecionado. Caso haja outra ocorrência semelhante, basta que o profile seja usado na geração do pendrive, ganhando bastante tempo. Novamente, essa funcionalidade pode ser obtida por outros modos no WFT e no FSP, mas levaria mais tempo.
- O módulo de relatórios possui alguns pré-montados que permitem correlacionar dados coletados por ferramentas distintas, algo que no WFT e no FSP precisaria ser feito "na mão", durante a análise;
- A documentação do COFEE é excelente, e torna o uso do programa extremamente simples;
- O uso do COFEE (pendrive gerado) na captura dos dados voláteis foi concebido para ser o mais simples possível. Realmente o é, e isso faz a ferramenta atingir o seu objetivo, de ser usada por pessoas que não tenham tantas noções de tecnologia. Basta inserir o pendrive no USB da máquina a ser investigada e pronto. Ele vai seguir em frente sem maiores interações. Os outros produtos que atuam nesse segmento necessitam de alguma interação com o usuário, algumas na forma de parâmetros, e isso no fim das contas pode requerer alguém com conhecimento prévio.
- Há alguns documentos de testes do COFEE dentre a documentação, indicando que o produto passou por inspeções diversas;
Parte ruim da estória
Sim, não se pode esperar que tudo seja perfeito. O COFEE tem algumas partes que não agradam:
- Não vi nenhuma opção de mandar os resultados coletados pela rede, como no caso do WFT e FSP, que usam o netcat. Os dados coletados são gravados no pendrive com as ferramentas;
- Como em qualquer caso de coleta de dados live, a máquina pode estar comprometida com rootkits que podem esconder dados importantes e também se ocultarem no processo. Logicamente, isso afeta a qualquer produto dessa natureza e não apenas ao COFEE;
- Os pendrives gerados e usados na coleta (chamados de runners) podem ser infectados e, na volta, acabar infectando também as estações onde os resultados são analisados. Nesse ponto, há uma estratégia de contorno interessante: Usar pendrives U3, colocando o conteúdo gerado pela interface do COFEE na porção CD do pendrive. Essa parte, além de ficar read-only durante o uso, poderia monitorar o que pode ser gravado no restante do pendrive, reduzindo o risco de trazerem malware para casa;
- A política de distribuição restrita aos LE. Eu posso entender os motivos, e em parte até concordar com eles. A prática, entretanto, só tem confirmado que esses segredos são difíceis de serem contidos e acabam por aumentar o interesse em sua divulgação. Essa prática também pode impedir o peer-review, tão importante nas validações forenses de técnicas e ferramentas.
Como eu disse anteriormente, quem critica o produto não o entendeu. Ele foi feito para fazer a mesma coisa que outros já faziam, mas de maneira facilitada, procurando ser acessível e operado mesmo por um policial sem conhecimento nenhum de Forense Computacional ou Resposta a Incidentes. Esse papel ele cumpre muito bem.
Alguém já usou o COFEE em uma situação real ? Saberiam dizer se as Polícias brasileiras também receberam o produto ? Comentem !
Até o próximo post !
No início, o burburinho era tanto que se acreditava que a Microsoft tinha criado uma super ferramenta para policiais, com tecnologia super nova e avançada. Segundo alguns, a restrição para distribuição apenas a LE era para impedir que detalhes da solução chegassem aos criminosos, e com isso pudessem impedir que contramedidas fossem criadas. Como diz o velho ditado de que segredo só é segredo enquanto apenas dois sabem, a estratégia de segurança por obscuridade provou não ser eficaz novamente. Por algum modo ainda não claro, o COFEE caiu na rede e está em tudo que é torrent por aí.
Esse episódio gerou uma grande quantidade de críticas assim que as pessoas puseram as mãos no produto. Findo o encanto, descobriram que não se trata de uma super-tecnologia nem algo de outro planeta, e agora passam a criticar o produto, taxando-o de simplório. Na minha opinião, quem o critica não entendeu bem o objetivo do produto. Para demonstrar isso, vou comentar um pouco mais de como ele funciona.
Para início de conversa, o COFEE realmente não é nada de novo. Pelo menos na sua idéia mais básica, já existem outros produtos que fazem a mesma coisa. O COFEE é, na sua essência, um produto para serializar comandos e colher os resultados, para depois serem analisados. O foco desses comandos é o que chamamos de dados voláteis, onde procuramos relacionar o estado da máquina e, posteriormente, analisar o resultado em busca de entender o ocorrido. Olhando dessa forma, o COFEE pode ser facilmente comparado a vários produtos estudados aqui no blog, incluindo o WFT e o FRUC/FSP. Todos rodam uma série de comandos e utilitários, captam as informações voláteis e geram reports finais para serem analisados. Onde o COFEE se diferencia ?
- O COFEE possui dois módulos. Um deles, com interface gráfica, é um módulo de administração. Possui duas funções principais: a geração de ferramentas e a exibição dos relatórios colhidos. A parte de geração de ferramentas é bastante inteligente. Enquanto que o WFT e o FSP configuram as ferramentas e comandos através de arquivos de configuração, o COFEE faz isso nessa interface gráfica. Com isso, é possível gerar um pendrive específico para cada caso a ser tratado, fazendo o seu uso na hora do incidente muito mais direcionado do que os outros. É lógico que esse mesmo comportamento pode ser obtido nos outros através da edição dos arquivos de configuração, mas no COFEE isso é muito mais automatizado e simples. Os comandos e utilitários podem, inclusive, ser alterados, e novos podem ser cadastrados;
- A montagem de grupos de comandos e utilitários pode ser salva no que o COFEE chama de Profiles. Com isso, pode-se selecionar rapidamente um profile específico a um incidente, criar o pendrive e usá-lo. Por exemplo, o time de policiais vai realizar uma operação que envolve apreender computadores de uma quadrilha que faz phishing; um profile específico para isso, contendo ferramentas que busquem vestígios de criação de phishing, deve ser elaborado e selecionado. Caso haja outra ocorrência semelhante, basta que o profile seja usado na geração do pendrive, ganhando bastante tempo. Novamente, essa funcionalidade pode ser obtida por outros modos no WFT e no FSP, mas levaria mais tempo.
- O módulo de relatórios possui alguns pré-montados que permitem correlacionar dados coletados por ferramentas distintas, algo que no WFT e no FSP precisaria ser feito "na mão", durante a análise;
- A documentação do COFEE é excelente, e torna o uso do programa extremamente simples;
- O uso do COFEE (pendrive gerado) na captura dos dados voláteis foi concebido para ser o mais simples possível. Realmente o é, e isso faz a ferramenta atingir o seu objetivo, de ser usada por pessoas que não tenham tantas noções de tecnologia. Basta inserir o pendrive no USB da máquina a ser investigada e pronto. Ele vai seguir em frente sem maiores interações. Os outros produtos que atuam nesse segmento necessitam de alguma interação com o usuário, algumas na forma de parâmetros, e isso no fim das contas pode requerer alguém com conhecimento prévio.
- Há alguns documentos de testes do COFEE dentre a documentação, indicando que o produto passou por inspeções diversas;
Parte ruim da estória
Sim, não se pode esperar que tudo seja perfeito. O COFEE tem algumas partes que não agradam:
- Não vi nenhuma opção de mandar os resultados coletados pela rede, como no caso do WFT e FSP, que usam o netcat. Os dados coletados são gravados no pendrive com as ferramentas;
- Como em qualquer caso de coleta de dados live, a máquina pode estar comprometida com rootkits que podem esconder dados importantes e também se ocultarem no processo. Logicamente, isso afeta a qualquer produto dessa natureza e não apenas ao COFEE;
- Os pendrives gerados e usados na coleta (chamados de runners) podem ser infectados e, na volta, acabar infectando também as estações onde os resultados são analisados. Nesse ponto, há uma estratégia de contorno interessante: Usar pendrives U3, colocando o conteúdo gerado pela interface do COFEE na porção CD do pendrive. Essa parte, além de ficar read-only durante o uso, poderia monitorar o que pode ser gravado no restante do pendrive, reduzindo o risco de trazerem malware para casa;
- A política de distribuição restrita aos LE. Eu posso entender os motivos, e em parte até concordar com eles. A prática, entretanto, só tem confirmado que esses segredos são difíceis de serem contidos e acabam por aumentar o interesse em sua divulgação. Essa prática também pode impedir o peer-review, tão importante nas validações forenses de técnicas e ferramentas.
Como eu disse anteriormente, quem critica o produto não o entendeu. Ele foi feito para fazer a mesma coisa que outros já faziam, mas de maneira facilitada, procurando ser acessível e operado mesmo por um policial sem conhecimento nenhum de Forense Computacional ou Resposta a Incidentes. Esse papel ele cumpre muito bem.
Alguém já usou o COFEE em uma situação real ? Saberiam dizer se as Polícias brasileiras também receberam o produto ? Comentem !
Até o próximo post !
quinta-feira, 5 de novembro de 2009
Caine Team
Se você der uma passada pelo site do Caine, vai notar 3 novidades :
- A versão mais nova do Live CD já está no ar. É o Caine 1.0 e já conversamos disso por aqui;
- A versão mais nova do Live USB também já está no ar. NBCaine 1.0. Eu vou falar desse produto em um outro post, já que ele merece essa exclusividade;
- A equipe do Caine está maior. Acrescentaram lá um tal de Tony Rodrigues ... :D
Essa novidade nasceu de um papo bastante construtivo que, de certa forma, começou com o post que colocamos aqui sobre o lançamento do Caine 1.0. Nesse bate papo, sugeri algumas coisas, e o Nanni me falou sobre o NBCaine e das possibilidades que esse produto tem para ser livremente estendido, coisa que o CD não permite por razões óbvias.
Aproveito para usar o blog como canal de sugestões para o projeto. Com certeza, muitos estão já fazendo uso do Caine em seus trabalhos e poderão ajudar nos testes e a propor melhorias.
Alguém quer começar com alguma sugestão ?
Até o próximo post !
- A versão mais nova do Live CD já está no ar. É o Caine 1.0 e já conversamos disso por aqui;
- A versão mais nova do Live USB também já está no ar. NBCaine 1.0. Eu vou falar desse produto em um outro post, já que ele merece essa exclusividade;
- A equipe do Caine está maior. Acrescentaram lá um tal de Tony Rodrigues ... :D
Essa novidade nasceu de um papo bastante construtivo que, de certa forma, começou com o post que colocamos aqui sobre o lançamento do Caine 1.0. Nesse bate papo, sugeri algumas coisas, e o Nanni me falou sobre o NBCaine e das possibilidades que esse produto tem para ser livremente estendido, coisa que o CD não permite por razões óbvias.
Aproveito para usar o blog como canal de sugestões para o projeto. Com certeza, muitos estão já fazendo uso do Caine em seus trabalhos e poderão ajudar nos testes e a propor melhorias.
Alguém quer começar com alguma sugestão ?
Até o próximo post !
domingo, 1 de novembro de 2009
Bug perigoso
O site do DEFT anunciou há alguns dias o lançamento de uma nova release do seu famoso live CD. A nova release (4.2.1) não traz nenhuma novidade em termos de utilitários nem de ferramentas. Traz o acerto de um bug bastante sério que foi descoberto na versão 4.2
Um dos maiores cuidados ao trabalhar com a imagem forense é manter sua integridade. Essa integridade pode ser verificada por uma função hash aplicada antes e depois de manipulá-la. Se os valores forem iguais, tudo em paz.
Para manter a integridade, as ferramentas forenses precisam ter alguns cuidados. Entre eles, nunca montar os dispositivos e imagens automaticamente. Isso faz com que o investigador tenha o controle exato de como e quando montar a imagem, dessa forma protegendo a integridade através de comandos e parâmetros específicos. Ainda assim, há um certo inimigo da integridade: O journaling.
Essa é uma funcionalidade presente em alguns sistemas de arquivos, incluindo o NTFS e os ext. Sendo bastante simplório, o journaling é como um log de transações. As operações de escrita vão primeiro para o journaling, e depois são efetivadas pelo SO. É possível que um sistema, ao ser desligado de forma abrupta, possua transações ainda não efetivadas no disco. No próximo boot, em algum momento o SO vai detectar isso e promover as operações, de forma que tudo fique como deveria. Esse mecanismo pode se tornar um problema para os peritos se estivermos com uma imagem forense de um sistema de arquivos cujo journaling ainda possui transações pendentes. Se essa imagem for montada sem os devidos cuidados, uma das primeiras coisas que o SO vai fazer é ler o journaling, detectar as transações pendentes e mandar efetuá-las. Ou seja, adeus integridade: a sua imagem forense, mesmo aberta como read-only, vai sofrer alterações.
Para evitar isso, os live CDs normalmente compilam código do kernel do Linux com pequenas alterações. A parte que trataria do journaling, efetuando as transações, é eliminada.
É aqui que mora o perigo.
Em alguns casos, essa alteração do kernel não é tão simples e pode apresentar bugs. Volta e meia uns desses acontecem e causam bastante alarde na comunidade de usuários da ferramenta. Por volta do ano passado, se não me engano, o Helix apresentou um problema desses no HFS+. A bola da vez é o DEFT 4.2, com os sistemas ext3 e ext4.
Conseguiram detectar que o DEFT estava lendo e efetivando transações em journaling pendentes de imagens forenses baseadas nos sistemas ext3 e ext4. Embora isso só aconteça em condições bastante específicas, alguns podem ter sido prejudicados na questão integridade da imagem. Não chega a ser desesperador justamente porque, para o problema acontecer, várias condições precisam estar presentes. O investigador precisa estar trabalhando com uma imagem forense ext3 ou ext4 (pelo menos no Brasil, o mais comum são imagens NTFS) e ter o azar de haver transações incompletas no journaling. Isso aconteceria, por exemplo, em uma dead acquisition, se a máquina foi desligada sem os procedimentos normais, não dando ao SO a oportunidade de aplicar as ultimas transações do journaling. Em uma live acquisition, há ainda mais chances de acontecer, já que várias transações podem estar acontecendo no disco no exato momento em que a parte do journaling no disco está sendo capturada para a imagem.
O que fazer caso o bug tenha afetado uma imagem ? Bem, as boas práticas forenses mandam que nós trabalhemos sempre em uma cópia da imagem forense. Se o hash não bateu, por esse ou outro problema, pegue a imagem original e faça nova cópia, tendo antes o cuidado de entender como a integridade foi quebrada.
Não estavas trabalhando com uma cópia da imagem ??? Vais ter mais trabalho. Terás que fazer a aquisição da imagem novamente, rompendo o lacre da mídia original e efetuando a operação. Documente tudo, pois o acesso à mídia original terá de constar da cadeia de custódia.
Alguém já teve problemas relativos a isso e gostaria de comentar ?
Até o próximo post !
Um dos maiores cuidados ao trabalhar com a imagem forense é manter sua integridade. Essa integridade pode ser verificada por uma função hash aplicada antes e depois de manipulá-la. Se os valores forem iguais, tudo em paz.
Para manter a integridade, as ferramentas forenses precisam ter alguns cuidados. Entre eles, nunca montar os dispositivos e imagens automaticamente. Isso faz com que o investigador tenha o controle exato de como e quando montar a imagem, dessa forma protegendo a integridade através de comandos e parâmetros específicos. Ainda assim, há um certo inimigo da integridade: O journaling.
Essa é uma funcionalidade presente em alguns sistemas de arquivos, incluindo o NTFS e os ext. Sendo bastante simplório, o journaling é como um log de transações. As operações de escrita vão primeiro para o journaling, e depois são efetivadas pelo SO. É possível que um sistema, ao ser desligado de forma abrupta, possua transações ainda não efetivadas no disco. No próximo boot, em algum momento o SO vai detectar isso e promover as operações, de forma que tudo fique como deveria. Esse mecanismo pode se tornar um problema para os peritos se estivermos com uma imagem forense de um sistema de arquivos cujo journaling ainda possui transações pendentes. Se essa imagem for montada sem os devidos cuidados, uma das primeiras coisas que o SO vai fazer é ler o journaling, detectar as transações pendentes e mandar efetuá-las. Ou seja, adeus integridade: a sua imagem forense, mesmo aberta como read-only, vai sofrer alterações.
Para evitar isso, os live CDs normalmente compilam código do kernel do Linux com pequenas alterações. A parte que trataria do journaling, efetuando as transações, é eliminada.
É aqui que mora o perigo.
Em alguns casos, essa alteração do kernel não é tão simples e pode apresentar bugs. Volta e meia uns desses acontecem e causam bastante alarde na comunidade de usuários da ferramenta. Por volta do ano passado, se não me engano, o Helix apresentou um problema desses no HFS+. A bola da vez é o DEFT 4.2, com os sistemas ext3 e ext4.
Conseguiram detectar que o DEFT estava lendo e efetivando transações em journaling pendentes de imagens forenses baseadas nos sistemas ext3 e ext4. Embora isso só aconteça em condições bastante específicas, alguns podem ter sido prejudicados na questão integridade da imagem. Não chega a ser desesperador justamente porque, para o problema acontecer, várias condições precisam estar presentes. O investigador precisa estar trabalhando com uma imagem forense ext3 ou ext4 (pelo menos no Brasil, o mais comum são imagens NTFS) e ter o azar de haver transações incompletas no journaling. Isso aconteceria, por exemplo, em uma dead acquisition, se a máquina foi desligada sem os procedimentos normais, não dando ao SO a oportunidade de aplicar as ultimas transações do journaling. Em uma live acquisition, há ainda mais chances de acontecer, já que várias transações podem estar acontecendo no disco no exato momento em que a parte do journaling no disco está sendo capturada para a imagem.
O que fazer caso o bug tenha afetado uma imagem ? Bem, as boas práticas forenses mandam que nós trabalhemos sempre em uma cópia da imagem forense. Se o hash não bateu, por esse ou outro problema, pegue a imagem original e faça nova cópia, tendo antes o cuidado de entender como a integridade foi quebrada.
Não estavas trabalhando com uma cópia da imagem ??? Vais ter mais trabalho. Terás que fazer a aquisição da imagem novamente, rompendo o lacre da mídia original e efetuando a operação. Documente tudo, pois o acesso à mídia original terá de constar da cadeia de custódia.
Alguém já teve problemas relativos a isso e gostaria de comentar ?
Até o próximo post !
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 !
- 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 !
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:
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 !
* 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/
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.
- 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.
- 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.
- É 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.
- É 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 ...- Nesses tempos modernos, Forense de Registry e de Memória são bastante úteis para um investigador.
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 !
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 !
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 !
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 !
quinta-feira, 17 de setembro de 2009
Blog da SANS troca de endereço
Aparentemente, andei cochilando quanto a isso. O endereço de um dos melhores blogs sobre Forense Computacional mudou e eu nem percebi, já que estou bastante atrasado nas minhas leituras diárias.
Bem, o link aqui do meu blog para o blog da SANS já foi atualizado. Se você consegue ler textos em inglês, esse blog é imperdível. Vale cada segundo lendo ...
Até o próximo post !
Bem, o link aqui do meu blog para o blog da SANS já foi atualizado. Se você consegue ler textos em inglês, esse blog é imperdível. Vale cada segundo lendo ...
Até o próximo post !
terça-feira, 15 de setembro de 2009
Vinho é um santo remédio !
As ferramentas que usamos em Forense Computacional são muito importantes para atingirmos o objetivo. Elas permitem que possamos avaliar e examinar vestígios de forma adequada. Uma situação bem comum é quando estamos realizando uma perícia e precisamos avaliar um vestígio, mas as ferramentas necessárias para isso não estão disponíveis no SO que estamos usando. Ou seja, quando estamos usando um Live CD baseado em Linux e nossa imagem e vestígios estão disponíveis, tudo está indo bem. No entanto, podemos topar com a necessidade de uma analise que requer uma ferramenta somente disponível em Windows. Aí o caldo começa a engrossar ...
Há algumas estratégias desenvolvidas para tratar isso. Todas tem prós e contras. Vou tentar resumir:
1) Podemos extrair os vestígios da imagem, salvando em uma partição FAT que depois será acessada pelo Windows e suas ferramentas.
2) Podemos extrair os vestígios da imagem ou mesmo montá-la, colocando os arquivos acessíveis em um compartilhamento (via Samba). Pelo Windows, mapearemos o compartilhamento e acessaremos os artefatos/vestígios, completando as análises.
3) Podemos extrair os vestígios para fora da imagem e depois acessar a partição Ext2/Ext3 usando utilitários Windows que conseguem ler e recuperar arquivos dessas partições.
Como já disse, cada uma dessas estratégias possui limitações e situações indesejadas. Elas precisam ser bem conhecidas para que o perito possa escolher qual usar quando for necessário. As estratégias que envolvem retirar os vestígios da imagem podem requerer grande quantidade de espaço em disco, seja na partição FAT ou na Ext2/Ext3. As estratégias que usam compartilhamento vão requerer que as estações forenses estejam em rede. Um problema a mais é que o Samba foi retirado das versões mais recentes do Helix e do Caine. O FCCU oferece dificuldades a mais em relação à rede.
Há outra alternativa para o problema e que não possui as características negativas acima: Vinho !
Vinho ???
Wine é o nome de um programa para Linux que, segundo documentações do site, compatibiliza o SO Linux, origem de nossos Live CDs de Forense, com as aplicações Windows. A documentação tenta ser bastante enfática no conceito, afirmando que o Wine não faz emulação de código, nem cria algum tipo de máquina virtual. O Wine cria condições para que um programa Windows possa rodar em Linux, numa boa. Ele é comparado a opção de executar um programa criado para o WinXP dentro do Vista. As opções de compatibilização fazem, por debaixo dos panos, o mesmo que o Wine faz, no Linux; Elas criam o mesmo ambiente básico que o programa espera encontrar para poder executar.
O que é necessário ?
Uma conexão de internet funcionando para o Live CD. Isso porque, como nenhum deles traz o Wine, será necessário atualizar o SO e baixar o Wine antes de poder usá-lo. Vamos a um passo a passo, que deve funcionar da mesma maneira em todos os Live CDs. Eu testei no Helix e no Caine:
1) Em um terminal root, execute apt-get update
O Live CD vai buscar algumas atualizações para o SO diretamente da internet.
2) Execute apt-get install wine
Esse demora um pouco mais e no final garante que o wine esteja completamente instalado no Live CD.
3) Execute qualquer utilitário Windows: wine UTILITARIO.EXE
O Wine monta um ambiente simulando um C:\ e executa o utilitário.
A página de download do Wine oferece outras formas de download e instalação do Wine. Clique aqui para ver. Use a linha do Ubuntu Hardy tanto para o Helix quanto para o Caine.
Essa é uma das melhores maneiras de reaproveitar ferramentas e resolver a questão que coloquei acima, quando não temos ferramenta para o vestígio que queremos investigar, nem no Live CD, nem fora, pelo menos em Perl ou Python. Eu testei algumas ferramentas:
- WFA: Funcionou perfeitamente e em todos os módulos;
- FastResolver e IPNetInfo: Não apresentaram todas as informações;
- HashCalc e Pre-Search, ambos do Deft: Funcionaram perfeitamente;
O site do Wine mantém um database com informações de programas que foram testados e podem ser considerados compatível. Embora eu não tenha testado, não tenho grandes expectativas de que programas do tipo filemon ou regmon funcionem no Wine. Imagino que, por eles usarem capacidades bastante elementares do Windows, não sejam facilmente portáveis.
Nem tudo são flores
Além da questão da compatibilidade, que descrevi acima, há outro detalhe: Estamos lidando com um Live CD. Todo o processo de instalação se perde quando a máquina é desligada. Isso pode fazer com que seja necessário repetir o processo de reinstalação toda nova sessão de investigação/perícia. Podemos evitar isso com:
- Um esquema para perpetuar a sessão. Não cheguei a pesquisar essa opção, mas havia essa possibilidade no Helix 1.9;
- Usar máquina virtual, e dar uma "pausa" na máquina quando ela não for mais necessária. Quando ela for utilizada novamente, o restore vai garantir que ela esteja com o Wine lá;
- Usar uma versão instalada do Helix ou do Caine. Nesse caso, o Wine não vai embora quando desligamos as luzes da sala ...
Gostaria de ouvir comentários de quem já usa essa ferramenta. Quais são os utilitários forenses que você tem usado com sucesso ? Que estratégia para manter o Wine você usa ?
Até o próximo post !
Há algumas estratégias desenvolvidas para tratar isso. Todas tem prós e contras. Vou tentar resumir:
1) Podemos extrair os vestígios da imagem, salvando em uma partição FAT que depois será acessada pelo Windows e suas ferramentas.
2) Podemos extrair os vestígios da imagem ou mesmo montá-la, colocando os arquivos acessíveis em um compartilhamento (via Samba). Pelo Windows, mapearemos o compartilhamento e acessaremos os artefatos/vestígios, completando as análises.
3) Podemos extrair os vestígios para fora da imagem e depois acessar a partição Ext2/Ext3 usando utilitários Windows que conseguem ler e recuperar arquivos dessas partições.
Como já disse, cada uma dessas estratégias possui limitações e situações indesejadas. Elas precisam ser bem conhecidas para que o perito possa escolher qual usar quando for necessário. As estratégias que envolvem retirar os vestígios da imagem podem requerer grande quantidade de espaço em disco, seja na partição FAT ou na Ext2/Ext3. As estratégias que usam compartilhamento vão requerer que as estações forenses estejam em rede. Um problema a mais é que o Samba foi retirado das versões mais recentes do Helix e do Caine. O FCCU oferece dificuldades a mais em relação à rede.
Há outra alternativa para o problema e que não possui as características negativas acima: Vinho !
Vinho ???
Wine é o nome de um programa para Linux que, segundo documentações do site, compatibiliza o SO Linux, origem de nossos Live CDs de Forense, com as aplicações Windows. A documentação tenta ser bastante enfática no conceito, afirmando que o Wine não faz emulação de código, nem cria algum tipo de máquina virtual. O Wine cria condições para que um programa Windows possa rodar em Linux, numa boa. Ele é comparado a opção de executar um programa criado para o WinXP dentro do Vista. As opções de compatibilização fazem, por debaixo dos panos, o mesmo que o Wine faz, no Linux; Elas criam o mesmo ambiente básico que o programa espera encontrar para poder executar.
O que é necessário ?
Uma conexão de internet funcionando para o Live CD. Isso porque, como nenhum deles traz o Wine, será necessário atualizar o SO e baixar o Wine antes de poder usá-lo. Vamos a um passo a passo, que deve funcionar da mesma maneira em todos os Live CDs. Eu testei no Helix e no Caine:
1) Em um terminal root, execute apt-get update
O Live CD vai buscar algumas atualizações para o SO diretamente da internet.
2) Execute apt-get install wine
Esse demora um pouco mais e no final garante que o wine esteja completamente instalado no Live CD.
3) Execute qualquer utilitário Windows: wine UTILITARIO.EXE
O Wine monta um ambiente simulando um C:\ e executa o utilitário.
A página de download do Wine oferece outras formas de download e instalação do Wine. Clique aqui para ver. Use a linha do Ubuntu Hardy tanto para o Helix quanto para o Caine.
Essa é uma das melhores maneiras de reaproveitar ferramentas e resolver a questão que coloquei acima, quando não temos ferramenta para o vestígio que queremos investigar, nem no Live CD, nem fora, pelo menos em Perl ou Python. Eu testei algumas ferramentas:
- WFA: Funcionou perfeitamente e em todos os módulos;
- FastResolver e IPNetInfo: Não apresentaram todas as informações;
- HashCalc e Pre-Search, ambos do Deft: Funcionaram perfeitamente;
O site do Wine mantém um database com informações de programas que foram testados e podem ser considerados compatível. Embora eu não tenha testado, não tenho grandes expectativas de que programas do tipo filemon ou regmon funcionem no Wine. Imagino que, por eles usarem capacidades bastante elementares do Windows, não sejam facilmente portáveis.
Nem tudo são flores
Além da questão da compatibilidade, que descrevi acima, há outro detalhe: Estamos lidando com um Live CD. Todo o processo de instalação se perde quando a máquina é desligada. Isso pode fazer com que seja necessário repetir o processo de reinstalação toda nova sessão de investigação/perícia. Podemos evitar isso com:
- Um esquema para perpetuar a sessão. Não cheguei a pesquisar essa opção, mas havia essa possibilidade no Helix 1.9;
- Usar máquina virtual, e dar uma "pausa" na máquina quando ela não for mais necessária. Quando ela for utilizada novamente, o restore vai garantir que ela esteja com o Wine lá;
- Usar uma versão instalada do Helix ou do Caine. Nesse caso, o Wine não vai embora quando desligamos as luzes da sala ...
Gostaria de ouvir comentários de quem já usa essa ferramenta. Quais são os utilitários forenses que você tem usado com sucesso ? Que estratégia para manter o Wine você usa ?
Até o próximo post !
terça-feira, 1 de setembro de 2009
WTF e Timestamps
WTF não é um termo técnico, mas deve ser a expressão mais usada de 8 entre 10 Peritos e Investigadores em Forense Computacional. Li esse termo hoje em um artigo muito bom, que traduz a essência do que é ser Perito: Analisar bem os vestígios e saber como as ferramentas que temos nas mãos funciona.
A situação ocorre quando, por necessidade de uma ordem judicial, um micro é apreendido para ser investigado. O Perito já está de posse do depoimento do usuário/dono do micro, que entre outras coisas, diz que o micro é novinho em folha. Ele diz que tinha comprado um HD novo e decidiu instalar o Windows XP logo depois de um jogo na TV. Isso tinha acontecido no dia anterior ao micro ser apreendido.
De posse dessas informações, o perito anota no seu caderninho (é um cara bem antigo, não usa CaseNotes):
- Data da operação: Dia 1 de setembro.
- Data da instalação: Dia 31 de agosto, por volta de 18h30.
O Perito prossegue, analisando a imagem que foi feita da máquina, obviamente segundo o processo forense (ou seja, duplicação bit-a-bit). Ao analisar o Registry, encontra lá, dentro de muitas chaves, a que informa a hora exata da instalação do Sistema Operacional:
HKLM/Software/Microsoft/Windows NT/CurrentVersion/InstallDate: 31/08/2009 22h30. Como bom Perito, ele sabe que essa hora está no formato GMT e logo deduz que o vestígio encontrado indica que a instalação do SO ocorreu em 19h30 (Hora de Brasília).
- "Bem", ele pensa, "estamos indo conforme o depoimento, tudo ok até aqui". O próximo passo é olhar timestamps do NTFS, para montar seu timeline. Antes disso, passeando pelo Autopsy, ele decide verificar o timestamp dos objetos do NT ($MFT, $LogFile e outros). Ora, se tudo estiver correto, o timestamp deverá indicar por volta de 18h30, já que entre a criação do sistema de arquivos e a finalização da instalação do SO, temos por volta de uma hora. Ele anota a data/hora e, sabendo que todas estão em notação GMT, converte-as para o nosso fuso horário e tem o resultado: 31/08/2009 15h33.
WTF ???? (O artigo é em inglês, então faça um exercício de imaginação sobre essas siglas aí ...)
O que poderia estar acontecendo ??? Então o dono da máquina iniciou a instalação às 15h33, com a formatação do HD novo, e ela só foi terminada mais tarde, por volta das 19h30 ?? O que houve no meio do caminho ?? Ele teria mentido sobre o que aconteceu ????
A resposta é um sonoro não !
O caso é que, como a formatação é uma das primeiras coisas que acontecem na operação de instalação de um SO novo, no momento da criação dos objetos do NT, o programa de formatação não tem ainda a referencia ao fuso horário. Essa informação só fica estabelecida posteriormente. Por conta disso, ele pega a data da Bios e grava ela nos timestamps diretamente, sem nenhuma conversão. Quando a instalação é finalizada, ao escrever essa informação no Registry, o fuso já é conhecido. Portanto, o SO pega a hora da BIOS e converte para GMT, gravando-a em seguida.
Assim, mesmo que a regra geral seja de que os timestamps do NTFS estão todos em GMT, temos a exceção: Os timestamps dos objetos de NTFS criados em uma formatação antes da instalação do SO estarão em horário local.
Dessa forma, a hora que o Perito viu (18h33) não precisava ser convertida (no nosso caso, subtraindo 3 para usar como hora de Brasília) . 18h33 foi a data/hora correta de formatação do HD, conferindo com o depoimento.
Moral da História: Cuidado com conversões de timestamps, principalmente quando os utilitários as fazem automaticamente.
Pergunta de prova: O que aconteceria se, ao invés de uma instalação novíssima, do zero, estivesse sendo feita uma formatação completa para uma reinstalação ? Comente !
Até o próximo post !
A situação ocorre quando, por necessidade de uma ordem judicial, um micro é apreendido para ser investigado. O Perito já está de posse do depoimento do usuário/dono do micro, que entre outras coisas, diz que o micro é novinho em folha. Ele diz que tinha comprado um HD novo e decidiu instalar o Windows XP logo depois de um jogo na TV. Isso tinha acontecido no dia anterior ao micro ser apreendido.
De posse dessas informações, o perito anota no seu caderninho (é um cara bem antigo, não usa CaseNotes):
- Data da operação: Dia 1 de setembro.
- Data da instalação: Dia 31 de agosto, por volta de 18h30.
O Perito prossegue, analisando a imagem que foi feita da máquina, obviamente segundo o processo forense (ou seja, duplicação bit-a-bit). Ao analisar o Registry, encontra lá, dentro de muitas chaves, a que informa a hora exata da instalação do Sistema Operacional:
HKLM/Software/Microsoft/Windows NT/CurrentVersion/InstallDate: 31/08/2009 22h30. Como bom Perito, ele sabe que essa hora está no formato GMT e logo deduz que o vestígio encontrado indica que a instalação do SO ocorreu em 19h30 (Hora de Brasília).
- "Bem", ele pensa, "estamos indo conforme o depoimento, tudo ok até aqui". O próximo passo é olhar timestamps do NTFS, para montar seu timeline. Antes disso, passeando pelo Autopsy, ele decide verificar o timestamp dos objetos do NT ($MFT, $LogFile e outros). Ora, se tudo estiver correto, o timestamp deverá indicar por volta de 18h30, já que entre a criação do sistema de arquivos e a finalização da instalação do SO, temos por volta de uma hora. Ele anota a data/hora e, sabendo que todas estão em notação GMT, converte-as para o nosso fuso horário e tem o resultado: 31/08/2009 15h33.
WTF ???? (O artigo é em inglês, então faça um exercício de imaginação sobre essas siglas aí ...)
O que poderia estar acontecendo ??? Então o dono da máquina iniciou a instalação às 15h33, com a formatação do HD novo, e ela só foi terminada mais tarde, por volta das 19h30 ?? O que houve no meio do caminho ?? Ele teria mentido sobre o que aconteceu ????
A resposta é um sonoro não !
O caso é que, como a formatação é uma das primeiras coisas que acontecem na operação de instalação de um SO novo, no momento da criação dos objetos do NT, o programa de formatação não tem ainda a referencia ao fuso horário. Essa informação só fica estabelecida posteriormente. Por conta disso, ele pega a data da Bios e grava ela nos timestamps diretamente, sem nenhuma conversão. Quando a instalação é finalizada, ao escrever essa informação no Registry, o fuso já é conhecido. Portanto, o SO pega a hora da BIOS e converte para GMT, gravando-a em seguida.
Assim, mesmo que a regra geral seja de que os timestamps do NTFS estão todos em GMT, temos a exceção: Os timestamps dos objetos de NTFS criados em uma formatação antes da instalação do SO estarão em horário local.
Dessa forma, a hora que o Perito viu (18h33) não precisava ser convertida (no nosso caso, subtraindo 3 para usar como hora de Brasília) . 18h33 foi a data/hora correta de formatação do HD, conferindo com o depoimento.
Moral da História: Cuidado com conversões de timestamps, principalmente quando os utilitários as fazem automaticamente.
Pergunta de prova: O que aconteceria se, ao invés de uma instalação novíssima, do zero, estivesse sendo feita uma formatação completa para uma reinstalação ? Comente !
Até o próximo post !
quinta-feira, 20 de agosto de 2009
Treinamento em Forense Computacional - CFPF
Pessoal, o site da TISafe traz novos detalhes em relação ao nosso curso de Computação Forense. Veja no item CFPF - Curso de Formação de Peritos Forenses Computacionais.
A próxima turma começa em 13 de setembro, no Rio de Janeiro, com aulas no período noturno. O curso tem duração de 40h com teoria e muita, muita prática.
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.
Estamos verificando a possibilidade de termos o treinamento em outros estados além do Rio de Janeiro, bem como turmas in-house. Se tiverem alguma dúvida, entrem em contato por email ou mesmo deixe um comentário aqui no blog.
Até o próximo post !
A próxima turma começa em 13 de setembro, no Rio de Janeiro, com aulas no período noturno. O curso tem duração de 40h com teoria e muita, muita prática.
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.
Estamos verificando a possibilidade de termos o treinamento em outros estados além do Rio de Janeiro, bem como turmas in-house. Se tiverem alguma dúvida, entrem em contato por email ou mesmo deixe um comentário aqui no blog.
Até o próximo post !
terça-feira, 18 de agosto de 2009
Byte Investigator III - OLEmergeSearch
Acabei de atualizar o pacote de scripts Perl Byte Investigator com uma rotina que vasculha em uma imagem forense, separando todos os arquivos Office, e em seguida testa cada um deles procurando por multiplos streams, o que pode indicar tentativa de obfuscar informações.
A rotina OLEmergesearch.pl usa o sorter, do TSK, para localizar os arquivos Office, e usa também o script perl OLEmerge.pl, do próprio Byte Investigator, para detectar as streams em cada arquivo. A resposta informa o inode de cada arquivo e quantas streams tem. Os arquivos que acusarem mais de uma stream devem ser extraídos e verificados com mais detalhes.
A rotina pode ser encontrada aqui
Até o próximo post !
A rotina OLEmergesearch.pl usa o sorter, do TSK, para localizar os arquivos Office, e usa também o script perl OLEmerge.pl, do próprio Byte Investigator, para detectar as streams em cada arquivo. A resposta informa o inode de cada arquivo e quantas streams tem. Os arquivos que acusarem mais de uma stream devem ser extraídos e verificados com mais detalhes.
A rotina pode ser encontrada aqui
Até o próximo post !
sábado, 15 de agosto de 2009
Byte Investigator II - OLE Structured Storage
OLE Structured Storage é uma estrutura de arquivo bastante interessante. É baseada no conceito recursivo de diretório e arquivo. Um diretório pode conter vários arquivos e outros diretórios. Um arquivo (stream) é onde fica o conteúdo propriamente dito. É simples assim.
Várias aplicações escolheram esse formato para seus arquivos. Dentre elas, o Registry e os arquivos do Office (.DOC, .XLS e .PPT).
Especificamente sobre os arquivos do Office, essa característica dá margem a uma estratégia de obfuscação bastante interessante. Como um diretório pode conter mais de uma stream (ou arquivo) é possível juntar um arquivo dentro do outro, de forma que fique oculto. Por exemplo, podemos colocar uma planilha do Excel dentro de um documento Word. A visualização de conteúdo é determinada pela extensão do arquivo; Ou seja, se a extensão é a .xls, vemos a planilha ao dar um duplo clique no arquivo. Se a extensão for um .doc, o Word é carregado e o que seria o documento pode ser acessado.
Esse comportamento é muito útil em alguns casos maliciosos e se torna ainda mais interessante por quase não ser divulgado. Um funcionário pode usar esse estratagema para subtrair uma planilha confidencial, bastando para isso mesclá-la internamente com um .doc inofensivo (um currículo, por exemplo). Quer ver o currículo, coloque a extensão .doc; quer ver a planilha, troque a extensão para .xls e lá estará o ouro ... Um pedófilo mais preparado e informado pode colocar as várias fotos suspeitas em um .doc e, em seguida, camuflar esse conteúdo dentro de uma planilha de contas a pagar. Nos dois casos, captar o truque pode ser bastante complicado.
Pensando nisso, desenvolvi uma nova rotina para o Byte Investigator. Ela tem por objetivo listar as streams de documentos Office que existem dentro de um arquivo Office. O uso é muito simples, e como é baseada em Perl, ela não depende de nenhum outro arquivo ou API externo, funcionando bem em Windows (com o Perl, lógico) e em qualquer live CD que tenha o Perl instalado.
Digitando OLEmerge.pl , ela verifica e lista cada stream encontrada. É possível usar o parâmetro -e, que apenas indica se há uma ou mais streams disponibilizadas. Obviamente, sempre que houver mais de uma stream, o arquivo deve ser analisado com mais detalhes, procurando qual o conteúdo oculto.
Você pode baixar a rotina aqui.
Comentários ?
Até o próximo post !
Várias aplicações escolheram esse formato para seus arquivos. Dentre elas, o Registry e os arquivos do Office (.DOC, .XLS e .PPT).
Especificamente sobre os arquivos do Office, essa característica dá margem a uma estratégia de obfuscação bastante interessante. Como um diretório pode conter mais de uma stream (ou arquivo) é possível juntar um arquivo dentro do outro, de forma que fique oculto. Por exemplo, podemos colocar uma planilha do Excel dentro de um documento Word. A visualização de conteúdo é determinada pela extensão do arquivo; Ou seja, se a extensão é a .xls, vemos a planilha ao dar um duplo clique no arquivo. Se a extensão for um .doc, o Word é carregado e o que seria o documento pode ser acessado.
Esse comportamento é muito útil em alguns casos maliciosos e se torna ainda mais interessante por quase não ser divulgado. Um funcionário pode usar esse estratagema para subtrair uma planilha confidencial, bastando para isso mesclá-la internamente com um .doc inofensivo (um currículo, por exemplo). Quer ver o currículo, coloque a extensão .doc; quer ver a planilha, troque a extensão para .xls e lá estará o ouro ... Um pedófilo mais preparado e informado pode colocar as várias fotos suspeitas em um .doc e, em seguida, camuflar esse conteúdo dentro de uma planilha de contas a pagar. Nos dois casos, captar o truque pode ser bastante complicado.
Pensando nisso, desenvolvi uma nova rotina para o Byte Investigator. Ela tem por objetivo listar as streams de documentos Office que existem dentro de um arquivo Office. O uso é muito simples, e como é baseada em Perl, ela não depende de nenhum outro arquivo ou API externo, funcionando bem em Windows (com o Perl, lógico) e em qualquer live CD que tenha o Perl instalado.
Digitando OLEmerge.pl
Você pode baixar a rotina aqui.
Comentários ?
Até o próximo post !
sexta-feira, 14 de agosto de 2009
BackTrack 4
Hoje é, segundo um email postado na lista PericiaForense, o pré-lançamento da versão 4 do BackTrack, uma distro voltada para Pen Test e que também possui alguma coisa para Forense Computacional. Segue o email enviado:
BackTrack é atualmente a melhor distribuição de Linux com foco em testes de penetração em sistemas (Pentesting). Sem nenhuma instalação (LiveCD), a plataforma de análise é iniciada directamente do CD-ROM ou Pen Drive sendo completamente acessível em minutos. BackTrack é uma distribuição Linux live que também pode ser instalada se preferir.
Back Track é uma junção de duas antigas distribuições relacionadas com segurança, Whax e Auditor Security Collection, reunindo mais de 300 ferramentas para análise e testes de vulnerabilidades Esta nova edição BackTrack 4, segundo o site oficial já alcançou mais de 100.000 downloads.
Segundo o anúncio, o BackTrack 4 traz grandes avanços conceituais e tem algumas novas e excelentes características. A mais importante destas mudanças é a expansão do Pentesting LiveCD para uma plena “Distribuição”.
Agora, baseado em Debian (núcleo e pacotes) e utilizando os repositórios de softwares do Ubuntu, BackTrack 4 pode ser adaptado em caso de atualização. Quando sincronizado com os repositórios oficiais do BackTrack, o sistema irá receber regularmente actualizações de segurança e novas ferramentas.
Algumas das novas características incluem:
- - Kernel 2.6.29.4 com melhor suporte de hardware.
- - Suporte nativo para cartões Pico E12 e E16 está agora totalmente funcional, fazendo do BackTrack a primeira distro Pentesting em utilizar plenamente os recursos destas minúsculas máquinas.
- - Suporte para Boot PXE.
- - SAINT EXPLOIT – gentilmente fornecido pela corporação SAINT com um número limitado de IPs livre.
- - Maltego 2.0.2
- - Os últimos patches mac80211 wireless injection pacthes foram aplicados, juntamente com vários patches personalizados para o rtl8187 injection. O suporte à wireless injection nunca foi tão amplo e funcional.
- - Unicornscan – Totalmente funcional com suporte ao postgress logging e web front end.
- - Suporte RFID
- - Suporte Pyrit CUDA
- - Novas ferramentas e atualizações
A lista de software contido nesta distribuição, tem aplicações com tudo de bom e do melhor, Wireless, Passwords, Spoofing, Tunneling, Enumeration, Bruteforce, Sniffers, VOIP, Bluetooth, Fuzzers, Forensics, Cisco, Debuggers, Database, RFID, Penetration, GPU e outras mais de 300
ferramentas.
Alguém já usou a ferramenta e gostaria de comentar ?
Até o próximo post !
BackTrack é atualmente a melhor distribuição de Linux com foco em testes de penetração em sistemas (Pentesting). Sem nenhuma instalação (LiveCD), a plataforma de análise é iniciada directamente do CD-ROM ou Pen Drive sendo completamente acessível em minutos. BackTrack é uma distribuição Linux live que também pode ser instalada se preferir.
Back Track é uma junção de duas antigas distribuições relacionadas com segurança, Whax e Auditor Security Collection, reunindo mais de 300 ferramentas para análise e testes de vulnerabilidades Esta nova edição BackTrack 4, segundo o site oficial já alcançou mais de 100.000 downloads.
Segundo o anúncio, o BackTrack 4 traz grandes avanços conceituais e tem algumas novas e excelentes características. A mais importante destas mudanças é a expansão do Pentesting LiveCD para uma plena “Distribuição”.
Agora, baseado em Debian (núcleo e pacotes) e utilizando os repositórios de softwares do Ubuntu, BackTrack 4 pode ser adaptado em caso de atualização. Quando sincronizado com os repositórios oficiais do BackTrack, o sistema irá receber regularmente actualizações de segurança e novas ferramentas.
Algumas das novas características incluem:
- - Kernel 2.6.29.4 com melhor suporte de hardware.
- - Suporte nativo para cartões Pico E12 e E16 está agora totalmente funcional, fazendo do BackTrack a primeira distro Pentesting em utilizar plenamente os recursos destas minúsculas máquinas.
- - Suporte para Boot PXE.
- - SAINT EXPLOIT – gentilmente fornecido pela corporação SAINT com um número limitado de IPs livre.
- - Maltego 2.0.2
- - Os últimos patches mac80211 wireless injection pacthes foram aplicados, juntamente com vários patches personalizados para o rtl8187 injection. O suporte à wireless injection nunca foi tão amplo e funcional.
- - Unicornscan – Totalmente funcional com suporte ao postgress logging e web front end.
- - Suporte RFID
- - Suporte Pyrit CUDA
- - Novas ferramentas e atualizações
A lista de software contido nesta distribuição, tem aplicações com tudo de bom e do melhor, Wireless, Passwords, Spoofing, Tunneling, Enumeration, Bruteforce, Sniffers, VOIP, Bluetooth, Fuzzers, Forensics, Cisco, Debuggers, Database, RFID, Penetration, GPU e outras mais de 300
ferramentas.
Alguém já usou a ferramenta e gostaria de comentar ?
Até o próximo post !
terça-feira, 4 de agosto de 2009
SSDDFJ
Há os que amam siglas. Não é o meu caso. Entretanto, ao que parece a sigla acima é mais usual para o espaço do que o nome completo: Small Scale Digital Device Forensics Journal, ou seja, Jornal Forense de Dispositivos Digitais de Pequena Escala. É um periódico bastante interessante, voltado para Forense Digital em aparelhos celulares, GPS, SSD, Iphones e afins. É uma parte que eu particularmente não aprecio muito, mas há uma extensa gama de conhecimento e aplicação delas.
Pois bem, o SSDDFJ Vol 3 já está disponível e traz alguns artigos:
3:1.1> Hashing Techniques for Mobile Device Forensics
3:1.2> Expanding the Potential for GPS Evidence Acquisition
3:1.3> The Fraternal Clone Method for CDMA Cell Phones
3:1.4> Provider Side Cell Phone Forensics
Os artigos podem ser lidos aqui.
Até o próximo post !
Pois bem, o SSDDFJ Vol 3 já está disponível e traz alguns artigos:
3:1.1> Hashing Techniques for Mobile Device Forensics
3:1.2> Expanding the Potential for GPS Evidence Acquisition
3:1.3> The Fraternal Clone Method for CDMA Cell Phones
3:1.4> Provider Side Cell Phone Forensics
Os artigos podem ser lidos aqui.
Até o próximo post !
sexta-feira, 31 de julho de 2009
Forense de Registry
A atividade investigativa em meio digital, apesar de complexa, pode ser resumida ao trabalho de descobrir vestígios que possam corroborar ou negar determinada tese. Com isso, precisamos conhecer cada vestígio possível de ser encontrado, dada uma ação qualquer realizada. Esse princípio é o mesmo em todos os tipos de perícia. No fim das contas, estamos olhando para os "efeitos" a fim de determinar as "causas".
Mina de Ouro
Um excelente local para se localizar artefatos (vestígios) é o Registry. Esse banco de dados de configurações apareceu pela primeira vez no mundo Windows com o Windows 95. A proposta dele era eliminar milhares de arquivos .ini, cada um acompanhando determinado programa. O Registry tem uma estrutura interna de banco de dados mesmo, conhecida como structured storage, e não simplesmente um arquivo de texto comum. Ele não é apenas um arquivo simples, mas um grupo deles, que pode ser verificado em conjunto em uma estrutura indentada, conhecida como hives. Não vou entrar em detalhes sobre essa estrutura, pois não caberia em um artigo desses, mas vale dizer que o Registry foi pensado para ser um repositório de configurações, não apenas do próprio Windows, mas também servindo aos programas de terceiros. Por que estamos falando tanto desse Registry, então ? Porque ele é uma mina de ouro para Investigadores Digitais.
É possível resgatar todo o tipo de informação de um Registry. Além de inserir vários pontos de controle do próprio Windows, a Microsoft nos fez o favor de dar às entradas do Registry um timestamp; ou seja, as chaves possuem data/hora da última modificação. Esse ponto, por si só, já nos permite conhecer um timeline das atividades de configuração da máquina, e em muitos casos, correlacionar dados com outros, buscados nas demais fontes de vestígios de um computador.
Forense de Registry
O Registry tem se tornado tão importante para a Computação Forense que há um perito especializado nesse tema, e depois de lançar ótimos livros sobre Forense Computacional em geral, está pesquisando a possibilidade de lançar um livro só sobre Registry. Harlan Carvey, já citado por mim aqui no blog algumas dezenas de vezes, estuda bastante o assunto e criou um programa para operar na extração (consequentemente, ajudando na análise) dos dados do registry. O RegRipper atua sobre um arquivo específico que compoe o registry e faz as extrações das informações, listando-as de maneira clara. Você pode estar se perguntando por que isso é melhor do que o RegEdit, do próprio Windows. Bem, isso é melhor porque:
Já está bom ?
Além disso tudo, o RegRipper é de graça e "conversa" muito bem com o F-Response, podendo ser usado em Live Analysis por conta disso.
Como se isso não bastasse, recentemente o Harlan publicou um novo programa no site do RegRipper: O RegXP. Esse utilitário serve para analisar os arquivos de Registry que são encontrados no System Restore. Vamos falar disso mais adiante, mas a idéia é que o RegXP possa fazer uma análise em conjunto de cada arquivo de Registry localizado nos System Restore da máquina. É um comparativo que pode indicar muito do que foi feito na máquina.
Alguém já usou a ferramenta e quer compartilhar suas impressões ? Comente !
Até o próximo post !
Mina de Ouro
Um excelente local para se localizar artefatos (vestígios) é o Registry. Esse banco de dados de configurações apareceu pela primeira vez no mundo Windows com o Windows 95. A proposta dele era eliminar milhares de arquivos .ini, cada um acompanhando determinado programa. O Registry tem uma estrutura interna de banco de dados mesmo, conhecida como structured storage, e não simplesmente um arquivo de texto comum. Ele não é apenas um arquivo simples, mas um grupo deles, que pode ser verificado em conjunto em uma estrutura indentada, conhecida como hives. Não vou entrar em detalhes sobre essa estrutura, pois não caberia em um artigo desses, mas vale dizer que o Registry foi pensado para ser um repositório de configurações, não apenas do próprio Windows, mas também servindo aos programas de terceiros. Por que estamos falando tanto desse Registry, então ? Porque ele é uma mina de ouro para Investigadores Digitais.
É possível resgatar todo o tipo de informação de um Registry. Além de inserir vários pontos de controle do próprio Windows, a Microsoft nos fez o favor de dar às entradas do Registry um timestamp; ou seja, as chaves possuem data/hora da última modificação. Esse ponto, por si só, já nos permite conhecer um timeline das atividades de configuração da máquina, e em muitos casos, correlacionar dados com outros, buscados nas demais fontes de vestígios de um computador.
Forense de Registry
O Registry tem se tornado tão importante para a Computação Forense que há um perito especializado nesse tema, e depois de lançar ótimos livros sobre Forense Computacional em geral, está pesquisando a possibilidade de lançar um livro só sobre Registry. Harlan Carvey, já citado por mim aqui no blog algumas dezenas de vezes, estuda bastante o assunto e criou um programa para operar na extração (consequentemente, ajudando na análise) dos dados do registry. O RegRipper atua sobre um arquivo específico que compoe o registry e faz as extrações das informações, listando-as de maneira clara. Você pode estar se perguntando por que isso é melhor do que o RegEdit, do próprio Windows. Bem, isso é melhor porque:
- O RegEdit só funciona em uma Live Analysis, enquanto que o RegRipper funciona em DeadAnalysis também
- O RegEdit é um browser da estrutura. Se ele achar um valor com uma string binária contendo o numero 1, ele vai exibir 1 para aquele valor, enquanto que o RegRipper vai exibir exatamente o que o "1" significa naquele contexto. Por exemplo, o "1" pode significar "Instalação Default" ou "Inativo" ...
- O RegEdit não faz parsing das estruturas armazenadas no registry; Ou seja, se houver um valor binário lá, ele vai mostrar um conjunto de dados completamente sem sentido. O RegRipper exibirá os dados todos traduzidos, de acordo com a sua estrutura.
- O RegEdit é um programa único que só faz a exibição dos dados. O RegRipper é extensível, aceita plugins que podem ser desenvolvidos por qualquer um que conheça Perl.
- O RegEdit não mostra os timestamps das chaves, o RegRipper as mostra e pode auxiliar na montagem de um timeline delas.
- O RegEdit exibe valores criptografados como estão, o RegRipper os descriptografa (casos onde os valores são gravados pelo Windows em ROT-13)
Já está bom ?
Além disso tudo, o RegRipper é de graça e "conversa" muito bem com o F-Response, podendo ser usado em Live Analysis por conta disso.
Como se isso não bastasse, recentemente o Harlan publicou um novo programa no site do RegRipper: O RegXP. Esse utilitário serve para analisar os arquivos de Registry que são encontrados no System Restore. Vamos falar disso mais adiante, mas a idéia é que o RegXP possa fazer uma análise em conjunto de cada arquivo de Registry localizado nos System Restore da máquina. É um comparativo que pode indicar muito do que foi feito na máquina.
Alguém já usou a ferramenta e quer compartilhar suas impressões ? Comente !
Até o próximo post !
Assinar:
Postagens (Atom)