Uma abordagem prática sobre Computação Forense

Há poucos dias, lendo um parecer, me deparei com a seguinte afirmação:

“… o algoritmo criptográfico MD5 já foi comprometido há vários anos, sendo que há mais de 10 anos esse algoritmo é sabidamente inseguro para o fim de criação de resumos criptográficos destinados à garantia de integridade de dados. Há mais de uma década não faz mais qualquer sentido usar hash MD5 para tentar garantir a integridade de cópias forenses de dados.”

Eu estou sempre aberto a discussões e a novos pontos de vista, afinal o aprendizado é um caminho, e compartilhar é o destino. Então não me surpreendo com tal afirmação, pois já fui abordado algumas vezes sobre colisões nos hashes MD5 (Message Digest 5) e SHA-1 (Secure Hash Algorithm 1) e a impossibilidade do suas utilizações na prática forense, entretanto não é bem assim.

Os algoritmos de hash são utilizados em nossa atividade para fins de identificação, verificação e autenticação de arquivos de evidências, como imagens periciais, além da composição de hashsets, que são conjuntos de hashes como os da NIST NSRL (National Software reference Library) utilizado pelo KFF  Server da AccessData, Encase da Guidance Software, utilizados para separar arquivos conhecidos e assim diminuir o esforço de análise, indexação e pesquisa, processo esse conhecido popularmente como deNIST. Outra utilização dos hashsets é na identificação de arquivos de imagens ligadas a prática de pedofilia e outros delitos.

Em 2011, a RFC-6151 passou a não recomendar o uso do MD5 em tarefas onde a resistência a colisões fosse necessária.

“MD5 is no longer acceptable where collision resistance is required such as digital signatures. It is not urgent to stop using MD5 in other ways, such as HMAC-MD5; however, since MD5 must not be used for digital signatures, new protocol designs should not employ HMAC-MD5.” – RFC-6151

O MD5, conforme recomendações, teve seu uso comprometido para fins criptográficos como armazenamento de hashes de senha e assinaturas digitais e as colisões do SHA-1, ainda estão em nível teórico, entretanto a utilização de ambos para fins de autenticação de arquivos ainda são válidas e utilizadas largamente nos softwares forenses conforme pode ser visto nas imagens abaixo.

Pesquisas realizadas em 2004, no sentido de comprovar tais colisões, obtiveram resultados positivos para arquivos de mesmo tamanho em bytes. Posteriormente, em outras pesquisas, essa condição foi quebrada, mas em compensação o tamanho final dos arquivos deveria permanecer o mesmo após o ataque. Cumprindo os requisitos determinados na pesquisa e passado pelo MD5 o resultado obtido era o mesmo, entretanto ao passar o SHA-1, os resultados se mostravam diferentes. Ainda assim uma análise do arquivo permitiu identificar facilmente ao final do arquivo, o bloco de dados injetado, comparado ao arquivo original.

A probabilidade de colisão no MD5 é de 1 em 2^128, imagine então, o esforço computacional necessário para efetuar a injeção de um arquivo em uma imagem forense e manter seu hash MD5 inalterado?

Se fosse tão simples e comprometedor como argumentam os mais pessimistas, porque os desenvolvedores de softwares forenses continuam utilizando o MD5 e o SHA-1 para autenticar imagens forenses? Injetar um arquivo modificado em uma imagem forense e provocar uma colisão ao ponto de obter um mesmo valor de hash, mesmo que sendo o MD5, é uma tarefa que beira a ficção, pois geraria alterações dos hashes de pastas e subpastas que contivessem tal arquivo, assim como sua referência em outros arquivos de sistemas, de tal forma que obter o mesmo hash da aquisição não seria factível. Imagine, se você utilizar o MD5 em conjunto com o SHA-1, o nível de segurança será infinitamente maior, pois a colisão a ser provocada após a injeção de dados forjados em uma imagem pericial, deveria manter os valores dos hashes MD5 e SHA-1 inalterados.

