Avançar para o conteúdo principal
BlogSegurançaLinode Security Digest 23-30 de Janeiro de 2022

Linode Security Digest 23-30 de janeiro de 2022

Linode Security Digest

Esta semana, vamos cobrir um novo espécime de malware chamado Sysjoker e um guia para perícia de memória Linux. Embora o guia forense não seja abrangente e certamente não esteja em todos os detalhes, poderá ajudar a compreender os princípios básicos de um processo de extracção e análise de memória usando a Volatilidade.

Sysjoker Backdoor

Numa recente post por Intezeros autores analisaram uma nova porta traseira capaz de funcionar em múltiplos sistemas operativos. De acordo com a análise, "Sysjoker" pode correr em macOS, Linux e Windows. Sysjoker esconde-se como uma actualização do sistema e usa diferentes métodos para esconder e alterar o endereço IP do seu servidor de Comando e Controlo (C2).

Também é preocupante o facto de a amostra ter vindo limpa das varreduras VirusTotal, o que pode indicar que a porta traseira é bastante nova. Embora os métodos que utiliza para infectar um sistema sejam diferentes em vários sistemas operacionais, uma vez que ganha persistência num sistema, começa a comunicar com o servidor C2. Na análise, o Intezer afirma que ainda não viu uma instrução da próxima fase do servidor C2. O post sugere a utilização de scanners de memória para detectar o malware.

Outra forma de fazer análise forense é deitar fora a memória e analisá-la com uma ferramenta bem conhecida como a Volatilidade. Nas versões mais antigas do kernel Linux, o despejo da memória podia ser conseguido copiando a memória virtual de /dev/mem usando uma ferramenta de linha de comando como a dd; contudo, este método foi depreciado devido a potenciais implicações de segurança. 

Forense de Memória Linux

Podemos resumir a análise forense como os diferentes métodos utilizados na aquisição de provas, análise de provas, e documentação das consequências de um incidente de segurança. Após uma quebra de segurança confirmada, uma análise forense tem geralmente lugar para compreender melhor o que se passou num sistema comprometido. Existem numerosas fontes de provas que pode analisar para fazer alegações defensáveis sobre a origem de um incidente; no entanto, apenas faremos uma análise prática da memória de um sistema Linux comprometido para demonstrar algumas das metodologias e ferramentas que pode utilizar.

Memória

A RAM, por natureza, é volátil. Exige potência constante para passar por ela para funcionar, e é reiniciada sempre que um sistema é reiniciado. O Linux mantém os dados armazenados na memória sob o directório /dev/mem; contudo, é impossível extrair artefactos da memória utilizando esta partição directamente em distribuições mais recentes. Isto porque a partir do kernel 4.16 do Linux, uma opção(CONFIG_STRICT_DEVMEM) é activada por defeito para impedir o acesso a esta partição sensível. 

Embora isto dificulte a aquisição da imagem de memória, também torna mais difícil para os adversários (e utilizadores inexperientes) causar danos devastadores ao sistema. Um atacante com acesso à raiz do sistema pode utilizar o dispositivo mem para injectar código directamente no kernel se esta opção for desactivada.

Para esta demonstração, criámos um Linode Debian 9 com o nome de anfitrião "forensics" num dos nossos centros de dados. Configurámos a caixa forense para ser um exemplo de um ambiente de construção e análise. Embora não seja necessário fazê-las numa máquina externa, a adulteração de um computador que contenha provas é desaconselhável. Aqui estão os passos para a nossa análise:

  1. Criar um perfil de Volatilidade para um sistema comprometido utilizando uma máquina com o mesmo SO e kernel build/version.
  2. Despeje a memória com a ferramenta da sua escolha (AVML nesta demonstração).
  3. Inspeccione a memória despejada utilizando o perfil que criou para a Volatilidade com a ajuda de plugins.

Advertência

Utilizaremos o repositório Python 2 de Volatilidade para fins de demonstração devido às questões de compatibilidade actualmente em curso com a Volatilidade 3. Estamos cientes de que o apoio a Python 2 terminou em 2020; isto é estritamente para demonstrar a utilização da ferramenta num ambiente controlado. Se quiser acompanhar o guia, faça-o por sua conta e risco.

Requisitos

Por defeito, Debian 9 Linodes não terá algumas das ferramentas que vamos utilizar nesta demonstração. Recomenda-se a instalação de todas elas com o seguinte comando antes de proceder com outras instruções:

sudo apt install make git zip dwarfdump linux-headers-$(uname -r) python-pip python-distorm3 python-crypto

Volatilidade

O Volatility Framework é uma colecção completamente aberta de ferramentas implementadas em Python sob a GNU General Public License para extrair artefactos digitais de amostras de memória volátil (RAM).

É importante assegurar que o perfil de Volatilidade correcto é utilizado quando se analisa um depósito de memória. Um perfil é um ficheiro que contém informação sobre a estrutura de dados de um kernel e símbolos de depuração que podem ser utilizados para analisar correctamente uma imagem de memória. Felizmente, a criação de um perfil com Volatilidade é bastante simples. Também se pode verificar o repositório de perfis de Volatilidade para alguns perfis pré-construídos.

