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 !