Em um exemplo muito utilizado para demonstrar isso, tomemos dois algoritmos: A soma e a multiplicação.

1+1=2 e 1+2=3

A injeção de dados de forma conveniente podem provocar a colisão.

1+1+5=7 e 1+2+4=7

Como resultado da colisão temos dois conjuntos de dados com mesmo resultado, mas alterando o algoritmo a ser aplicado aos dados, teremos outro resultado.

1x1=1 e 1x2=2

Nos dados onde anteriormente obtivemos colisões, teremos um resultado bem diferente.

1x1x5=5 e 1x2x4=8

Assim podemos ver quanto é complexo comprometer dois algoritmos simultaneamente, como o MD5 e o SHA-1.

Já proteger um banco de senhas com hash MD5 é muito arriscado, pois podemos gerar uma lista de palavras em hash MD5 (rainbow tables) e promover um ataque de comparação de dicionários. Aqui a vulnerabilidade é grande, não porque o MD5 seja ruim, mas sim porque ele é muito rápido, permitindo realizar um ataque em um curto espaço de tempo. Algoritmos de hashes bons para proteger senhas, devem ser lentos.

Logo a utilização de hashes MD5 e SHA-1, na minha humilde opinião e de outros tantos profissionais da área, continua a ser válida para a autenticação de arquivos de imagens forenses.

É possível encontrar grande quantidades de artigos sobre o tema pela internet, mas apenas para ajudar, vejam os artigos a seguir:

• http://www.forensicmag.com/article/2008/12/hash-algorithm-dilemma-hash-value-collisions
• https://digital-forensics.sans.org/blog/2009/01/07/law-is-not-a-science-admissibility-of-computer-evidence-and-md5-hashes/
• http://federalevidence.com/pdf/2013/02Feb/EE-4thAmSearch-Power of Hash.pdf

Até o próximo.

Recentemente me deparei com um questionamento a um trabalho realizado há cerca de três anos, relacionado a alguns registros armazenados no arquivo System.evtx do Log de Eventos do Microsoft Windows 7. Um dos registros dizia o seguinte:

06/02/2013 12:07:25 – A hora do sistema mudou de 2013-02-06T15:07:25.500000000Z para 2013-02-06T01:51:27.510396000Z.
05/02/2013 22:51:22 – O sistema está entrando em suspensão. Motivo da Suspensão: Botão ou Tampa

Sabendo que a data e hora do registro está no padrão de horário local e as datas e horas alteradas estão no padrão UTC (Universal Time Cordinated) teríamos então, em primeira análise, que houve uma atualização de um tempo mais recente para um tempo mais antigo, ou seja, que o relógio foi atrasado para um horário anterior, não deixando claro o fato ocorrido, visto que o sistema não executaria tal ação sozinho. Observando o registro nos seus detalhes nota-se que, o sistema informa a mudança de horário no seguinte formato:

TimeCreated [SystemTime] – A hora do sistema mudou de EventData [NewTime] para EventData [OldTime]

Seria coerente se fosse ao contrário. Primeiro OldTime e depois NewTime. Sabendo que não houve manipulações do sistema, resolvi realizar uma análise mais profunda sobre o caso, até porque o objetivo inicial da perícia era outro e a citação do log de eventos tinha como único motivo demonstrar que o usuário tinha por hábito suspender o uso do computador e não desligá-lo.

Inicialmente realizei uma pesquisa em diversos sites relacionados ao suporte do Microsoft Windows e apenas em um fórum brasileiro, alguém fazia menção ao mesmo problema, imputando o fato a um usuário que supostamente obteve acesso ao servidor e realizou tal alteração. Em inglês, não havia uma linha sequer sobre o assunto, o que me deixou desconfiado do problema. Seria possível que o sistema teria sido manipulado pelo usuário e produzido tal resultado? Foquei no fórum brasileiro e li todas as dúvidas e sugestões acerca do fato e nada. Eles não haviam chegado a nenhuma conclusão.