Construir um perfil

Após a instalação das ferramentas necessárias, podemos começar a construir o nosso perfil de Volatilidade para a máquina em que está a funcionar.

1. git clone https://github.com/volatilityfoundation/volatility ~/volatility
2. cd ~/volatility/tools/linux/
3. make
4. zip ~/$(lsb_release -i -s)_$(uname -r).zip ./module.dwarf /boot/System.map-$(uname -r)
5. cp ~/$(lsb_release -i -s)_$(uname -r).zip ~/volatility/volatility/plugins/overlays/linux/
6. python ~/volatility/vol.py --info

A linha inicial (1) irá clonar o repositório de Volatilidade no directório home do utilizador. Entrando no directório (2) ~/volatility/tools/linux, podemos utilizar o make (3) para recompilar os módulos do kernel. É importante que os cabeçalhos do kernel sejam descarregados previamente, caso contrário este processo pode falhar. 

Isto resulta num module.dwarf. Depois o próximo comando (4) utiliza este módulo para ler o mapa do sistema a partir de /boot para gerar o perfil que precisamos de utilizar em Volatilidade. Podemos então copiar este perfil (5) para o directório certo, para que o Volatility o possa utilizar. Finalmente, para verificar se o nosso perfil está devidamente carregado em Volatilidade, podemos executar Volatilidade uma vez com a bandeira de informação (6). Se todas as etapas forem bem sucedidas, devemos ver o nosso perfil personalizado na secção Perfis da saída.

Instalação de um Módulo de Núcleo Escondido

Para este exemplo, utilizámos o HiddenWall para gerar um Módulo de Kernel Linux oculto (LKM), chamámos-lhe 'cantfindme', e carregámo-lo noutro Debian 9 Linode com a mesma construção/versão de kernel que a máquina 'forensics'. Embora o módulo seja carregado, não pode ser visto quando lsmod ou modprobe é executado no sistema: 

Clique na imagem para aumentá-la.

Aquisição de Memória

Existem grandes ferramentas que pode utilizar para despejar a memória no Linux; contudo, neste guia, iremos com AVML (Acquire Volatile Memory for Linux) uma vez que o LiME é coberto frequentemente na web. AVML é uma ferramenta de aquisição de memória open-source para Linux feita pela Microsoft. Pode encontrar o último lançamento aqui e descarregar o binário para a máquina a partir da qual pretende descarregar a memória. Lembre-se que o computador de onde estamos a despejar a memória deve ter o mesmo kernel/OS build e versão que o perfil de Volatilidade que gerámos anteriormente.

Num cenário real, é importante não mexer num sistema comprometido para garantir que as provas que recolhemos possam ser admissíveis num tribunal. Também é importante não comprimir quaisquer imagens sempre que possível, porque a aquisição bit a bit pode fornecer dados que uma imagem comprimida pode não fornecer.

Depois de descarregar o binário AVML para o directório home, pode usar o seguinte comando para descarregar a memória de um sistema para o directório home.

sudo ~/avml ~/output.lime

A AVML irá despejar a memória em formato LiME, para que possamos começar a nossa análise com o perfil de Volatilidade que criámos. Também é possível verificar o tamanho do despejo para garantir que corresponde à RAM total no dispositivo. A volatilidade não deve alterar o despejo da memória, mas é melhor fazer uma cópia do ficheiro e analisar os dados copiados em vez do original, depois de assegurar que os seus hashes coincidem.

Depois de despejarmos a memória da caixa 'pwnd', transferimo-la para a caixa 'forense' para análise.

Plugins de Volatilidade

A volatilidade oferece numerosos plugins para ajudar o analista forense. Pode encontrar uma lista destes plugins na sua página Github. Ao utilizar os plugins Volatility podemos obter uma visão rápida da imagem da memória. O formato de comando para análise de uma imagem de memória pode ser encontrado abaixo:

python ~/volatility/vol.py -f <path_to_memory_dump> --profile=<profile>
<plugin_name> <plugin_options>

Aqui está a saída do plugin linux_hidden_modules que lista os módulos de kernel carregados escondidos da imagem da memória:

Clique na imagem para aumentá-la.

Este plugin pode ajudá-lo a encontrar Módulos de Kernel Linux ocultos que podem ser maliciosos. Mesmo quando estes módulos não podem ser vistos quando se corre o lsmod no sistema, ambos podem ser detectados e extraídos de um despejo de memória. Pode usar o plugin linux_moddump para descarregar os módulos do kernel, especificando o seu nome num padrão regex ou especificando o endereço base do módulo na imagem da memória:

Clique na imagem para aumentá-la.

Há mais que se pode fazer com Volatilidade que simplesmente não podemos cobrir neste posto. Sinta-se à vontade para deixar um comentário em baixo para partilhar as suas ideias e sugestões.


Comentários

Deixe uma resposta

O seu endereço de correio electrónico não será publicado. Os campos obrigatórios estão marcados com *