halpomeranz/lmgScript para automatizar a captura e análise de memória Linux
Coletor de Memória Linux Um script para capturar memória Linux e criar perfis do Volatility(TM). Hal Pomeranz ([email protected]), 2020-02-01
"Se vi mais longe, foi por estar sobre os ombros de gigantes." ~ Isaac Newton
Há muitas pessoas que merecem agradecimentos por tornar esta pequena ferramenta possível:
-- Os bons colegas da Microsoft por disponibilizarem o AVML
-- Joe Sylve pelo seu trabalho no LiME
-- Toda a equipa de desenvolvimento do Volatility(TM) pelo seu trabalho contínuo. Gostaria de reconhecer particularmente Andrew Case, que respondeu a várias questões incómodas minhas durante o desenvolvimento da minha ferramenta.
-- David Anderson pelo seu apoio contínuo ao libdwarf e dwarfdump
-- Matt Suiche da MoonSols. Quando estava a montar a minha ferramenta, o meu objetivo de design era "torná-la tão fácil de usar como o DumpIt" (se precisar de capturar memória Windows, não conheço ferramenta mais fácil de usar). Então, obrigado pela inspiração, Matt!
-- Pessoas que forneceram ideias e código para melhorar a ferramenta:
Julien -- Diretórios alternativos de saída/build e etiquetas de ID de caso,
abortar se não estiver a correr como root
Jonathon Poling -- ideias semelhantes às do Julien
Jeff Bryner -- Criação de ficheiros volatilityrc para cada captura
A comunidade é melhor por todos estes esforços. Optei por disponibilizar a minha ferramenta sob a Licença Creative Commons "Atribuição" (CC BY), de forma a torná-la o mais amplamente disponível possível.
Para analisar a memória Linux, primeiro precisa de ser capaz de capturar a memória Linux. O AVML funciona muito bem, mas se o seu sistema não tiver /proc/kcore ou /dev/crash, então precisará do Linux Memory Extractor (LiME) do Joe Sylve. Mas precisa de ter um módulo LiME compilado para o kernel do sistema onde deseja capturar a RAM.
O Volatility(TM) é excelente para analisar imagens de memória Linux. Mas precisa de um perfil que corresponda ao sistema onde a memória foi capturada. Construir um perfil significa compilar um programa C no sistema apropriado e usar dwarfdump para obter os endereços de estruturas de dados importantes do kernel. Também precisa de uma cópia do ficheiro System.map do diretório /boot.
Agora, se por acaso tiver um duplicado do seu sistema alvo, pode construir o perfil Volatility(TM) no clone e, se necessário, construir o LiME para capturar e analisar a memória do seu alvo. Mas existem muitas situações em que um duplicado do seu sistema alvo não está disponível. Portanto, pode ter de construir o seu perfil Volatility(TM) e o LiME na sua máquina alvo.
E isto não é para os fracos de coração. Existem vários passos, e alguns comandos Linux bastante de baixo nível envolvidos. O meu objetivo era criar um pacote que pudesse ser instalado (por um especialista) numa pen USB e distribuído a agentes no terreno. O utilizador da pen USB deveria poder ligar a pen USB, executar um único comando, e adquirir com sucesso uma imagem de memória da máquina alvo e um perfil Volatility(TM) funcional. O resultado é o meu script lmg (Linux Memory Grabber).
Se é um rigoroso quanto à pureza forense, esta provavelmente não é a ferramenta para si. Vamos discutir algumas das formas como a minha ferramenta interage com o sistema alvo:
Mídia Removível -- A ferramenta foi concebida para ser executada a partir de um dispositivo USB portátil, como uma pen USB. Vai ligar um dispositivo gravável ao seu sistema alvo, onde pode potencialmente ser alvo de utilizadores maliciosos ou malware no sistema. O ato de ligar o dispositivo ao sistema vai alterar o estado da máquina (por exemplo, criar entradas de log, entradas mtab, etc.). Se o dispositivo não for montado automaticamente pelo sistema operativo, o utilizador deve montar manualmente o dispositivo através de uma shell root.
Compilação -- Criar um perfil Volatility(TM) envolve compilar código na máquina alvo. O mesmo acontece ao construir o LiME quando o AVML não funciona. Portanto, o gcc será executado, ficheiros de cabeçalho lidos, bibliotecas vinculadas, etc. O lmg tenta minimizar o impacto no sistema de ficheiros da máquina alvo ao definir TMPDIR para um diretório no dispositivo USB onde o lmg é executado. Isto significa que os ficheiros intermediários criados pelo compilador serão escritos na pen USB em vez do sistema de ficheiros local da máquina alvo.
Dependências -- Para compilar código de kernel no Linux, a máquina alvo precisa de um ambiente de desenvolvimento funcional com gcc, make, etc. e todos os ficheiros de inclusão e bibliotecas partilhadas apropriados. E, em particular, os ficheiros de cabeçalho do kernel precisam de estar presentes na máquina local. Estas dependências podem não existir no alvo. Nesse caso, o utilizador enfrenta a escolha de instalar as dependências apropriadas (se possível) ou ser incapaz de construir o perfil Volatility(TM) para o sistema.
Malware -- O lmg usa /bin/bash, gcc, zip e uma série de outros programas da máquina alvo. Se o sistema tiver sido comprometido, as aplicações que o lmg usa podem não ser confiáveis. Uma solução mais completa seria criar um ambiente de execução seguro para o lmg no dispositivo USB portátil, mas isso estava além do âmbito desta prova de conceito inicial.
Memória -- Todos os comandos executados farão com que a memória do sistema alvo mude. O ato de capturar RAM criará sempre artefactos, mas neste caso há compilação extensiva, acesso ao sistema de ficheiros, etc., além de executar um despejador de RAM.
Dito isto, o lmg é uma ferramenta muito conveniente para permitir que agentes menos experientes capturem dados úteis de análise de memória de sistemas alvo.
Note que se o AVML falhar, o lmg procurará por um módulo LiME já existente no dispositivo USB que corresponda à versão do kernel e à arquitetura do processador da máquina alvo. Se encontrado, o lmg não se preocupará em recompilar. Da mesma forma, pode optar por não deixar o lmg criar o perfil Volatility(TM) para o alvo, a fim de minimizar o impacto no sistema alvo.
O lmg usa nomes de caminho relativos ao invocar programas como gcc e zip. Portanto, se desejar executar estes programas a partir de mídia alternativa, basta atualizar $PATH conforme apropriado antes de executar o lmg.
Primeiro, prepare uma pen USB de acordo com as instruções no documento INSTALL fornecido com o lmg.
Quando desejar adquirir RAM, ligue a pen USB ao seu sistema alvo. Na maioria dos sistemas Linux, novos dispositivos USB serão montados automaticamente em /media. Suponhamos que o seu acaba em /media/LMG.
Agora, como root, execute "/media/LMG/lmg". Este é o modo interativo e o utilizador será solicitado a confirmar antes de o lmg construir um módulo LiME para o sistema e/ou criar um perfil Volatility(TM). Se não quiser ser solicitado, use "/media/LMG/lmg -y".
Todo o resto é automatizado. Após o script ser executado, terá um novo diretório na pen USB chamado
".../capture/-YYYY-MM-DD_hh.mm.ss"
O lmg suporta uma opção -c para especificar um nome de diretório de ID de caso a ser usado em vez do diretório padrão "-YYYY-MM-DD_hh.mm.ss".
Qualquer que seja o nome do diretório usado, o diretório conterá:
-YYYY-MM-DD_hh.mm.ss-memory.lime -- a captura de RAM -YYYY-MM-DD_hh.mm.ss-profile.zip -- perfil Volatility(TM) -YYYY-MM-DD_hh.mm.ss-bash -- cópia do /bin/bash do alvo volatilityrc -- ficheiro de configuração protótipo do Volatility
O ficheiro volatilityrc define as localizações apropriadas para a memória capturada e o plugin. Consulte o EXEMPLO DE USO abaixo para saber como usar este ficheiro.
A cópia do /bin/bash é útil para determinar o endereço da estrutura de dados do histórico da shell na memória dos processos bash na captura de memória. Consulte https://github.com/volatilityfoundation/volatility/wiki/Linux-Command-Reference#linux_bash para mais detalhes sobre como usar este executável (ou consulte o EXEMPLO DE USO abaixo).
Note que pode haver momentos em que não deseja escrever dados na mídia a partir da qual está a executar o lmg — por exemplo, se as ferramentas do lmg estiverem em mídia apenas de leitura, como um DVD-ROM. O lmg suporta uma opção -d para especificar um diretório de saída diferente. Por padrão, toda a compilação ocorrerá no diretório alvo, mas o utilizador pode especificar um diretório de compilação alternativo com -B.
Aqui está um exemplo de uso da ferramenta lmg, que inclui usar o Volatility(TM) diretamente da pen USB para analisar a imagem capturada. Na minha máquina de teste, a pen USB estava em /dev/sdb e não foi montada automaticamente pelo meu sistema operativo. Então fiz tudo manualmente.
[root@localhost ~]$ sudo -s [sudo] password for lab: [root@localhost lab]# mkdir -p /mnt/usb [root@localhost lab]# mount /dev/sdb1 /mnt/usb
[root@localhost lab]# /mnt/usb/lmg -y AVML is /mnt/usb/avml/avml-x86_64 Dumping memory in "lime" format to /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55 This could take a while...Done! Grabbing a copy of /bin/bash...Done! Writing volatilityrc to /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55...Done! make -C //lib/modules/4.18.0-147.3.1.el8_1.x86_64/build M="/mnt/usb/volatility-master/tools/linux" clean make[1]: Entering directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' make[1]: Leaving directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' rm -f module.dwarf make -C //lib/modules/4.18.0-147.3.1.el8_1.x86_64/build CONFIG_DEBUG_INFO=y M="/mnt/usb/volatility-master/tools/linux" modules make[1]: Entering directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' CC [M] /mnt/usb/volatility-master/tools/linux/module.o Building modules, stage 2. MODPOST 1 modules WARNING: modpost: missing MODULE_LICENSE() in /mnt/usb/volatility-master/tools/linux/module.o see include/linux/module.h for more information CC /mnt/usb/volatility-master/tools/linux/module.mod.o LD [M] /mnt/usb/volatility-master/tools/linux/module.ko make[1]: Leaving directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' dwarfdump -di module.ko > module.dwarf make -C //lib/modules/4.18.0-147.3.1.el8_1.x86_64/build M="/mnt/usb/volatility-master/tools/linux" clean make[1]: Entering directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' CLEAN /mnt/usb/volatility-master/tools/linux/.tmp_versions CLEAN /mnt/usb/volatility-master/tools/linux/Module.symvers make[1]: Leaving directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' adding: module.dwarf (deflated 90%) adding: boot/System.map-4.18.0-147.3.1.el8_1.x86_64 (deflated 79%)
[root@localhost lab]# cd /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55 [root@localhost localhost.localdomain-2020-02-01_08.16.55]# ls localhost.localdomain-2020-02-01_08.16.55-bash localhost.localdomain-2020-02-01_08.16.55-memory.lime localhost.localdomain-2020-02-01_08.16.55-profile.zip volatilityrc [root@localhost localhost.localdomain-2020-02-01_08.16.55]# ../../volatility-master/vol.py --conf-file=volatilityrc linux_banner Volatility Foundation Volatility Framework 2.6.1 Linux version 4.18.0-147.3.1.el8_1.x86_64 ([email protected]) (gcc version 8.3.1 20190507 (Red Hat 8.3.1-4) (GCC)) #1 SMP Fri Jan 3 23:55:26 UTC 2020
[root@localhost localhost.localdomain-2020-02-01_08.16.55]# gdb localhost.localdomain-2020-02-01_08.16.55-bash GNU gdb (GDB) Red Hat Enterprise Linux 8.2-6.el8_0 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from localhost.localdomain-2020-02-01_08.16.55-bash...Missing separate debuginfo for /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55/localhost.localdomain-2020-02-01_08.16.55-bash
Try: dnf --enablerepo='debug' install /usr/lib/debug/.build-id/b6/858d77c486b7b596f22956149bbc9f8058d98d.debug
Reading symbols from .gnu_debugdata for /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55/localhost.localdomain-2020-02-01_08.16.55-bash...(no debugging symbols found)...done.
(no debugging symbols found)...done.
(gdb) disass history_list
Dump of assembler code for function history_list:
0x00000000000ccea0 <+0>: endbr64
0x00000000000ccea4 <+4>: mov 0x24b09d(%rip),%rax # 0x317f48
0x00000000000cceab <+11>: retq
End of assembler dump.
(gdb) quit
[root@localhost localhost.localdomain-2020-02-01_08.16.55]# ../../volatility-master/vol.py --conf-file=volatilityrc linux_bash -H 0x317f48
Volatility Foundation Volatility Framework 2.6.1
Pid Name Command Time Command
13822 bash 2020-01-30 20:25:39 UTC+0000 uname -a 13822 bash 2020-01-30 20:25:39 UTC+0000 ls 13822 bash 2020-01-30 20:25:39 UTC+0000 sudo -s 13822 bash 2020-01-30 20:25:39 UTC+0000 fg [... more output not shown ...]