Técnicas forenses computacionais e a resposta a Incidentes: coleta do conteúdo da memória física em sistemas Linux

A contínua evolução e popularização observadas nas últimas décadas em sistemas computacionais em baixa plataforma, demonstra que tais sistemas se tornaram cada vez mais imprescindíveis às pessoas e aos negócios. É notório que a crescente demanda e dependência dos computadores e dos serviços informáticos os tornaram também alvos e instrumentos para as mais diversas práticas delituosas.

O ordenamento jurídico brasileiro assevera os crimes cibernéticos como próprios ou impróprios. Simplificadamente, pode-se entender o crime cibernético próprio como um crime onde o bem jurídico tutelado é a informática, a exemplo do defacement (descaracterização) de um website ou da destruição de uma base de dados. Já o crime cibernético impróprio se utiliza dos recursos informáticos como auxiliares para prática de ilícitos, a exemplo do uso de phishing scam em condutas fraudulentas, ou o uso de mídias sociais em ataques a contra a honra.

A perícia forense computacional, analogamente à perícia forense “tradicional”, também tem a preservação como um de seus principais pilares, dada a necessidade de garantir a integridade da evidência digital a ser coletada.

Os procedimentos periciais executados em sistemas em produção, também referidos como in vivo, podem produzir relevantes evidências normalmente não disponíveis em análises post-mortem, tais como a identificação dos processos em execução no host alvo, listagem das conexões de rede ativas, inventário dos comandos executados pelos usuários do sistema e hashes de senhas den­tre outras. Assim sendo, a perícia forense computacional in vivo pode oferecer expressiva contribuição também para o esclarecimento de incidentes de segurança, e desta maneira, para o fortalecimento das políticas e processos relacionados à segurança da informação em ambientes corporativos.

Entretanto, fatores como a dinâmica e a alta volatilidade das evidências digitais podem tornar sua preservação um grande desafio para o investigador. Edmond Locard (1877-1966), cientista forense do início do século XX, postulou um dos princípios fundamentais da ciência forense, conhecido como o Princípio da Troca de Locard (Locard Exchange Principle, 1920), o qual, de forma bastante sucinta, afirma que todo contato deixa vestígios, assim sendo, tem-se: de um lado o autor do delito deixando vestígios de sua passagem no local de crime, e de outro, o autor do delito levando consigo vestígios de sua permanência ou ações no local de crime, no caso, um sistema computacional.

Considerando-se ainda o Princípio da Incerteza de Heisenberg, a partir do qual é sabido ser essencialmente impossível a coleta de todas as informações armazenadas em um computador, torna-se imprescindível, então, a correta abordagem ao sistema-alvo a fim de maximizar o volume de evidências coletadas.

Neste sentido, cabe enfatizar o correto planejamento que deverá preceder a execução do dump da memória volátil (RAM), tomando-se como referência a efemeridade da evidência digital, conforme descrito por Farmer e Venema (2011) como Ordem de Volatilidade dos dados (tabela 1).

Em termos práticos, a coleta das evidências residentes na RAM depende de um módulo a ser nela carregado. Toma-se aqui como referência o Linux Memory Extractor (LiME), um módulo carregável do kernel (Loadable Kernel Module – LKM) desenvolvido para aquisição do conteúdo da memória volátil em sistemas Linux e derivados, como o Android, que tem como compromisso minimizar a interação entre o usuário e os processos executados em kernel space ao longo do processo de aquisição; característica que, aliada ao fato de possibilitar o armazenamento remoto do dump via rede, contribui para a preservação do ambiente e, assim, das evidências neste contidas. Entretanto, da Ordem de Volatilidade vem a impossibilidade de execução dos procedimentos necessários à produção do LKM no próprio objeto questionado (host sob investigação), dada a consequente contaminação e potencial perda de evidências resultantes.

Recomenda-se, portanto, a condução de tais procedimentos em ambiente virtual (VM) implementado na estação de trabalho do investigador, executando a mesma versão do kernel executada pelo objeto questionado; transferindo-se ao final do processo, o módulo produzido para o objeto questionado.

A figura 1 abaixo ilustra as linhas gerais relacionadas ao processo de dump do conteúdo da RAM, cabendo ainda destacar que, embora o foco aqui recaia sobre a parte dos trabalhos relacionados ao segmento de tecnologia da informação, a validade e aceitabilidade dos resultados obtidos depende diretamente do alinhamento legal. Assim sendo, é necessário que a condução dos trabalhos seja feita à luz de modelos de referências e práticas reconhecidas e alinhadas com o ordenamento jurídico. Frente a isto, adota-se como modelo de referência, embora de forma bastante discreta e simplificada, o EDRM (Electronic Discovery Reference Model), também em função de sua íntima ligação e aplicabilidade aos ambientes corporativos – foco deste artigo.

