halpomeranz/lmgScript per automatizzare l'acquisizione e l'analisi della memoria Linux
Linux Memory Grabber Uno script per scaricare la memoria Linux e creare profili Volatility(TM). Hal Pomeranz ([email protected]), 2020-02-01
"Se ho visto più lontano è perché stavo sulle spalle di giganti." ~ Issac Newton
Ci sono molte persone che meritano ringraziamenti per aver reso possibile questo piccolo e semplice strumento:
-- Le brave persone di Microsoft per aver reso disponibile AVML
-- Joe Sylve per il suo lavoro su LiME
-- L'intero team di sviluppo di Volatility(TM) per il loro lavoro continuo. Vorrei riconoscere in particolare Andrew Case che ha risposto a una serie di domande fastidiose da parte mia durante lo sviluppo del mio strumento.
-- David Anderson per il suo supporto continuo a libdwarf e dwarfdump
-- Matt Suiche di MoonSols. Quando stavo mettendo insieme il mio strumento, il mio obiettivo di progettazione era "renderlo facile da usare come DumpIt" (se hai bisogno di acquisire memoria Windows, non conosco strumento più facile da usare). Quindi grazie per l'ispirazione, Matt!
-- Persone che hanno fornito idee e codice per migliorare lo strumento:
Julien -- Directory di output/build alternative ed etichette ID caso, interruzione se non eseguito come root
Jonathon Poling -- idee simili a quelle di Julien
Jeff Bryner -- Creazione di file volatilityrc per ogni acquisizione
La comunità è migliore grazie a tutti questi sforzi. Ho scelto di rendere disponibile il mio strumento sotto la licenza Creative Commons "Attribuzione" (CC BY), per renderlo il più ampiamente possibile disponibile.
Per analizzare la memoria Linux, devi prima essere in grado di acquisire la memoria Linux. AVML funziona benissimo, ma se il tuo sistema non ha /proc/kcore o /dev/crash allora avrai bisogno del Linux Memory Extractor (LiME) di Joe Sylve. Ma devi avere un modulo LiME compilato per il kernel del sistema su cui vuoi catturare la RAM.
Volatility(TM) è ottimo per analizzare le immagini di memoria Linux. Ma necessita di un profilo che corrisponda al sistema in cui la memoria è stata acquisita. Costruire un profilo significa compilare un programma C sul sistema appropriato e usare dwarfdump per ottenere gli indirizzi delle importanti strutture dati del kernel. Hai anche bisogno di una copia del file System.map dalla directory /boot.
Ora, se per caso hai un duplicato del tuo sistema di destinazione, puoi costruire il profilo Volatility(TM) sul clone e, se necessario, compilare LiME per catturare e analizzare la memoria dal tuo target. Ma ci sono molte situazioni in cui un duplicato del sistema di destinazione non è disponibile. Quindi potresti dover costruire il profilo Volatility(TM) e LiME sulla tua macchina target.
E questo non è per i deboli di cuore. Ci sono diversi passaggi e alcuni comandi Linux di basso livello coinvolti. Il mio obiettivo era creare un pacchetto che potesse essere installato (da un esperto) su una chiavetta USB e distribuito agli agenti sul campo. L'utente della chiavetta USB dovrebbe essere in grado di inserire la chiavetta, eseguire un singolo comando e acquisire con successo un'immagine della memoria della macchina target e un profilo Volatility(TM) funzionante. Il risultato è il mio script lmg (Linux Memory Grabber).
Se sei un pignolo per la purezza forense, probabilmente questo non è lo strumento per te. Discutiamo alcuni dei modi in cui il mio strumento interagisce con il sistema target:
Supporti rimovibili -- Lo strumento è progettato per essere eseguito da un dispositivo USB portatile come una chiavetta. Collegherai un dispositivo scrivibile al tuo sistema target, dove potrebbe essere preso di mira da utenti malintenzionati o malware presenti sul sistema. L'atto di collegare il dispositivo al sistema cambierà lo stato della macchina (ad esempio, creerà voci di log, voci mtab, ecc.). Se il dispositivo non viene montato automaticamente dal sistema operativo, l'utente deve montare manualmente il dispositivo tramite una shell di root.
Compilazione -- Creare un profilo Volatility(TM) comporta la compilazione di codice sulla macchina target. Lo stesso vale per la compilazione di LiME quando AVML non funziona. Quindi gcc verrà eseguito, verranno letti i file header, collegate le librerie, ecc. lmg cerca di minimizzare l'impatto sul filesystem della macchina target impostando TMPDIR su una directory sul dispositivo USB da cui viene eseguito lmg. Ciò significa che i file intermedi creati dal compilatore verranno scritti sulla chiavetta USB piuttosto che sul filesystem locale della macchina target.
Dipendenze -- Per compilare codice kernel su Linux, la macchina target necessita di un ambiente di sviluppo funzionante con gcc, make, ecc. e tutti i file include e le librerie condivise appropriate. In particolare, i file header del kernel devono essere presenti sulla macchina locale. Queste dipendenze potrebbero non esistere sul target. In questo caso, l'utente si trova di fronte alla scelta di installare le dipendenze appropriate (se possibile) o di non essere in grado di costruire il profilo Volatility(TM) per il sistema.
Malware -- lmg utilizza /bin/bash, gcc, zip e una serie di altri programmi dalla macchina target. Se il sistema è stato compromesso, le applicazioni utilizzate da lmg potrebbero non essere affidabili. Una soluzione più completa sarebbe creare un ambiente di esecuzione sicuro per lmg sul dispositivo USB portatile, ma ciò era al di là dello scopo di questa prova di concetto iniziale.
Memoria -- Tutti i comandi eseguiti causeranno la modifica della memoria del sistema target. L'atto di catturare la RAM creerà sempre artefatti, ma in questo caso c'è un'estesa compilazione, accesso al filesystem, ecc. in aggiunta all'esecuzione di un dump della RAM.
Detto questo, lmg è uno strumento molto comodo per consentire ad agenti meno esperti di catturare dati utili per l'analisi della memoria dai sistemi target.
Nota che se AVML fallisce, lmg cercherà un modulo LiME già esistente sul dispositivo USB che corrisponda alla versione del kernel e all'architettura del processore della macchina target. Se trovato, lmg non si preoccuperà di ricompilare. Allo stesso modo, puoi scegliere di non far creare a lmg il profilo Volatility(TM) per il target per minimizzare l'impatto sul sistema target.
lmg utilizza nomi di percorso relativi quando invoca programmi come gcc e zip. Quindi se desideri eseguire questi programmi da supporti alternativi, aggiorna semplicemente $PATH come appropriato prima di eseguire lmg.
Per prima cosa, prepara una chiavetta USB secondo le istruzioni nel documento INSTALL fornito con lmg.
Quando desideri acquisire RAM, collega la chiavetta al tuo sistema target. Sulla maggior parte dei sistemi Linux, i nuovi dispositivi USB vengono montati automaticamente sotto /media. Supponiamo che il tuo finisca sotto /media/LMG.
Ora, come root, esegui "/media/LMG/lmg". Questa è la modalità interattiva e all'utente verrà chiesto di confermare prima che lmg costruisca un modulo LiME per il sistema e/o crei un profilo Volatility(TM). Se non vuoi essere interrogato, usa "/media/LMG/lmg -y".
Tutto il resto è automatizzato. Dopo l'esecuzione dello script, avrai una nuova directory sulla chiavetta USB denominata
".../capture/-YYYY-MM-DD_hh.mm.ss"
lmg supporta un'opzione -c per specificare un nome di directory ID caso da utilizzare al posto della directory predefinita "-YYYY-MM-DD_hh.mm.ss".
Qualunque sia il nome della directory utilizzato, la directory conterrà:
-YYYY-MM-DD_hh.mm.ss-memory.lime -- l'acquisizione RAM -YYYY-MM-DD_hh.mm.ss-profile.zip -- profilo Volatility(TM) -YYYY-MM-DD_hh.mm.ss-bash -- copia di /bin/bash del target volatilityrc -- file di configurazione prototipo di Volatility
Il file volatilityrc definisce le posizioni appropriate per la memoria acquisita e il plugin. Vedi ESEMPIO DI UTILIZZO qui sotto per come usare questo file.
La copia di /bin/bash è utile per determinare l'indirizzo della struttura dati della cronologia della shell nella memoria dei processi bash nell'acquisizione di memoria. Vedi https://github.com/volatilityfoundation/volatility/wiki/Linux-Command-Reference#linux_bash per ulteriori dettagli su come utilizzare questo eseguibile (o consulta ESEMPIO DI UTILIZZO qui sotto).
Nota che potrebbero esserci momenti in cui non vuoi scrivere dati sul supporto da cui stai eseguendo lmg, ad esempio se gli strumenti lmg si trovano su supporto di sola lettura come un DVD-ROM. lmg supporta un'opzione -d per specificare una directory di output diversa. Per impostazione predefinita, tutta la compilazione avverrà nella directory di destinazione, ma l'utente può specificare una directory di compilazione alternativa con -B.
Ecco un esempio di utilizzo dello strumento lmg, che include l'uso di Volatility(TM) direttamente dalla chiavetta per analizzare l'immagine acquisita. Sulla mia macchina di test, la chiavetta era in /dev/sdb e non è stata montata automaticamente dal mio sistema operativo. Quindi ho fatto tutto 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 ...]