Quindi ci sono così tanti strumenti per il test delle penne che eseguono un dump della memoria sul sistema. Come funzionano esattamente - cosa succede esattamente?
Un core dump , sia dell'intero sistema, sia del singolo eseguibile, è l'intero contenuto di che elabora la memoria, o nel caso del sistema, la memoria di tutto, scritta su un file. Ci possono essere molti dati in tale discarica - ecco una forma abbreviata dello spazio di memoria di gvim, che attualmente sto correndo:
pmap 19133
19133: gvim fsstate.py
0000000000400000 2184K r-x-- /usr/bin/gvim ; program code
0000000000821000 100K rw--- /usr/bin/gvim ; program code again
000000000083a000 52K rw--- [ anon ]
0000000000a39000 56K rw--- /usr/bin/gvim ; more program code
0000000002469000 3592K rw--- [ anon ]
0000003d53c00000 16K r-x-- /lib64/libuuid.so.1.3.0 ; shared object
0000003d53c04000 2044K ----- /lib64/libuuid.so.1.3.0
0000003d53e03000 4K rw--- /lib64/libuuid.so.1.3.0
0000003d55000000 28K r-x-- /usr/lib64/libSM.so.6.0.1
0000003d55007000 2044K ----- /usr/lib64/libSM.so.6.0.1
...
00007f46d66c7000 20K r---- /usr/share/locale/en_GB/LC_MESSAGES/gdk-pixbuf.mo
00007f46d66cc000 4K r---- /usr/share/locale/en_GB/LC_MESSAGES/libc.mo
00007f46d66cd000 56K r---- /usr/share/locale/en_GB/LC_MESSAGES/gtk20.mo
00007f46d66db000 28K r--s- /usr/lib64/gconv/gconv-modules.cache
00007f46d66e5000 4K rw--- [ anon ]
00007fffc9ed9000 132K rw--- [ stack ] ; stack!
00007fffc9f9b000 4K r-x-- [ anon ]
ffffffffff600000 4K r-x-- [ anon ]
Da quello spazio indirizzo, gli oggetti condivisi non verrebbero scaricati, ma tutto il resto, stack, heap, sarebbe. Gli indirizzi saranno relativi a determinate versioni di oggetti condivisi e potenzialmente con ASLR potrebbero non allineare il processo da elaborare. Un dump del kernel può essere configurato per contenere quantità variabili di informazioni, da piccoli dump a tutto.
Che cosa ti dice questo? Esattamente lo stato del sistema o del programma al momento del dumping: cosa ha in pila (e quindi probabilmente in quale funzione si trova). La maggior parte dei dump di core contiene anche altre informazioni utili come quelle contenute nei registri del processore al momento del dump.
In termini di come si sta verificando cosa sta succedendo, EIP o RIP su x86 (x64) ti diranno esattamente quale indirizzo di memoria il processo stava eseguendo. rbp o ebp ti diranno dove si trova lo stack sulla tua funzione. Ci si aspetterebbe di trovare variabili locali lì. Potresti anche cercare potenzialmente tutte le chiamate di sistema e i loro argomenti fatti in un core dump.
Tutto questo serve a dirti cosa sta succedendo con un processo in quel preciso momento. Neanche uno strumento per il test delle penne; è possibile analizzare i core dump come una forma di debugging delle applicazioni, in particolare dove eseguire debugger è difficile o impossibile. Ad esempio, potresti analizzare un core dump del kernel per capire perché il kernel si è bloccato (cosa stava facendo quando è entrato nel panico?) Invece di collegare un debugger e riprovare - permette anche ad altre persone di inviare dump a te per l'analisi. / p>
In che modo questo aiuta con il test delle penne? Allo stesso modo il debug aiuta a testare le penne. Puoi vedere cosa viene caricato in memoria, qual è lo stato corrente. È possibile capire cosa potrebbe fare un processo quando si esegue il dump e, cosa più importante, tutti i dati memorizzati in qualsiasi eseguibile in memoria (heap, stack ecc.) Finiranno anche nel core dump, incluse le password memorizzate come testo normale nella memoria .
Che cosa fanno gli strumenti di analisi? Cerca modelli e strutture indicativi di un potenziale exploit (o errore, se sei in cerca di debug). Una spiegazione completa di questo è probabilmente oltre lo scopo di questa scatola: ci sono molti libri dedicati alle tecniche per analizzare i dump della memoria. Gran parte di questo è anche dipendente dal sistema e dall'architettura; le tecniche per Windows x86 sono diverse dalle tecniche per Linux su MIPS.
Come esempio di qualcosa che potrebbe essere indicativo di un errore, ecco un esempio che AviD apprezzerà molto:
push rbp
mov rbp, rsp
sub rsp, 32
mov QWORD PTR [rbp-24], rdi ; this is a char* argument stored on stack
mov rdx, QWORD PTR [rbp-24] ; and this is a pointer loading it into a register
lea rax, [rbp-16] ; this is only 8 bytes further down
mov rcx, QWORD PTR [rdx] ; load contents of rdx into rcx
mov QWORD PTR [rax], rcx ; put those 8 bytes to rbp-16
mov rcx, QWORD PTR [rdx+8] ; load next 8 butes
mov QWORD PTR [rax+8], rcx ; write to rbp-8
mov rcx, QWORD PTR [rdx+16]
mov QWORD PTR [rax+16], rcx ; write to rbp
mov rcx, QWORD PTR [rdx+24]
mov QWORD PTR [rax+24], rcx ; write to rbp+8
mov rcx, QWORD PTR [rdx+32]
mov QWORD PTR [rax+32], rcx ; write to rbp+16
mov rcx, QWORD PTR [rdx+40]
mov QWORD PTR [rax+40], rcx ; write to rbp+24
mov rcx, QWORD PTR [rdx+48]
mov QWORD PTR [rax+48], rcx ; write to rbp+32
mov rdx, QWORD PTR [rdx+56]
mov QWORD PTR [rax+56], rdx ; write to rbp+40
lea rax, [rbp-16]
Come puoi vedere, il primo spazio disponibile per questa funzione nello stack per le variabili locali era rbp-16 e sotto. Al di sopra di questo, abbiamo appena fatto amicizia con uno stack frame con un'intera pila di dati, probabilmente causando il crash del programma. Tuttavia, questo codice potrebbe indicare un possibile exploit. Cercare pattern come quello in un crash dump è ciò che li rende utili, e inoltre rip in questo caso ti dirà esattamente quale accesso alla memoria ha causato il problema, perché indicherà l'istruzione incriminata (in teoria).
Nel caso ve lo stiate chiedendo, il pezzo di codice incriminato era semplicemente un memcpy da un buffer illimitato in uno spazio bersaglio molto più piccolo. La funzione chiamata a memcpy è stata ottimizzata.
Prima di tutto, ci sono due utenti principali dei dump di memoria in sicurezza - forensics e exploit che scrivono ragazzi. Pen-tester, non tanto - ovviamente dipende dal pentest;)
I soliti strumenti di gestione del dump della memoria sono l'apertura dello pseudo-dispositivo di memoria e la lettura di tutti i contenuti in un file.
Ad esempio con dd in windows si farebbe qualcosa come dd if=\.\Device\PhysicalMemory of=memory.bin bs=4096 (pre-win-2003, dopo aver bisogno di un driver del kernel)
Lo stesso vale per linux, ad es. dd if=/dev/mem of=/home/john/mem.bin bs=1024
Questo è il modo più semplice, naturalmente. Altri modi per acquisire memoria sono usando i dump di crash come menziona Ninefingers, i dump di LiveKd, recuperano la memoria attraverso l'hypervisor se parliamo di una VM, ottengono il file di ibernazione se ne esiste uno o addirittura la memoria attraverso il fireware o un'altra interfaccia DMA. Certo, poi c'è anche l'attacco a freddo.
Avere la memoria su un file, puoi fare molte cose, dipende da cosa vuoi. Il comune è cercare stringhe, ad es. token password, chiavi private e il resto, questo è il più semplice.
Se vuoi fare qualcosa di più, di solito è necessario molto più lavoro, ma è automatizzato con vari gradi di successo usando strumenti commerciali o open source. L'idea principale è che la memoria fisica nella tua discarica sarà sparsa nelle pagine. Per dare un senso a ciò, localizzate per ricerca euristica le tabelle delle pagine e cercate di ricostruire una visione logica della memoria. Fatto ciò, è possibile eseguire altre ricerche e individuare strutture per i vari processi in esecuzione, aprire file, connessioni di rete, ecc. Dipende davvero da quali sono i tuoi obiettivi.
Sarebbe utile se tu elencassi quali strumenti, in quanto vi sono delle differenze, ad esempio l'intera memoria rispetto alle aree specifiche. Non riesco a pensare ad alcuno strumento di attacco che io usi regolarmente per memorizzare la memoria.
Ma semplicemente, prendendo un dump di memoria, esaminiamo non solo il codice dell'applicazione in situ, ma anche i valori delle variabili.
La memoria viene semplicemente copiata su un disco in modo simile al modo in cui le pagine di memoria vengono scambiate su disco nel normale utilizzo o uno strumento legge direttamente la memoria.
Leggi altre domande sui tag operating-systems memory penetration-test vulnerability-scanners