A composição do registro do evento era estranha. Como apontar uma mudança de horário indicando primeiramente a nova hora e depois a hora antiga? Será que os campos NewTime e OldTime estavam invertidos? Qual seria o problema então? Aí você tem que ser “o perito”, essa é sua função. Antes de atribuir o problema a algo que você desconhece ou ignora, pense, analise e refaça o trabalho que está deixando tanta dúvida.

Inicialmente conferi, como disse no post anterior, o campo EventRecordID, até porque a mudança de horário alteraria o posicionamento dos registros quando classificados pelo momento da gravação do registro. Nada errado. Tudo seguia a sequência normal dos eventos, que nesse caso possuía a numeração 172401, 172402, etc.

Quando o registro é gravado no disco, possui pouco conteúdo em formato legível para humanos (human readable), sendo que sua composição é realizada pelos visualizadores, através da combinação de modelos pré-definidos armazenados em DLLs e EXEs, com os dados existentes nos arquivos EVT e EVTX . Isso é percebido claramente quando copiamos os arquivos EVT/EVTX para analisar em outro computador que não possua os mesmos softwares do computador alvo da análise, gerando mensagens do tipo:

“The description for Event ID ( xxxx ) in Source ( yyyyyy ) could not be found.
Either the component that raises this event is not installed on the computer or the installation is corrupted. You can install or repair the component or try to change Description Server.“

Como utilizei um equipamento dotado do Microsoft Windows 7 em português, e vi que nenhum site de língua inglesa fazia menção ao problema, resolvi realizar a análise detalhada da composição, trocando o sistema operacional por um Microsoft Windows 7 com idioma em inglês, afinal este tipo de evento é gerado pelo próprio sistema operacional e não por uma aplicação de terceiros instalada nele. Feito isso abri o arquivo System.evtx no snap-in do Event Viewer (visualizador de eventos) e busquei os mesmos registros, obtendo o seguinte resultado:

06/02/2013 12:07:25 – The system time has changed to 2013-02-06T15:07:25.500000000Z from 2013-02-06T01:51:27.510396000Z.
05/02/2013 22:51:22 – The system is entering in sleep. Sleep Reason: Button or Lid

Comparei então os detalhes e o formato do evento onde vi que a mensagem era composta assim:

TimeCreated [SystemTime] – The system time has changed to EventData [NewTime] from EventData [OldTime]

Um erro na tradução do pacote de idioma produzia um registro incoerente. Na tradução “to” transformou-se em “de” e “from” em “para”.

Descrição do evento em português e inglês e suas diferenças na tradução

Veja a galeria com detalhes:

Até o próximo.

Passou mais de um ano desde o último post sobre o WhatsApp. Apareceu a criptografia ponta a ponta assegurando que somente os interlocutores possam ler as mensagens e ter acesso as mídias transmitidas, impedindo a interceptação, os arquivos Crypt já estão na versão 12, e outras novidades mais.

Mas continuamos a abordar como extrair os arquivos necessários presentes no dispositivo para se obter acesso às mensagens e a chave de criptografia necessária a abrir os arquivos msgstore-yyyy-mm-dd.x.db*.

Conforme vimos no post anterior sobre o WhatsApp, os desenvolvedores do aplicativo desabilitaram a permissão de backup pelo ADB, de seus arquivos, no app manifest, exigindo a substituição do app pela versão sem a restrição de permissão de backup. Mais uma vez temos novidades com o lançamento de mais uma solução para extração da chave de criptografia. Trata-se de um script que realiza os passos do post anterior, mas de forma mais automatizada.

REQUISITOS:

• Sistema Windows Vista, 7, 8, 10, Mac OS X, Linux;
• Java;
• ADB (Android Debug Bridge);
• Ative a “Depuração USB” em “Opções do desenvolvedor”. Caso não apareça no menu, clique seguidamente na opção “Sobre o telefone\Número da versão” até efetuar o desbloqueio da “Opções do desenvolvedor”;
• Android com versão 4.0 ou superior