A figura 2 oferece uma visão geral dos procedimentos para da coleta de evidências digitais.

Das figuras 1 e 2, sugere-se que, após efetivamente confirmado o incidente de segurança e mediante o aval do time de resposta a incidentes, seja iniciada a fase de investigação do ocorrido.

Identificado o objeto questionado e o kernel em execução neste, é possível, então, a criação de uma máquina virtual na estação de trabalho do investigador, que execute o mesmo kernel verificado no objeto questionado, embora esta máquina virtual não necessariamente tenha de ser baseada na mesma distribuição implementada no objeto questionado.

O LiME deverá ser baixado da Internet e compilado neste ambiente virtual, produzindo o LKM, que por sua vez deverá ser copiado pelo investigador a partir do objeto questionado, utilizando-se de uma conexão segura (SSH).

Vale ressaltar:

• O cliente SSH é instalado por padrão pela maioria das distribuições Linux quando da implementação desta.
• A compilação do LiME depende da prévia instalação de pacotes complementares no ambiente virtual (VM), por exemplo: os pacotes build essential e linux-headers-(<release-do-kernel>) em sistemas baseados no Debian.

Por meio do destaque [1] da figura 3 é possível observar que a compilação do LKM é muito simples, necessitando apenas a execução do comando make; o destaque [2] mostra que o LKM produzido foi renomeado de lime.ko para lime-3.16.0-4-amd64.ko, desta maneira explicitando à qual kernel ele deverá ser aplicado, no caso, kernel versão 3, release 16 (estável), micro number / patch level 0-4, plataforma 64 bits.

Vale destacar ainda que, embora o host utilizado para compilação do LKM (estação de trabalho do investigador) fosse um Debian 8.1 (Jessie), para efeito da prova do conceito, o objeto questionado executava uma distribuição diferente (Point Linux), entretanto, com o mesmo kernel.

Com o auxílio do netcat, uma porta (4500) foi aberta na estação de trabalho do investigador, a fim de permitir ao objeto questionado se conectar para transferência e armazenamento do dump da RAM.

Do destaque [1] da figura 4 é possível verificar o uso do SCP para download do LKM a partir da estação de trabalho do investigador, e na sequência, o carregamento deste para a RAM (destaque [2]); vale ressaltar a abertura de um segundo terminal (destaque [3]), responsável por conectar a instância do LiME à porta aberta pelo netcat na estação do investigador, possibilitando, assim, o armazenamento remoto do dump neste último.

A figura 5 ilustra uma parte dos resultados obtidos pelo Volatility quando da análise do dump da RAM, onde é possível observar o histórico dos comandos executados no objeto questionado.

A figura 6 ilustra parcialmente a árvore dos processos em execução no objeto questionado quando do dump da RAM.

Tome-se agora como exemplo prático, um cenário onde um rootkit é instalado com sucesso em um servidor HTTP, conforme ilustrado no cenário da figura 7.

Basicamente, rootkits são um tipo de malware destinado a garantir ao atacante a manutenção do acesso privilegiado obtido após um ataque com sucesso ao sistema alvo, ou ainda, à ocultação da presença de outros códigos maliciosos implementados no sistema como resultado deste ataque. Os chamados “rootkits de aplicativo” subvertem ferramentas básicas (binários) do sistema alvo a fim de ocultar do usuário e dos mecanismos de proteção do sistema, sua presença e suas ações.

Por exemplo, ao subverter o binário ls, as listagens de arquivos e diretórios solicitadas pelo usuário não mais exibiriam os arquivos relacionados  ao rootkit.

Além deste binário, pode-se elencar dentre outros comumente modificados pelos rootkits:

• O ps: para ocultação de seus processos;
• O netstat e lsof: para ocultação de suas conexões;
• O sshd: para ocultação dos acessos remotos promovidos por eles;
• O w e who: para ocultação da presença de algum usuário;
• O su: para escalação de privilégios no sistema alvo.

Frente ao exposto, é possível concluir que também os registros (logs) do sistema alvo serão manipulados pelos rootkits, e que sob tais circunstâncias, as evidências e trilhas de auditoria obtidas por meio de técnicas tradicionais e ferramentas nativas do sistema não serão confiáveis.

