quinta-feira, 20 de dezembro de 2007

Processo do Clã MacLeod

Estava lendo um artigo do Andreas Schuster, um dos Papas no assunto de Forense da Memória de sistemas Windows.

O artigo apresenta vários conceitos básicos não apenas a respeito da importância de se fazer forense da memória, mas também indicando que em alguns casos a memória será a única a conter o artefato que pode trazer luz ao caso sendo investigado.

Lá pelas tantas do artigo, Schuster abre um tópico sobre a persistência dos dados na memória principal. Ele mostra estudos e estatísticas de máquinas que ficaram com informações disponíveis até 14 dias após o processo ter terminado !

Sendo mais claro: Em muita situações, você poderá executar comandos e utilitários que farão um instantâneo da máquina. Esses comandos, muito comentados em operações de Resposta a Incidentes, falam da situação atual da máquina. Em geral, eles não estão preparados para dar informações sobre um processo que já foi finalizado, por exemplo. Imagine que o tal era exatamente o elo que você buscava e, descobrindo-o, todas as dúvidas a respeito do caso seriam resolvidas. Mas o problema continua, porque você só tem na mão a foto do sistema, que foi tirada no momento em que o processo vilão já tinha saído de cena.

O que o Schuster apurou é que, devido a forma como as memórias Windows são gerenciadas, ele conseguiu obter informações de processos depois de muito tempo que foram terminados. Na situação-exemplo acima, uma análise forense da imagem da memória iria revelar o processo vilão.

Não pense que o ilustre pesquisador ficou satisfeito. Ele sacou algo inicialmente dito pela dupla de também gurus da Forense Computacional Farmer e Venema, que nem todos os computadores zeram a memória principal quando estão reiniciando. Isso depende mais da codificação da BIOS do que do sistema operacional, mas não há especificação que obrigue a isso, embora a maioria o faça. Consequências ??? Simplesmente, em suas pesquisas, ele descobriu processos com datas anteriores ao reboot da máquina ! No artigo ele mostra um deles, que resistiu bravamente a três reinicializações.

Estamos frente a um processo Highlander !!! 8-))

Brincadeiras a parte, as informações sobre o processo ultrapassaram as reinicializações, o que aumenta o valor da investigação em imagens da memória, não ?

Gostaria de ver comentários a respeito disso. Você já pesquisou algo parecido ? Já encontrou resultados que apontassem isso em investigações ?

Até o próximo post !

4 comentários:

Marcelo disse...

Ola Tony, leio seus posts com frequencia. Em relacao a esse ultimo sobre persistencia de dados na memoria apos reinicializacao, tenho algumas duvidas que talvez possa me ajudar. Q opcao de BIOS que controla isso e nao o OS? Durante a coleta de conteudo de memoria, esses dados seriam vinculados `a um processo anterior mesmo se este ja tivesse sido finalizado? Um abraco e Feliz Natal

Tony Rodrigues disse...

Marcelo,

Também achei essa situação muito esquisita, mas pesquisa é pesquisa, e os tais que falaram são super conceituados.
Bom, vou voltar um pouco no assunto para explicar melhor.

O gerenciamento de memória do Windows prevê alguns metadados para identificar o que está acontecendo. Um desses metadados é um objeto chamado EPROCESS que armazena, entre outras coisas, a data/hora de ativação do processo. Esses objetos ficam em uma lista duplamente encadeada, ou seja, enquanto estão ativos, eles tem um ponteiro apontando para o próximo processo e outro para o anterior.
Quando um processo termina, essas estruturas são retiradas da lista dupla e ficam marcadas como memória disponível. Ou seja, a memória não é zerada quando não está em uso, aquele espaço simplesmente fica marcado como disponível, criando uma situação muito parecida com a deleção de um arquivo.
Ao estudar um dump de memória, é possível localizar essas estruturas EPROCESS e montar um gráfico indicando quem é o pai de quem, e se os processos que elas descrevem estavam ativos ou não. Recuperando-se essas estruturas pode-se chegar às informações de data/hora que o processo foi iniciado. Está tudo lá no EPROCESS dele.
De acordo com o artigo, uma das rotinas de inicialização da máquina, na BIOS, seria zerar todo o conteúdo da memória principal antes de iniciar a carga do SO. Não fazendo isso, ficamos com trechos de memória marcados como liberados, mas que contém ainda informações anteriores ao boot. Esses trechos ficarão lá até serem sobrepostos por outros dados, mas vale dizer que o artigo cita ter encontrado informações de até 14 dias antes, o que mostra que os dado podem ficar muito tempo até serem sobrescritos.
Outro ponto de sua pergunta: O artigo que eu citei não entra em detalhes, mas não entendi como sendo uma opção da BIOS, da qual poderíamos configurar, e tal. Entendi que é uma implementação possível, uma escolha do fabricante, já que não há um padrão para isso.

Se continuar com dúvidas, fique a vontade para perguntar mais. Só aprendemos mesmo quando compartilhamos o conhecimento, não é verdade ?
Feliz Natal prá vc !

Augusto disse...

Não sei se tem muito a ver, mas li uma vez que as placas de rede também armazenam logs internos, para saber quando foram desligadas e ligadas...e estes logs não são apagados quando reinicia a máquina. Existiria algum consenso entre os dois? Uma dúvida, o processo que ficou alocado, é um processo de aplicação de terceiros, ou algo do próprio windows?? um cvhost.exe da vida, hehehe :)
Abs[]

Tony Rodrigues disse...

Augusto,

Nunca ouvi falar desse log, e não me lembro de ter visto nenhum projeto de NIC com componentes que tivessem essa funcionalidade. O mais próximo que li sobre isso foi o buffer que a NIC implementa usando memórias. Mas não seria algo relativo ao que comentei no artigo.

O processo não ficou alocado. O que aconteceu, na verdade, foi que as informações sobre esse processo, que estava rodando antes do boot, ficaram disponíveis na memória depois do boot, não sendo sobreescritas. E, realmente, eram de um processo do Windows, mas não tem relação com o caso. Poderia ser qualquer outro que estivesse naquela localização específica.

Abraço,