Preenchido os requisitos baixe os arquivos necessários aqui. Descompacte e execute o arquivo WhatsAppKeyExtract.bat, conectando o dispositivo quando solicitado. Os arquivos extraídos serão copiados na pasta /Extracted dentro da pasta onde o conteúdo foi extraído. Dentro da pasta você terá cinco arquivos, sendo o msgstore.db o arquivo com os diálogos, wa.db o arquivo com a agenda de contatos e o arquivo whatsapp.cryptkey a chave de criptografia para descriptografar os arquivos msgstore-yyyy-mm-dd.x.db.crypt12 presentes na pasta /sdcard/WhatsApp/Databases.

Eu utilizo preferencialmente o Linux como ambiente para realizar as extrações. No Windows encontro muitos problemas e até deixar o ambiente 100%, tenho um trabalho considerável.

Só para lembrar: Não é possível abrir os arquivos criptografados sem a chave utilizada para a codificação.

Até o próximo.

Recentemente fiz uma perícia em um disco rígido buscando identificar acessos à mídia após a apreensão. Entre a apreensão e a perícia oficial, se detectou diversas inicializações do sistema, e para complicar um pouco mais a situação, a máquina perdeu sua configuração do BIOS por problemas na bateria da placa-mãe. Durante a análise fiz um exame no log de eventos e classifiquei os registros por data/hora, onde me deparei com alguns registros contendo dados inconsistente com o caso, como logon sem o respectivo logoff e vice versa, em circunstâncias que haveria aquele tipo de comportamento. A análise individual dos registros mostrava nos detalhes, um campo denominado EventRecordID, onde fica registrada a sequência de gravação do registro de cada evento, não visível ao snap-in Event Viewer do Microsoft Windows.

E sua configuração padrão, o snap-in do Windows apresenta as colunas “Nível”, “Data/Hora”, “Fonte”, “Identificação do Evento” e “Categoria da Tarefa”, mas existem ainda outras quinze colunas configuráveis, mas nenhuma delas permite visualizar a sequência de registros na ordem em que foram gerados.

Utilizando uma ferramenta externa, o Event Log Explorer da FSPRO Labs, utilitário freeware para uso pessoal, abri os arquivos do log de eventos do sistema periciado e acrescentei a visualização da coluna “Record No” que corresponde ao campo EventRecordID. Classifiquei então esta coluna e lendo os registros organizados por sequencia de gravação pude perceber que o equipamento, após a sua apreensão, teve as configurações de data/hora alteradas para o instante de interesse, de forma que a teoria aventada coubesse na timeline do caso. Ficou claro que houve manipulação do equipamento antes de ser periciado de forma que pudesse incriminar um indivíduo inocente.

Nas imagens a seguir podemos ver as telas do snap-in do Windows e do Event Log Explorer mostrando um mesmo registro do evento.

Até o próximo.

Após seis meses ausente, volto a publicar novos posts. Mais uma vez o trabalho me deixou sem ter como produzir material para o blog. O laboratório de Computação Forense onde trabalho recebeu novos equipamentos e softwares, o que nos levou a dedicar mais tempo na leitura dos manuais e no teste do material recebido. Temos dois novos duplicadores da Tableau, o TD3, que permite operar através de interface web ou localmente no dispositivo, possuindo excelente performance. São mais dois bloqueadores T35u, com interface USB3, para uso em campo. Outro dispositivo que sobressai é o UFED Touch, utilizado largamente na Operação Lava Jato, responsável por extração de grande volume de dados. Quanto aos softwares estamos utilizando além do Encase da Guidance, o FTK da AccessData e o IEF da Magnetic Forensics. Associados a estes recursos vieram novas estações de trabalho, robustas, bem equipadas, hardware de primeira linha, enfim, estamos dedicando um tempo maior para nos ambientar aos novos recursos, adquiridos com recursos federais pela Secretaria Nacional de Segurança Pública, do Ministério da Justiça.

Vamos lá.