Não faz muito tempo (mais ou menos 2 anos) que foi anunciado uma quebra do algoritmo de hash SHA-1. Pois bem, a façanha foi repetida há poucos dias por uma turma de pesquisadores da Macquarie University, em Sydney, Australia.
O avanço anterior já tinha reduzido a possibilidade de colisão do algoritmo de 280 operações para algo em torno de 269. A pesquisa agora reduziu esse número a "meros" 263 , o que colocaria este esforço ao alcance de empresas com orçamento e intencionadas em se beneficiar de algum resultado obtido via colisão provocada.
Um ponto a destacar, principalmente para os alarmistas de plantão, é que ataques contra o uso de hashs em Forense Computacional ainda não são efetivos. Tais ataques, conhecido como pre-image attacks, não são ainda factíveis usando as técnicas apresentadas, nem no SHA-1 nem no MD5, conforme descrevi aqui alguns posts atrás. Apesar disso, como nossos casos podem durar anos, considero bastante válido que as ferramentas tratem de apresentar cálculos de hashs usando algoritmos com mais capacidades de bits. Eles estão chegando muito perto ...
Veja aqui o PDF do trabalho.
Comentários ?
Até o próximo post !
Mostrando postagens com marcador hash. Mostrar todas as postagens
Mostrando postagens com marcador hash. Mostrar todas as postagens
sábado, 13 de junho de 2009
segunda-feira, 6 de abril de 2009
Correlação
Correlação é a palavra do momento, em se tratando de Forense Computacional. Há algum tempo já vinham percebendo que essa é a chave para várias questões não respondidas a cerca de várias técnicas e situações comuns na área.
Correlação diz respeito a interligação. Correlação indica que há uma relação estreita em tudo que acontece, não apenas em um computador, mas em tudo o mais na vida. Vamos a um exemplo prático.
Um homem é achado morto em uma casa. O legista afirma ser difícil precisar a hora da morte, por circunstâncias diversas. No entanto, a vítima era assinante de jornal, e segundo os vizinhos, tinha hábitos costumeiros, como acordar cedo, pegar o jornal na porta e tomar seu café lendo o jornal. O fato do jornal estar amontoado na porta há 3 dias diz alguma coisa para você ? Isso é correlação. Obviamente, um fato gera tantos artefatos (ou vestígios) que devem se correlacionar entre si (nem sempre é aparente). A reunião de todos eles reconta a história ou o fato que aconteceu. Se um vizinho disser que ouviu a vítima gritando ao telefone na véspera, a correlação direta com o jornal fica abalada, e precisa inclusive ser explicada.
Uma conta atrasada sobre a estante pode ser outro ponto de correlação, se a vítima nunca atrasava aquele tipo de conta. Enfim, correlacionar significa estar atento não só ao fato em si, mas relacionar tudo que está em volta ao fato; De certa forma, devemos enxergar tudo a volta como resultado do fato.
Entendido isso, temos um ponto importantíssimo a respeito da correlação.
1) Se você só tem um único vestígio, então não há caso. Isso significa dizer que não há como provar um fato baseado em apenas um único vestígio encontrado. Na prática até dá, mas a prova careceria de força suficiente, e pode levantar muitos questionamentos. Já li sobre algumas situações onde um americano, acusado de pedofilia, se defendeu afirmando que o conteúdo fora baixado sem seu conhecimento, por um trojan.
Esse caso, inclusive, ficou conhecido como Trojan Defense, já discutido aqui no blog, e deu origem a muitas linhas de defesa onde o suspeito alegava "Não fui eu, foi um vírus". Entretanto, a perícia do caso foi incapaz de correlacionar os vestígios da máquina para fortalecer a prova. Ao que tudo indica, o cidadão foi inocentado.
2) Se você consegue correlacionar devidamente os vestígios que estão localizados, não há MD5 que prove ser mais forte. Eu tenho levantado aqui no blog uma série de questões a respeito de dificuldades de apontarmos a integridade de algumas provas. Isso porque o hash, tido como a última palavra para determinar a integridade, fica comprometido sob vários aspectos. De maneira geral, temos dificuldades em comprovar um hash quando não fazemos uma imagem completa do disco, levando apenas arquivos.
A mesma dificuldade acontece quando estamos lidando com dumps de memória, ou mesmo quando a mídia está defeituosa. Mais recentemente, há de se usar uma enorme ginástica para trabalhar com discos criptografados, e o hash entra na situação como mais um item a incomodar. Para "chutar o pau da barraca", temos a alegação de que o MD5, algoritmo mais usado para hash em Forense Computacional, já foi quebrado a algum tempo (embora eu coloque isso na categoria Orelha de Frango: Todo mundo fala de Birthday Attack no MD5, mas eu não vi ninguém me mostrar um em uma imagem de HD até hoje).
O ponto é que, correlacionando, não tem como negar nada, com ou sem MD5. Você conseguiria derrubar uma imagem forense cujo hash não bate, mas que tem tudo perfeitamente encadeado ? Eu imagino que não.
Bom, falando específicamente sobre correlações, vou dar alguns exemplos e uma sugestão ao final.
1) Uma correlação fantástica é usar o log de antivírus e o de restore point para determinar se houve alteração na data/hora da máquina. Tanto um quanto o outro são sequenciais, portanto não podem ter data/hora fora de ordem.
2) Em análises de arquivos de link (atalhos), achar apontamentos para um mesmo disco rígido com diferentes MAC Addresses pode indicar troca de placa de rede ou, o que é mais comum, que o HD já pertenceu a outra máquina.
3) O número de boots pode ser aproximado com o número de execuções de alguns itens indicados no Prefetch
4) Um arquivo PDF que teve seu MAC Times forjado pode ser descoberto se verificarmos em seus metadados a versão do PDF e correlacionarmos com a data de lançamento dessa versão. Se o atributo de Creation for anterior a tal data, convém verificar esse arquivo melhor.
Uma base de conhecimento sobre correlações seria um bom projeto para os nossos investigadores e peritos em Forense Computacional. Algo como uma Wiki, com links para programinhas que verificariam a correlação sobre uma imagem (montada ou não). Seria útil para todos e daria bastante visibilidade. Alguém se habilita ? Já temos 4 correlações simples para iniciar.
Até o próximo post !
Correlação diz respeito a interligação. Correlação indica que há uma relação estreita em tudo que acontece, não apenas em um computador, mas em tudo o mais na vida. Vamos a um exemplo prático.
Um homem é achado morto em uma casa. O legista afirma ser difícil precisar a hora da morte, por circunstâncias diversas. No entanto, a vítima era assinante de jornal, e segundo os vizinhos, tinha hábitos costumeiros, como acordar cedo, pegar o jornal na porta e tomar seu café lendo o jornal. O fato do jornal estar amontoado na porta há 3 dias diz alguma coisa para você ? Isso é correlação. Obviamente, um fato gera tantos artefatos (ou vestígios) que devem se correlacionar entre si (nem sempre é aparente). A reunião de todos eles reconta a história ou o fato que aconteceu. Se um vizinho disser que ouviu a vítima gritando ao telefone na véspera, a correlação direta com o jornal fica abalada, e precisa inclusive ser explicada.
Uma conta atrasada sobre a estante pode ser outro ponto de correlação, se a vítima nunca atrasava aquele tipo de conta. Enfim, correlacionar significa estar atento não só ao fato em si, mas relacionar tudo que está em volta ao fato; De certa forma, devemos enxergar tudo a volta como resultado do fato.
Entendido isso, temos um ponto importantíssimo a respeito da correlação.
1) Se você só tem um único vestígio, então não há caso. Isso significa dizer que não há como provar um fato baseado em apenas um único vestígio encontrado. Na prática até dá, mas a prova careceria de força suficiente, e pode levantar muitos questionamentos. Já li sobre algumas situações onde um americano, acusado de pedofilia, se defendeu afirmando que o conteúdo fora baixado sem seu conhecimento, por um trojan.
Esse caso, inclusive, ficou conhecido como Trojan Defense, já discutido aqui no blog, e deu origem a muitas linhas de defesa onde o suspeito alegava "Não fui eu, foi um vírus". Entretanto, a perícia do caso foi incapaz de correlacionar os vestígios da máquina para fortalecer a prova. Ao que tudo indica, o cidadão foi inocentado.
2) Se você consegue correlacionar devidamente os vestígios que estão localizados, não há MD5 que prove ser mais forte. Eu tenho levantado aqui no blog uma série de questões a respeito de dificuldades de apontarmos a integridade de algumas provas. Isso porque o hash, tido como a última palavra para determinar a integridade, fica comprometido sob vários aspectos. De maneira geral, temos dificuldades em comprovar um hash quando não fazemos uma imagem completa do disco, levando apenas arquivos.
A mesma dificuldade acontece quando estamos lidando com dumps de memória, ou mesmo quando a mídia está defeituosa. Mais recentemente, há de se usar uma enorme ginástica para trabalhar com discos criptografados, e o hash entra na situação como mais um item a incomodar. Para "chutar o pau da barraca", temos a alegação de que o MD5, algoritmo mais usado para hash em Forense Computacional, já foi quebrado a algum tempo (embora eu coloque isso na categoria Orelha de Frango: Todo mundo fala de Birthday Attack no MD5, mas eu não vi ninguém me mostrar um em uma imagem de HD até hoje).
O ponto é que, correlacionando, não tem como negar nada, com ou sem MD5. Você conseguiria derrubar uma imagem forense cujo hash não bate, mas que tem tudo perfeitamente encadeado ? Eu imagino que não.
Bom, falando específicamente sobre correlações, vou dar alguns exemplos e uma sugestão ao final.
1) Uma correlação fantástica é usar o log de antivírus e o de restore point para determinar se houve alteração na data/hora da máquina. Tanto um quanto o outro são sequenciais, portanto não podem ter data/hora fora de ordem.
2) Em análises de arquivos de link (atalhos), achar apontamentos para um mesmo disco rígido com diferentes MAC Addresses pode indicar troca de placa de rede ou, o que é mais comum, que o HD já pertenceu a outra máquina.
3) O número de boots pode ser aproximado com o número de execuções de alguns itens indicados no Prefetch
4) Um arquivo PDF que teve seu MAC Times forjado pode ser descoberto se verificarmos em seus metadados a versão do PDF e correlacionarmos com a data de lançamento dessa versão. Se o atributo de Creation for anterior a tal data, convém verificar esse arquivo melhor.
Uma base de conhecimento sobre correlações seria um bom projeto para os nossos investigadores e peritos em Forense Computacional. Algo como uma Wiki, com links para programinhas que verificariam a correlação sobre uma imagem (montada ou não). Seria útil para todos e daria bastante visibilidade. Alguém se habilita ? Já temos 4 correlações simples para iniciar.
Até o próximo post !
terça-feira, 10 de março de 2009
To hash or not to hash: Eis a questão
O assunto hash como comprovação de integridade veio a tona algumas semanas atrás nos blogs dos EUA. Além do já conhecido "birthday attack", foram levantadas novas polêmicas em relação a esta forma de cálculo. De certa forma, o assunto retornou porque não faz muito tempo um grupo de pesquisadores conseguiu emitir um certificado digital válido atacando vulnerabilidades do MD5. Depois do burburinho inicial, a polêmica do uso de hashs acabou por retornar.
O fato novo é que, desta vez, a discussão não parou no uso do algoritmo X, Y ou Z. De certa forma, foi mais profunda e acredito que tenha ajudado a levantar questões ainda não respondidas. Sim, porque em muitas situações, adotamos um procedimento como o correto a ser feito para todas as ocasiões, sem o menor questionamento, e acaba por ficar anos assim. Isso me lembra a estória do caminho das cabras. Há quem diga que, há alguns séculos, as cabras criavam suas próprias rotas no pasto, em busca de alimento. Os colonizadores, ao chegar, percebiam mais facilidade naquele caminho, pois a vegetação ali já estaria menos densa. Ao usá-los com frequência, acabaram por alargar a vegetação a sua volta e criaram ali as primeiras ruas. O progresso chegou e o primeiro passo foi asfaltar as ruas da tal cidade. Hoje, crianças perguntam aos avós porque determinada rua faz curva, enquanto que outras são retas e ninguém sabe a resposta. É porque aquele era o caminho das cabras ...
Pois bem, a polêmica foi boa para se repensar nos procedimentos e não ficarmos colocando asfalto sobre caminho de cabras. Um dos pontos questionados foi por que é obrigatório o uso de hash em casos de comprovação de integridade, quando os algoritmos usados já foram quebrados. É possível uma prova não ser admitida só porque alguém quebrou o algoritmo que comprovaria a sua integridade ??? E o caso de Live Forensics, onde o hash não vai ser igual porque o ambiente muda o tempo todo, já que ainda está em uso ? Houve ainda quem falasse da própria forense de memória, e que não dá para usar esta forma de comprovação de integridade.
Entre perguntas para cá e para lá, gostei muito da postura e opiniões de um dos participantes. Algo que ele ponderou, e que vale para nós brasileiros, é que não há nenhuma exigência legal de que seja usado o hash para a garantia de integridade. Isso foi um procedimento adotado e que agora precisa ser questionado. No caso americano, não haveria nenhum ponto no que eles conhecem como Dalbert Challenge que eliminaria uma prova só porque o hash dela não está idêntico. Outro ponto muito bem indicado é que a prova deve ter uma integridade estrutural por si mesma. Se ela não tiver, então não há caso. Simplificando o que ele disse, não podemos nunca basear uma conclusão em um único ponto, mas sim em um conjunto de vestígios que irão comprovar a história toda. Não podemos dizer que alguém é pedófilo porque simplesmente uma foto foi encontrada em um HD, mas poderemos se a foto estiver em um diretório particular, com algum tipo de classificação, se encontrarmos vestígios de que ela foi baixada em um site e que este site está gravado nos favoritos, ou ainda achamos atalhos no "recent documents" apontando para ela. Neste caso, é inegável a conclusão, e um hash não faria a menor falta ao processo.
O que você tem feito para constatar a integridade de dumps de memória ? E em casos onde o conteúdo só está on-line ? Ou ainda, caso seja impossível capturar toda a mídia, o que você usa como procedimento ? Comente !
Até o próximo post !
O fato novo é que, desta vez, a discussão não parou no uso do algoritmo X, Y ou Z. De certa forma, foi mais profunda e acredito que tenha ajudado a levantar questões ainda não respondidas. Sim, porque em muitas situações, adotamos um procedimento como o correto a ser feito para todas as ocasiões, sem o menor questionamento, e acaba por ficar anos assim. Isso me lembra a estória do caminho das cabras. Há quem diga que, há alguns séculos, as cabras criavam suas próprias rotas no pasto, em busca de alimento. Os colonizadores, ao chegar, percebiam mais facilidade naquele caminho, pois a vegetação ali já estaria menos densa. Ao usá-los com frequência, acabaram por alargar a vegetação a sua volta e criaram ali as primeiras ruas. O progresso chegou e o primeiro passo foi asfaltar as ruas da tal cidade. Hoje, crianças perguntam aos avós porque determinada rua faz curva, enquanto que outras são retas e ninguém sabe a resposta. É porque aquele era o caminho das cabras ...
Pois bem, a polêmica foi boa para se repensar nos procedimentos e não ficarmos colocando asfalto sobre caminho de cabras. Um dos pontos questionados foi por que é obrigatório o uso de hash em casos de comprovação de integridade, quando os algoritmos usados já foram quebrados. É possível uma prova não ser admitida só porque alguém quebrou o algoritmo que comprovaria a sua integridade ??? E o caso de Live Forensics, onde o hash não vai ser igual porque o ambiente muda o tempo todo, já que ainda está em uso ? Houve ainda quem falasse da própria forense de memória, e que não dá para usar esta forma de comprovação de integridade.
Entre perguntas para cá e para lá, gostei muito da postura e opiniões de um dos participantes. Algo que ele ponderou, e que vale para nós brasileiros, é que não há nenhuma exigência legal de que seja usado o hash para a garantia de integridade. Isso foi um procedimento adotado e que agora precisa ser questionado. No caso americano, não haveria nenhum ponto no que eles conhecem como Dalbert Challenge que eliminaria uma prova só porque o hash dela não está idêntico. Outro ponto muito bem indicado é que a prova deve ter uma integridade estrutural por si mesma. Se ela não tiver, então não há caso. Simplificando o que ele disse, não podemos nunca basear uma conclusão em um único ponto, mas sim em um conjunto de vestígios que irão comprovar a história toda. Não podemos dizer que alguém é pedófilo porque simplesmente uma foto foi encontrada em um HD, mas poderemos se a foto estiver em um diretório particular, com algum tipo de classificação, se encontrarmos vestígios de que ela foi baixada em um site e que este site está gravado nos favoritos, ou ainda achamos atalhos no "recent documents" apontando para ela. Neste caso, é inegável a conclusão, e um hash não faria a menor falta ao processo.
O que você tem feito para constatar a integridade de dumps de memória ? E em casos onde o conteúdo só está on-line ? Ou ainda, caso seja impossível capturar toda a mídia, o que você usa como procedimento ? Comente !
Até o próximo post !
segunda-feira, 23 de julho de 2007
Nosso Amigo Hash - Parte III
Hash aplicado na Forense Computacional - Prática
Vamos agora partir para exemplos práticos de uso do hash. Para facilitar, vou fazer referência aos exemplos já citados no post anterior (Parte II).
O primeiro passo é obter um utilitário que faça o cálculo do hash. Existem alguns disponíveis, tanto para o algoritmo MD5 quanto para o SHA-1.
Usaremos o MD5Sum.exe, que pode ser baixado aqui
Esse programa tem um uso muito simples:
c:>md5sum arquivo.txt
763430d9cf670bb98094c15f9288ca75 *arquivo.txt
O arquivo.txt é qualquer arquivo, com qualquer conteúdo. Fotos, mp3, executáveis, enfim, qualquer informação pode existir nos arquivos.
Primeiro exemplo - Integridade de Arquivos transmitidos:
- João calcula o hash MD5 de um arquivo
c:>md5sum relacao.xls
3f39881820bdd7bdb842af37224daedc *relacao.xls
- e envia o arquivo por e-mail para José.
- Logo em seguida, liga para ele e dita o resultado (3f39881820bdd7bdb842af37224daedc).
- Assim que José recebe o e-mail, ele computa o hash MD5 novamente e confere com o valor anotado. Se for igual, o arquivo está integro.
Segundo exemplo - Integridade de arquivos baixados de um site:
- João visita o site da e-fense para fazer o download da imagem-iso do Helix. Após o download, ele computa o hash do arquivo e verifica se o valor é o mesmo do indicado no website
Terceiro exemplo - Comprovando a integridade das ferramentas:
O CD do Helix traz a relação de hashes MD5 para cada ferramenta usada. No caso de usar as ferramentas a partir de um CD, obviamente que um código malicioso não conseguiria alterá-las. Porém, imaginando que tenhamos um pen drive com as ferramentas, essa alteração pode acontecer.
Para detectar qualquer alteração indevida nas ferramentas, é interessante antes do uso aplicar o MD5Sum no diretório das ferramentas e comparar os resultados com a lista criada anteriormente:
e:/tools>md5sum *
ce338fe6899778aacfc28414f2d9498b *rrr.exe
ce338fe6899778aacfc28414f2d9498b *qqq.bat
3f39881820bdd7bdb842af37224daedc *www.EXE
3f39881820bdd7bdb842af37224daedc *yyy.EXE
1c17da341aa184c96a5f305cca04871f *xxx.exe
Na próxima, continuarei com os exemplos de integridade da imagem de um HD.
Até o próximo post !
Vamos agora partir para exemplos práticos de uso do hash. Para facilitar, vou fazer referência aos exemplos já citados no post anterior (Parte II).
O primeiro passo é obter um utilitário que faça o cálculo do hash. Existem alguns disponíveis, tanto para o algoritmo MD5 quanto para o SHA-1.
Usaremos o MD5Sum.exe, que pode ser baixado aqui
Esse programa tem um uso muito simples:
c:>md5sum arquivo.txt
763430d9cf670bb98094c15f9288ca75 *arquivo.txt
O arquivo.txt é qualquer arquivo, com qualquer conteúdo. Fotos, mp3, executáveis, enfim, qualquer informação pode existir nos arquivos.
Primeiro exemplo - Integridade de Arquivos transmitidos:
- João calcula o hash MD5 de um arquivo
c:>md5sum relacao.xls
3f39881820bdd7bdb842af37224daedc *relacao.xls
- e envia o arquivo por e-mail para José.
- Logo em seguida, liga para ele e dita o resultado (3f39881820bdd7bdb842af37224daedc).
- Assim que José recebe o e-mail, ele computa o hash MD5 novamente e confere com o valor anotado. Se for igual, o arquivo está integro.
Segundo exemplo - Integridade de arquivos baixados de um site:
- João visita o site da e-fense para fazer o download da imagem-iso do Helix. Após o download, ele computa o hash do arquivo e verifica se o valor é o mesmo do indicado no website
Terceiro exemplo - Comprovando a integridade das ferramentas:
O CD do Helix traz a relação de hashes MD5 para cada ferramenta usada. No caso de usar as ferramentas a partir de um CD, obviamente que um código malicioso não conseguiria alterá-las. Porém, imaginando que tenhamos um pen drive com as ferramentas, essa alteração pode acontecer.
Para detectar qualquer alteração indevida nas ferramentas, é interessante antes do uso aplicar o MD5Sum no diretório das ferramentas e comparar os resultados com a lista criada anteriormente:
e:/tools>md5sum *
ce338fe6899778aacfc28414f2d9498b *rrr.exe
ce338fe6899778aacfc28414f2d9498b *qqq.bat
3f39881820bdd7bdb842af37224daedc *www.EXE
3f39881820bdd7bdb842af37224daedc *yyy.EXE
1c17da341aa184c96a5f305cca04871f *xxx.exe
Na próxima, continuarei com os exemplos de integridade da imagem de um HD.
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)