Acabei de ler uma excelente nota (e um grande avanço para nós) no site da F-Response.
Para quem não conhece ainda, F-Response é a badalação do momento no que se refere a software para Forense Computacional. Esqueça a idéia de uma mega ferramenta que faz tudo, porque o F-Response não é por aí. O executável do produto não deve passar de 200 Kb, para você ter uma idéia.
A grande sacada desse produto foi agregar, via rede, os discos de uma outra máquina. Com meia dúzia de clicks você consegue acessar, em modo somente-escrita, os discos remotos como se fossem discos locais. E não é só isso (isso parece aqueles anúncios de produtos que vendem na TV) ! Ele não depende de nenhuma aplicação forense em especial, pois monta os discos remotos fisicamente. Com isso, podemos usar desde EnCase, FTK, ProDiscover, até os utilitários e ferramentas disponíveis em opensource, como se os discos estivessem locais.
Pode esperar que vem uma revolução muito boa aí na forma de fazer Forense Computacional. Já não era hora. Aqui no Brasil ainda não parecemos sentir isso, porque estamos a bem da verdade engatinhando nesse terreno, mas lá fora tenho lido sobre algumas preocupações com o rumo da tecnologia versus metodologia e isso está tirando o sono de alguns. Nesse caso, o F-Response veio para ajudar, e muito ...
A boa notícia ?
Eu conheci o produto, entrei em contato com o criador dele e conversamos sobre a disponibilização desse produto no Brasil. Coloquei em contato com o Matthew um dos meus amigos aqui do Brasil, da competentíssima TI Safe, e a conversa deu Samba ! Agora temos um representante no Brasil desse produto, o que facilita muita coisa na compra e no suporte.
Dê uma olhada no site, e veja na área de representantes a bandeira verde e amarela ;)
Alguém já conhecia o produto ? Comentários ?
Até o próximo post !
Blog bem humorado, na Lingua Portuguesa, destinado a assuntos de Segurança de Informações com ênfase em Resposta a Incidentes e Forense/Investigação Computacional.
Mostrando postagens com marcador Live Acquisition. Mostrar todas as postagens
Mostrando postagens com marcador Live Acquisition. Mostrar todas as postagens
sábado, 20 de setembro de 2008
quinta-feira, 23 de agosto de 2007
E o Live Accquisition leva um TKO ...
Se estivéssemos em uma luta de boxe das boas entre a turma do Live X Dead acquisition (captura da imagem de um disco ativo e em uso pelo SO ou não), o artigo que acabei de ler representaria um bom direto de direita, daqueles de levantar a platéia e fazer o juiz abrir a contagem, com o lutador ainda se perguntando se anotaram a placa do caminhão ...
O artigo é uma apresentação do Darren Bilby, da Security Assessment, para a Ruxcon 2006. Sob o título de "Low Down and Dirty: Anti-Forensic Rootkits", o autor explora o que o mundo dos rootkits pode trazer e afetar ferramentas de captura de imagens forenses.
Na sua essência, um rootkit é um código (ou conjunto de) que tem por objetivo alterar o comportamento normal das rotinas, comandos e drivers do sistema operacional, na maioria das vezes para esconder a presença de outros códigos.
Os rootkits mais clássicos são aqueles em Unix que substituiam comandos e, dessa forma, conseguiam fazer passar despercebidos os arquivos e processos usados em ataques e invasões.
Por exemplo, o comando ps, que lista os processos executando na máquina, era substituído por um outro ps, parte do rootkit, que ao ser usado continuava listando realmente todos os processos em execução, MENOS os processos relativos ao ataque.
Rootkits mais complexos chegam a trocar e alterar códigos e device drivers diretamente no kernel do SO, e são cada vez mais difíceis de detectar. Eles se protegem de ferramentas de detecção, inclusive, interceptando chamadas e alterando o resultado, de forma a se manterem indetectáveis.
O artigo explora justamente o conceito de que um rootkit, se devidamente instalado e presente em um sistema, pode ser preparado para ser totalmente indetectável aos mecanismos usados em um software de captura de imagem. Mesmo o famoso DD poderia ser enganado com algumas técnicas, de forma a capturar não toda a mídia, mas apenas aquilo que o rootkit deixar.
O por que do nocaute técnico ? É que em uma live acquisition o rootkit estaria ativo, e portanto, alterando tudo que o DD está capturando. Em um sistema infectado por um desses, o Investigador de Forense Computacional poderia estar literalmente levando gato por lebre ...
Obviamente, na Dead Acquisition isso não acontece. O sistema não carregou o rootkit para memória, a captura ocorre normalmente e uma boa análise da imagem vai indicar a presença dos arquivos alterados que fazem parte do código maledito, como diriam alguns ... ;)
Continuo no débito do artigo do Hash com Database ...
Até o próximo post !
O artigo é uma apresentação do Darren Bilby, da Security Assessment, para a Ruxcon 2006. Sob o título de "Low Down and Dirty: Anti-Forensic Rootkits", o autor explora o que o mundo dos rootkits pode trazer e afetar ferramentas de captura de imagens forenses.
Na sua essência, um rootkit é um código (ou conjunto de) que tem por objetivo alterar o comportamento normal das rotinas, comandos e drivers do sistema operacional, na maioria das vezes para esconder a presença de outros códigos.
Os rootkits mais clássicos são aqueles em Unix que substituiam comandos e, dessa forma, conseguiam fazer passar despercebidos os arquivos e processos usados em ataques e invasões.
Por exemplo, o comando ps, que lista os processos executando na máquina, era substituído por um outro ps, parte do rootkit, que ao ser usado continuava listando realmente todos os processos em execução, MENOS os processos relativos ao ataque.
Rootkits mais complexos chegam a trocar e alterar códigos e device drivers diretamente no kernel do SO, e são cada vez mais difíceis de detectar. Eles se protegem de ferramentas de detecção, inclusive, interceptando chamadas e alterando o resultado, de forma a se manterem indetectáveis.
O artigo explora justamente o conceito de que um rootkit, se devidamente instalado e presente em um sistema, pode ser preparado para ser totalmente indetectável aos mecanismos usados em um software de captura de imagem. Mesmo o famoso DD poderia ser enganado com algumas técnicas, de forma a capturar não toda a mídia, mas apenas aquilo que o rootkit deixar.
O por que do nocaute técnico ? É que em uma live acquisition o rootkit estaria ativo, e portanto, alterando tudo que o DD está capturando. Em um sistema infectado por um desses, o Investigador de Forense Computacional poderia estar literalmente levando gato por lebre ...
Obviamente, na Dead Acquisition isso não acontece. O sistema não carregou o rootkit para memória, a captura ocorre normalmente e uma boa análise da imagem vai indicar a presença dos arquivos alterados que fazem parte do código maledito, como diriam alguns ... ;)
Continuo no débito do artigo do Hash com Database ...
Até o próximo post !
sábado, 23 de junho de 2007
Live Acquisition X Dead Acquisition
O meio mais comum de se fazer a aquisição de uma imagem forense continua sendo o boot por um live CD com utilitários de captura de imagem, desviando o arquivo para algum destino. Adaptamos o HD a ser duplicado em uma interface USB, de preferência protegido por um write-blocker, que é um dispositivo que bloqueia qualquer sinal de escrita que passe pela interface com o HD, impedindo qualquer alteração. Em geral, os CDs bootáveis dedicados a Forense Computacional (Helix, FCCU, FIRE, e outros) se preocupam em evitar qualquer escrita, mas como dizia meu avô, seguro morreu de velho... O write-blocker é um grande dispositivo para fazer investigadores dormirem tranquilos.
O processo é mais ou menos o mesmo: O investigador faz as devidas conexões, inicializa a máquina onde fará a duplicação bootando com o live CD, prepara o HD de destino e inicia a cópia.
Algumas vezes é impossível retirar o HD a ser duplicado da máquina onde ele está e nesses casos podemos reinicializar a própria máquina com o live CD. Esse processo é mais arriscado, pois é necessário assegurar que a ordem de inicialização na BIOS está devidamente alterada, indicando o CD como o primeiro device de boot. Vários artefatos poderão ser perdidos se, por engano, o HD a ser duplicado for acionado durante o boot da máquina.
Uma outra variação desse procedimento é quando não há como adaptar seguramente um HD para destino da imagem. Nesses casos é comum ter na máquina onde está sendo feita a duplicação o utilitário netcat, enviando por rede os dados para serem escritos em outra máquina, onde estará o HD de destino.
Pois bem, esses procedimentos e suas variações são conhecidos como Dead Acquisition. O HD a ser duplicado não está sendo escrito pelo sistema operacional em nenhum momento, e não apenas é o meio mais indicado para se fazer a captura, mas também o único que cobre os requisitos da RFC 3227, que dá diretrizes sobre isso, e contém as regras que tornam evidencias colhidas válidas nas cortes americanas. Entre outras coisas, dessa forma podemos atestar a validade da imagem como duplicação perfeita (bit a bit) do HD original. Em geral, funções HASH são usadas com esse objetivo.
Recentemente, acompanhei alguns posts na lista Windowsforensicsanalysis onde comentava-se sobre um outro procedimento de captura, referenciado por live acquisition. Seria um procedimento com o mesmo objetivo que os descritos anteriormente: capturar uma imagem que é a duplicação exata de um HD. A diferença dessa técnica é que o HD está em uso e montado pelo SO. Estranho, né ? Mas é válido.
Alguns motivos:
- A máquina a ser analisada é um servidor 24x7 que não pode sair do ar;
- A máquina usa uma unidade de storage ou RAID e não há drivers disponíveis que consigam acessar o seu conteúdo;
- Outros casos onde o tempo de captura é crítico.
Vale lembrar que em todos os casos discutidos, não houve comentários sobre como comprovar a duplicação exata dos dados, até porque como o HD está recebendo escritas, seu estado ao final da geração da imagem será com certeza diferente de quando o processo de captura da imagem começou, e os HASHs nunca coincidiriam. Evidências obtidas em casos como esses não seriam aceitas nas cortes americanas como provas, mas valem em investigações privadas, desde que todos estejam cientes desses detalhes e aceitem o procedimento de olho nos benefícios que ele dá.
Gostaria de ver comentários de quem já usou essa técnica. Alguém se habilita ?
Até o próximo post !
O processo é mais ou menos o mesmo: O investigador faz as devidas conexões, inicializa a máquina onde fará a duplicação bootando com o live CD, prepara o HD de destino e inicia a cópia.
Algumas vezes é impossível retirar o HD a ser duplicado da máquina onde ele está e nesses casos podemos reinicializar a própria máquina com o live CD. Esse processo é mais arriscado, pois é necessário assegurar que a ordem de inicialização na BIOS está devidamente alterada, indicando o CD como o primeiro device de boot. Vários artefatos poderão ser perdidos se, por engano, o HD a ser duplicado for acionado durante o boot da máquina.
Uma outra variação desse procedimento é quando não há como adaptar seguramente um HD para destino da imagem. Nesses casos é comum ter na máquina onde está sendo feita a duplicação o utilitário netcat, enviando por rede os dados para serem escritos em outra máquina, onde estará o HD de destino.
Pois bem, esses procedimentos e suas variações são conhecidos como Dead Acquisition. O HD a ser duplicado não está sendo escrito pelo sistema operacional em nenhum momento, e não apenas é o meio mais indicado para se fazer a captura, mas também o único que cobre os requisitos da RFC 3227, que dá diretrizes sobre isso, e contém as regras que tornam evidencias colhidas válidas nas cortes americanas. Entre outras coisas, dessa forma podemos atestar a validade da imagem como duplicação perfeita (bit a bit) do HD original. Em geral, funções HASH são usadas com esse objetivo.
Recentemente, acompanhei alguns posts na lista Windowsforensicsanalysis onde comentava-se sobre um outro procedimento de captura, referenciado por live acquisition. Seria um procedimento com o mesmo objetivo que os descritos anteriormente: capturar uma imagem que é a duplicação exata de um HD. A diferença dessa técnica é que o HD está em uso e montado pelo SO. Estranho, né ? Mas é válido.
Alguns motivos:
- A máquina a ser analisada é um servidor 24x7 que não pode sair do ar;
- A máquina usa uma unidade de storage ou RAID e não há drivers disponíveis que consigam acessar o seu conteúdo;
- Outros casos onde o tempo de captura é crítico.
Vale lembrar que em todos os casos discutidos, não houve comentários sobre como comprovar a duplicação exata dos dados, até porque como o HD está recebendo escritas, seu estado ao final da geração da imagem será com certeza diferente de quando o processo de captura da imagem começou, e os HASHs nunca coincidiriam. Evidências obtidas em casos como esses não seriam aceitas nas cortes americanas como provas, mas valem em investigações privadas, desde que todos estejam cientes desses detalhes e aceitem o procedimento de olho nos benefícios que ele dá.
Gostaria de ver comentários de quem já usou essa técnica. Alguém se habilita ?
Até o próximo post !
Assinar:
Postagens (Atom)