Todavia, o conteúdo residente na memória (RAM) não pode ser manipulado pelo rootkit sob pena de corrompimento de dados ou processos em execução, tornando-se recomendável, portanto, o emprego de técnicas forenses e o dump da memória volátil a fim de se coletar com a devida integridade, informações ocultadas ou manipuladas por ferramentas do sistema operacional que tenham sido subvertidas.

Isto posto, a partir da estação de trabalho do investigador (figura 7) foram extraídas as strings existentes no dump da memória RAM do servidor HTTP (objeto questionado), utilizando-se para tal de ferramenta com o mesmo nome, obtendo-se desta maneira as seguintes informações (evidência 1):

• Às 21:41:29hs do dia 24 de março do corrente ano [1], o host Betsy [2] – objeto questionado, foi remotamente acessado via SSH [3], tendo a conexão sido originada pelo host0.33.7 [5], se utilizando do username sshuser [4], sendo a referida conexão encerrada pelo próprio usuário [7] às 21:42:31 da mesma data [6]. O endereço IP registrado pela evidência sugere ter a referida conexão sido originada na mesma rede onde reside o sistema alvo, e ainda, que esta conexão poderia ser um simples teste de acessibilidade ao alvo, dada sua breve duração.  Aliando-se a tais fatos o horário da ocorrência, os vestígios apurados poderão configurar indício das ações de um insider.

• A partir agora, de nova pesquisa no arquivo com as strings extraídas do dump da RAM, foi possível também a obtenção do hash da senha vinculada ao username sshuser (evidência 2).

Com auxílio do crunch, ferramenta bastante difundida para criação de dicionários, foi criada a wordlist (evidência 3, destaque [1]) utilizada conjuntamente com o John the Ripper – aplicação para descoberta de senhas fracas por meio dos respectivos hashes, assim obtendo-se a senha vinculada ao username sshuser (evidência 3, destaque [2]).

Dentre outras possibilidades, a posse da credencial completa utilizada para acesso ao servidor HTTP, alvo do ataque, permitirá a comparação desta com o determinado pelas políticas de segurança e procedimentos da empresa para criação de credenciais de usuário.

A eventual falta de conformidade entre os padrões definidos pela empresa e a credencial verificada, poderá reforçar a hipótese de um insider haver criado um novo usuário para acesso ao servidor HTTP, o qual seria camuflado pelo rootkit implantado neste servidor.

Naturalmente, tendo este trabalho o objetivo de oferecer uma visão geral em relação à perícia forense computacional, faz-se necessário que os conceitos aqui abordados sejam devidamente aprofundados e complementados antes de aplicados a demandas reais.

Finalmente, vale mais uma vez destacar a necessidade de alinhamento entre a parte tecnológica e os aspectos jurídicos, a fim de que os resultados obtidos ao final dos trabalhos periciais sejam confiáveis e lícitos em toda sua extensão, garantindo assim, a legitimidade necessária às evidências produzidas.

Referências:

• CORBET, J.; RUBINI A.; KROAH-HARTMAN, G. Linux Device Drivers 3.ed. California: O’Reilly Media, Inc., 2005.
• DULAY, N. Memory Organisation – CPU Organisation and Operation –Introduction to Assembly Programming. Imperial College London. Disponível em: <https://www.doc.ic.ac.uk/~eedwards/compsys/ 0_Notes2_MemoryCPU.do>. Acesso em: 6 abr. 2018.
• EDRM Duke Law. EDRM Model. Disponível em: <http://www.edrm.net/ frameworksand-standards/edrm-model/>. Acesso em: 10 mar. 2018.
• FARMER, D.; VENEMA, W. Perícia Forense Computacional – Teoria e Prática Aplicada 4a reimp., 2011 São Paulo: Pearson Prentice Hall, 2007.
• HALE–LIGH, M.; CASE, A.; LEVY, J.; WALTERS, A. The Art of Memory Forensics. Detecting Malware and Threats in Windows, Linux, and Mac Memory. Indianapolis: John Wiley & Sons Inc., 2014.
• LiME. Linux Memory Extractor. Disponível em <https://github.com/ 504ensicsLabs/LiME>.  Acesso em: 6 abr. 2018.
• VOLATILITY PROJECT. Volatility Foundation. Disponível em: <http://www.volatilityfoundation.org/>. Acesso em: 6 abr. 2018.
• CERT.Br. Cartilha de Segurança na Internet. Disponível em < https://cartilha.cert.br/malware/>. Acesso em 8 abr. 2018.