Sparse Files

Li recentemente um artigo interessante, relacionando arquivos esparsos com possíveis problemas para Forense Computacional. Antes de comentar, vou explicar alguns detalhes do artigo.

Arquivos Esparsos

Presente em alguns sistemas de arquivos, tais como o NTFS, arquivos esparsos seriam arquivos muito grandes, mas com pouca informação. Ao marcar um arquivo com essas características como esparso, a parte do arquivo sem informação fica desalocada no sistema de arquivos.

Vamos usar como exemplo um grande arquivo criado com 500 Gb para servir de disco virtual. Logo nos primeiros momentos de uso desse arquivo, vamos supor que acrescentamos informações da ordem de 10Mb. Apesar do arquivo ter apenas essa quantidade de informação real, ele continuará alocando e gastando os 500 Gb. As partes não utilizadas deverão estar cheias de zeros.

No entando, se esse arquivo estiver marcado como esparso, a parte não utilizada será liberada para ser alocada. O espaço consumido real do arquivo será de 10Mb. Na prática, quando o sistema operacional lê um arquivo esparso na parte não utilizada (comumente chamada de "buraco"), ele retorna como se estivesse lendo zeros.

Os arquivos esparsos são comuns para implementação de discos virtuais, bancos de dados, logs e qualquer outro tipo de arquivo que pré-aloca uma grande quantidade de disco, mas não a usa imediatamente.

Problemas com Forense Computacional

O problema apresentado por essa funcionalidade, em relação a Forense Computacional, está ligado diretamente à comprovação de integridade. Explico: imagine dois arquivos de 500Gb, ambos com 10Mb idênticos criados, um deles normal e o outro criado como esparso.

Se extrairmos ambos os arquivos a partir do seu volume, montando-os setor a setor, os hashes que iremos obter a partir disso indicarão que os conteúdos são diferentes. Enquanto que a parte que não contém informação real de um arquivo normal contém zeros, essa mesma parte de um arquivo esparso contem informação que na verdade pode pertencer a outros arquivos.

Porém, se ao invés de extrairmos esses arquivos, nós aplicarmos algoritmos de hash diretamente pelo sistema de arquivos (acessando-os com a imagem montada), os hashes de ambos serão idênticos pelo que já mencionei acima: a parte que não contém informação real de um arquivo esparso é tratada como se estivesse zerada. Conclusão: os arquivos são diferentes, mas o hash de ambos, feito pelo sistema de arquivos, diz que eles são iguais.

Agora sim, as considerações

Após explicado os detalhes do artigo, o autor destaca dois possíveis problemas:

1) Perda de informações sigilosas: Alguém mal intencionado rouba informações sigilosas e cria dois arquivos grandes com elas, um esparso e outro não. Ele copia o arquivo esparso para um pen-drive e logo em seguida troca, na origem, o arquivo esparso pelo normal. Se, por algum motivo, a operação for descoberta, pode ser alegado que o arquivo jamais caberia em mídias transportadas, como um pendrive.

2) Denial-of-Service: Alguém pode criar um grande arquivo normal, e colocá-lo no servidor, consumindo seus recursos de disco e causando a parada do sistema. Logo depois, o atacante substitui o arquivo normal por uma versão esparsa e alega que criou um arquivo esparso.

Nas duas situações, o hash como verificador de integridade vai corroborar com as alegações.

Você consegue imaginar outras situações onde poderíamos ter problemas ?

Um outro ponto que me prendeu a atenção foi que esse é mais um dos problemas de Forense Computacional criados por novas funcionalidades dos sistemas de arquivo. Há muito já vem se falando das Alternate Data Streams, e agora mais essa. Gostaria de saber o que você acha que pode ser feito para ter mais arquitetos e engenheiros de software comprometidos não apenas com as funcionalidades e versatilidades milagrosas, mas também com a Segurança das Informações.

Aguardo comentários. Até o próximo post !