Volatility

Acquisizione della memoria volatile

La RAM, acronimo dell’inglese Random Access Memory ovvero memoria ad accesso casuale, è un tipo di memoria volatile caratterizzata dal permettere l’accesso diretto a qualunque indirizzo di memoria con lo stesso tempo di accesso.

Nella memoria RAM vengono copiati (“caricati”) i programmi che la CPU deve eseguire. Una volta chiuso il programma le modifiche effettuate verranno salvate e i programmi verranno automaticamente ricopiati sul disco rigido.

Per le sue caratteristiche viene utilizzata come memoria primaria nei computer più comuni. Poiché i dati vanno persi allo spegnimento del dispositivo, l’acquisizione della RAM deve essere eseguita a sistema acceso.

Quando è utile acquisire la RAM?

L’esecuzione di tale attività consentirà di ricavare informazioni relative a:

  • presenza di malware, o comunque particolari processi in esecuzione;
  • eventuali passphrases in chiaro riconducibili a container crittografici;
  • dati temporanei che non sono stati ancora memorizzati;
  • dati riconducibili alla navigazioni in incognito;

DUMP

Il DUMP: è un elemento di un database contenente un riepilogo della struttura delle tabelle del database medesimo e/o i relativi dati, ed è normalmente nella forma di una lista di dichiarazioni SQL. Tale dump è usato per lo più per fare il backup del database, poiché i suoi contenuti possono essere ripristinati nel caso di perdita di dati. I database “corrotti” (ossia, i cui dati non sono più utilizzabili in seguito ad una modifica “distruttiva” di qualche parametro di formato) possono spesso essere rigenerati mediante l’analisi del dump.

Con l’espressione inglese core dump s’intende specificamente lo stato registrato della memoria di un programma in un determinato momento, specie quando tale programma si sia chiuso “inaspettatamente” (crash).

(https://it.wikipedia.org/wiki/Dump)

Acquisizione della memoria volatile

Vi sono molti software per acquisire/analizzare la RAM:

  • Volatility
  • Rekall
  • Mandiant Memoryze
  • AccessData FTK Imager
  • Windows Memory Reader
  • Mac Memory Reader
  • MoonSols Windows Memory
  • DumpIt
  • Belcasoft RAM capture
  • Fmem (Linux)
  • e altri ancora…

DARTDigital Advanced Response Toolkit

DART è una collezione di programmi portabili per live forensics inclusa nel sistema DEFT (www.deftlinux.net). Contiene :

  • programmi per Windows, Linux e per Mac OS X;
  • ulteriore corposa sezione di programmi command line;
  • struzioni e script per il completamento del pacchetto con i software non ridistribuibili.

Ha inoltre ottenuto il permesso esclusivo da diversi sviluppatori per la distribuzione dei loro tool in DEFT/DART (ViaForensics, MonSools, CrowdInspect, Mandiant, Belkasoft, Carvey, ASH368, CyberMarshall, ecc.)

Volatility

Volatility è un software open source multi piattaforma (Windows, Linux, Mac) che consente di effettuare analisi del dump della RAM.

Il vantaggio di questo software è che è “modulare” ovvero espandibile tramite l’ausilio di plugin che variano in base alle esigenze.

Periodicamente vengono rilasciati nuovi plugin per la soluzione di nuove esigenze.

Dai un’occhiata a questo Cheatsheet 😉

Alcuni esempi:

vol.py --profile=[WinXPSP3x86] [comando] -f win-mem-image.bin
  • filescan scansiona tutti i file aperti nel dump e li elenca
  • hashdump elenca gli utenti con relativi hash delle password
  • dlllist elenca le dll caricate
  • procdump esegue il dump dei processi
  • pslist elenca i processi in esecuzione
  • sockscan scansiona oggetti sul socket
  • screenshot salva dei pseudo screenshot del desktopdumpfiles salva tutti i file presenti nella memoria

Image identification

Per avviare un’analisi di memoria con Volatility, l’identificazione del tipo di immagine di memoria è un passo obbligatorio.

Per verificare il sistema di provenienza della nostra acquisizione di memoria, utilizziamo il comando:

imageinfo

vol.py -f win-mem-image.bin imageinfo

Questo plugin fornirà le informazioni essenziali per la successiva analisi in quanto permette di identificare il profilo che verrà utilizzato da tutti gli altri plugin.

Utilizzeremo il comando imageinfo per ottenere un riepilogo ad alto livello del campione di memoria che si sta analizzando. Questo comando viene spesso usato per identificare il sistema operativo, il service pack e l’architettura hardware (32 o 64 bit), ma contiene anche altre informazioni utili come l’indirizzo DTB e l’ora in cui il campione è stato raccolto

Nota:

  • DTB (directory table base) used for address translation. Although identity paging helps translate some static addresses found in System.map, it doesn’t work for all regions of memory. Thus, performing full-scale memory forensics (i.e., list walking, accessing process memory) requires the capability to translate virtual addresses based on the algorithm used by the CPU. For this to be possible, you must find the initial directory table base (DTB). This is a very simple operation because the address of the initial DTB (swapper_pg_dir) is stored in both the System.map file and within the identity-mapped region of the kernel.
  • PAE  (Physical Address Extension, Estensione dell’indirizzo fisico) è una caratteristica di alcuni processori x86 e x86-64 che permette di usare più di 4 gigabyte di memoria fisica nei sistemi a 32 bit – in concomitanza con il supporto appropriato del sistema operativo. Il PAE è supportato dagli Intel Pentium Pro (e successivi) compresi tutti gli ultimi processori Pentium (ad eccezione delle versioni con bus a 400 MHz del Pentium M) – e allo stesso modo dall’AMD Athlon (e successivi).

L’output di imageinfo indica il profilo suggerito da utilizzare come parametro a profile = PROFILE nell’impiego di altri plugin. È possibile che vengano suggeriti più di un profilo se questi ultimi sono strettamente connessi. Viene visualizzato anche l’indirizzo della struttura KDBG (abbreviazione per _KDDEBUGGER_DATA64) che verrà utilizzata da plugin come pslist e da moduli per trovare rispettivamente gli heads di processo e di moduli stessi. In alcuni casi, particolarmente in campioni di memoria più grandi, potrebbero essere presenti più strutture KDBG. Allo stesso modo, se ci sono più processori, otterremo l’indirizzo KPCR e il numero di CPU per ciascuno di essi.

I plugin esplorano automaticamente i valori KPCR e KDBG quando ne hanno bisogno. Tuttavia, è possibile specificare i valori per qualsiasi plugin fornendo kpcr = ADDRESS o kdbg = ADDRESS. Fornendo il profilo e KDBG (o in mancanza quello KPCR) ad altri comandi di Volatility, otterremo risultati più precisi e più veloci. Nota: il pluginimageinfo non funziona sui file di ibernazione, a meno che il profilo corretto non venga fornito in anticipo. Ciò è dovuto al fatto che le definizioni delle strutture importanti variano tra diversi sistemi operativi.

Nota: The KDBG is a structure maintained by the Windows kernel for debugging purposes. It contains a list of the running processes and loaded kernel modules. It also contains some version information that allows you to determine if a memory dump came from a Windows XP system versus Windows 7, what Service Pack was installed, and the memory model (32-bit vs 64-bit).

kdbgscan

Al contrario di imageinfo che fornisce semplicemente suggerimenti sul profilo, kdbgscan è progettato per identificare positivamente il profilo corretto ed il corretto indirizzo KDBG (se sono molteplici). Questo plugin esegue la scansione delle firme KDBGHeader collegate ai profili di Volatility ed applica controlli per ridurre i falsi positivi. La ridondanza dell’output e il numero di controlli per ridurre i falsi positivi che possono essere eseguiti dipende dal fatto se Volatility riesce a trovare un DTB, quindi se già si conosce il profilo corretto (o se si ha un suggerimento di profilo da imageinfo), assicurarsi di utilizzarlo.

Ecco un esempio di quando questo plugin può essere utile. Si supponga che il dump della memoria sia di un sistema Windows 2003 SP2 x64, ma pslist non mostra alcun processo. Il plugin pslist si basa sulla ricerca dell’ heads degli elenchi dei processi indicato da KDBG. Tuttavia, il plugin prende il primo KDBG trovato nel campione di memoria, che non è sempre il migliore. È possibile scontrarsi con questo problema se un KDBG con un puntatore PsActiveProcessHead non valido viene trovato in un dump (ad es. con un offset fisico inferiore) rispetto al KDBG valido.

Osservare come kdbgscan raccoglie due strutture KDBG: una non valida (con 0 processi e 0 moduli) viene trovata prima all’indirizzo 0xf80001172cb0 e una valida (con 37 processi e 116 moduli) si trova successivamente all’indirizzo 0xf80001175cf0. Per ovviare al problema con pslist per questo esempio, è sufficiente fornire il plugin plk -kdbg = 0xf80001175cf0.

Processi e DLL

Iniziamo ad analizzare la lista dei processi.

Una volta identificato il profilo corretto, possiamo iniziare ad analizzare i processi in memoria e, quando il dump proviene da un sistema Windows, le DLL caricate.

pslist

Per elencare i processi di un sistema, utilizziamo il comando pslist. In questo modo viene visualizzata la lista doppiamente collegata a cui punta PsActiveProcessHead e mostra l’offset, il nome del processo, l’ID del processo, l’ID del processo principale, il numero di thread, il numero di handle e la data/ora all’avvio ed al termine del processo. A partire dalla versione 2.1 mostra anche l’ID di sessione e se è un processo Wow64 (Windows 32-bit on Windows 64-bit, ovvero Windows 32 bit su Windows 64 bit; usa uno spazio di indirizzamento a 32 bit su un kernel a 64 bit).

Questo plugin non rileva processi nascosti o non collegati (ma psscan può farlo).

In caso di processi con 0 thread, 0 handle e/o un tempo di termine non vuoto, il processo potrebbe non essere ancora attivo.

Nota: WoW64 (Windows 32-bit on Windows 64-bit, in italiano windows 32 bit su windows 64 bit) è un sottosistema del sistema operativo Windows capace di far funzionare le applicazioni nate a 32 bit ed è incluso in tutte le versioni di Windows a 64 bit (incluso Windows XP Professional x64 Edition, Windows Server 2003 x64 Edition e Windows XP 64-bit Edition). WOW64 supplisce a tutte le differenze tra Windows a 32 ed a 64 bit, in particolare i cambiamenti strutturali dello stesso sistema operativo.

pslist

Come di seguito si può notare, regsvr32.exe risulta terminato anche se ancora presente nell’elenco “attivo”. Si noti inoltre che i due processi System e smss.exe non avranno un ID sessione, poiché il System viene avviato prima che le sessioni vengano stabilite e smss.exe è il gestore della propria sessione.

Per impostazione predefinita, pslist mostra offset virtuali per il _EPROCESS ma l’offset fisico può essere ottenuto con l’opzione -P

pstree

Per visualizzare l’elenco dei processi in forma di albero, utilizzare il comando pstree. Questo enumera i processi usando la stessa tecnica di pslist, quindi non mostrerà processi nascosti o non collegati. I processi figli sono indicati usando indentazioni ed i punti.

psscan

Per enumerare i processi utilizzando la scansione dei pool tags  (_POOL_HEADER), utilizzare il comando psscan. Questo plugin può trovare processi che sono stati precedentemente interrotti (inattivi) e processi che sono stati nascosti o scollegati da un rootkit. Il rovescio della medaglia è che i rootkit possono ancora nascondersi sovrascrivendo i valori del pool tag (sebbene non siano comunemente visti).

Se un processo è stato precedentemente chiuso, il campo Time exited mostrerà il tempo di uscita. Se si vuole ricercare un processo nascosto (come visualizzare le sue DLL), allora si avrà bisogno dell’offset fisico dell’oggetto _EPROCESS, che è mostrato nella colonna più a sinistra. Quasi tutti i plug-in relativi al processo utilizzano un parametro –OFFSET per poter lavorare con processi nascosti.

Nota: A pool tag is a four-byte character that is associated with a dynamically allocated chunk of pool memory.  The tag is specified by a driver when it allocates the memory. (https://blogs.technet.microsoft.com/askperf/2008/04/11/an-introduction-to-pool-tags/)

psdispscan

Questo plugin è simile a psscan, ma enumera i processi eseguendo la scansione di DISPATCHER_HEADER invece dei pool tags. Questo fornisce un modo alternativo per rilevare oggetti _EPROCESS nel caso in cui un utente malintenzionato tentasse di nascondersi modificando i  pool tags. Questo plugin non è ben gestito e supporta solo XP x86. Per usarlo, è necessario digitare:      –plugins = contrib / plugins su riga di comando

dlllist

Per visualizzare le DLL caricate di un processo, si utilizza il comando dlllist. Il comando scorre la lista delle strutture _LDR_DATA_TABLE_ENTRY a cui fa riferimento l’InLoadOrderModuleList del PEB. Le DLL vengono aggiunte automaticamente a questo elenco quando un processo chiama LoadLibrary (o altra derivata come LdrLoadDll) e non vengono rimossi finché FreeLibrary non viene chiamato e il conteggio dei riferimenti raggiunge lo zero. La colonna del conteggio dei load indica se una DLL è stata caricata staticamente (ad esempio come risultato dell’exe o di un’altra tabella di importazione della DLL) o caricata in modo dinamico.

Per visualizzare le DLL per un processo specifico anziché tutti i processi, si utilizza il filtro -p o pid. Inoltre, nel seguente output, si nota che si sta analizzando un processo Wow64. I processi di Wow64 hanno un elenco limitato di DLL negli elenchi PEB, ma ciò non significa che siano le uniche DLL caricate nello spazio degli indirizzi del processo. Quindi Volatility  ricorderà di usare i ldrmodules per questi processi. Per visualizzare le DLL per un processo nascosto o scollegato da un rootkit, utilizzare prima psscan per ottenere lo offset fisico dell’oggetto EPROCESS e fornirlo con — offset = OFFSET. Il plug-inrimbalzerà” e determinerà l’indirizzo virtuale di EPROCESS e quindi acquisirà uno spazio indirizzo per accedere al PEB

Nota:

  • Win32 Process Environment Block (PEB)
  • PID (Process Id – identificatore unico del processo nel sistema. Non appena il sistema interpreta un comando, per la sua esecuzione viene creato un processo indipendente dotato di un numero di identificazione (PID) esclusivo. Il sistema utilizza il PID per tenere traccia dello stato corrente di ogni processo.

dlldump

Per estrarre una DLL dallo spazio di memoria di un processo e scaricarla su disco per l’analisi, utilizzare il comando dlldump. La sintassi è quasi la stessa di quella che per dlllist. È possibile il dump di

  • tutte le DLL da tutti i processi;
  • tutte le DLL da un processo specifico (con pid = PID);
  • tutte le DLL da un processo nascosto / non collegato (con –offset = OFFSET);
  • un PE da qualsiasi punto della memoria del processo (con –base = BASEADDR), questa opzione è utile per estrarre DLL nascoste;
  • una o più DLL che corrispondono a un’espressione regolare (regex = REGEX), case sensitive o meno (ignore-case).

Se l’estrazione non riesce, come mostrato in figura, probabilmente alcune delle pagine di memoria di quella DLL non erano residenti in memoria (a causa del paging). In particolare, questo è un problema se la prima pagina che contiene l’intestazione PE e quindi i mapping delle sezioni PE non sono disponibili. In questi casi si può ancora estrarre il segmento di memoria usando il comando vaddump, ma si dovrà ricostruire manualmente l’intestazione PE e correggere le sezioni (se si ha intenzione di analizzare con IDA Pro). Per eseguire il dump di un file PE che non esiste nell’elenco delle DLL (ad esempio, a causa code injectiono maliciousunlinking), è sufficiente specificare l’indirizzo di base del PE del processo in memoria:

vol.py --profile=WinXPSP3x86 -f win7.dmp dlldump --pid=492 -D out --base=0x00680000

È possibile specificare un offset per EPROCESS se la DLL di interesse è in un processo nascosto:

vol.py --profile=WinXPSP3x86 -f win7.dmp dlldump -o 0x3e3f64e8 -D out --base=0x00680000

handles

Per visualizzare gli handles aperti in un processo, utilizzare il comando handles. Questo vale per i file, le chiavi di registro, i mutexes, i named pipes, gli eventi, le windows, i desktop, i thread e tutti gli altri tipi di oggetti esecutivi sicuri. A partire dalla versione 2.1, l’output include il valore di handle e l’accesso concesso per ciascun oggetto

È possibile visualizzare gli handle per un particolare processo specificando pid = PID o l’offset fisico di una struttura _EPROCESS                (physical-offset=OFFSET). È possibile anche filtrare per tipo di oggetto usando -t o object-type=OBJECTTYPE.

Il tipo di oggetto può essere uno qualsiasi dei nomi visualizzati dal comando windbgobject\ObjectTypes.

In alcuni casi, la colonna dettagli potrebbe essere vuota (ad esempio, se gli oggetti non hanno nomi).

Per default, saranno visualizzati sia gli oggetti con nome che quelli senza. Tuttavia, se è possibile nascondere i risultati meno significativi e mostrare solo oggetti con nome, usando il parametro silent per questo plugin.

getsids

Per visualizzare i SID (Security Identifiers) associati a un processo, si utilizza il comando getsids. Ciò può aiutare a identificare i processi che hanno maliciously escalated privileges e quali processi appartengono a utenti specifici.

cmdscan

Il plugin cmdscan ricerca in memoria csrss.exe su XP/2003/Vista/2008 e conhost.exe su Windows 7 poiché potrebbero essere stati sostituiti da un utente malintenzionato attraverso una shell della console (cmd.exe). Questo plugin trova strutture note come COMMAND_HISTORY cercando un valore costante noto (MaxHistory) e quindi applicando i controlli di integrità. Il valore predefinito è 50 su sistemi Windows, ovvero i 50 comandi più recenti vengono salvati. È possibile modificarlo utilizzando il parametro  max_history=NUMBER. Le strutture utilizzate da questo plugin non sono pubbliche (ad esempio, Microsoft non produce PDB per loro), quindi non sono disponibili in WinDBG o in qualsiasi altro framework forense. Oltre ai comandi inseriti in una shell, questo plugin mostra:

  • il nome del processo host della console (csrss.exe o conhost.exe); 
  • il nome dell’applicazione che utilizza la console (qualunque processo stia utilizzando cmd.exe);
  • la posizione dei buffer della cronologia dei comandi, incluso il buffer corrente di «conteggio», l’ultimo comando aggiunto e l’ultimo comando visualizzato; l’handle del processo applicazione

A causa della tecnica di scansione utilizzata da questo plugin, è possibile ricavare la cronologia dei comandi da console sia attive sia chiuse.

consoles

Simile a cmdscan, il plugin consoles trova i comandi che sono stati digitati in cmd.exe o eseguiti tramite backdoor. Tuttavia, anziché eseguire la scansione di COMMAND_HISTORY, questo plugin esegue la scansione di CONSOLE_INFORMATION. Il vantaggio principale di questo plugin è che non solo visualizza i comandi digitati (anche da chi compier un’intrusione!), ma comprende l’intero buffer dello schermo (input e output). Ad esempio, invece di vedere il solo comando “dir“, verrà riportato esattamente ciò che è stato visualizzato, inclusi tutti i file e le directory elencati dal comando “dir“.

Notare come l’utente sembra non riesca a trovare lo strumento dd.exe per la copia di dati. Quasi 20 errori di battitura più tardi, lo trova e lo usa.

Inoltre, questo plugin mostra quanto segue:

  • titolo della finestra della console originale e titolo della finestra della console corrente;
  • il nome e il pid dei processi allegati (scorre LIST_ENTRY per enumerarli tutti se più di uno);
  • qualsiasi alias associato ai comandi eseguiti. Ad esempio, gli autori di attacchi possono registrare un alias in modo che digitando “hello” venga effettivamente eseguito “cd system“;
  • le coordinate dello schermo della console cmd.exe.

verinfo

Per visualizzare le informazioni sulla versione incorporate nei file PE, utilizzare il comando verinfo. Non tutti i file PE hanno informazioni sulla versione e molti autori di malware lo forgiano per includere dati falsi; ciò nonostante può essere molto utile per identificare i binari e creare correlazioni con altri file.

Questo plugin supporta solo le informazioni sulla versione da file eseguibili e DLL, ma in seguito verrà ampliato per includere i moduli del kernel. Se si desidera filtrare in base al nome del modulo, utilizzare le opzioni —regex = REGEX e/o —ignore-case.

enumfunc

Questo plugin enumera le funzioni importate ed esportate da processi, DLL e driver del kernel. Nello specifico, gestisce le funzioni importate ed esportate per nome o numero ordinale e le esportazioni inoltrate. L’output sarà molto dettagliato nella maggior parte dei casi (le funzioni esportate da ntdll, msvcrt e kernel32 possono raggiungere più di 1000 voci ciascuna). Quindi è possibile ridurre l’eccesso di risultati filtrando i criteri con le opzioni da riga di comando (vds -h) oppure si può sfruttare il codice in enumfunc.py come esempio per l’uso delle funzioni API di per l’analisi delle tabelle IAT e EAT. Ad esempio, il pluginapihooks sfrutta le API di importazione ed esportazione per trovare le funzioni in memoria durante il controllo degli hook.

È possibile utilizzare –s per la ricerca di processi e driver del kernel. Questo può essere utile se si sta cercando di enumerare le funzioni in processi o driver nascosti.

Nota: IAT e EAT: tabelle degli indirizzi di importazione/esportazione situate all’interno del PE.

Per mostrare le funzioni esportate dai processi in memoria, usare -P e –E :

Per mostrare le funzioni importate dai processi in memoria, usare -K e –I :

Process Memory

Se proviamo ad analizzare la memoria più a fondo, senza soffermarsi solo sui processi, possiamo trovare altre informazioni interessanti.

memmap

Il comando memmap mostra esattamente quali pagine sono residenti in memoria, dato un DTB di processo specifico (o DTB del kernel se si utilizza questo plugin sul processo Idle o System). Verrà  mostrato l’indirizzo virtuale della pagina, l’offset fisico corrispondente e la dimensione della pagina. Le informazioni generate da questo plugin provengono dal metodo get_available_addresses. Dalla versione 2.1, la nuova colonna DumpFileOffset aiuta a correlare l’output di memmap con il filedump prodotto dal plugin memdump.

Ad esempio, in base all’output qui sopra, la pagina all’indirizzo virtuale 0x0000000000058000 del processo di memoria System può essere trovata all’offset 0x00000000162ed000 del file win7_trial_64bit.raw. Dopo aver utilizzato memdump per estrarre la memoria indirizzabile del processo System, è possibile trovare questa pagina all’offset 0x8000.

Per estrarre tutte le pagine residenti in memoria di un processo in un singolo file, utilizzare il comando memdump, specificando la directory di destinazione con -D o —dump-dir = DIR.

A questo punto dovremmo essere in grado di formulare un’affermazione riguardante la relazione delle pagine mappate ed estratte:

procdump

Per eseguire il dump di un processo eseguibile, si utilizza il comando procdump. È possibile usare i flagunsafe o -u per ignorare determinati controlli di integrità utilizzati durante l’analisi dell’intestazione PE. Alcuni malware falsificheranno intenzionalmente i campi delle dimensioni nell’intestazione PE per evitare che gli strumenti di dumping della memoria funzionino.

Usare –memory per includere lo slack space tra le sezioni PE che non sono allineate alla pagina, altrimenti si otterrà un file che ricorda più il file su disco, prima che le sezioni vengano espanse.

procmemdump e procexedump (dalla ver. 2.4 di Volatility)

Quando gli eseguibili vengono caricati dal disco, Windows utilizza l’intestazione PE per determinare il numero di pagine, e con quali autorizzazioni, verranno allocate per ciascuna sezione. L’intestazione descrive la dimensione e la posizione di ciascuna sezione sul disco e le sue dimensioni e posizione in memoria. Poiché le sezioni devono essere allineate alla pagina in memoria, ma non sul disco, questo in genere comporta l’aggiunta di spazio tra le sezioni quando vengono caricate in memoria. Ci sono anche modifiche apportate in memoria a causa di rilocazioni e funzioni importate.

Durante il recupero degli eseguibili dalla memoria, esistono alcune limitazioni del tool di ripristino, per esempio le pagine dell’eseguibile potrebbero non essere nel pagefile.sys, o non essere valide, o non essere state ancora caricate.

procmemdump

Con questo comando si può recuperare la rappresentazione in memoria di un eseguibile. Ciò significa che nei file generati da questo plugin le pagine sono allineate in memoria, non allineate al disco.

$ python vol.py -f ~/Downloads/unknown.img procmemdump -p 1440 -D ~/Downloads/memf/ 

procexedump

Con questo comando si può recuperare ancora l’eseguibile, ma questa volta è possibile riallineare le sezioni così come erano sul disco. Ciò avviene analizzando l’intestazione PE in memoria e usato per annullare alcune delle modifiche apportate al momento del caricamento.

vadinfo

Il comando vadinfo visualizza informazioni estese sui nodi VAD di un processo. In particolare, mostra:

  • l’indirizzo della struttura MMVAD nella memoria del kernel;
  • gli indirizzi virtuali iniziali e finali nella memoria di processo a cui appartiene la struttura MMVAD;
  • il tag VAD;
  • i flag VAD, i flag di controllo, ecc;
  • il nome del file mappato in memoria (se ne esiste uno); la costante di protezione della memoria (permessi).

Nota: VAD (virtual address descriptor), è l’acronimo di descrittore di indirizzo virtuale. Il kernel di Windows organizza la memoria allocata dal processo (o dal kernel) in un albero di assegnazioni con tag VAD. C’è una differenza tra la protezione originale e la protezione corrente. La protezione originale è derivata dal parametro flProtect in VirtualAlloc. Ad esempio è possibile riservare la memoria (MEM_RESERVE) con la protezione PAGE_NOACCESS (protezione originale). Successivamente, è possibile chiamare di nuovo VirtualAlloc per eseguire il commit (MEM_COMMIT) e specificare PAGE_READWRITE (diventa la protezione corrente). Il comando vadinfo mostra solo la protezione originale. Pertanto, solo perché si legge PAGE_NOACCESS, non significa che il codice nella regione non possa essere letto, scritto o eseguito.

vadtree

Per visualizzare i nodi VAD come una struttura ad albero, si può utilizzare il comando vadtree.

Se si desidera visualizzare l’albero binario nel formato Graphviz, è sufficiente aggiungere –output = dot –output-file = graph.dot al proprio comando. Quindi sarà possibile aprire graph.dot con un qualsiasi visualizzatore compatibile con Graphviz. Questo plugin supporta anche la codifica a colori dell’output in base alle regioni che contengono stack, heap, file mappati, DLL, ecc.

vaddump

Per estrarre l’intervallo di pagine descritto da un nodo VAD, si utilizza il comando vaddump. È simile al memdump, eccetto che le pagine che appartengono a ciascun nodo VAD sono collocate in file separati (denominati in base agli indirizzi di inizio e fine) invece di un grande file conglomerato. Se alcune pagine dell’intervallo non sono residenti in memoria, vengono riempite con 0 utilizzando il metodo zread () dello spazio di indirizzo.

I file sono denominati in questo modo:

ProcessName.PhysicalOffset.StartingVPN.EndingVPN.dmp

La ragione per cui esiste il campo PhysicalOffset è che in questo modo è possibile distinguere tra due processi con lo stesso nome.

iehistory

Questo plugin recupera frammenti di file di cache della cronologia IE in index.dat Può trovare collegamenti accessibili (via FTP o HTTP), collegamenti reindirizzati (– REDR) e voci cancellate (– LEAK). Si applica a qualsiasi processo che carica e utilizza la libreria wininet.dll, non solo per Internet Explorer. In genere include “esplora risorse” di Windows e persino campioni di malware.

Kernel Memory e Objects

modules

Per visualizzare l’elenco dei driver del kernel caricati sul sistema, si utilizza il comando modules. Scorre la lista delle strutture LDR_DATA_TABLE_ENTRY indicate da PsLoadedModuleList.

Simile al comando pslist, si basa sulla ricerca della struttura KDBG. In rari casi, potrebbe essere necessario utilizzare kdbgscan per trovare l’indirizzo della struttura KDBG più appropriato e quindi fornirlo a questo plugin come kdbg = ADDRESS.

Poiché questo plugin “scorre la lista”, in genere è possibile presumere che l’ordine di visualizzazione dei moduli nell’output sia l’ordine in cui questi sono stati caricati nel sistema. Nell’esempio è stato caricato dapprima ntoskrnl.exe, seguito da hal.dll e così via.

L’output mostra l’offset della struttura LDR_DATA_TABLE_ENTRY, che è un indirizzo virtuale per default, ma può essere specificato come indirizzo fisico con lo switch -P come mostrato in figura. In entrambi i casi, la colonna Base è l’indirizzo virtuale della base del modulo nella memoria del kernel (dove ci si aspetterebbe di trovare l’intestazione PE).

Nota:

  • Kernel Debugging Block (KDBG), è una struttura gestita dal kernel di Windows a scopo di debug. Contiene un elenco dei processi in esecuzione e dei moduli del kernel caricati. Contiene anche alcune informazioni sulla versione che consentono di determinare se un dump della memoria proviene da un sistema Windows XP piuttosto che Windows 7, quale Service Pack è stato installato e il modello di memoria (32 bit vs 64 bit).
  • Modules non riesce a trovare i driver del kernel nascosti/non collegati, per questo scopo usare modscan.

modscan

Il comando modscan trova le strutture LDR_DATA_TABLE_ENTRY analizzando la memoria fisica per i pool tags. Questo può raccogliere driver, anche quelli precedentemente scaricati che sono stati nascosti/scollegati dai rootkit. A differenza di modules, l’ordine dei risultati non ha alcuna relazione con l’ordine in cui sono stati caricati i driver. Come si può notare in figura, infatti, DumpIt.sys riporta l’offset fisico più basso, ma probabilmente era uno degli ultimi driver da caricare (dato che era usato per acquisire la memoria).

moddump

Per estrarre un driver del kernel in un file, si utilizza il comando moddump, indicando la directory di destinazione con -D o dump-dir = DIR. Senza parametri aggiuntivi, tutti i driver identificati da modlist verranno scaricati. Se si desidera un driver specifico, fornire un’espressione regolare del nome del driver con regex = REGEX o l’indirizzo base del modulo con –base = BASE.

Simile a dlldump, se le parti critiche dell’intestazione PE non sono residenti in memoria, la ricostruzione/estrazione del driver potrebbe non riuscire. Inoltre, per i driver mappati in sessioni diverse (come win32k.sys), non esiste attualmente alcun modo per specificare quale sessione utilizzare quando si acquisisce il driver.

filescan

Per trovare FILE_OBJECT nella memoria fisica utilizzando la scansione dei tag pool, si può utilizzare il comando filescan. Verranno trovati i file aperti anche se un rootkit li nasconde sul disco e se li aggancia ad alcune funzioni API per nascondere gli handle aperti su un sistema live. L’output mostra l’offset fisico di FILE_OBJECT, il nome del file, il numero di puntatori all’oggetto, il numero di handle per l’oggetto e le autorizzazioni concesse all’oggetto

symlinkscan

Questo plugin esegue la scansione degli oggetti di collegamento simbolici e mostra le loro informazioni. In passato, questo era stato utilizzato per collegare lettere di unità (ad esempio D :, E :, F :, ecc) a veri volumi di crittografia (ad esempio \ Device \ TrueCryptVolume).

dumpfiles

Un concetto importante per ogni analista informatico (non solo forense), così come  per coloro che hanno a che fare coi sistemi operativi, è intimamente familiare con il caching. I file vengono memorizzati nella cache per sostenere le prestazioni del sistema quando i file stessi vengono utilizzati e acceduti. Ciò rende la cache una fonte preziosa da una prospettiva forense dal momento che si è in grado di recuperare i file che erano correttamente in uso. I file scaricati dalla memoria possono quindi essere elaborati con strumenti esterni.

Esistono diverse opzioni per il plugin dumpfiles:

Nota: al contrario del file carving che non si preoccupa di come gli oggetti sono mappati in memoria. I file potrebbero non essere completamente mappati in memoria (anche per le prestazioni), quindi le sezioni mancanti sono riempite con degli zero.

Per impostazione predefinita, il dumpfiles esegue l’iterazione attraverso il VAD, estraendo tutti i file mappati come DataSectionObject, ImageSectionObject o SharedCacheMap. Da un punto di vista  investigativo, tuttavia, si potrebbe voler eseguire una ricerca più mirata. È possibile utilizzare i flag -r e -i per specificare un’espressione regolare senza distinzione tra maiuscole e minuscole di un nome di file. Nell’output riportato è possibile vedere da dove è stato eseguito il dump dei file (DataSectionObject, ImageSectionObject o SharedCacheMap), l’offset di _FILE_OBJECT, il PID del processo il cui VAD conteneva il file e il percorso del file su disco:

Il nome dump file è nel formato:

        file. [PID]. [OFFSET] .ext

OFFSET è l’offset di SharedCacheMap o di _CONTROL_AREA, non di _FILE_OBJECT.

L’estensione (EXT) può essere:

    img – ImageSectionObject

    dat – DataSectionObject

    vacb – SharedCacheMap

Possiamo osservare nel -S/–summary-file per recuperare il nome originale del file :

È inoltre possibile utilizzare lo script parsesummary.py per analizzare l’output JSON del file di riepilogo. Quanto segue mostra un esempio di utilizzo dello script. Oltre al nome del file originale, del PID del processo con il file aperto e la dimensione, è possibile vedere quali pagine erano presenti e quali mancanti e di conseguenza riempite con degli zer0 nell’output di riepilogo analizzato:

È possibile usare, inoltre, l’opzione -n​/–name per scaricare i file con il nome originale.

Non tutti i file saranno attualmente attivi o nel VAD e tali file non verranno scaricati quando si utilizza l’opzione -r/–regex. Per questi file è possibile prima cercare un _FILE_OBJECT e quindi usare il flag    -Q/–physoffset per estrarre il file. I file speciali NTFS sono esempi di file che devono essere scaricati in modo specifico.

L’opzione -f/–filter consente di specificare quale parte del file si desidera eseguire il dump (DataSectionObject, ImageSectionObject o SharedCacheMap).

Ad esempio, se si desidera visualizzare solo le informazioni di stato per un file eseguibile, è possibile specificare              filter = ImageSectionObject.

unloadedmodules

Windows memorizza le informazioni sui driver scaricati di recente a scopo di debug. Questo fornisce un modo alternativo per determinare cosa è successo su un sistema, oltre ai ben noti moduli e plugin modscan.

Networking

connections

Per visualizzare le connessioni TCP attive al momento dell’acquisizione della memoria, si utilizza il comando connections. Questo modulo scorre la tabella handle in tcpip.sys e visualizza le connessioni correnti. L’output include l’offset virtuale di _TCPT_OBJECT per default, quello fisico può essere ottenuto con l’opzione –P.

Note:

  • funziona solo per x86 e x64,  Windows XP e Windows 2003 Server;
  • se si utilizza un’immagine ibernata, questo potrebbe non funzionare perché Windows chiude tutte le connessioni prima della sospensione. Si potrebbe trovare più efficace invece connscan.

connscan

Per trovare le strutture _TCPT_OBJECT utilizzando la scansione dei pool tags, si ricorre al comando connscan. È possibile rilevare, oltre alle connessioni attive, anche quelle precedenti terminate.

Note:

  • funziona solo per x86 e x64,  Windows XP e Windows 2003 Server;
  • nell’output in esempio, alcuni campi sono stati parzialmente sovrascritti, ma alcune informazioni sono ancora presenti; infatti, il campo PID dell’ultima voce è 0, ma tutti gli altri campi sono ancora intatti. Quindi, a fronte di maggiori falsi positivi, si ottiene il vantaggio di rilevare quante più informazioni possibili.

sockets

Per rilevare socket di ascolto per qualsiasi protocollo (TCP, UDP, RAW, ecc.), si utilizzare il comando socket. In questo modo viene visualizzato un elenco di strutture socket aperte indicate nel modulo tcpip.sys.

L’output include l’offset virtuale di _ADDRESS_OBJECT per impostazione predefinita. L’offset fisico può essere ottenuto con lìopzione -P. Funziona solo per x86 e x64,  Windows XP e Windows 2003 Server.

sockscan

Per trovare le strutture _ADDRESS_OBJECT utilizzando la scansione dei pool tag, si ricorre al comando sockscan. Come con connscan, è possibile raccogliere dati residui e artefatti da socket precedenti.

Funziona solo per x86 e x64,  Windows XP e Windows 2003 Server.

netscan

Per eseguire la scansione degli artefatti di rete in Windows Vista a 32 e 64 bit, Windows 2008 Server e Windows 7, si utilizza il comando netscan. Questo trova endpoint TCP, listener TCP, endpoint UDP e listener UDP. Distingue tra IPv4 e IPv6, stampa l’IP locale e remoto (se possibile), la porta locale e remota (se possibile), quando il socket è stato collegato o quando è stata stabilita la connessione e lo stato corrente (solo per le connessioni TCP).

netscan utilizza la scansione dei pool tag.

Note:

  • Un endpoint è una coppia (indirizzo IP, porta), una connessione è una coppia di endpoint (sorgente, destinazione).
  • Esistono almeno 2 modi alternativi per enumerare connessioni e socket sui sistemi operativi Vista. Uno di questi utilizza le partizioni e le tabelle hash dinamiche, che è il modo in cui funziona netstat.exe sui sistemi Windows. L’altro include bitmap e port pool.
  • Port pools e bitmap rappresenta un altro approccio per enumerare l’attività di rete nei dump della memoria. Questi ports pool contengono una bitmap di 65535 bit (un bit rappresenta ciascuna porta su un sistema) e un numero uguale di puntatori alle strutture _PORT_ASSIGNMENT. Un modo estremamente rapido per determinare quali porte sono in uso su un sistema è semplicemente quello di scansionare la bitmap (0 = non usato, 1 = usato). Se è impostato un bit, Windows utilizza l’indice del bit per calcolare l’indirizzo della corrispondente struttura: TCPLISTENER, TCP_ENDPOINT o UDP_ENDPOINT.

Windows Registry

hivescan

Per trovare gli indirizzi fisici di CMHIVE (registry hives) in memoria, utilizzare il comando hivescan.

Questo plugin non è generalmente utile da solo. Dovrebbe essere ereditato da altri plugin (come hivelist trattato di seguito) che si basano su CMHIVE e interpretano le informazioni trovate in nello stesso registro.

Per individuare gli indirizzi virtuali degli hive del registro di sistema nella memoria e i percorsi completi per l’hive corrispondente sul disco, si utilizza il comando hivelist. Se si desidera stampare valori da un certo hive, eseguire prima questo comando in modo da poter rilevare l’indirizzo dell’hives.

Nota: il registro si trova in una serie di file binari, che prendono il nome di hive (“alveare”).

Windows NT-based systems store the registry in a binary file format which can be exported, loaded and unloaded by the Registry Editor in these operating systems. The following system Registry files are stored in %SystemRoot%\System32\Config\:

  • Sam – HKEY_LOCAL_MACHINE\SAMSecurity – HKEY_LOCAL_MACHINE\SECURITY
  • Software – HKEY_LOCAL_MACHINE\SOFTWARE
  • System – HKEY_LOCAL_MACHINE\SYSTEM
  • Default – HKEY_USERS\.DEFAULT
  • Userdiff – Not associated with a hive. Used only when upgrading operating systems

    The following file is stored in each user’s profile folder:

    %UserProfile%\Ntuser.dat – HKEY_USERS\<User SID> (linked to by HKEY_CURRENT_USER)

For Windows 2000, Server 2003 and Windows XP, the following additional user-specific file is used for file associations and COM information:

    %UserProfile%\Local Settings\Application Data\Microsoft\Windows\Usrclass.dat (path is localized) – HKEY_USERS\<User SID>_Classes (HKEY_CURRENT_USER\Software\Classes)

For Windows Vista and later, the path was changed to:

    %UserProfile%\AppData\Local\Microsoft\Windows\Usrclass.dat (path is not localized) alias %LocalAppData%\Microsoft\Windows\Usrclass.dat – HKEY_USERS\<User SID>_Classes (HKEY_CURRENT_USER\Software\Classes)

Windows 2000 kept an alternate copy of the registry hives (.ALT) and attempts to switch to it when corruption is detected. Windows XP and Windows Server 2003 do not maintain a System.alt hive because NTLDR on those versions of Windows can process the System.log file to bring up to date a System hive that has become inconsistent during a shutdown or crash. In addition, the %SystemRoot%\Repair folder contains a copy of the system’s registry hives that were created after installation and the first successful startup of Windows. Each registry data file has an associated file with a “.log” extension that acts as a transaction log that is used to ensure that any interrupted updates can be completed upon next startup. Internally, registry files are split into 4 kB “bins” that contain collections of “cells”.

printkey

Per visualizzare sottochiavi, valori, dati e tipi di dati contenuti in una chiave di registro specificata, utilizzare il comando printkey. Per default cercherà tutti gli hives e fornirà le informazioni (se trovate) per la chiave richiesta. Pertanto, se la chiave si trova in più di un hive, le informazioni relative alla chiave verranno fornite per ciascun hive che la contiene.

Nell’esempio, è mostrato come ricercare informazioni nella chiave HKEY_LOCAL_MACHINE \ Microsoft \ Security Center \ Svc.

Nota: se si sta utilizzando Volatility su Windows, è necessario racchiudere la chiave tra virgolette.

Qui possiamo vedere come appare l’output quando più hive (DEFAULT e ntuser.dat) contengono la stessa chiave “Software \ Microsoft \ Windows NT \ CurrentVersion“.

Se si desidera restringere la ricerca a un hive specifico, printkey accetta anche un indirizzo virtuale dell’hive. Ad esempio, per visualizzare il contenuto di HKEY_LOCAL_MACHINE, utilizzare il comando come mostrato in figura.

Nota: l’offset viene ricavato dall’output hivelist precedente.

hivedump

Per elencare in modo ricorsivo tutte le sottochiavi di ​​un hive, si utilizza il comando hivedump fornendo l’indirizzo virtuale dell’hive desiderato.

hashdump

Per estrarre e decodificare le credenziali del dominio memorizzate nel registro, utilizzare il comando hashdump.

Per utilizzare hashdump, passare l’indirizzo virtuale dell’hive SYSTEM con l’opzione -y e l’indirizzo virtuale dell’hive SAM con –s.

Gli hash possono ora essere sottoposti  a software per il password cracking come John the Ripper, rainbow tables, HashCat, ecc.

È possibile che una chiave del registro di sistema non sia disponibile in memoria. Quando ciò accade, potrebbe occorrere il seguente errore: “ERROR: volatility.plugins.registry.lsadump: Unable to read hashes from registry

È possibile provare a vedere se sono disponibili le chiavi corrette: “CurrentControlSet\Control\lsa” da SYSTEM e “SAM\Domains\Account” da SAM.

Per prima cosa è necessario ottenere il “CurrentControlSet“, per questo possiamo usare volshell (sostituire [SYSTEM REGISTRY ADDRESS] con l’offset ottenuto da hivelist):

Quindi usare il plugin printkey per verificare che le chiavi e i loro dati siano lì. Poiché “CurrentControlSet” è 1 nell’esempio, come primo comando utilizzeremo “ControlSet001” :

In mancanza della chiave avremmo il messaggio di errore: “The requested key could not be found in the hive(s) searched”.

lsadump

Per scaricare i LSA secrets dal registro, si utilizza il comando lsadump. Mostrerà informazioni quali la password predefinita (per i sistemi con autologin abilitato), la chiave pubblica RDP e le credenziali utilizzate da DPAPI.

Le possibili voci sono:

  • $MACHINE.ACC: autenticazione del dominio Microsoft;
  • DefaultPassword: password utilizzata per accedere a Windows quando è abilitato l’accesso automatico.
  • NL$KM: chiave segreta utilizzata per crittografare le password del dominio memorizzate nella cache;
  • L$RTMTIMEBOMB_*: timestamp che indica la data in cui una copia non attivata di Windows cesserà di funzionare. L$HYDRAENCKEY_*: chiave privata utilizzata per il Remote Desktop Protocol (RDP). Se si dispone anche di una cattura dei pacchetti da un sistema attaccato tramite RDP, è possibile estrarre la chiave pubblica del client dal pacchetto catturato, e la chiave privata del server dalla memoria; quindi decifrare il traffico.

Note:

  • I LSA secrets sono uno speciale spazio di archiviazione protetto per i dati importanti utilizzati dalla Local Security Authority (LSA) in Windows. LSA è progettato per la gestione della politica di sicurezza locale di un sistema, il controllo, l’autenticazione, la registrazione degli utenti sul sistema, la memorizzazione di dati privati. I dati sensibili degli utenti e del sistema sono memorizzati nei secrets. L’accesso a tutti i dati segreti è disponibile solo per il sistema.
  • È possibile utilizzare una firma digitale per firmare i file con estensione rdp utilizzati per le connessioni a desktop virtuali tramite Connessione RemoteApp e desktop. Sono inclusi i file rdp utilizzati per le connessioni ai pool di desktop virtuali e ai desktop personali virtuali.Il file RDP (Remote Desktop Protocol) contiene il token EndpointFedAuth. Il possesso di tale file consente di accedere alla console di una macchina virtuale specifica.
  • Data Protection application programming interface (DPAPI), a partire da Windows 2000, il sistema operativo ha iniziato a fornire un’interfaccia di programmazione delle applicazioni (API) per la protezione dei dati. Questa API di protezione dei dati (DPAPI) è una coppia di chiamate di funzione che forniscono servizi di protezione dei dati a livello di sistema operativo ai processi dell’utente e di sistema.

userassist

Per ottenere le chiavi di registro UserAssist è possibile utilizzare il plugin userassist. UserAssist tiene traccia dei programmi eseguiti, del numero di esecuzioni e dell’ultima data e ora di esecuzione

Note:

  • Per maggiori informazioni vds il post del plugin UserAssist per volatility di Gleeda.
  • I sistemi Windows mantengono un set di chiavi nel database del registro (chiavi UserAssist) per tenere traccia dei programmi eseguiti. Il numero di esecuzioni e l’ultima data e ora di esecuzione sono disponibili in queste chiavi. Le informazioni all’interno dei valori binari UserAssist contengono solo dati statistici sulle applicazioni lanciate dall’utente tramite Windows Explorer. I programmi avviati tramite la riga di comando (cmd.exe) non compaiono in queste chiavi di registro. Da un punto di vista forense, essere in grado di decodificare queste informazioni può essere molto utile.

shellbags

Questo plugin analizza e visualizza le informazioni Shellbag ottenute dal registro. Ci sono due opzioni per l’output: verbose (default) e il formato bodyfile.

In Shellbags possono essere trovate queste informazioni:

  • dimensioni e preferenze delle windows;
  • impostazioni di visualizzazione icone e cartelle;
  • metadati come i timestamp MAC
  • file e tipo di file utilizzati più di recente (zip, directory, programma di installazione);
  • file, cartelle, file zip, programmi di installazione (anche se cancellati);
  • condivisioni di rete e di cartelle;
  • metadati associati a uno dei tipi sopra elencati che possono includere timestamp e percorsi assoluti; volumi crittografici True Crypt.

Note:

  • Shellbags” è un termine comunemente usato per descrivere una raccolta di chiavi del registro di sistema che consente al “sistema operativo Windows di tracciare le preferenze di visualizzazione della finestra utente specifiche per Windows Explorer”.
  • Per ulteriori informazioni, consultare Shellbags in Memory, SetRegTime e TrueCrypt Volumes.

Un’altra opzione è usare —output = body per il formato file TSK 3.x bodyfile. È possibile utilizzare questa opzione quando si desidera combinare l’output di mftparser e timeliner. È possibile anche includere un identificatore di macchina nell’intestazione del bodyfile con il flag –machine (questo è utile quando si combinano timeline da più macchine). Solo gli elementi ITEMPOS e FILE_ENTRY vengono generati con il formato bodyfile.

Note:

  • TSK 3.x bodyfile: the body file is an intermediate file when creating a timeline of file activity. It is a pipe (“|”) delimited text file that contains one line for each file.
  • Mftparser: this plugin scans for potential Master File Table (MFT) entries in memory (using “FILE” and “BAAD” signatures) and prints out information for certain attributes, currently: $FILE_NAME ($FN), $STANDARD_INFORMATION ($SI), $FN and $SI attributes from the $ATTRIBUTE_LIST, $OBJECT_ID (default output only) and resident $DATA.
  • Timeliner: this timeliner plugin creates a timeline from various artifacts in memory.

shimcache

Questo plugin analizza la chiave di registro Application Compatibility Shim Cache.

I metadati dei file che vengono eseguiti su un sistema Windows sono collocati all’interno di questa struttura dati sul sistema in esecuzione. Al momento dell’arresto del sistema, questa struttura dati viene serializzata sul registro in uno dei due percorsi del registro in base alla versione del sistema operativo.

dumpregistry

Il plugin dumpregistry consente di scaricare l’hive del registro di sistema sul disco. Per default, il plugin eseguirà il dump di tutti i file di registro (inclusi i registri virtuali come HARDWARE) sul disco, tuttavia è possibile specificare l’offset virtuale per un hive specifico per scaricare solo un registro alla volta. Un avvertimento sull’utilizzo di questo plugin (o del plugin dumpfiles) è che potrebbero esserci dei buchi nel dump del registro che potrebbero bloccare questi tools se non abbastanza robusti per gestire file “corrotti”. Questi buchi sono indicati nell’output come: Physical layer returned None for index 2000, filling with NULL.

Si noti che il registro HARDWARE ha “Data” come tipo. Questo perché le prime celle del registro vengono azzerate. Se si esamina il registro con un editor esadecimale, si vedranno chiavi e valori validi.

È inoltre possibile scaricare un solo registro alla volta utilizzando l’offset virtuale dell’hive.

Analisi e conversione dei crash dump e degli hibernation files

Volatility supporta dump di memoria in diversi formati, questo per garantire la massima compatibilità con i differenti strumenti di acquisizione.

È possibile analizzare i file di ibernazione, i crash dump, i core dump di Virtualbox, ecc. nello stesso modo di qualsiasi dump di memoria e Volatility rileverà il formato di file alla base e applicherà lo spazio di indirizzamento appropriato.

È possibile anche la convertire tra formati di file.

crashinfo

Le informazioni nell’intestazione del crashdump possono essere visualizzate utilizzando il comando crashinfo.

hibinfo

Il comando hibinfo rivela informazioni aggiuntive memorizzate negli  hibernation file, incluse lo stato dei registri di controllo, come CR0, ecc. Identifica anche l’ora in cui è stato creato il file di ibernazione, lo stato del file di ibernazione e la versione di Windows in ibernazione.

Note:

  • A control register is a processor register which changes or controls the general behavior of a CPU or other digital device. Common tasks performed by control registers include interrupt control, switching the addressing mode, paging control, and coprocessor control.
  • CR0. The CR0 register is 32 bits long on the 386 and higher processors. On x86-64 processors in long mode, it (and the other control registers) is 64 bits long. CR0 has various control flags that modify the basic operation of the processor.

imagecopy

Il comando imagecopy consente di convertire qualsiasi tipo di indirizzo di uno spazio (come un crashdump, un file di ibernazione, un core dump di virtualbox, uno snapshot di vmware) in un’immagine di memoria grezza. Questa conversione è necessaria se alcuni degli strumenti forensi supportano solo la lettura di dump di memoria grezzi.

Il profilo dovrebbe essere specificato per questo comando, quindi se non si conosce, ricorrere prima ai comandi kdbgscan o imageinfo. Il file di output è specificato con il flag -O.

Lo stato di avanzamento viene aggiornato man mano che il file viene convertito.

raw2dmp

Per convertire un dump di memoria grezza (ad esempio da un’acquisizione win32dd o un file VMware.vmem) in un crash dump di Microsoft, si utilizza il comando raw2dmp.

È utile se si desidera caricare la memoria nel WinDbg kernel debugger per l’analisi.

vboxinfo

Per estrarre dettagli da un virtualbox core dump, si ricorre al comando vboxinfo.

vmwareinfo

Utilizzare questo plugin per analizzare le informazioni dell’intestazione del vmss (vmware saved state) o del vmsn (vmware snapshot).

I metadati contengono i registri della CPU, l’intero file di configurazione VMX, le informazioni sull’esecuzione della memoria e gli screenshots PNG della VM ospite.

Note:

  • The snapshot feature is most useful when you want to preserve the state of the virtual machine so you can return to the same state repeatedly.
  • When you suspend a virtual machine, a file with a .vmss extension is created. This file contains the entire state of the virtual machine.
  • You can take a screenshot of a virtual machine and save it to the clipboard, to a file, or to both a file and the clipboard.
  • When a take a screenshot of a virtual machine, the image is saved as a portable network graphics (.png) file by default. On Windows hosts, you can also save the screenshot as a bitmap (.bmp) file.
  • Note: while some VMware products store guest memory in .vmem files, other products (such as ESX) create these .vmsn or .vmss files when you suspend or take snapshots of running virtual machines. Since ESX is typically used for larger virtualization environments (compared to VMware Fusion or VMware Desktop), the capability to analyze .vmss/.vmsn can be critical in corporate IR/forensics.
  • You can convert a .vmss/.vmsn to a raw dd-style memory dump by extracting the physical memory runs to a separate file. To do this, use the imagecopy plugin.

hpakinfo

Questo plugin mostra informazioni da un dump di memoria con formato hpak creato da FDPro.exe.

hpakextract

Se si dispone di un file hpak il cui contenuto è compresso, è possibile estrarre e decomprimere l’immagine della memoria fisica utilizzando questo plugin.

Filesystem

mbrparser

Esegue la scansione e analizza i potenziali Master Boot Records (MBR). Ci sono diverse opzioni per trovare i MBR e filtrare l’output. Sebbene questo plugin sia stato scritto pensando ai bootkit di Windows, può essere utilizzato anche con campioni di memoria di altri sistemi.

Quando viene eseguito senza opzioni aggiuntive, mbrparser esegue la scansione e restituisce informazioni su tutti i potenziali MBR definiti dalla firma (‘\x55\xaa) rilevati in memoria. Le informazioni includono: disassemblaggio del codice di avvio (deve essere installato distorm3) e informazioni sulla partizione. Questo probabilmente genererà falsi positivi.

Se distorm3 non è installato, l’opzione -H /–hex può essere utilizzata per ottenere l’intera sezione bootcode in hex invece che disassemblata:

$ vol.py -f [sample] mbrparser -H

Se l’offset fisico dell’MBR è noto, può essere specificato con l’opzione -o/– offset=

$ vol.py -f [sample] -o 0x600 mbrparser

Note:

  • Per ulteriori informazioni, consultare Recovering Master Boot Records from Memory.
  • Il Bootkit è una recente tipologia di virus informatico, che si può vedere come un ibrido tra un virus del tipo che infetta i boot-sector e un virus tipo rootkit. Questo tipo di virus è molto difficile da eliminare in quanto è invisibile (quasi totalmente) dal suo PC infetto.
  • Distorm3 Powerful Disassembler Library For x86/AMD64.

Se l’hash MD5 del bootcode desiderato è noto, è possibile specificarlo utilizzando l’opzione -M/–hash (l’hash del bootcode fino all’istruzione RET – «Return from Procedure» ):

oppure l’opzione -F/–fullhash (l’hash del bootcode completo):

Per ridurre i falsi positivi esiste un’opzione di controllo -C/–check che controlla la tabella delle partizioni per trovarne una avviabile (di tipo noto) e non vuota (NTFS, FAT*, ecc.):

Esiste anche un’opzione per cambiare l’offset per l’inizio del disassemblaggio. Questo può essere utile per analizzare macchine (come Windows XP) che copiano solo la parte del bootcode MBR che non è stata ancora eseguita.

Ad esempio, prima di modificare l’offset:

dopo aver modificato l’offset iniziale:

mftparser

Questo plugin analizza le potenziali voci della Master File Table (MFT) in memoria (utilizzando le firme “FILE” e “BAAD“) e visualizza le informazioni per determinati attributi, attualmente: $FILE_NAME ($FN), $STANDARD_INFORMATION ($SI), $FN e $SI da $ATTRIBUTE_LIST, $OBJECT_ID (solo output predefinito) e $DATI residenti. Le opzioni di interesse includono:

  • –machine : nome del computer da aggiungere all’intestazione della timeline (utile quando si combinano timeline da più macchine);
  • -D/–dump-dir : directory di output;
  • –output=body : visualizza l’output nel formato Sleuthkit 3.X;
  • –no-check : visualizza tutte le voci incluse quelle con timestamp nullo;
  • -E/–entry-size : modifica la dimensione della voce MFT di 1024 byte predefinita;
  • -O/–offset : visualizza la voce MFT con un dato offset (delimitato da virgole).

Note:

  • Questo plugin ha spazio per l’espansione, tuttavia VTypes per altri attributi sono già inclusi.
  • Vtypes: A representation of structures used in the OS, such as size, names, members, types, and offsets

Questo plugin potrebbe impiegare un po’ di tempo prima dell’esecuzione dell’output, poiché prima esegue la scansione e quindi costruisce l’albero delle directory con percorsi di file completi.

Esempio (output predefinito):

Anche l’output di bodyfile è un’opzione. Si consiglia di archiviare l’output in un file utilizzando l’opzione –output-file, poiché potrebbe essere piuttosto lungo. Quanto segue mostra la creazione di un bodyfile usando mftparser durante il dumping dei file residenti. È anche possibile vedere un file di interesse creato sul sistema (f.txt) e recuperato nella directory di output:

mactime

L’utility mactime di Sleuthkit può essere utilizzata per generare il bodyfile in modo leggibile:

Windows GUI

sessions

Visualizza l’elenco dei dettagli di _MM_SESSION_SPACE sulle sessioni di accesso utente.

Ogni volta che si verifica un accesso, il kernel di Windows crea una nuova sessione, che è fondamentalmente un contenitore per processi e oggetti (come windows stations e desktop) che appartengono alla sessione.

L’analisi di queste strutture di sessione permette di rilevare le sessioni di accesso attive (e in alcuni casi terminate) da dump di memoria basati su Windows, inclusi i processi associati, i moduli del kernel, il pool. La struttura principale per una sessione è, appunto, _MM_SESSION_SPACE

Nota: gli elenchi di processi rilevati da questo plugin vengono sfruttati dal plugin psxview per il rilevamento dei rootkit.

wndscan

wndscan è un pool scanner per il tag WINDOWSTATION. Questo comando fornisce informazioni dettagliate sulle windows stations e sui processi che interagiscono con gli appunti. Questo comando potrebbe essere utilizzato in un’indagine per mostrare che un processo specifico stava usando gli appunti.

Verrà visualizzato:

  • nome della Window Station;
  • ID di sessione;
  • Atom Table;
  • Desktop;
  • processo di visualizzazione degli appunti; numero di elementi negli appunti.

Note:

  • Una sessione è composta da tutti i processi e da altri oggetti di sistema che rappresentano la sessione di accesso di un singolo utente. Questi oggetti includono tutte le finestre, i desktop e le  Windows Stations. Un desktop è un’area del pool di paging specifica della sessione e carica nello spazio di memoria del kernel. Questa area è da dove vengono allocati gli oggetti della GUI della sessione privata. Una Windows Stations è fondamentalmente un limite di sicurezza per contenere desktop e processi. Quindi, una sessione può contenere più di una Windows Station e ogni stazione Windows può avere più desktop.
  • Una atom table è una tabella definita dal sistema che memorizza stringhe e identificatori corrispondenti. Un’applicazione inserisce una stringa in una atom table e riceve un numero intero a 16 bit, chiamato atom, che può essere utilizzato per accedere alla stringa. Una stringa che è stata collocata in una atom table è chiamata atom name.
  • Gli atoms sono stringhe che possono essere facilmente condivise tra processi nella stessa sessione. Tuttavia, anziché passare il valore di stringa effettiva o eseguire operazioni di confronto tra stringhe, le atom table forniscono un’implementazione più semplice e veloce. In breve, un processo aggiunge un atom a una atom table passando una stringa a una funzione come AddAtom o GlobalAddAtom (o indirettamente tramite una API).
  • Le API AddAtom restituiscono un identificativo intero che il processo o altri processi possono utilizzare per recuperare la stringa. Una atom table è un «bucket hash» che contiene il numero intero di mapping di stringhe.

deskscan

Poolscanner per il tag DESKTOP (desktops)

deskscan enumera i desktop, le allocazioni dell’heap del desktop e i thread associati. Può essere utilizzato per i seguenti scopi:

  • aiuta a trovare i rogue desktop utilizzati per nascondere le applicazioni dagli utenti connessi;
  • rileva i desktop creati da ransomware;
  • collega i thread ai loro desktop;
  • analizza l’heap del desktop per individuare corruzioni della memoria; cerca le allocazioni dell’heap del desktop del profilo per individuare gli oggetti USER.

atomscan

Pool scanner per _RTL_ATOM_TABLE

Il plugin atomscan individua le tabelle atom nella memoria fisica cercando i pool tag e quindi eseguendo controlli di integrità nei campi Signature e NameLength. Non include gli atom locali del processo. Gli atom sono riportati nell’ordine in cui sono stati trovati, a meno che non si specifichi:

sort-by=atom (ordina per ID atom)

–sort-by=refcount (ordina per numero di riferimenti all’atom). Usando questo plugin è possibile trovare i window messages registrati, i percorsi delle DLL sospette «rogue injected», i nomi delle classi window, ecc.

atoms

Lo svantaggio di atomscan  è che non esiste un modo chiaro per collegare una tabella atom alla sua sessione proprietaria o alla window station.

Viene fornito, quindi, anche un secondo plugin, atoms, che è in grado di eseguire l’associazione. Questo plugin visualizza le atom table delle sessioni e delle window. Questo plugin mostrerà le informazioni sulla atom table e collegherà ogni voce alla sessione e alla window station che lo possiede. Questa informazione può essere utile nelle indagini sui malware scoprendo artefatti che molte persone non considererebbero nel tentativo di coprire le loro tracce.

clipboard

Questo comando può estrarre le informazioni memorizzate negli appunti. L’opzione –v visualizzerà i dati degli appunti in formato esadecimale.

Nota: in caso di copia e incolla di un file da Windows Explorer, il contenuto dell’intero file non viene copiato negli appunti, ma solo il percorso completo.

eventhooks

Questo comando enumera gli hook di eventi installati tramite l’API SetWinEventHook.

Visualizza gli ID evento (minimo e massimo) a cui si applica l’hook, i thread interessati, i processi proprietari e l’offset alla procedura di hook.

Gli hook degli eventi vengono installati chiamando SetWinEventHook. L’enumerazione degli hook avviene analizzando la struttura tagEVENTHOOK attraverso il plugineventhook di Volatility.

Nota: eventMin ed eventMax si riferiscono all’evento di sistema più basso e più elevato a cui si applica l’hook. Nell’esempio l’hook proviene da MENU avvia e arresta delle operazioni. Inoltre ihmod  è un indice di un’array di atoms, un valore di -1 indica che la procedura offPfn con valore 0xf6264 si trova all’interno del processo di hooking.

messagehooks

Questo comando visualizza gli hook di messaggi sia locali che globali, installati tramite le API SetWindowsHookEx. Questo è un trucco comune utilizzato dal malware per iniettare codice in altri processi e registrare sequenze di tasti, registrare movimenti del mouse, ecc.

creenshot

Questo comando prende uno screenshot da ogni desktop sul sistema. Enumera le finestre per ogni desktop nel loro ordine Z (focus front-to-back). Prende le coordinate sinistra, destra, superiore e inferiore di ogni finestra dalla struttura tag WND e disegna rettangoli con PIL (Python Imaging Library).

Esempio: due utenti hanno eseguito l’accesso a Windows 7 con la commutazione rapida dell’utente (ctrl+alt+canc, quindi opzione «cambia utente»). Ogni utente ha lasciato aperte varie finestre. Dopo aver acquisito la memoria ed eseguito il plugin degli screenshot, avremo uno screenshot  per ogni desktop.

Nota: PIL (Python Imaging Library) necessita della lib jepg.

userhandles

Questo comando individua la struttura tag SHAREDINFO specifica della sessione, scorre le strutture aheList (un array di _HANDLEENTRY). Determina se ogni voce di handle è di proprietà di un thread o di un processo, mostra il tipo di oggetto e il relativo offset nello spazio di sessione. Il risultato mostrato da questo plugin non è molto dettagliato, ma ha lo scopo di presentare una panoramica degli oggetti USER attualmente in uso da ogni thread o processo; e funge da API per altri plugin che desiderano dettagli maggiori su un tipo di oggetto. Ad esempio i plugin gditimers e eventhooks sfruttano le API di questo plugin.

gditimers

Questo comando sfrutta l’API della tabella di handleUSER (come descritto per userhandles) e per ogni TYPE_TIMER, dereferenzia l’oggetto come tag TIMER e mostra i dettagli sui campi.

Nota: il malware utilizza spesso i timer per pianificare le funzioni di routine, come contattare un server C2 o assicurarsi che un processo nascosto rimanga nascosto.

windows

Questo comando enumera tutte le finestre (visibili o meno) in tutti i desktop del sistema. Scorre le windows nel loro ordine Z (cioè front-end-focus) a partire dal valore spwnd del desktop (la finestra in primo piano). Per ogni finestra mostra i dettagli sul titolo della finestra, gli atoms di classe, il thread e il processo proprietario, le proprietà di visibilità, le coordinate sinistra/destra/alto/basso, i flag e gli ex-flag e l’indirizzo della procedura della windows.

wintree

Questo comando enumera le finestre nello stesso modo del precedente comando Windows, ma stampa meno dettagli in modo che la relazione genitore/figlio possa essere facilmente espressa in una forma ad albero. Invece di una vista “piatta”, è possibile vedere quali finestre sono contenute in altre finestre.

Windows Malwares

Sebbene tutti i comandi forniti da Volatility possano aiutare a scoprire malware (in un modo o nell’altro), ve ne sono alcuni progettati specificamente per la ricerca di rootkit e codice malevolo.

malfind

Il comando malfind aiuta a trovare codice e DLL nascoste o iniettate nella memoria in «modalità utente», in base a caratteristiche quali tag VAD e autorizzazioni.

Se si desidera salvare le copie estratte dei segmenti di memoria identificati da malfind, fornire semplicemente una directory di output con -D o –dump-dir = DIR. In questo caso, una copia decompressa di un binario malevolo iniettato verrebbe salvata sul disco.

Note:

  • malfind non rileva DLL immesse in un processo utilizzando CreateRemoteThread -> LoadLibrary. Le DLL iniettate con questa tecnica non sono nascoste e quindi è possibile visualizzarle con dlllist. Lo scopo malfind è individuare le DLL che i metodi e gli strumenti standard non rilevano.
  • Nell’esempio malfind viene utilizzato per rilevare la presenza di Zeus. Il primo segmento di memoria (a partire da 0x01600000) è stato rilevato perché il suo eseguibile, contrassegnato come privato (non condiviso tra processi) e con un tag VadS il che significa che non c’è alcun file di memoria mappato che occupa già lo spazio. Sulla base di uno disassembly  dei dati trovati a questo indirizzo, sembra contenere alcune  API hook trampoline stubs.
  • Il secondo segmento di memoria (a partire da 0x015D0000) è stato rilevato perché conteneva un eseguibile che non è elencato negli elenchi dei moduli di PEB.

yarascan

Volatility ha diversi motori di scansione per trovare modelli semplici come i pool tag in spazi di indirizzi fisici o virtuali. Tuttavia, se è necessario cercare elementi più complessi come le espressioni regolari o le regole composte (cioè cercare “questo” e non “quello”), è possibile utilizzare il comando yarascan. Questo plugin può aiutare a localizzare qualsiasi sequenza di byte (come istruzioni di assembly con caratteri jolly), espressioni regolari, stringhe ANSI o stringhe Unicode in modalità utente o memoria del kernel. È possibile creare un file di regole YARA e specificarlo come yara-file = RULESFILE. Oppure, se si sta cercando qualcosa di semplice, si può specificare i criteri come yara-rules = RULESTEXT.

Creiamo una firma yara come segue:

Identifichiamo il processo corrispondente alla firma yara:

Per cercare le firme definite nel file rules.yar, in qualsiasi processo e visualizzare i risultati sullo schermo:

Per cercare una stringa semplice in qualsiasi processo e scaricare i segmenti di memoria che contengono una corrispondenza:

Per cercare un byte pattern nella memoria del kernel, si può utilizzare la tecnica mostrata in esempio. La ricerca viene effettuata nella memoria in blocchi da 1 MB, in tutte le sessioni.

Nota: Nell’esempio si cerca il malware TDL3 che opera applicando una hard-patch agli adattatori SCSI sul disco (a volte atapi.sys o vmscsi.sys). In particolare, aggiunge un po’ di codice shell alla sezione .rsrcdel file e quindi modifica AddressOfEntryPoint in modo che punti al codice della shell. Questo è il metodo di persistenza principale di TDL3. Una delle istruzioni univoche nel codice shell è cmpdwordptr [‘3LDT’] così è possibile creare una firma YARA da questi opcode.

Per cercare un determinato modello di byte in un particolare processo:

Per cercare un’espressione regolare in un particolare processo:

svcscan

Volatility permette di elencare i servizi senza utilizzare le API di Windows su una macchina live. Per vedere quali servizi sono registrati nel dump di memoria, si può usare il comando svcscan. L’output mostra l’ID del processo di ciascun servizio (se è attivo e si riferisce a un processo usermode), il nome del servizio, il nome visualizzato del servizio, il tipo di servizio e lo stato corrente. Mostra anche il percorso binario per il servizio registrato, che sarà un file EXE per i servizi di usermode e un nome del driver per i servizi che vengono eseguiti dalla modalità kernel.

A partire da dalla versione 2.3 di Volatility è disponibile l’opzione –verbose che controlla la chiave del registro di sistema ServiceDll e segnala quale DLL ospita il servizio. Questa è una funzionalità critica poiché il malware molto comunemente installa servizi che utilizzano svchost.exe (il processo di servizio host condiviso) e implementa il codice malevolo reale in una DLL.

ldrmodules

Esistono molti modi per nascondere una DLL. Uno dei modi prevede lo scollegamento della DLL da uno (o tutti) degli elenchi collegati nel PEB. Tuttavia, in questo caso, vi sono ancora informazioni contenute all’interno del VAD (Virtual Address Descriptor) che identifica l’indirizzo di base della DLL e il suo percorso completo su disco. Per fare un riferimento incrociato a queste informazioni (note come file mappati in memoria) con le 3 liste PEB, si utilizza il comando ldrmodules. Per ogni file PE mappato in memoria, il comando ldrmodules visualizza True o False se il PE esiste negli elenchi PEB.

Poiché le liste PEB e DLL che esse contengono sono tutte esistenti in modalità utente, è anche possibile che il malware nasconda (o oscuri) una DLL semplicemente sovrascrivendo il percorso. Gli strumenti che cercano solo le voci non collegate possono non considerare che il malware potrebbe sovrascrivere C:\bad.dll per mostrare C:\windows\system32\kernel32.dll. Quindi è possibile utilizzare l’opzione -v o –verbose con ldrmodules per vedere il percorso completo di tutte le voci.

Poiché le liste PEB e DLL che esse contengono sono tutte esistenti in modalità utente, è anche possibile che il malware nasconda (o oscuri) una DLL semplicemente sovrascrivendo il percorso. Gli strumenti che cercano solo le voci non collegate possono non considerare che il malware potrebbe sovrascrivere C:\bad.dll per mostrare C:\windows\system32\kernel32.dll. Quindi è possibile utilizzare l’opzione -v o –verbose con ldrmodules per vedere il percorso completo di tutte le voci.

impscan

Per poter eseguire il reverse engineering del codice che si trova nel dump della memoria, è necessario vedere quali funzioni il codice importa. In altre parole, quali funzioni API chiama. Quando si esegue il dump dei file binari con dlldump, moddump o procdump, l’IAT (Import Address Table) potrebbe non essere ricostruito correttamente a causa dell’elevata probabilità che una o più pagine nell’intestazione PE o IAT non siano residenti in memoria (paged). Impscan, invece, identifica le chiamate alle API senza analizzare lo IAT di un PE. Funziona anche se il malware cancella completamente l’intestazione PE e funziona sui driver del kernel.

Prendendo il malware Coreflood come esempio, nella figura si nota che questo malware ha eliminato l’intestazione PE una volta caricata nel processo di destinazione (chiamando VirtualFree nell’ImageBase della DLL iniettata).

È possibile utilizzare malfind per rilevare la presenza di Coreflood in base ai criteri tipici (autorizzazioni di pagina, tag VAD, ecc.).

Si noti come l’indirizzo di base del PE non contiene la solita intestazione “MZ“.

Nota: le versioni precedenti di impscan creavano automaticamente un IDB con etichetta da utilizzare con IDA Pro. Questa funzionalità è stata temporaneamente disabilitata, ma tornerà in futuro quando verranno introdotte altre funzionalità simili.

Supponiamo che si voglia estrarre la copia decompressa di Coreflood e vedere le sue API importate. Utilizzare impscan specificando come indirizzo di base quello fornito da malfind. In questo caso, si utilizza l’indirizzo di base nella forma 0x1000 per tenere conto della pagina mancante nella ImageBase reale.

Se non si specifica un indirizzo di base con -b o –base, si finirà con la scansione del modulo principale del processo (cioè IEXPLORE.EXE poiché è -p 2044) per le funzioni importate. È anche possibile specificare l’indirizzo di base di un driver del kernel per analizzare il driver per le funzioni importate in modalità kernel.

Laqma loads a kernel driver named lanmandrv.sys. If you extract it with moddump, the IAT will be corrupt. So use impscan to rebuild it:

$ python vol.py -f laqma.vmem impscan -b 0xfca29000
Volatility Foundation Volatility Framework 2.4
IAT        Call       Module               Function
---------- ---------- -------------------- --------
0xfca2a080 0x804ede90 ntoskrnl.exe         IofCompleteRequest
0xfca2a084 0x804f058c ntoskrnl.exe         IoDeleteDevice
0xfca2a088 0x80568140 ntoskrnl.exe         IoDeleteSymbolicLink
0xfca2a08c 0x80567dcc ntoskrnl.exe         IoCreateSymbolicLink
0xfca2a090 0x805a2130 ntoskrnl.exe         MmGetSystemRoutineAddress
0xfca2a094 0x805699e0 ntoskrnl.exe         IoCreateDevice
0xfca2a098 0x80544080 ntoskrnl.exe         ExAllocatePoolWithTag
0xfca2a09c 0x80536dc3 ntoskrnl.exe         wcscmp
0xfca2a0a0 0x804fdbc0 ntoskrnl.exe         ZwOpenKey
0xfca2a0a4 0x80535010 ntoskrnl.exe         _except_handler3
0xfca2a3ac 0x8056df44 ntoskrnl.exe         NtQueryDirectoryFile
0xfca2a3b4 0x8060633e ntoskrnl.exe         NtQuerySystemInformation
0xfca2a3bc 0x805bfb78 ntoskrnl.exe         NtOpenProcess

The next example shows impscan on an x64 driver and using the render_idc output format. This gives you an IDC file you can import into IDA Pro to apply labels to the function calls.

$ python vol.py -f ~/Desktop/win7_trial_64bit.raw --profile=Win7SP0x64 impscan -b 0xfffff88003980000 --output=idc --output-file=imps.idc
Volatility Foundation Volatility Framework 2.4

$ cat imps.idc 
#include <idc.idc>
static main(void) {
   MakeDword(0xFFFFF8800398A000);
   MakeName(0xFFFFF8800398A000, "KeSetEvent");
   MakeDword(0xFFFFF8800398A008);
   MakeName(0xFFFFF8800398A008, "PsTerminateSystemThread");
   MakeDword(0xFFFFF8800398A010);
   MakeName(0xFFFFF8800398A010, "KeInitializeEvent");
   MakeDword(0xFFFFF8800398A018);
   MakeName(0xFFFFF8800398A018, "PsCreateSystemThread");
   MakeDword(0xFFFFF8800398A020);
   MakeName(0xFFFFF8800398A020, "KeWaitForSingleObject");
   MakeDword(0xFFFFF8800398A028);
   MakeName(0xFFFFF8800398A028, "ZwClose");
   MakeDword(0xFFFFF8800398A030);
   MakeName(0xFFFFF8800398A030, "RtlInitUnicodeString");
[snip]
   MakeDword(0xFFFFF8800398A220);
   MakeName(0xFFFFF8800398A220, "RtlAnsiCharToUnicodeChar");
   MakeDword(0xFFFFF8800398A228);
   MakeName(0xFFFFF8800398A228, "__C_specific_handler");
Exit(0);}

apihooks

Per trovare gli hook dell’API in modalità utente o kernel, si usa il plugin apihooks. Questo comando trova: IAT, EAT, Inline style hooks e diversi tipi speciali di hook. Per gli Inline hook, rileva CALL e JMP in posizioni dirette e indirette e rileva sequenze di istruzioni PUSH/RET. Rileva anche CALL o JMP ai registri dopo che un valore immediato (indirizzo) viene spostato nel registro. I tipi speciali di hook che rileva includono l’hook di syscall in ntdll.dll e le chiamate a pagine di codice sconosciute nella memoria del kernel. A partire dalla versione 2.1 di Volatility, apihooks rileva anche le tabelle delle procedure winsock agganciate, include un formato di output più semplice da leggere, supporta il multiple hop disassembly e può eseguire una scansione più rapida della memoria ignorando i processi e le DLL non critiche.

Note:

  • Requires Install distorm3
  • Inline hooks sono quelli in cui i primi pochi byte del prologo di una funzione vengono modificati in un JMP che punta al codice del rootkit. Questo è il modo in cui la maggior parte dei trojan funziona se fanno hooking  in «linea» e anche la maggior parte delle librerie di hook API.

Ecco un esempio di rilevamento degli hook IAT installati dal malware Coreflood. Il modulo di hook è sconosciuto perché non esiste alcun modulo (DLL) associato alla memoria in cui esiste il codice rootkit. Per estrarre il codice contenente gli hook, occorre:

  • tentare con malfind al fine di trovarlo ed estrarlo automaticamente;
  • utilizzare i comandi volshell dd/db per eseguire la scansione a ritroso e cercare un’intestazione MZ. Quindi passare l’indirizzo a dlldump come valore –base;
  • utilizzare vaddump per estrarre tutti i segmenti di codice in singoli file (denominati in base all’indirizzo iniziale e finale), quindi trovare il file che contiene gli intervalli 0x7ff82.
Here is an example of detecting the Inline hooks installed by Silentbanker. Note the multiple hop disassembly which is new in 2.1. It shows the first hop of the hook at 0x7c81caa2 jumps to 0xe50000. Then you also see a disassembly of the code at 0xe50000 which executes the rest of the trampoline.

$ python vol.py -f silentbanker.vmem -p 1884 apihooks
Volatility Foundation Volatility Framework 2.4
************************************************************************
Hook mode: Usermode
Hook type: Inline/Trampoline
Process: 1884 (IEXPLORE.EXE)
Victim module: kernel32.dll (0x7c800000 - 0x7c8f4000)
Function: kernel32.dllExitProcess at 0x7c81caa2
Hook address: 0xe50000
Hooking module: <unknown>

Disassembly(0):
0x7c81caa2 e959356384       JMP 0xe50000
0x7c81caa7 6aff             PUSH -0x1
0x7c81caa9 68b0f3e877       PUSH DWORD 0x77e8f3b0
0x7c81caae ff7508           PUSH DWORD [EBP+0x8]
0x7c81cab1 e846ffffff       CALL 0x7c81c9fc

Disassembly(1):
0xe50000 58               POP EAX
0xe50001 680500e600       PUSH DWORD 0xe60005
0xe50006 6800000000       PUSH DWORD 0x0
0xe5000b 680000807c       PUSH DWORD 0x7c800000
0xe50010 6828180310       PUSH DWORD 0x10031828
0xe50015 50               PUSH EAX

[snip]

Here is an example of detecting the PUSH/RET Inline hooks installed by Laqma:

$ python vol.py -f laqma.vmem -p 1624 apihooks
Volatility Foundation Volatility Framework 2.4
************************************************************************
Hook mode: Usermode
Hook type: Inline/Trampoline
Process: 1624 (explorer.exe)
Victim module: USER32.dll (0x7e410000 - 0x7e4a0000)
Function: USER32.dllMessageBoxA at 0x7e45058a
Hook address: 0xac10aa
Hooking module: Dll.dll

Disassembly(0):
0x7e45058a 68aa10ac00       PUSH DWORD 0xac10aa
0x7e45058f c3               RET
0x7e450590 3dbc04477e       CMP EAX, 0x7e4704bc
0x7e450595 00742464         ADD [ESP+0x64], DH
0x7e450599 a118000000       MOV EAX, [0x18]
0x7e45059e 6a00             PUSH 0x0
0x7e4505a0 ff               DB 0xff
0x7e4505a1 70               DB 0x70

Disassembly(1):
0xac10aa 53               PUSH EBX
0xac10ab 56               PUSH ESI
0xac10ac 57               PUSH EDI
0xac10ad 90               NOP
0xac10ae 90               NOP

[snip]

Here is an example of the duqu style API hooks which moves an immediate value into a register and then JMPs to it.

************************************************************************
Hook mode: Usermode
Hook type: Inline/Trampoline
Process: 1176 (lsass.exe)
Victim module: ntdll.dll (0x7c900000 - 0x7c9af000)
Function: ntdll.dllZwQuerySection at 0x7c90d8b0
Hook address: 0x980a02
Hooking module: <unknown>

Disassembly(0):
0x7c90d8b0 b8020a9800       MOV EAX, 0x980a02
0x7c90d8b5 ffe0             JMP EAX
0x7c90d8b7 03fe             ADD EDI, ESI
0x7c90d8b9 7fff             JG 0x7c90d8ba
0x7c90d8bb 12c2             ADC AL, DL
0x7c90d8bd 1400             ADC AL, 0x0
0x7c90d8bf 90               NOP
0x7c90d8c0 b8a8000000       MOV EAX, 0xa8
0x7c90d8c5 ba               DB 0xba
0x7c90d8c6 0003             ADD [EBX], AL

Disassembly(1):
0x980a02 55               PUSH EBP
0x980a03 8bec             MOV EBP, ESP
0x980a05 51               PUSH ECX
0x980a06 51               PUSH ECX
0x980a07 e8f1fdffff       CALL 0x9807fd
0x980a0c 8945fc           MOV [EBP-0x4], EAX
0x980a0f e872feffff       CALL 0x980886
0x980a14 8945f8           MOV [EBP-0x8], EAX
0x980a17 83               DB 0x83
0x980a18 7df8             JGE 0x980a12

Here is an example of using apihooks to detect the syscall patches in ntdll.dll (using a Carberp sample):

$ python vol.py -f carberp.vmem -p 1004 apihooks
Volatility Foundation Volatility Framework 2.4
************************************************************************
Hook mode: Usermode
Hook type: NT Syscall
Process: 1004 (explorer.exe)
Victim module: ntdll.dll (0x7c900000 - 0x7c9af000)
Function: NtQueryDirectoryFile
Hook address: 0x1da658f
Hooking module: <unknown>

Disassembly(0):
0x7c90d750 b891000000       MOV EAX, 0x91
0x7c90d755 ba84ddda01       MOV EDX, 0x1dadd84
0x7c90d75a ff12             CALL DWORD [EDX]
0x7c90d75c c22c00           RET 0x2c
0x7c90d75f 90               NOP
0x7c90d760 b892000000       MOV EAX, 0x92
0x7c90d765 ba               DB 0xba
0x7c90d766 0003             ADD [EBX], AL

Disassembly(1):
0x1da658f 58               POP EAX
0x1da6590 8d056663da01     LEA EAX, [0x1da6366]
0x1da6596 ffe0             JMP EAX
0x1da6598 c3               RET
0x1da6599 55               PUSH EBP
0x1da659a 8bec             MOV EBP, ESP
0x1da659c 51               PUSH ECX
0x1da659d 8365fc00         AND DWORD [EBP+0xfffffffc], 0x0
0x1da65a1 688f88d69b       PUSH DWORD 0x9bd6888f

[snip]

Here is an example of using apihooks to detect the Inline hook of a kernel mode function:

$ python vol.py apihooks -f rustock.vmem 
************************************************************************
Hook mode: Kernelmode
Hook type: Inline/Trampoline
Victim module: ntoskrnl.exe (0x804d7000 - 0x806cf980)
Function: ntoskrnl.exeIofCallDriver at 0x804ee130
Hook address: 0xb17a189d
Hooking module: <unknown>

Disassembly(0):
0x804ee130 ff2580c25480     JMP DWORD [0x8054c280]
0x804ee136 cc               INT 3
0x804ee137 cc               INT 3
0x804ee138 cc               INT 3
0x804ee139 cc               INT 3
0x804ee13a cc               INT 3
0x804ee13b cc               INT 3
0x804ee13c 8bff             MOV EDI, EDI
0x804ee13e 55               PUSH EBP
0x804ee13f 8bec             MOV EBP, ESP
0x804ee141 8b4d08           MOV ECX, [EBP+0x8]
0x804ee144 83f929           CMP ECX, 0x29
0x804ee147 72               DB 0x72

Disassembly(1):
0xb17a189d 56               PUSH ESI
0xb17a189e 57               PUSH EDI
0xb17a189f 8bf9             MOV EDI, ECX
0xb17a18a1 8b7708           MOV ESI, [EDI+0x8]
0xb17a18a4 3b35ab6d7ab1     CMP ESI, [0xb17a6dab]
0xb17a18aa 7509             JNZ 0xb17a18b5
0xb17a18ac 52               PUSH EDX
0xb17a18ad 57               PUSH EDI
0xb17a18ae e8c6430000       CALL 0xb17a5c79
0xb17a18b3 eb6a             JMP 0xb17a191f

Here is an example of using apihooks to detect the calls to an unknown code page from a kernel driver. In this case, malware has patched tcpip.sys with some malicious redirections.

$ python vol.py -f rustock-c.vmem apihooks 
Volatility Foundation Volatility Framework 2.4
************************************************************************
Hook mode: Kernelmode
Hook type: Unknown Code Page Call
Victim module: tcpip.sys (0xf7bac000 - 0xf7c04000)
Function: <unknown>
Hook address: 0x81ecd0c0
Hooking module: <unknown>

Disassembly(0):
0xf7be2514 ff15bcd0ec81     CALL DWORD [0x81ecd0bc]
0xf7be251a 817dfc03010000   CMP DWORD [EBP+0xfffffffc], 0x103
0xf7be2521 7506             JNZ 0xf7be2529
0xf7be2523 57               PUSH EDI
0xf7be2524 e8de860000       CALL 0xf7beac07
0xf7be2529 83               DB 0x83
0xf7be252a 66               DB 0x66
0xf7be252b 10               DB 0x10

Disassembly(1):
0x81ecd0c0 0e               PUSH CS
0x81ecd0c1 90               NOP
0x81ecd0c2 83ec04           SUB ESP, 0x4
0x81ecd0c5 c704246119c481   MOV DWORD [ESP], 0x81c41961
0x81ecd0cc cb               RETF

[snip]

idt

Per visualizzare l’IDT del sistema (Interrupt Descriptor Table), si utilizza il comando idt. Se nel sistema sono presenti più processori, viene visualizzato l’IDT per ogni singola CPU. Sarà visualizzato: il numero della CPU, il selettore GDT (Global Descriptor Table), l’indirizzo corrente e il modulo proprietario, il nome della sezione PE in cui risiede la funzione IDT. Se si fornisce il parametro –verbose, verrà visualizzato uno disassembly della funzione IDT. Alcuni rootkit agganciano la voce IDT di KiSystemService, ma la indirizzano a una routine all’interno del modulo NT (dove KiSystemService dovrebbe puntare). Tuttavia, a quell’indirizzo, c’è un Inline hook. Il seguente output mostra un esempio di come Volatility può identificarlo.

Note:

  •  module, parte del kernel, è il primo modulo ad essere caricato.
  • Si noti nella figura come la voce 0x2E per KiSystemService si trovi nella sezione .rsrc di ntoskrnl.exe invece di .text come tutti gli altri.

Per ottenere maggiori dettagli sulla possibile modifica IDT, utilizzare –verbose.

gdt

Per visualizzare il GDT (Global Descriptor Table) del sistema, si utilizza il comando gdt. Questo è utile per rilevare i rootkit (Alipop per esempio) che installano una call gate in modo che i programmi in modalità utente possano chiamare direttamente nel kernel mode (usando un’istruzione CALL FAR).

Se il sistema ha più CPU, viene mostrato il GDT per ciascun processore. Nell’output riportato in figura, è possibile vedere che il selettore 0x3e0 è stato infettato e utilizzato ai fini di un call gate a 32 bit. L’indirizzo del call gate è 0x8003f000, ovvero dove l’esecuzione continua.

Nota: Sistema di protezione ideato da Intel. Sofisticati meccanismi chiamati gate  regolano in maniera rigida l’esecuzione di interrupt  (interrupt gate), processi (task gate) e le chiamate al sistema operativo (call gate). Nel caso in cui si verifica un’interruzione o un’eccezione (sia esso esterna, cioè provocata da una periferica, o interna, provocata dal codice), viene prelevato un opportuno selettore della GDT (l’interrupt gate, appunto) che specifica in maniera precisa quale codice dev’essere eseguito, e le necessarie restrizioni. I task gate vengono, invece, utilizzati per memorizzare lo stato di un processo e semplificare il passaggio dall’uno all’altro. Infine per le call gate il meccanismo è analogo, ma il relativo gate offre in più la possibilità di specificare se e quanti parametri passare dall’applicazione al sistema operativo, sfruttando i relativi stack per la copia di questi valori.

volshell

Se si desidera approfondire l’analisi, è possibile suddividere il risultato con volshell come mostrato in figura. Quindi disassemblare il codice all’indirizzo del call gate.

threads

Il comando fornisce informazioni dettagliate sui thread, incluso il contenuto dei registri di ciascun thread (se disponibile), un disassemblaggio del codice all’indirizzo iniziale del thread e vari altri campi che possono essere rilevanti per un’analisi. Poiché ogni sistema ha centinaia di thread, rendendo difficile l’ordinamento, questo comando associa tag descrittivi ai thread che trova (e quindi è possibile filtrare per nome del tag con il parametro -F o –filter). Se non si specifica alcun filtro, il comando genererà informazioni su tutti i thread. Altrimenti, specificare un singolo filtro o più filtri separati da virgole.

$ python vol.py -f test.vmem threads -L
Volatility Foundation Volatility Framework 2.4
Tag                  Description
--------------       --------------
DkomExit             Detect inconsistencies wrt exit times and termination
HwBreakpoints        Detect threads with hardware breakpoints
ScannerOnly          Detect threads no longer in a linked list
HideFromDebug        Detect threads hidden from debuggers
OrphanThread         Detect orphan threads
AttachedProcess      Detect threads attached to another process
HookedSSDT           Detect threads using a hooked SSDT
SystemThread         Detect system threads

In figura un esempio di ricerca di thread attualmente in esecuzione nel contesto di un processo diverso dal processo proprietario del thread.

Innanzitutto, viene visualizzato l’indirizzo virtuale dell’oggetto ETHREAD insieme all’ID processo e all’ID thread. Successivamente verranno visualizzati tutti i tag associati al thread (SystemThread, AttachedProcess, HookedSSDT), i tempi di creazione/uscita, lo stato, la priorità, l’indirizzo iniziale, ecc. Mostra la base SSDT insieme all’indirizzo di ogni tabella di servizio e qualsiasi funzione collegata nelle tabelle. Infine, viene visualizzato uno disassembly dell’indirizzo iniziale del thread.

callbacks

Volatility permette di visualizzare un varietà di importanti routine di notifica e kernel callback. Con questo comando è possibile visualizzare:

  • PsSetCreateProcessNotifyRoutine (creazione del processo).
  • PsSetCreateThreadNotifyRoutine (creazione del thread).
  • PsSetImageLoadNotifyRoutine (caricamento di immagine/DLL).
  • IoRegisterFsRegistrationChange (registrazione del file system).
  • KeRegisterBugCheck e KeRegisterBugCheckReasonCallback.
  • CmRegisterCallback (registro callback su XP).
  • CmRegisterCallbackEx (registro callback su Vista e 7).
  • IoRegisterShutdownNotification (callback di chiusura).
  • DbgSetDebugPrintCallback (debug visualizza callback su Vista e 7).
  • DbgkLkmdRegisterCallback (debug callbacks su 7).

Note:

  • Rootkit, suite anti-virus, strumenti di analisi dinamici (Sysinternals’ Process Monitor e Tcpview) e molti componenti del kernel di Windows usano questi callback per monitorare eventi.
  • The KeRegisterBugCheckReasonCallback routine registers a BugCheckDumpIoCallback, BugCheckSecondaryDumpDataCallback, or BugCheckAddPagesCallback routine, which executes when the operating system issues a bug check.
Here's an example of detecting the thread creation callback installed by the BlackEnergy 2 malware. You can spot the malicious callback because the owner is 00004A2A - and BlackEnergy 2 uses a module name composed of eight hex characters.

$ python vol.py -f be2.vmem callbacks
Volatility Foundation Volatility Framework 2.4
Type                                 Callback   Owner
PsSetCreateThreadNotifyRoutine       0xff0d2ea7 00004A2A
PsSetCreateProcessNotifyRoutine      0xfc58e194 vmci.sys
KeBugCheckCallbackListHead           0xfc1e85ed NDIS.sys (Ndis miniport)
KeBugCheckCallbackListHead           0x806d57ca hal.dll (ACPI 1.0 - APIC platform UP)
KeRegisterBugCheckReasonCallback     0xfc967ac0 mssmbios.sys (SMBiosData)
KeRegisterBugCheckReasonCallback     0xfc967a78 mssmbios.sys (SMBiosRegistry)
[snip]

Here is an example of detecting the malicious process creation callback installed by the Rustock rootkit (points to memory owned by \Driver\pe386).

$ python vol.py -f rustock.vmem callbacks
Volatility Foundation Volatility Framework 2.4
Type                                 Callback   Owner
PsSetCreateProcessNotifyRoutine      0xf88bd194 vmci.sys
PsSetCreateProcessNotifyRoutine      0xb17a27ed '\\Driver\\pe386'
KeBugCheckCallbackListHead           0xf83e65ef NDIS.sys (Ndis miniport)
KeBugCheckCallbackListHead           0x806d77cc hal.dll (ACPI 1.0 - APIC platform UP)
KeRegisterBugCheckReasonCallback     0xf8b7aab8 mssmbios.sys (SMBiosData)
KeRegisterBugCheckReasonCallback     0xf8b7aa70 mssmbios.sys (SMBiosRegistry)
KeRegisterBugCheckReasonCallback     0xf8b7aa28 mssmbios.sys (SMBiosDataACPI)
KeRegisterBugCheckReasonCallback     0xf76201be USBPORT.SYS (USBPORT)
KeRegisterBugCheckReasonCallback     0xf762011e USBPORT.SYS (USBPORT)
KeRegisterBugCheckReasonCallback     0xf7637522 VIDEOPRT.SYS (Videoprt)
[snip]

Here is an example of detecting the malicious registry change callback installed by the Ascesso rootkit. There is one CmRegisterCallback pointing to 0x8216628f which does not have an owner. You also see two GenericKernelCallback with the same address. This is because notifyroutines finds callbacks in multiple ways. It combines list traversal and pool tag scanning. This way, if the list traversal fails, we can still find information with pool tag scanning. However, the Windows kernel uses the same types of pool tags for various callbacks, so we label those as generic.

$ python vol.py -f ascesso.vmem callbacks
Volatility Foundation Volatility Framework 2.4
Type                                 Callback   Owner
IoRegisterShutdownNotification       0xf853c2be ftdisk.sys (\Driver\Ftdisk)
IoRegisterShutdownNotification       0x805f5d66 ntoskrnl.exe (\Driver\WMIxWDM)
IoRegisterShutdownNotification       0xf83d98f1 Mup.sys (\FileSystem\Mup)
IoRegisterShutdownNotification       0xf86aa73a MountMgr.sys (\Driver\MountMgr)
IoRegisterShutdownNotification       0x805cdef4 ntoskrnl.exe (\FileSystem\RAW)
CmRegisterCallback                   0x8216628f UNKNOWN (--)
GenericKernelCallback                0xf888d194 vmci.sys
GenericKernelCallback                0x8216628f UNKNOWN
GenericKernelCallback                0x8216628f UNKNOWN

driverirp

Per visualizzare la tabella IRP (Major Function) di un driver, si utilizza il comando driverirp. Questo comando eredita da driverscan in modo che sia in grado di individuare DRIVER_OBJECTs. Quindi scorre la tabella delle funzioni, visualizzando lo scopo di ciascuna funzione, l’indirizzo della funzione e il modulo proprietario dell’indirizzo.

Molti driver inoltrano le loro funzioni IRP ad altri driver per scopi legittimi, quindi rilevare le funzioni hook IRP sulla basate dei moduli contenuti non è un buon metodo, quindi verrà visualizzato tutto e lasciato giudicare all’analista. Il comando controlla anche gli Inline hook delle funzioni IRP e opzionalmente visualizza un disassembly delle istruzioni all’indirizzo IRP (utilizzare l’opzione -v o verbose). Questo comando genera informazioni per tutti i driver, a meno che non si specifichi un filtro di espressioni regolari.

Nell’output non è evidente che il driver vmscsi.sys sia stato infettato dal rootkit (TDL3 nell’esempio). Sebbene tutti gli IRP facciano riferimento a vmscsi.sys, essi puntano ad uno stub messo in evidenza in quell’area da TDL3 al fine proprio di bypassare gli strumenti di rilevamento dei rootkit. Per ottenere informazioni più dettagliate, si utilizza –verbose.

Ora è possibile vedere che TDL3 reindirizza tutti gli IRP al proprio stub nel driver vmscsi.sys. Il codice salta a qualsiasi indirizzo indicato da 0xffdf0308 una posizione nella regione KUSER_SHARED_DATA.

Nota: un metodo “stub” o semplicemente stub nell’Ingegneria del software è una porzione di codice utilizzata in sostituzione di altre funzionalità software. Uno stub può simulare il comportamento di codice esistente (come una Routine su un sistema remoto) o COM, e temporaneo sostituto di codice ancora da sviluppare. Gli stub sono perciò molto utili durante il porting di software, l’elaborazione distribuita e in generale durante lo sviluppo di software e il software testing.

devicetree

Windows utilizza un’architettura di driver a livelli o una catena di driver in modo che più driver possano ispezionare o rispondere a un IRP. I rootkit spesso inseriscono driver (o dispositivi) in questa catena per nascondere file, nascondere connessioni di rete, carpire sequenze di tasti o movimenti del mouse, ecc… Il plugin devicetree mostra la relazione di un oggetto driver con i suoi dispositivi (scorrendo  _DRIVER_OBJECT.DeviceObject.NextDevice) e su tutti i dispositivi collegati (_DRIVER_OBJECT.DeviceObject.AttachedDevice). In figura, Stuxnet ha infettato \FileSystem\Ntfs allegando un dispositivo malevolo senza nome. Sebbene il dispositivo stesso sia senza nome, l’oggetto device identifica il suo driver (\Driver\ MRxNet).

Nota: il plugin devicetree utilizza “DRV” per indicare i driver, “DEV” per indicare i dispositivi e “ATT” per indicare i dispositivi collegati.

psxview

Questo plugin consente di rilevare processi nascosti confrontando ciò che contiene PsActiveProcessHead con quanto riportato da varie altre fonti di elenchi di processi, ovvero:

  • PsActiveProcessHead linked list;
  • EPROCESS pool scanning;
  • ETHREAD pool scanning (quindi fa riferimento al proprio EPROCESS);
  • PspCidTable
  • Csrss.exe handle table;Csrss.exe internal linked list.

Nella figura viene rilevata la presenza del malware Prolaco. “False” in qualsiasi colonna indica che manca il rispettivo processo. È possibile affermare che “1_doc_RCData_61” sia sospetto poiché compare in ogni colonna tranne pslist (PsActiveProcessHead).

Nota: su Windows Vista e Windows 7 l’elenco interno dei processi in csrss.exe non è disponibile. Potrebbe anche non esserlo in alcune immagini XP in caso di pagine non risiedenti in memoria.

timers

Questo comando visualizza i timer del kernel installati (KTIMER) e tutti i DPC associati (Deferred Procedure Calls, chiamate di procedure differite). Alcuni rootkit (come Zero Access, Rustock e Stuxnet) registrano i timer con un DPC. Sebbene il malware cerchi di essere invisibile e nascondersi del kernel, trovando i KTIMER ed osservando l’indirizzo del DPC, è possibile trovare rapidamente gli intervalli del codice dannoso. In figura si noti come uno dei timer ha un modulo UNKNOWN (il DPC punta a una regione sconosciuta della memoria del kernel). Questo è in definitiva il nascondiglio del rootkit.

Nota: i timer sono elencati in modi diversi a seconda del sistema operativo. Windows memorizza i timer nelle variabili globali per XP, 2003, 2008 e Vista. Dal Windows 7, i timer si trovano in regioni specifiche del processore al di fuori del KPCR (Kernel Processor Control Region). A partire dalla versione 2.1 di Volatility , se ci sono più CPU, il plugin timer trova tutti i KPCR e visualizza i timer associati a ciascuna CPU.

Miscellaneous

strings

Data un’immagine e un file contenente righe nel formato <decimal_offset>: <string>, o <decimal_offset> <string>, visualizza il corrispondente processo e gli indirizzi virtuali in cui è possibile trovare quella stringa. L’input previsto per questo tool è l’output dell’utility Strings di Microsoft Sysinternals o di altra utility che fornisce un formato offset:string. Si noti che gli offset di input sono offset fisici dall’inizio del file/immagine.

Sysinternals Strings può essere utilizzato su Linux/Mac usando Wine. L’output dovrebbe essere reindirizzato a un file da utilizzare con il plugin strings di Volatility. Alcuni esempi di utilizzo:

Windows:

Il completamento di Sysinternals Strings può richiedere tempo. Gli switch -q e -o sono imperativi poiché assicurano che l’intestazione non venga visualizzata (q) e che vi sia un offset per ogni riga (-o).

Linux/Mac, è possibile utilizzare Sysinternals Strings con Wine:

Note:

  • se si sta usando il comando strings GNU, usare il flag -td per produrre offset in decimale (il plugin non accetta offset esadecimali).
  • È anche possibile utilizzare l’utility GNU strings fornita con Linux e Mac (l’utility strings predefinita su Mac non ha il supporto Unicode, è possibile installare il pacchetto GNU binutils per ottenere un’utilitystrings che funzioni). Usare il flag -td per ottenere l’offset decimale e fare un secondo passaggio con il flag -el per ottenere stringhe Unicode (little endian). Si noti che il secondo passaggio aggiunge (>>) al file esistente:
$ strings -a -td win7.dd > win7_strings.txt
$ strings -a -td -el win7.dd >> win7_strings.txt

Il risultato dovrebbe essere un file di testo che contiene l’offset e le stringhe dell'immagine, ad esempio:
16392:@@@
17409:
17441:
17473:""" 
17505:###
17537:$$$
17569:%%%
17601:&&&
17633:'''
17665:(((
17697:)))
17729:***

EnCase Keyword Export. È possibile anche utilizzare EnCase per esportare parole chiave e offset in questo formato con qualche ritocco. Una cosa da notare è che EnCase esporta il testo in UTF-16 con un BOM di (U + FEFF) che può causare problemi con il plugin strings (il Byte Order Mark (BOM) è una piccola sequenza di byte che viene posizionata all’inizio di un flusso di dati di puro testo (tipicamente un file) per indicarne il tipo di codifica Unicode). Un esempio di file delle parole chiave esportate:

File Offset Hit Text
114923  DHCP
114967  DHCP
115892  DHCP
115922  DHCP
115952  DHCP
116319  DHCP

Ora modificando il file rimuovendo l'intestazione e le tabulazioni, abbiamo:
114923:DHCP
114967:DHCP
115892:DHCP
115922:DHCP
115952:DHCP
116319:DHCP

Mediante un editor esadecimale noteremo che trattasi di UTF-16 ed ha BOM di (U + FEFF).
$ file export.txt 
export.txt: Little-endian UTF-16 Unicode text, with CRLF, CR line terminators

$ xxd export.txt |less

0000000: fffe 3100 3100 3400 3900 3200 3300 3a00  ..1.1.4.9.2.3.:.

Dobbiamo convertirlo in ANSI o UTF-8. In Windows è possibile aprire il file di testo e utilizzare la finestra di dialogo "Salva con nome" per salvare il file come ANSI (nel menu a discesa "Codifica"). In Linux puoi usare iconv: 
$ iconv -f UTF-16 -t UTF-8 export.txt > export1.txt

NOTA: è necessario accertarsi che NON ci siano righe vuote nel file "stringhe" finale.

Ora possiamo vedere la differenza nel modo in cui questi due file sono gestiti:

$ python vol.py -f Bob.vmem --profile=WinXPSP2x86 strings -s export.txt 
Volatility Foundation Volatility Framework 2.4
ERROR   : volatility.plugins.strings: String file format invalid.

$ python vol.py -f Bob.vmem --profile=WinXPSP2x86 strings -s export1.txt 
Volatility Foundation Volatility Framework 2.4
0001c0eb [kernel:2147598571] DHCP
0001c117 [kernel:2147598615] DHCP
0001c4b4 [kernel:2147599540] DHCP
0001c4d2 [kernel:2147599570] DHCP
0001c4f0 [kernel:2147599600] DHCP
0001c65f [kernel:2147599967] DHCP
0001c686 [kernel:2147600006] DHCP

L’output di strings di Volatility è molto dettagliato ed è meglio reindirizzarlo o salvarlo in un file. Il seguente comando salva l’output usando l’opzione –output-file e il nome “win7_vol_strings.txt”:

$ python vol.py --profile=Win7SP0x86 strings –f win7.dd –s win7_strings.txt --output-file=win7_vol_strings.txt

Di default, strings fornisce solo l’output per i processi trovati scorrendo la lista a cui punta PsActiveProcessHead oltre agli indirizzi del kernel. strings può anche fornire l’output per i processi nascosti utilizzando l’opzione S:

$ python vol.py --profile=Win7SP0x86 strings –f win7.dd –s win7_strings.txt --output-file=win7_vol_strings.txt -S  

Può essere visualizzato anche l’offset EPROCESS:

$ python vol.py --profile=Win7SP0x86 strings –f win7.dd –s win7_strings.txt --output-file=win7_vol_strings.txt -o 0x04a291a8 

Il plugin strings richiede un po’ di tempo per essere completato. Al termine, si dovrebbe avere un file di output con ogni riga nel seguente formato:

In figura un esempio di output ove è possibile vedere riferimenti a PID e kernel:

Una volta ottenuto l’output, è possibile vedere quale processo ha la stringa sospetta in memoria. È possibile usare grep per la stringa o il pattern a seconda del contesto, ad esempio:

Per tutti gli IP:

Per tutti gli URL:

volshell

Per esplorare in modo interattivo un’immagine di memoria, si usa il comando volshell. Questo fornisce un’interfaccia simile a WinDbg nel dump della memoria. Ad esempio è possibile:

  • elencare i processi;
  • passare al contesto di un processo;
  • mostrare i tipi di strutture/oggetti;
  • sovrapporre un tipo su un dato indirizzo;
  • scorrere le liste collegate; disassemblare il codice a un dato indirizzo.

Nota: volshell può sfruttare IPython se è installato. Questo aggiungerà il completamento della tabulazione e la cronologia dei comandi salvati.

Per utilizzare volshell:

Volendo vedere cosa c’è all’indirizzo 0x779f0000 nella memoria di explorer.exe, si visualizzerà innanzitutto i processi in modo da poter ottenere il PID o l’offset di EPROCESS di explorer.

Nota: se si desidera visualizzare i dati nella memoria del kernel, non è necessario prima cambiare i contesti.

Ora ci si sposta al contesto di explorer e si visualizzano dati con db (visualizza come hexdnump) o dd (visualizzato come double-words):

Osserviamo un PE all’indirizzo 0x779f0000 in explorer.exe. Se si desidera disassemblare le istruzioni in RVA (Relative Virtual Address) 0x2506 in PE, è possibile nel modo seguente:

Per i membri in un oggetto EPROCESS per il sistema operativo specificato, procedere come segue:

Per sovrapporre i tipi di EPROCESS all’offset per explorer.exe, procedere come segue:

 comandi db, dd, dt e dis accettano tutti un parametro opzionale “space” che consente di specificare uno spazio di indirizzo. Si otterranno dati diversi a seconda dello spazio di indirizzo utilizzato. Volshell ha alcune impostazioni predefinite e regole che è importante evidenziare:

  • se non si fornisce uno spazio di indirizzo e non si è passati a un contesto di processo con cc, verrà utilizzato lo spazio del kernel predefinito (System process);
  • se non si fornisce uno spazio di indirizzo e si è passati a un contesto di processo con cc, si utilizzerà lo spazio del processo attivo/corrente;
  • se si fornisce esplicitamente uno spazio di indirizzo, verrà utilizzato quest’ultimo.

Si immagini che dopo aver utilizzato uno dei comandi di scansione (psscan, connscan, ecc.) si teme di aver rilevato un falso positivo. Poiché i comandi di scansione emettono un offset fisico (offset nel file di immagine della memoria), si potrebbe esplorare i dati intorno al potenziale falso positivo per determinare se alcuni membri della struttura appaiono avere un senso o meno. Un modo per farlo è aprire il dump della memoria in un visualizzatore esadecimale e passare all’offset fisico per visualizzare i byte grezzi. Tuttavia, un modo migliore è usare volshell e sovrapporre la domanda della struttura al presunto offset fisico. Questo permetterà di vedere i campi interpretati come il loro tipo previsto (DWORD, string, short, ecc.).

Ecco un esempio. Prima istanziare uno spazio di indirizzamento fisico:

Supponendo che il presunto falso positivo per un EPROCESS sia a 0x433308:

Un altro trucco è usare volshell in modo non interattivo. Ad esempio, supponendo di voler conertire un indirizzo nella memoria del kernel nel corrispondente offset fisico.

Quindi l’indirizzo 0x823c8830 del kernel si traduce in offset fisico 0x25c8830 nel file di immagine della memoria. È possibile seguire più comandi in sequenza in questo modo:

bioskbd

Per leggere le sequenze di tasti dall’area del BIOS della memoria, si può utilizzare il comando bioskbd. Con questo comando è possibile rivelare le password digitate nei BIOS di HP, Intel e Lenovo e nei software SafeBoot, TrueCrypt e BitLocker. A seconda del tool utilizzato per acquisire la memoria, non tutte le immagini di memoria conterranno l’area del BIOS necessaria.

patcher

Il plugin patcher accetta un singolo argomento -x seguito da un file XML. Il file XML, che specifica le patch richieste, è formattato come segue:

Attenzione: è necessario abilitare il supporto per la scrittura e quindi il dump della memoria verrà modificato.

L’elemento radice del file XML è sempre patchfile e contiene un numero qualsiasi di elementi di patchinfo. Quando viene eseguito il patchfile, viene effettua una scansione della memoria per ogni patchinfo, tentando di eseguire la scansione utilizzando il metodo specificato nell’attributo method. Attualmente l’unico metodo di supporto è pagescan e questo deve essere esplicitamente dichiarato in ogni elemento di patchinfo.

Ogni elemento di patchinfo di tipo pagescan contiene un singolo elemento constraints e un singolo elemento patches. La scansione procede quindi su ciascuna pagina in memoria, verificando che tutti i vincoli suddetti siano soddisfatti e, in tal caso, vengono eseguite le istruzioni specificate nell’elemento patches.

L’elemento constraints contiene un numero qualsiasi di elementi match che prendono uno specifico attributo offset (specificando dove all’interno della pagina deve avvenire la corrispondenza) e quindi contengono una stringa esadecimale per i byte che dovrebbero corrispondere.

L’elemento patch contiene, invece, un numero qualsiasi di elementi setbytes che prendono uno specifico attributo offset (specificando dove con la pagina la patch dovrebbe modificare i dati) e quindi contiene una stringa esadecimale per i byte che dovrebbero essere scritti nella pagina. Nota: quando si esegue il plugin patcher, non verrà apportata alcuna modifica alla memoria a meno che non sia stata specificata l’opzione di scrittura -w sulla riga di comando.

pagecheck Il plugin pagecheck utilizza un DTB del kernel (dal processo System/Idle) e determina quali pagine devono essere residenti in memoria (utilizzando il metodo AddressSpace.get_available_pages). Per ogni pagina, tenta di accedere ai dati della pagina ed ai dettagli dei report, come gli indirizzi PDE e PTE se il tentativo fallisce. Questo è un plugin di diagnostica, di solito utile per la risoluzione dei “buchi” in uno spazio degli indirizzi.

Note:

  • Questo plugin non è ben supportato. È nella directory contrib e attualmente funziona solo con spazi di indirizzi x86 non PAE.
  • DTB (directory table base) used for address translation. Although identity paging helps translate some static addresses found in System.map, it doesn’t work for all regions of memory. Thus, performing full-scale memory forensics (i.e., list walking, accessing process memory) requires the capability to translate virtual addresses based on the algorithm used by the CPU. For this to be possible, you must find the initial directory table base (DTB). This is a very simple operation because the address of the initial DTB (swapper_pg_dir) is stored in both the System.map file and within the identity-mapped region of the kernel.
  • PDE (page directory entry) l processore x86 divide lo spazio di indirizzamento fisico (memoria fisica) in pagine da 4KB ciascuna. Quindi per avere 4GB di memoria avremo bisogno di 1M (1024×1024) di 4KB pagine. Per fare questo viene usata una struttura a 2 livelli. Il primo livello è la Page Directory mentre il secondo è rappresentato dalla Page Table. Quindi avremo una prima tabella, la Page Directory(PD), composta da 1024 elementi, e ognuna di queste punta ad una Page Table(PT) che contiene, a sua volta,1024 elementi i quali puntano alle pagine (quelle da 4KB).
  • PTE (page table entry) Una PTE (Page Table Entry) è l’ elemento di base per il mapping tra la memoria virtuale (o logica) e quella fisica. La memoria virtuale viene divisa in pagine, la dimensione di una pagina può variare a seconda dell’architettura del processore, per esempio x86 e x64 definiscono entrambi pagine di 4KB (4096 byte) mentre Itanium ha una pagina di 8KB. Ogni pagina virtuale può avere una PTE associata che descrive se essa è valida (ovvero disponibile al processore) ed in caso affermativo quale pagina di memoria fisica corrisponde alla pagina virtuale di interesse.

Il plugin timeliner crea una timeline da varie risorse in memoria accedendo alle seguenti fonti (gli elementi tra parentesi sono filtri che possono essere utilizzati con il flag –type per ottenere solo gli elementi di tale artefatto):

È possibile filtrare per una qualsiasi delle opzioni indicate in modo da avere un output più focalizzato usando il flag –type:

Esistono tre opzioni per l’output:

  • •testo predefinito;
  • •il formato bodyfile;
  • un file Excel.

È possibile anche includere un identificatore di macchina nell’intestazione con il flag –machine (questo è utile quando si combinano timeline da più macchine). In figura l’output di testo predefinito:

Se non si desidera eseguire un ulteriore passaggio di importazione, è possibile utilizzare l’opzione    output=xlsx con –output-file = [FILE] (OUTPUT) per salvare direttamente in un file Excel 2007 (è necessario che OpenPyxl sia installato).

Un’altra alternativa è usare l’opzione output=body per il formato TSK 3.x bodyfile. È possibile utilizzare questa opzione di output quando si desidera combinare l’output di timeliner, mftparser e shellbags. Per default tutti, tranne il timestampLastWrite del registro di sistema, sono inclusi nell’output di timeliner, poiché l’ottenimento dei timestamp del registro di sistema è piuttosto laborioso. Per aggiungerli all’output, è sufficiente aggiungere l’opzione type=Registry quando si esegue Volatility. È inoltre possibile limitare l’attenzione dei timestamp del registro di sistema precisando un nome di registro specifico (come hive=SYSTEM) o utente (user = Jim) o entrambi (–hive = UsrClass.dat —user = jim). Queste opzioni sono case insensitive.

Nota: TSK 3.x bodyfile

VOLATILITY: un esempio pratico

Dato un dump di una memoria (useremo l’acquisizione RAMWin7Ultimate.mem creata per l’esercitazione), la prima operazione da effettuare è quella di identificarne il «profilo», ovvero verificare il sistema di provenienza dell’acquisizione di memoria:

vol.py -f  RAMWin7Ultimate.mem imageinfo

«Win7SP1x64» è il profilo del sistema di provenienza e sarà utilizzato da tutti gli altri plugin per la successiva analisi.

Dall’analisi del file di dump possiamo estrarre diverse informazioni come la versione del sistema operativo, il numero di CPU, gli indirizzi fisici per ciascun processore, la data e ora relativa alla creazione del dump:

Identificato il profilo, è possibile procedere all’analisi del dump di memoria utilizzando i plugin di volatility:

vol.py -f win-mem-image.mem --profile=[profile] [plugin]

filescan: scansiona il dump alla ricerca di tutti i file aperti e li elenca:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 filescan

Poichè filescan può produrre un output voluminoso, è consigliabile salvare l’elenco in un file.txt:

pslist: un’altra informazione utile che possiamo estrapolare dal file di dump della RAM è quella relativa ai processi che erano in esecuzione sulla macchina al momento del dump:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 pslist

Con pslist possiamo ricercare un dato processo specificandone il nome, utilizzando  l’opzione –n. Potremmo, ad esempio, ricercare se un determinato processo era in esecuzione al momento dell’acquisizione della memoria:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 pslist –n wordpad

psxview: poiché pslist non mostrerà i processi nascosti o non collegati, è possibile utilizzare il plugin psxview per rilevare processi nascosti confrontando ciò che contiene PsActiveProcessHead con quanto riportato da varie altre fonti di elenchi di processi:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 psxview

vadtree: il kernel di Windows organizza la memoria allocata dal processo (o dal kernel) in un albero di assegnazioni con tag VAD (Virtual Address Descriptor, acronimo di descrittore di indirizzo virtuale). Possiamo utilizzare questo plugin per visualizzare i nodi VAD del processo come una struttura ad albero:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 vadtree

Ancora meglio, possiamo visualizzare la struttura ad albero in modo grafico, salvando l’output nel formato Graphviz mediante l’opzione –output=dot –output-file=graph.dot:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 vadtree --output=dot --output-file=[directory]graph.dot

Quindi sarà possibile aprire graph.dot con un qualsiasi visualizzatore compatibile con Graphviz. Questo plugin supporta anche la codifica a colori dell’output in base alle regioni che contengono stack, heap, file mappati, DLL, ecc.

Copiamo ed incolliamo il contenuto del file graph.dot nel visualizzatore web: http://www.webgraphviz.com/:

ed ecco il risultato:

memdump

Utilizzando il plugin pslist si è potuto constatare che mentre è stato effettuato il dump della memoria era in esecuzione wordpad (PID 2988).

Poiché procdump estrae un processo eseguibile e dumpfiles salva tutti i file (o un determinato file) presenti nella memoria, potremmo aver bisogno, invece, di estrarre tutte le pagine residenti in memoria legate ad un processo.

Nel caso di wordpad.exe, ad esempio, ciò potrebbe permettere di risalire all’eventuale testo digitato, che non sarebbe rilevabile con la sola estrazione del processo (procdump) né tantomeno del singolo file (dumpfiles). Allo scopo, si utilizza il plugin memdump che consente di estrarre tutte le pagine residenti in memoria di un processo in un singolo file:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 memdump –p 2988 –D [directory di output]

Il file così ottenuto può essere analizzato con altri strumenti (visualizzatori esadecimali, p.e.) alla ricerca di eventuali ed ulteriori informazioni.

Nel nostro esempio si è utilizzato l’editor esadecimale WinHex come interprete di dati, il quale ha permesso di estrarre un file con estensione .rtf al cui interno era presente la stringa di testo “Hello!”.

iehistory: questo plugin recupera frammenti di file di cache della cronologia IE in index.dat. Si applica a qualsiasi processo che carica e utilizza la libreria wininet.dll e quindi non solo per Internet Explorer, ma include anche “esplora risorse”.

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 iehistory

netscan: questo plugin mostra tutte le connessioni di rete, il nome del processo, gli indirizzi IP di origine e di destinazione, comprese le porte:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 netscan

userassist: con questo plugin è possibile ottenere le chiavi di registro UserAssist, che tiene traccia dei programmi eseguiti, del numero di esecuzioni e dell’ultima data e ora di esecuzione:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 userassist

shimcache: questo plugin analizza la chiave di registro Application Compatibility Shim Cache, alla ricerca dei metadati dei file che vengono eseguiti su un sistema Windows:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 shimcache

sessions: questo comando elenca i processi in esecuzione, suddivisi per sessione in cui sono stati avviati:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 sessions

deskscan: enumera i desktop, le allocazioni dell’heap del desktop ed i thread associati. In ambiente GUI, un desktop è essenzialmente un contenitore per le finestre delle applicazioni e gli oggetti dell’interfaccia utente:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 deskscan

imeliner: crea una timeline delle risorse in memoria accedendo al varie fonti (quest’ultime verranno indicate tra parentesi  quadre):

hivelist: individua gli indirizzi virtuali degli hive del registro di sistema nella memoria e i percorsi completi per l’hive corrispondente sul disco.

Il registro di sistema contiene informazioni a cui il sistema operativo fa continuamente riferimento mentre viene utilizzato, quali i profili di tutti gli utenti, le applicazioni installate nel computer e i tipi di documenti creati da ciascuna applicazione, le impostazioni delle finestre, le proprietà delle cartelle e le icone delle applicazioni, i componenti hardware presenti nel sistema e le porte in uso.

Un hive del registro di sistema è un gruppo di chiavi, sottochiavi e valori che dispone di una serie di file di supporto contenenti copie di backup dei relativi dati. È possibile visualizzare gli hive del registro caricati in memoria con il seguente comando:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 hivelist

Verrà mostrato per ciascun hive, il relativo indirizzo fisico e virtuale.

I due indirizzi evidenziati in figura sono gli indirizzi virtuali degli hive di SAM e SYSTEM. Questi due hive contengono informazioni sufficienti ad estrarre gli hash delle password di Windows.

Ricorrendo al plugin hashdump, potremo visualizzare gli utenti con relativi hash delle password. Per utilizzare hashdump, occorre fornire l’indirizzo virtuale dell’hive SYSTEM con l’opzione -y e l’indirizzo virtuale dell’hive SAM con –s. In questo modo verranno estratte le credenziali dei domini memorizzate nel registro.

hashdump:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 hashdump –y 0xfffff8a000024010 –s 0xfffff8a00304d010

hashdump:

lsadump: permette di visualizzare i LSA secrets dal registro, ovvero mostrerà informazioni quali la password predefinita (per i sistemi con autologin abilitato), la chiave pubblica RDP e le credenziali utilizzate da DPAPI:

vol.py -f  RAMWin7Ultimate.mem --profile=Win7SP1x64 lsadump

VOLATILITY: un esempio pratico – parte 2

Oltre ai plugin trattati nell’esempio precedente, volatility ne ha altri a corredo, specificatamente implementati per l’analisi dei dump di memoria con macchina virtuale in esecuzione (virtualbox, vmware). Useremo l’acquisizione RAMWin7Ultimate.vmem ottenuta da un dump di memoria con macchina virtuale in esecuzione (vmware, per la precisione):

vol.py -f  ‘Windows 7 x64 Ultimate-0581c0c9.vmem’ imageinfo

vmwareinfo: con questo plugin possiamo analizzare le informazioni dell’intestazione del vmss (vmware saved state) o del vmsn (vmware snapshot). Ciò consentirà di visualizzare i registri della CPU, l’intero file di configurazione VMX, le informazioni sull’esecuzione della memoria:

vol.py -f  ‘Windows 7 x64 Ultimate-0581c0c9.vmem’ vmwareinfo

vmwareinfo: … e gli screenshots PNG della VM ospite:

vol.py -f  ‘Windows 7 x64 Ultimate-0581c0c9.vmem’ vmwareinfo --verbose 
--dump-dir=[directory di destinazione]

vmwareinfo: … e gli screenshots PNG della VM ospite:

Il Rischio Cyber nelle Aziende

Master Executive di II livello in Cyber Security – Anno Accademico 2015-2016, estratto dalla mia tesi.

“There are two types of companies: those who have been hacked, and those who don’t yet know they have been hacked”

  • John Chambers, Executive Chairman Cisco Systems. World Economic Forum 2015

“… possiamo affermare che il 2016 è stato complessivamente l’anno peggiore di sempre in termini di evoluzione delle minacce “cyber” e dei relativi impatti, non solo dal punto di vista quantitativo ma anche e soprattutto da quello qualitativo.”

  • Rapporto Clusit 2017

Questa era la mia prefazione alla tesi redatta nel 2016, ma considerando quanto scritto nel “Rapporto Clusit 2023”:

“Osservando la situazione dal punto di vista quantitativo, negli ultimi 5 anni la situazione è peggiorata nettamente, seguendo un trend pressoché costante. Confrontando i numeri del 2018 con quelli del 2022 la crescita del numero di attacchi rilevati è stata del 60% … Oltre alla maggiore frequenza, anche la nostra valutazione della Severity media (indice di gravità) di questi attacchi è drasticamente peggiorata, il che rappresenta un significativo moltiplicatore dei danni.”

Anello debole: l’uomo. La forza di una catena, si dice, si misura da quella del suo anello più debole.

Cap.1 La Minaccia Cyber nelle Aziende

La vulnerabilità dei sistemi informatici è oggi riconosciuta a livello globale. Cittadini, aziende e governi subiscono attacchi sempre più frequenti e difficili da contrastare. L’ultimo “Rapporto Clusit” sulla sicurezza ICT evidenzia che la capacità complessiva di attivare protezioni efficaci è ancora debole.

La minaccia cyber

Con minaccia cibernetica intendiamo l’insieme delle condotte controindicate che possono essere realizzate nel e tramite lo spazio cibernetico ovvero in danno di quest’ultimo e dei suoi elementi costitutivi. La minaccia si sostanzia nei c.d. attacchi cibernetici: azioni più o meno automatizzate sulle reti da parte di singoli individui o organizzazioni, statuali e non, finalizzate a distruggere, danneggiare o ostacolare il regolare funzionamento dei sistemi, delle reti o dei sistemi attuatori di processo da essi controllati ovvero a compromettere l’autenticità, l’integrità, la disponibilità e la riservatezza dei dati ivi custoditi o che vi transitano[1].

Una caratteristica saliente della minaccia cibernetica è la sua asimmetricità. L’attaccante infatti:

  • può colpire a grandissima distanza, da dovunque nel mondo esista un accesso alla rete;
  • potenzialmente può attaccare sistemi particolarmente sofisticati e protetti sfruttandone anche una sola vulnerabilità;
  • può agire con tempi tali da non consentire un’efficace reazione difensiva;
  • può rimanere anonimo o comunque non facilmente individuabile rendendo in tal modo estremamente complessa e difficile una corretta risposta da parte dell’attaccato.

In cosa consiste la Cyber Security?

Sui giornali, ai convegni, nelle presentazioni commerciali si evidenzia una notevole con­fusione in merito al significato dell’espressione “Cyber Security”.

Ma possiamo dire che “La cyber security è quella pratica che consente a una entità̀ (ad esempio, organizzazione, cittadino, nazione ecc.) la protezione dei propri asset fisici e la confidenzialità̀, integrità̀ e disponibilità̀ delle proprie informazioni dalle minacce che arrivano dal cyber space.[2]

Dove, “the Cyberspace” è definito come “il complesso ambiente derivante dall’interazione tra persone, software e servizi su Internet tramite dispositivi tecnologici e reti connesse, che non esiste in nessuna forma fisica[3]

In sintesi, proteggere gli assetti della propria organizzazione significa garantire i seguenti tre obiettivi:

  • riservatezza,le informazioni devono essere accessibili direttamente o indirettamente solo alle persone (o ai sistemi) che ne hanno diritto e che sono espressamente autorizzate a conoscerle;
  • integrità, i dati e le rispettive informazioni devono essere protette da alterazioni, quali modifiche, danneggiamenti o cancellazioni improprie, anche accidentali;
  • disponibilità, i dati e le rispettive informazioni devono essere sempre accessibili agli utilizzatori che ne hanno diritto nei tempi e nei modi previsti.

Il dato è la rappresentazione oggettiva di un fatto o evento che consenta la sua trasmissione oppure interpretazione da parte di un soggetto umano o di uno strumento informatico.

L’informazione è l’interpretazione e il significato assegnato a uno o più dati.

Cap.2 I Possibili “Nemici

Già nel Rapporto CLUSIT 2015, alla luce dei trend individuati si leggeva: “dunque la vera questione per i difensori (con riferimento ai dati, alle infrastrutture informati­che ed a tutti quei servizi, molti dei quali critici, oggi realizzati tramite l’ICT) non è più “se”, ma “quando” si subirà un attacco informatico (dalle conseguenze più o meno dannose), e quali saranno gli impatti conseguenti”.

Questa tendenza si è ulteriormente consolidata e nel 2016, il principa­le problema non è tanto che si verrà attaccati (tutti lo sono ormai costantemente, per lo più tramite sistemi automatizzati, nella sfera personale e professionale, per i motivi più disparati), ma quali saranno gli impatti degli attacchi andati a buon fine sulla sicurezza di organizzazioni, utenti, clienti e partner, e come impedire al maggior numero possibile di incidenti di verificarsi.

Tipi di minaccia

A seconda degli attori e delle finalità si usa distinguere la minaccia cibernetica in quattro macro-categorie. Si parla in tal caso di:

  • criminalità cibernetica (cyber-crime): complesso delle attività con finalità criminali (quali, per esempio, la truffa o frode telematica, il furto d’identità, la sottrazione indebita di informazioni o di creazioni e proprietà intellettuali);
  • spionaggio cibernetico (cyber-espionage): acquisizione indebita di dati/informazioni sensibili, proprietarie o classificate;
  • terrorismo cibernetico (cyber-terrorism): insieme delle azioni ideologicamente motivate, volte a condizionare uno stato o un’organizzazione internazionale;
  • guerra cibernetica (cyber-warfare): insieme delle attività e delle operazioni militari pianificate e condotte allo scopo di conseguire effetti nel predetto ambiente.

Europol, nel suo rapporto IOCTA[4] sugli otto trend del cyber crime nel 2016, li ha classificati in:

  • crime-as-a-service: il crimine diventa una commodity che si compra al “supermercato” (nero) criminale. Il crimine informatico e la criminalità ordinaria sono sempre più vicini grazie al modello noto come “cybercrime-as-a-service” in cui esperti hacker offrono prodotti e servizi a gruppi criminali che intendono differenziare le proprie attività;
  • i ransomware, la nuova edizione dell’estorsione;
  • l’uso criminale dei dati nelle forme di truffe od estorsioni più sofisticate;
  • le frodi nei pagamenti;
  • la pedopornografia online e gli abusi;
  • l’abuso di darknet per attività illecite;
  • il social engineering, ora rivolto anche ai vertici aziendali per frodi articolate;
  • l’uso distorto delle valute virtuali, divenute lo strumento di pagamento degli illeciti.

Gli autori

  • pirati informatici, quelli che spesso, comunemente, vengono chiamati hacker, È sbagliato pensare che i cybercriminali puntino solamente ad eseguire attacchi in grande stile. A fianco di bersagli quali istituti governativi e bancari, sono sempre più oggetto di attacchi informatici anche PMI, liberi professionisti, sino al singolo utente domestico;
  • spie, sabotatori, vandali. Attualmente, diversi Governi si sono dotati delle necessarie capacità per penetrare le reti nazionali degli altri Stati (in uso sia alle autorità pubbliche che ai privati) a fini di spionaggio o per mappare i sistemi potenzialmente oggetto di un futuro attacco. Il vandalo adotta un insieme di azioni al fine di danneggiare o distruggere beni altrui materiali e non, per puro divertimento o incuria. Il sabotatore ha per obiettivo creare danni ad un sistema, dal rallentamento sino al denial of service, per i motivi più vari. È evidente che una netta distinzione tra i due attori non è possibili in quanto agiscono spesso con le medesime modalità e per gli stessi scopi;
  • oltre ai criminali comuni, che si rifanno al modello noto come “cybercrime-as-a-service” di cui si è parlato prima, vi sono organizzazioni criminali che hanno preso coscienza delle potenzialità dei malware andando a creare strutture commerciali efficientemente organizzate, capaci di generare sensibili profitti dalla vendita dei servizi che le botnet[5] sono in grado di offrire;
  • terroristi, è possibile ipotizzare che nel prossimo futuro gruppi terroristici o singoli individui possano impiegare strumenti cibernetici offensivi ed utilizzarli contro obiettivi militari e civili. Si può far rientrare in questa categoria, quella degli attivisti, dal 2013 sempre più spesso si assiste ad una commistione tra finalità cyber criminali e forme di hacktivism. I due ambiti, originariamente distinti per background, finalità e modalità di azione, sempre più spesso trovano conveniente allearsi per raggiungere i propri obiettivi: tipologie di attacco motivate ideologicamente, con intento sostanzialmente dimostrativo, che mirano principalmente a creare un danno d’immagine e/o alla funzionalità temporanea di sistemi e reti;
  • personale interno, ovvero l’ “insider”, cioè il soggetto che all’interno di una organizzazione – pubblica o privata poco importa – può generare situazioni compromettenti la sicurezza o addirittura la sopravvivenza della realtà di appartenenza. L’attenzione è incentrata sia sui soggetti che ora lavorano nell’organizzazione, sia su quelli che hanno interrotto ogni rapporto. Va tenuto nella dovuta considerazione il fatto che l’attenzione agli attacchi informatici deve necessariamente essere rivolta non solo verso l’esterno, ma anche verso l’interno dell’azienda. Un dipendente particolarmente motivato potrebbe creare un danno molto maggiore rispetto a quello di un cyber attaccante, vista la sua conoscenza dell’infrastruttura e degli asset aziendali. A mio parere rappresenta una fra le minacce più gravi: partono in vantaggio rispetto ad un attaccante esterno per la conoscenza delle dinamiche interne, delle infrastrutture, ecc.., hanno già le credenziali di accesso e spesso non vengono revocate in tempo. Esempio italiano Hacking Team;
  • fornitori di servizi, outsourcers, nel 2013 si è assistito all’emergere di una chiara tendenza, per cui gli attaccanti hanno individuato negli outsourcer l’anello più debole da colpire per raggiungere (tipicamente sfruttandone le utenze privilegiate e le connessioni VPN) i loro bersagli primari. Questo fenomeno, data la propensione degli attaccanti a minimizzare gli sforzi, è destinato a crescere in modo esponenziale, dal momento che spesso questi fornitori sono aziende medio-piccole, con una cultura della sicurezza sensibilmente inferiore a quella dei loro grandi clienti, pur avendo di frequente accessi poco o per nulla presidiati alle loro reti ed infrastrutture;
  • dal crimine informatico allo state-sponsored hacking. Lo scenario attuale vede un crescente numero di attacchi informatici caratterizzati da livelli di complessità elevati, determinati dalla proliferazione di hacker al soldo di governi oppure di malware sviluppati dai governi stessi. Se il crimine informatico preoccupa gli esperti di sicurezza, il nation-state hacking non è da meno. La quasi totalità dei governi è intenta nell’ampliamento del proprio arsenale cibernetico.

Cap.3 Il Rischio Cyber per le Imprese

Vulnerabilità e potenziali attacchi

In questo capitolo vengono elencate le principali tipologie di attacchi e di vulnerabilità che possono essere riscontrate nella pratica, per lo sviluppo sicuro delle applicazioni, nell’ottica di identificare un modello adeguato da utilizzare nella identificazione delle contromisure da adottare per il profilo di sicurezza di una applicazione.

Per realizzare un profilo di sicurezza efficace, sarà infatti necessario conoscere innanzitutto quali sono i potenziali attacchi che più verosimilmente potranno essere riscontrati nell’ambito di una applicazione.

L’identificazione di queste possibili situazioni critiche potrà essere quindi utilizzata secondo un approccio probabilistico nella successiva fase di analisi dei rischi, per la individuazione delle contromisure che più convenientemente sia il caso di adottare.

Un potenziale attacco può essere definito come l’attuazione di una delle possibili minacce per un sistema, mentre la vulnerabilità è una debolezza all’interno del sistema stesso e che rende possibile il verificarsi di quel potenziale attacco.

La vulnerabilità può essere causata da un disegno di analisi non adeguato, da errori di configurazione o da tecniche di programmazione non sicure o inappropriate. Una insufficiente validazione dell’input è un esempio di vulnerabilità a livello di sicurezza delle applicazioni e che potrebbe causare il verificarsi di attacchi tramite input maliziosi.

La distribuzione dei potenziali attacchi suddivisi per categoria di vulnerabilità, come riportato di seguito, fornisce una rappresentazione delle aree dove più frequentemente si verificano problemi in termini di sicurezza delle applicazioni e può costituire uno strumento di supporto da seguire nelle fasi di sviluppo e di analisi.

Categoria di VulnerabilitàPotenziale attacco
Validazione dell’inputBuffer overflow;
Script XSS;
SQL injection;
Altre forme di iniezione di codice (O.S., LDAP)
Canonicizzazione.
AutenticazioneNetwork eavesdropping;
Brute force attacks;
Dictionary attacks;
Cookie replay;
Furto di credenziali.
AutorizzazioneElevazione di privilegi,
Violazione di dati riservati, Accesso a funzionalità non autorizzate
Data tampering;
Luring attacks.
Gestione della ConfigurazioneAccessi non autorizzati ad interfacce di amministrazione;
Accessi non autorizzati a file di configurazione;
Reperimento in chiaro di dati riguardanti la configurazione;
Assegnazione di account non individuali; Processi e account del servizio con privilegi troppo elevati.
Categoria di VulnerabilitàPotenziale attacco
Dati SensibiliAccesso a dati sensibili in memoria o file system;
Network eavesdropping;
Data tampering.
Gestione delle SessioniSession hijacking;
Session replay;
Man in the middle.
CrittografiaGestione o generazione non appropriata delle chiavi;
Crittografia debole.
Manipolazione di ParametriManipolazione di query string;
Manipolazione di campi relativi a maschere di input, inclusi campi hidden;
Manipolazione di Cookie;
Manipolazione di header HTTP
Gestione delle eccezioni/erroriInformation disclosure; Denial of service.
Audit e LogNegazione di aver effettuato una operazione;
Violazione di una applicazione senza lasciare tracce;
Cancellazione delle proprie tracce.

Per effettuare in maniera sistematica una identificazione delle possibili minacce per una applicazione, un approccio valido consiste nella verifica delle vulnerabilità che sono ad essa applicabili.

Una volta individuate le vulnerabilità a cui l’applicazione potrebbe essere soggetta, si potranno identificare le possibili minacce, o attacchi potenziali ad essa collegate e le corrispondenti contromisure da adottare.

Validazione dell’Input

In questa categoria ricadono le tecniche di filtraggio di una applicazione che debba accettare dei dati di input, e che portano alla accettazione o al rifiuto degli stessi, dopo averne verificato la validità. Si ha una vulnerabilità di questo tipo ad esempio quando:

  • un programma non gestisce correttamente un errore di sintassi nell’input;
  • un modulo accetta parametri di input esterni e arbitrari senza validarli;
  • un modulo non gestisce correttamente dei campi di input non valorizzati;
  • un campo non è stato definito correttamente per tipo, numero di caratteri, ecc.

Per gli attacchi che ricadono in questa categoria, dovrebbe essere generalmente applicata una strategia di difesa in profondità, sinteticamente definita in tre passi:

  • il primo consiste nello stabilire delle limitazioni per accettare in input soltanto dati validi, definendo dei filtri riguardanti tipo, formato, lunghezza e range;
  • il secondo, rifiutare i dati non validi, è meno robusto del primo dato che non sarà sempre possibile prevedere le eventuali varianti di un input illegittimo;
  • per il terzo, l’obiettivo consiste nel rendere innocui altri dati potenzialmente dannosi, una tecnica potrà essere ad esempio la eliminazione degli spazi presenti alla fine della stringa di input.

Buffer overflow (Applicabilità: Applicazioni Web Oriented e Client Server). Un Buffer overflow è una situazione di errore che si può verificare durante l’esecuzione di un programma, quando la lunghezza effettiva dell’input supera il suo valore massimo previsto. Un programma avente una vulnerabilità di questo tipo potrebbe essere sfruttato illecitamente, introducendo input di tipo malizioso con lunghezza superiore alle capacità del buffer. Ciò avviene solitamente nell’ambito di una chiamata ad una funzione: in occasione di una CALL, la CPU si preoccupa infatti di salvare in memoria l’indirizzo di ritorno (EIP), per poter riprendere dopo il return l’istruzione immediatamente successiva alla CALL stessa. Se il corrispondente buffer dichiarato in memoria, tipicamente nello stack, viene sovrascritto da una quantità di dati tale da causarne lo “straripamento” in zone di memoria adiacenti, ciò provocherà anche la sovrascrittura dell’indirizzo di ritorno del chiamante, necessario per puntare all’istruzione successiva. In questo contesto, come descritto nell’esempio, sarà possibile sostituire l’indirizzo di ritorno della funzione con un altro indirizzo scelto dall’attaccante, modificando il flusso di esecuzione del programma allo scopo di eseguire codice arbitrario.

XSS – Cross-Site Scripting (Applicabilità: Applicazioni Web Oriented). Un attacco di tipo script XSS, o Cross-Site scripting, consiste nel provocare l’esecuzione di codice arbitrario di tipo HTML e script da esso eseguibili (quali Javascript) attraverso il browser, utilizzando l’applicazione come veicolo per l’attacco. Vulnerabilità XSS si verificano quando un’applicazione presenta all’utente (nel browser) delle informazioni ricevute precedentemente in input qualora queste non siano state opportunamente validate. Se l’input contiene caratteri che, quando sottoposti al browser, rappresentano codice (HTML, Javascript), si ottiene un attacco in cui si provoca l’esecuzione di codice arbitrario, che avverrà nel contesto di sicurezza del browser.

SQL Injection (Applicabilità: Applicazioni Web oriented, Client server). Un attacco di questo tipo consiste nello sfruttare vulnerabilità presenti nel meccanismo di validazione dell’input, al fine di eseguire comandi arbitrari nel database.

Autenticazione

È il processo in cui una entità prova la identità di un’altra entità, tipicamente attraverso credenziali come user name e password, relative ad una applicazione. Gli aspetti fondamentali collegati all’autenticazione riguardano:

  • la identificazione dei punti in cui richiedere l’autenticazione all’interno dell’applicazione, tipicamente nelle zone che delimitano un’area di ‘Trust’;
  • la validazione di credenziali, che nelle applicazioni Web vengono trasmesse tramite form HTML (o, meno comunemente per le implicazioni di sicurezza associate, utilizzando schemi quali http basic o digest authentication);
  • l’assegnazione di un token all’utente per la sua identificazione.

I punti da considerare per una corretta strategia di protezione sono i seguenti:

  • evitare il passaggio di credenziali ‘in chiaro’ attraverso la rete e utilizzare canali di comunicazione sicuri;
  • memorizzare i dati relativi alle credenziali in maniera crittografata o utilizzare eventualmente algoritmi di hash;
  • identificare univocamente l’utente che si è autenticato, proteggendo i suoi cookie di autenticazione.

Network eavesdropping (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questo tipo di attacco, ossia ‘spiare attraverso la rete’ potrebbe andare a buon fine se le credenziali relative all’autenticazione vengono passate in chiaro dal client al server. I dati HTTP che viaggiano in chiaro nella rete sono soggetti a questo tipo di attacco, che viene perpetrato attraverso software di monitoraggio della rete al fine di intercettare e/o modificare dati riservati. Da tenere in considerazione che il protocollo HTTP impiega solo una semplice codifica Base64 prima di trasmettere le password.

Brute force attack (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questo tipo di attacco è mirato verso la individuazione automatica delle password o altre informazioni sensibili. L’attacco consiste nella possibilità di ‘craccare’ (to crack = rompere) la password o altre informazioni riservate, codificate con meccanismi crittografici o di hashing, verificando tutte le combinazioni possibili per le informazioni in oggetto (ad es., tutte le combinazioni di username, password).

Dictionary attack (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questo tipo di attacco è mirato verso la individuazione automatica delle password. Se le password da conservare in memoria vengono codificate tramite un meccanismo di hashing, il meccanismo di autenticazione avviene ricodificando con lo stesso meccanismo la password digitata dall’utente ed effettuando il confronto del valore ottenuto con il corrispondente valore memorizzato nel database. Se un attaccante riesce ad ottenere la lista delle password codificate, potrà cercare di individuare il meccanismo di decodifica (Brute Force). In aggiunta a ciò, un attacco di questo tipo (Dictionary attack) viene perpetrato con l’ausilio di appositi programmi che effettuano delle iterazioni, utilizzando tutte le parole di un dizionario (o di più dizionari di lingua diversa), effettuando poi l’hashing per ognuna delle parole possibili. L’hashing risultante viene poi confrontato con il corrispondente valore del database. Per questo motivo viene sconsigliato l’uso di password troppo semplici.

Cookie replay (Applicabilità: Applicazioni Web Oriented). Con questo tipo di attacco, si cerca di impadronirsi dei cookie di autenticazione dell’utente utilizzando software di monitoraggio, replicandone poi il contenuto per accedere all’applicazione, impersonificando un utente legittimo. Un attacco di questo tipo può verificarsi quando il canale di comunicazione non è cifrato (ad es., si utilizza http) e l’attaccante ha la capacità di osservare traffico in transito dalla vittima.

Furto di credenziali (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Se una applicazione contempla l’uso di propri ‘contenitori’ relativi a credenziali dell’utente, il suo meccanismo di sicurezza potrebbe essere meno robusto di quello fornito dalla piattaforma di riferimento.

Autorizzazione/profilazione

Le autorizzazioni/profilazioni connesse con una applicazione riguardano sia le modalità con cui essa accede a risorse, database e/o operazioni sia se e con quali diritti gli utenti finali accedono a loro volta all’applicazione stessa.

Le principali implicazioni che derivano da vulnerabilità imputabili ad una inappropriata gestione delle autorizzazioni sono:

Elevazione di privilegi (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questo tipo di attacco, collegato con la fase di assegnazione delle autorizzazioni, consiste nella possibilità che qualcuno possa allargare il proprio campo di azione, utilizzando privilegi non consentiti per il proprio account, come ad esempio i diritti assegnati ad un gruppo di amministratori. L’attacco avviene solitamente in modo indiretto, dato che spesso deve sfruttare altre vulnerabilità (es. un buffer overflow) presenti nell’applicazione per poter essere messo in pratica.

Violazione di dati riservati (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questo tipo di minaccia riguarda i dati gestiti da una applicazione e consiste nella possibilità di visualizzazione di dati riservati da parte di un utente non autorizzato.

Data tampering (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questo tipo di minaccia riguarda i diritti assegnati agli utenti e consiste nella possibilità di modifica dei dati da parte di un utente non autorizzato.

Luring attacks (Applicabilità: Applicazioni Web Oriented). Questo tipo di problema, che rientra nella categoria di attacchi che comportano una elevazione di privilegi, consiste nella possibilità, da parte di una entità, di richiamarne un’altra avente privilegi superiori, ossia che consentano di effettuare una certa operazione altrimenti non autorizzata.

Gestione della configurazione

Questa categoria riguarda le applicazioni dotate di interfacce e funzionalità che permettono a sviluppatori, operatori e amministratori di gestire:

  • parametri di configurazione di un sito web;
  • contenuti delle pagine Web;
  • account degli utenti;
  • informazioni sugli user profile;
  • stringhe di connessione al database;
  • routine di manutenzione e amministrazione.

Questo tipo di vulnerabilità potrebbe permettere ad un attaccante di accedere al sito con privilegi di amministratore. Se, ad esempio, un application server è dotato di funzioni di amministrazione remota, un accesso non sicuro alla interfaccia di amministrazione potrebbe permettere l’ingresso e la modifica di qualsiasi informazione.

Accessi non autorizzati ad interfacce di amministrazione (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questo tipo di minaccia potrebbe riguardare quelle applicazioni dotate di interfacce, interne od esterne all’applicazione stessa, tramite le quali sia possibile effettuare operazioni di gestione e di configurazione.

Accessi non autorizzati a file di configurazione (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questa minaccia riguarda le informazioni contenute nei file di configurazione (o file .ini nelle applicazioni client server) che, a causa della loro natura, devono essere protette da accessi non autorizzati.

Reperimento in chiaro di dati riguardanti la configurazione (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questa minaccia è collegata con la precedente: oltre a riguardare la limitazione degli accessi sui file contenenti dati di configurazione, comporta l’adozione di un meccanismo di difesa in profondità attraverso la crittografia dei dati sensibili/critici o delle stringhe di connessione.

Assegnazione di account non individuali (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questa minaccia riguarda la possibilità da parte di un attaccante di modificare informazioni relative alla configurazione ed all’amministrazione di sistemi e siti e di accedere a dati riservati senza una adeguata tracciabilità delle operazioni e della persona che le ha effettuate attraverso le attività di auditing e logging.

Processi e account del servizio con privilegi troppo elevati (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Un importante aspetto per una corretta configurazione dell’applicazione è rappresentato dall’assegnazione di minimi privilegi agli account di processo usati per esempio per eseguire il processo Web server e gli account di servizio usati per accedere alle risorse e ai sistemi.

Dati sensibili

Questa categoria è soggetta ad una varietà considerevole di possibili tentativi di visualizzazione o modifica di dati riservati, e può riguardare sia dati memorizzati, sia dati che viaggiano sulla rete.

I meccanismi principali per gestire la privacy di queste informazioni sono:

  • la crittografia;
  • l’integrità attraverso codici di autenticazione del messaggio (MAC).

Accesso a dati sensibili in memoria (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Network eavesdropping (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Data tampering (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Queste minacce si riferiscono alla possibilità da parte di alcuni utenti malintenzionati di accedere in maniera non autorizzata a dati riservati, memorizzati su qualsiasi tipo supporto.

Gestione delle sessioni

Questo tipo di vulnerabilità costituisce un aspetto critico per una applicazione, e le applicazioni Web in particolare devono utilizzare sessioni per tenere traccia delle richieste di ogni utente: il protocollo HTTP non offre questa funzionalità e quindi ogni applicazione deve implementarla in qualche modo.

Session hijacking (Applicabilità: Applicazioni Web Oriented). La tecnica di questo attacco consiste nell’attendere che qualcuno porti a termine con successo il proprio processo di autenticazione, al fine di sfruttare in seguito la medesima connessione, anche quando il legittimo utente ne ha terminato l’utilizzo.

Session replay (Applicabilità: Applicazioni Web Oriented). Questa minaccia riguarda la possibilità di sfruttare informazioni riguardanti la sessione, intercettate come descritto nel punto precedente, al fine di bypassare il meccanismo di autenticazione. In altre parole è l’utilizzo delle autorizzazioni da parte dell’hacker senza che esse gli siano state date. Se ad esempio il token relativo alla sessione è presente in chiaro all’interno di un cookie o di una URL, potrebbe essere intercettato (Session hijacking) e poi riutilizzato.

Man in the middle (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questo tipo di attacco può riguardare un qualsiasi tipo di richiesta inviata attraverso la rete nel corso di una comunicazione client/server. Consiste nella alterazione dei messaggi nella fase di passaggio fra mittente e destinatario, prima dell’effettivo arrivo a destinazione. Il messaggio falsificato viene accettato come vero dal destinatario, che intraprende le azioni corrispondenti. Analogamente, quando in seguito viene inviata una risposta, anche questa viene falsificata. In tal modo nessuna delle due parti si renderà mai conto di essere stata attaccata.

Session Riding (Applicabilità: Applicazioni Web Oriented). Session Riding, altrimenti detta Cross-Site Request Forgery, rappresenta una classe di vulnerabilità che consente di inviare comandi ad applicazioni web tramite un (inconsapevole) utente, mediante l’invio a quest’ultimo di email o inducendolo a visitare apposite pagine web.

Crittografia

Di fronte all’esigenza di trattare informazioni sensibili dal punto di vista della sicurezza, cosa abbastanza comune per un gran numero di applicazioni, potrebbe essere necessario utilizzare un algoritmo di crittografia. In tal caso, il meccanismo prescelto non dovrà essere utilizzato in maniera impropria. Probabilmente, l’errore più comune è rappresentato da codice di crittografia realizzato autonomamente, solitamente debole e semplice da violare.

È importante assicurarsi che l’algoritmo scelto sia adatto al lavoro che deve svolgere e allo stesso tempo bisogna assicurarsi di usare una giusta dimensione della chiave che garantisca un sufficiente grado di sicurezza. Generalmente più grande è la chiave, maggiore sarà il livello di sicurezza, ma più onerosa la sua implementazione.

Di seguito vengono analizzate le minacce (solitamente sottovalutate) che possono essere sfruttate affinché gli attacchi possano avere successo e quindi compromettere la sicurezza delle applicazioni.

La seguente lista sintetizza gli algoritmi più diffusi e le chiavi che essi implementano:

  • Data Encryption Standard (DES) chiave a 64 bit suddivisa in 8 blocchi da 8 bit (8 bytes) – Simmetrico (chiave privata);
  • TripleDES (3DES) chiavi a 128 bit o 192 bit (16 o 24 bytes) – Simmetrico (chiave privata);
  • Rijndael 128 –256 bit (16-32 bytes) – Simmetrico (chiave privata);
  • RSA 1024 bit (128 bytes) Asimmetrico (chiave pubblica).

Gestione o generazione non appropriata delle chiavi (Applicabilità: Applicazioni Web Oriented, Client server). Gli utenti malintenzionati possono decriptare i dati se essi hanno accesso alla chiave di encriptyng o possono dedurla. Alcuni utenti malintenzionati potrebbero scoprire le chiavi se le stesse sono generate in maniera non casuale od utilizzando degli algoritmi fai da te. Questo tipo di minaccia, utilizzabile da un attacco, ha una probabilità di fallimento che è direttamente proporzionale alla robustezza del meccanismo di generazione e gestione delle chiavi crittografiche.

Crittografia debole (Applicabilità: Applicazioni Web, Applicazioni Client server). Un algoritmo di crittografia non offre nessuna sicurezza se può essere decodificato, ossia è vulnerabile ad un attacco di tipo “Brute Force”. Gli algoritmi “fai da te” sono particolarmente vulnerabili se non testati adeguatamente. È d’obbligo in questi casi l’utilizzo di algoritmi noti e accuratamente testati. Questo tipo di vulnerabilità ha una probabilità di insuccesso direttamente proporzionale alla robustezza dell’algoritmo di crittografia utilizzato.

Manipolazione di parametri

In questa categoria ricadono le applicazioni Web in cui avvenga un passaggio di parametri fra client e applicazione. Ciò potrebbe riguardare stringhe contenenti query, campi della maschera di input, cookie e header HTTP.

Manipolazione di stringhe contenenti query (Applicabilità: Applicazioni Web). Le stringhe di query sono porzioni di una URL dinamica che contengono parametri per la generazione di una pagina. La manipolazione di questi dati è solitamente una operazione abbastanza semplice e non esistono metodi robusti per prevenirla, soprattutto se i parametri vengono passati tramite una HTTP GET da client a server, che provoca la loro successiva visualizzazione all’interno della URL.

Manipolazione di campi relativi a maschere di input (Applicabilità: Applicazioni Web). Quando un utente inserisce dati in una pagina HTML, questi vengono solitamente memorizzati come valori di campi del form e inviati in chiaro all’applicazione come una richiesta HTTP (GET o POST). Questi campi potrebbero essere modificati per bypassare le routine di validazione del client e la manipolazione potrebbe riguardare tutti i campi presenti nel form, compresi quelli nascosti.

Manipolazione di Cookie (Applicabilità: Applicazioni Web). I cookie sono un conveniente meccanismo di memorizzazione delle preferenze utente e di altri dati, fra cui i session token. Esistono due diverse tipologie di cookie:

  • Cookie persistenti;
  • Cookie non-persistenti

I cookie di tipo persistente sono memorizzati in file di testo che si trovano sul client, e sono validi per un determinato periodo, stabilito in base alla corrispondente data di scadenza. I cookie di tipo non-persistente sono memorizzati sul client nella RAM, e vengono cancellati quando il browser viene chiuso oppure il cookie viene terminato da uno script di logoff. Entrambe le tipologie sono suscettibili a manomissioni da parte del client, che li invia successivamente al server effettuando richieste tramite header HTTP, ad esempio per ottenere l’accesso ad un sito Web, oppure utilizzando Javascript.

Manipolazione di header http (Applicabilità: Applicazioni Web). Gli header HTTP sono informazioni di controllo, che vengono scambiate fra client e Web server nelle richieste HTTP. Gli header relativi al client vengono solitamente indicati come request header, mentre i response header sono quelli relativi al server. Il cookie può essere considerato un esempio di response header. Queste informazioni sono solitamente contenute in una riga ASCII di testo, ed hanno un nome ed un valore. Normalmente, i web browser non consentono la modifica degli header, e un attaccante dovrà scrivere un apposito programma che effettua la richiesta HTTP, oppure utilizzare degli strumenti facilmente reperibili in rete, che consentono di modificare i dati inviati dal browser (proxies).

Gestione delle eccezioni/errori

Una corretta gestione degli errori non deve esporre informazioni sulla struttura interna dell’applicazione ad eventuali attacchi. Le applicazioni che non effettuano una corretta gestione delle eccezioni sono vulnerabili da questo punto di vista.

Information disclosure (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Con questo tipo di attacco si cerca di provocare un errore dell’applicazione, al fine di ottenere informazioni riguardanti l’applicazione stessa, come ad esempio: versione della piattaforma, nomi di server, stringhe contenenti comandi SQL, e stringhe di connessione al database.

Denial of Service (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Un attacco di questo tipo viene solitamente effettuato inviando intenzionalmente un input errato ad una applicazione. Questo per due scopi principali:

  • causare un errore che riveli informazioni di dettaglio sull’applicazione;
  • provocare il crash dell’applicazione o di una sua componente.

Se tutte le eccezioni non sono state opportunamente catturate e gestite, questa eventualità potrebbe verificarsi.

Audit e Log

L’audit è una tecnica che permette di determinare e scoprire a posteriori le violazioni sulla sicurezza e si basa sulla creazione di log (di solito file) in cui registrare gli eventi e/o statistiche che una entità effettua sul sistema in oggetto. Questo tipo di tecnica dovrebbe essere utilizzata per individuare, riparare e possibilmente prevenire il maggior numero possibile di attività illecite. I log forniscono un meccanismo per analizzare lo stato di sicurezza del sistema, anche per determinare se un’azione richiesta metterà il sistema in uno stato non sicuro o per determinare la sequenza degli eventi che conducono il sistema in uno stato di non sicurezza.

Si raccomanda di registrare almeno le azioni riguardanti le seguenti tipologie di eventi delle applicazioni:

  • lettura dati sensibili;
  • scrittura dati sensibili;
  • cancellazione di ogni tipologia di dato;
  • tutti gli eventi di autenticazione (login, logout, e log failure)
  • tutti i tentativi di modifica autorizzazioni includendo data e ora, se è avvenuto con successo o è stato rifiutato, la risorsa o la funzione alla quale si autorizza, e l’utente che ha chiesto l’autorizzazione.

Si riportano i problemi che possono far sì che il meccanismo di log non possa fornire le informazioni necessarie per stabilire lo stato di sicurezza del sistema.

Negazione di aver effettuato una operazione (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). L’attacco consiste nella possibilità di ripudio di una azione o di una transazione che è realmente avvenuta facendola apparire come se non fosse mai stata eseguita.

Violazione di una applicazione senza lasciare tracce (Applicabilità: Applicazioni Web Oriented, Client server, MainFrame). Questa minaccia consiste nell’attacco a un’applicazione utilizzando uno dei metodi descritti in precedenza senza che ci sia conoscenza del cambiamento sullo stato del sistema.

Vediamo ora alcuni delle minacce più diffuse:

Defacement

Il web defacement è la modifica non autorizzata di come visivamente appare un sito web. Tale azione è ormai un elemento ricorrente in Internet e le motivazioni che spingono un attaccante ad agire in questo modo sono molteplici, incluse la dimostrazione di abilità, le ragioni ideologiche, la truffa ed il ricatto con implicazioni prevalentemente di danno economico. La gravità di questo problema è ormai diventata incontrovertibile, come dimostrato da numerosi dati di fatto. Attacchi di questo genere sono ormai effettuati in maniera automatizzata ed in larga scala, in modo analogo a quanto avviene con la propagazione dei virus e degli worm. I contenuti originari vengono sostituiti con testi e/o immagini irridenti e critici, a volte “nonsense” (o apparentemente tali).

Un defacement mina la credibilità del sito colpito, che dimostra di essere vulnerabile. Pur interferendo con la comunicazione del sito colpito, il danno non è permanente. La modifica del sito web viene effettuata ottenendo un accesso al server che lo ospita.

Attacchi di Denial of Service (DoS) e Distributed Denial of Service (DDoS)

La sigla DoS di Denial of Service si traduce letteralmente in negazione del servizio. Si tratta di un malfunzionamento dovuto ad un attacco informatico in cui si esauriscono deliberatamente le risorse di un sistema informatico che fornisce un servizio, ad esempio un sito web, fino a renderlo non più in grado di erogare il servizio. Alcuni mirano solo ad un servizio, ad esempio Web, SMTP, FTP, etc., altri invece mirano a mettere fuori uso completamente il server o, addirittura, un’intera rete.

Gli attacchi DDoS (Distributed Denial of Service) amplificano la portata di tali minacce.

Gli attacchi di tipo DDoS sono molto più insidiosi da bloccare perché:

  • la potenza dell’attacco (volume dei dati trasmessi, banda occupata, etc.) è maggiore, di vari ordini di grandezza, rispetto a quella possibile attraverso un DoS;
  • è praticamente impossibile bloccare l’attaccante nella considerazione che sono decine di migliaia di computer infetti che perpetrano l’attacco;
  • è praticamente impossibile riconoscere il traffico autorizzato da quello non autorizzato, visto che i computer partecipanti alla botnet sono dislocati, praticamente in tutto il globo.

Attacchi man in the middle.

Consistono nell’intercettazione da parte dell’attaccante della comunicazione legittima in corso tra due attori. Tramite diverse tecniche, che si differenziano attraverso la tipologia di connessione in corso, l’attaccante osserva lo scambio di informazioni tra le due parti, e al momento più opportuno si sostituisce a una delle due per ottenere quanto desidera.

Un classico esempio di questa tipologia di attacco, che sta mietendo sempre più vittime anche in Italia, viene denominato man in the mail: a seguito della violazione dell’account di posta di uno dei due attori coinvolti, l’attaccante è in grado di assistere alle conversazioni email. In questo modo egli può carpire quante più informazioni sulle persone coinvolte e al momento opportuno sostituirsi ad una di esse in maniera esemplare. L’unico modo per evitare il verificarsi di tali truffe è chiedere una conferma certa da parte del ricevente e in caso di dubbi stoppare l’attività di bonifico.

Malware

Il termine malware indica genericamente un qualsiasi software creato con il solo scopo di causare danni più o meno gravi ad un computer, ai dati degli utenti del computer, o a un sistema informatico su cui viene installato. Si conoscono molte categorie di malware, anche se spesso questi programmi sono composti di più parti interdipendenti e rientrano pertanto in più di una classe. Tra questi i più frequenti sono:

  • Virus: sono parti di codice che si diffondono copiandosi all’interno di altri programmi, o in una particolare sezione del disco fisso, in modo da essere eseguiti ogni volta che il file infetto viene aperto. Si trasmettono da un computer a un altro tramite lo spostamento di file infetti ad opera degli utenti;
  • Worm: il loro scopo è rallentare il sistema con operazioni inutili o dannose;
  • Trojan horse: software che contengono istruzioni dannose che vengono eseguite all’insaputa dell’utilizzatore, per diffondersi devono essere consapevolmente inviati alla vittima;
  • Backdoor: consentono un accesso non autorizzato al sistema su cui sono in esecuzione;
  • Spyware: software che vengono usati per raccogliere informazioni dal sistema su cui sono istallati e per trasmetterle ad un destinatario interessato, le informazioni carpite possono andare dalle abitudini di navigazione fino alle password e alle chiavi crittografiche di un utente;
  • Dialer: questi programmi si occupano di gestire la connessione ad Internet tramite la normale linea telefonica, possono essere utilizzati in modo illecito, modificando il numero telefonico chiamato dalla connessione predefinita con uno a tariffazione speciale, allo scopo di trarne illecito profitto all’insaputa dell’utente;
  • Hijacker: questi programmi si appropriano di applicazioni di navigazione in rete (soprattutto browser) e causano l’apertura automatica di pagine web indesiderate;
  • Keylogger: sono dei programmi in grado di registrare tutto ciò che un utente digita su una tastiera o che copia e incolla rendendo così possibile il furto di password o di dati che potrebbero interessare qualcun altro.

Il loro numero e la varietà, unite alla loro rapida evoluzione ed obsolescenza non consentono di classificarli al fine di raggiungere una loro tipizzazione sanzionatoria. La Convenzione di Budapest ha quindi evitato deliberatamente di sanzionare specificamente le varie forme di malware, anche soltanto limitandosi alle tipologie più ricorrenti, al fine di evitare la rapida perdita di attualità delle norme ivi contenute. Tuttavia è possibile ricondurre anche i malware sotto specifiche disposizioni della Convenzione avendo riguardo alla funzionalità ed ai danni prodotti dai malware che sono, invece, suscettibili di catalogazione e di tipizzazione normativa. Vengono in considerazione le norme[6] che sanzionano l’accesso abusivo, l’interruzione e l’intercettazione di comunicazioni telematiche, le varie forme di danneggiamento aventi ad oggetto dati, programmi o sistemi, le norme che sanzionano la disponibilità e la cessione a terzi di programmi realizzati al fine di accedere illegalmente a computer e sistemi protetti ovvero al fine di danneggiarli, i programmi concepiti per l’alterazione e la falsificazione di informazioni presenti in banche dati pubbliche o private, i malware specificamente progettati per recare un danno economico e conseguire un profitto tramite l’interferenza sul funzionamento di computer o sistemi.

Advanced Persistent Threats

L’anno 2014 è stato caratterizzato da numerosi attacchi del tipo Advanced Persistent Threat (APT), basati su malware già noti in passato ma riutilizzati secondo una nuova connotazione. Gli APT sono schemi di attacco articolati, mirati a specifiche entità o organizzazioni, e che si contraddistinguono per un accurato studio del bersaglio preventivo e che spesso continua anche durante l’attacco, per l’impiego di tool e malware sofisticati e per la lunga durata o persistenza nel tempo cercando di rimanere inosservati per continuare a perpetrare quanto più possibile il proprio effetto.

Crimini di identità

Il nuovo contesto tecnologico, la diffusione capillare di Internet e fenomeni quali i social network hanno fatto sì, infatti, che l’attenzione dei criminali si rivolgesse verso nuove forme di cybercrime che hanno ragione di esistere in quanto sfruttano l’immaterialità del cyberspace.

Questa nuove forme di crimini informatici si sostanziano in abusi di profili identitari altrui nel cyberspace, ovvero il furto d’identità digitale, il phishing, l’abuso di identità “virtuale”, le frodi identitarie, fenomeni questi che possono essere ricondotti nella categoria generale degli “identity crime”.

Tale categoria comprende in pratica tutte quelle condotte delittuose che comportano una aggressione all’identità digitale altrui, dovendosi intendere con tale espressione quell’insieme di informazioni presenti online e relative ad una persona, un ente, un brand, ecc.

I crimini di identità si dividono in due categorie: i furti d’identità, cioè la sottrazione di dati personali di persone esistenti o decedute e le frodi d’identità, cioè la creazione di un’identità fittizia, basata su dati falsi o manomessi (mescolando dati reali di più persone).

La tecnica più diffusa per il furto di identità è il phishing: può essere definito come “una metodologia di comportamento sociale indirizzata a carpire informazioni personali o abitudini e stili di vita”. Attraverso tale tecnica si induce l’utente a fornire dati personali che consentono l’accesso ad informazioni riservate.

Social Engineering. La dissimulazione disonesta: l’ingegneria sociale

Non importa di quali tecnologie di sicurezza sia dotata un’azienda, l’investimento in soluzioni all’avanguardia potrebbe essere inficiato dal comportamento di un solo utente, manipolato con un attacco di ingegneria sociale. Non esiste alcuna tecnologia che permetta di prevenirlo o di difendersi. Per esserne immuni è necessario essere addestrati.

L’ingegneria sociale è in generale l’arte di indurre le persone a compiere determinate azioni dissimulando il reale obiettivo dell’attacco. L’ingegnere sociale è abile a mascherare la propria identità, fingendosi un’altra persona: in tal modo, attraverso la conversazione o altre interazioni, riesce a ricavare informazioni che altrimenti non otterrebbe.

In ambito security il social engineering viene utilizzato come metodo di intrusione e spesso l’attività di social engineering è strettamente collegata a quella di phishing. L’evoluzione del cybercrime negli ultimi anni evidenzia la tendenza all’utilizzo congiunto di tecniche avanzate di malware e social engineering per lanciare attacchi sempre più sofisticati e difficili da prevedere o rilevare, tali da provocare danni ingenti e a volte irreparabili ai sistemi di sicurezza aziendali, con conseguenti perdite economiche, perdita di dati sensibili e informazioni strategiche, danno alla reputazione.

Operazioni estorsive. Cifratura di file con ransomware

Questa tipologia di attacchi si sta evolvendo e raffinando sempre più. Il metodo di diffusione più comune è quello dell’email, che viene camuffata ad arte per assomigliare ad esempio ad una fattura o ad un ordine di un potenziale cliente. Il fine dell’attaccante è quello di indurre l’utente ad eseguire il download dell’allegato presente sulla mail ricevuta, in modo tale da poter eseguire l’installazione del virus sulla macchina target. Una volta installato, il ransomware esegue una cifratura di quanti più file riesce a infettare, includendo non solo la macchina locale su cui è stato scaricato, ma anche le eventuali cartelle condivise. Per ottenere la chiave di decifrazione la vittima deve pagare un riscatto, solitamente sotto forma di Bitcoin, la moneta digitale utilizzata sempre più dai cybercriminali per le transazioni di questo genere, in quanto difficilmente rintracciabili.

Ultimamente questo tipo di ransomware (locker-ransomware), è stato gradualmente soppiantato da un più insidioso crypto-ransomware, co­dici che criptano i soli documenti lasciando però accesso al sistema che invece risulterà vuoto e chie­dendo un riscatto (generalmente nell’ordine delle centinaia di dollari) per riottenere i documenti in chiaro.

Questa particolare forma di malware è cresciuta di molto anche grazie alla diffusione di servizi di ransomware as a service gestiti da gruppi criminali che affittano servizi completi di ransomware a chi decide di gestire in proprio le campagne di estorsione informatica.

Attacchi alle infrastrutture Cloud

L’utilizzo del Cloud computing ha introdotto nuove sfide che aziende e organizzazioni di ogni tipo e dimensione hanno la necessità di affrontare. Le politiche e procedure disegnate attraverso esperienze decennali nella gestione delle minacce on-premise[7], continuano ad avere la loro validità anche negli ambienti public e hybrid cloud, ma non sono più sufficienti: c’è la forte necessità per i team di sicurezza di mantenersi aggiornati sulle nuove tipologie di minacce che il cloud computing deve affrontare, per definire la migliore strategia di protezione. Tali minacce possono essere introdotte da caratteristiche peculiari dei servizi cloud o per effetto dell’interconnessione tra l’ambiente on-premise con quello cloud.

Strategia di un attacco

Per individuare le vulnerabilità all’interno di una applicazione possono essere sfruttate diverse forme di interazione, i cui passi principali sono:

  • controllo e identificazione: l’obiettivo dell’attacco viene studiato al fine di identificare congiuntamente le caratteristiche di una applicazione, ossia ad esempio i servizi ed i protocolli utilizzati, le corrispondenti vulnerabilità e punti di accesso. In primo luogo si potrà simulare il normale utilizzo da parte di un utente e a tale scopo sarà sufficiente un qualunque client http;
  • infiltrazione: dopo aver studiato ed identificato l’obiettivo, il passo successivo sarà quello di cercare una strada che permetta di infiltrarsi nel sistema. Se la sicurezza della rete e la sicurezza dell’host saranno state ben salvaguardate, sarà presa di mira la sicurezza delle applicazioni;
  • appropriazione di privilegi: dopo aver trovato una via di ingresso, il prossimo passo potrebbe consistere nel tentativo di ottenere diritti di accesso ancora più elevati, per allargare il proprio campo di azione. Se nella corrispondente gestione della configurazione sono stati previsti processi e account del servizio con privilegi troppo elevati, ciò faciliterà questa tipologia di intervento. Per questo motivo il principio del minimo privilegio resta sempre una contromisura molto importante da adottare;
  • mantenimento di un accesso: dopo aver ottenuto l’accesso ad un sistema, si cercherà di mantenerlo, provvedendo anche a semplificarlo per il futuro ed a cancellarne le tracce. Un esempio potrebbe consistere nell’installazione di programmi di back-door, che lasciano aperta la strada o anche nella scelta di un account adatto. Per coprire le proprie tracce, sarà poi effettuata una pulizia dei log, che costituiscono un altro potenziale obiettivo di attacco ed è per questo motivo che i file di log dovrebbero essere salvaguardati ed analizzati sistematicamente;
  • negazione del servizio (Denial of Service): alcuni attaccanti che non riescano ad ottenere l’accesso ad un sistema, spesso cambiano obiettivo, cercando di impedire agli utenti legittimi di utilizzare l’applicazione, per altri ancora, questo può essere invece l’obiettivo primario.

Cap.4 Le Investigazioni Digitali

Lo “stato” della digital forensics in Italia si è, negli ultimi anni, evoluto sensibilmente e, fortunatamente, in maniera abbastanza omogenea. Sin dagli anni duemila, la scienza che studia la corretta identificazione, acquisizione, produzione e, in senso lato, “resistenza” in giudizio della fonte di prova digitale ha vantato anche in Italia uno sviluppo lineare che ha riguardato tutti i settori coinvolti, nessuno escluso: il mondo dell’accademia, le Forze dell’Ordine, la magistratura e l’avvocatura e il mondo dei consulenti, dei tecnici, degli esperti, delle associazioni e delle aziende che producono software ed hardware per la digital forensics (soggetti, questi, giustamente più votati a un approccio alla materia tecnico e d’immediata utilità, compresa la formazione nell’utilizzo di tali strumenti, sovente complessi). Ciò ha portato a uno sviluppo equilibrato del settore, cosa molto utile e apprezzabile in un ambito che viene a toccare, come è noto, i diritti fondamentali dell’individuo.

Prova digitale: «È da considerarsi prova digitale il dato e la rispettiva informazione avente valore probatorio, ricavati da un accertamento tecnico-scientifico di tipo informatico, svolto nell’ambito di un procedimento penale o civile.»

L’aspetto più importante, e che è divenuto la questione centrale, è che la digital forensics ha intaccato alcuni concetti base ritenuti universalmente validi in ambito legale, i quali devono essere in qualche modo ricodificati o quantomeno riadattati all’inarrestabile evoluzione tecnologica del mondo digitale.

Ad esempio…

La dematerializzazione

In generale il processo di dematerializzazione è stato largamente introdotto quando, anche la PA, ha cercato di trasformare l’enorme massa di documentazione cartacea in suo possesso in file su una memoria di massa digitale.

A questo va aggiunto che si è cercato non solo di implementare l’archiviazione in tal senso, ma anche le procedure, spostando le attività umane su flussi descritti e contenuti in complessi database (archivi elettronici) e software basati su articolate reti di computer.

Il completo processo di dematerializzazione, però, e mi riferisco in Italia, impiegherà lunghi periodi, lasciando ancora alla carta un centralissimo ed indiscutibile compito in qualsiasi ambito documentale e procedurale.

Uno dei motivi fondamentali di tale difficoltà di avanzamento è la mancanza di fiducia verso il digitale, che ha sicuramente mostrato la sua pervasività ed indispensabilità, ma ha parimenti evidenziato un’assoluta incapacità di gestire sicurezza, affidabilità e disponibilità dei dati:

  • sicurezza: stabilire chi (identità) è autorizzato a fare cosa (attività) e con quali dati (informazioni) ed evitare che non autorizzati svolgano procedure o accedano a dati loro vietati. Non esiste ad oggi un sistema tecnico completamente sicuro per i sistemi digitali, soprattutto quando sono in rete, è indispensabile una politica di gestione della sicurezza che coinvolga anche le persone;
  • affidabilità: garanzia che i dati registrati restino integri nel tempo. La maggior parte delle memorie digitali si danneggia con frequenza molto più alta della carta, che resta il supporto di memoria al momento più longevo;
  • disponibilità: garanzia che i dati restino disponibili agli autorizzati quando questi lo richiedono. Spesso tra guasti di sistema, difficoltà di connessione, ecc. i dati, pur essendo presenti in una rete complessa, non sono disponibili.

Succede poi che in Italia sicurezza, affidabilità e disponibilità vengono percepiti come costi sia dalle PA che dalle aziende e non come investimenti e quindi si cerca di “spenderci il meno possibile” conseguendo sistemi deboli e mediamente mal funzionanti che vengono rafforzati solo nelle aree in cui non se ne può fare a meno (es. aree riservate o critiche).

La dematerializzazione nella digital forensics

Nella digital forensics i problemi appena visti per la dematerializzazione in generale, non solo esistono, ma sono rafforzati dalla pesantezza e rilevanza dell’attività considerata che è quantomeno un’indagine civile/penale. Ogni volta infatti che si devono affrontare questioni critiche in cui si rischiano grosse ripercussioni per degli errori è naturale irrigidirsi. Si può passare immediatamente a considerare l’aspetto digital forensics centrale di tale faccenda mediante un esempio base di semplice e diretta comprensione. Qualora un PC contenga nella sua memoria di massa (hard disk) alcuni dati di estremo interesse, per un’indagine di PG nei confronti del suo possessore, se ne può disporre il sequestro (fisico) per poi consentire ad un CT di svolgere un’analisi forense approfondita consegnandogli l’oggetto. La domanda però è perché disporre un sequestro fisico dello strumento quando NON si è interessati a tutto quello che contiene ma solo ad alcuni dati in esso registrati.

In definitiva si è stabilito un nuovo concetto di sequestro virtuale in cui l’oggetto del sequestro non è la “cosa” ma il “dato”. Va dunque distinto il “contenitore” rispetto al “contenuto”.

Il punto massimo sul reperto virtuale e sulla dematerializzazione, lo si ha con i sistemi cloud. In breve un cloud system è un sistema che usa Internet come semplice rete di appoggio, combinando il lavoro di migliaia di server in tutto il mondo, ciò a determinare una serie di servizi.

Il computer virtuale su cloud o computer remoto è un intero sistema di elaborazione che NON esiste fisicamente ma solo virtualmente (è definito scientificamente macchina virtuale distribuita). Il suo sequestro può essere SOLO di natura virtuale ed il reperto che ne consegue è un insieme di dati che difficilmente potrà sussistere solo in un hard disk.

In altre parole NON è sempre possibile registrare questa fonte di prova su una nostra memoria locale, tale contenitore non è adeguato. L’unico modo di gestire la situazione è lasciare il computer virtuale nel cloud e chiedere al gestore del cloud di “congelarlo” lì dove si trova, ad esclusivo uso di PG ed AG e dei loro CT e periti.

Cyberspace vs. “domicilio informatico”

A differenza di circa venti anni fa, l’investigatore moderno volente o nolente si trova proiettato ad indagare in un mondo parallelo ed intangibile che costituisce di fatto una sorta di quinta dimensione, ossia il cyberspace. Ma cosa s’intende con tale termine di origine anglosassone? Una definizione formale ed esaustiva l’ha fornita la ISO 27032:2012, la quale ha sancito che è intendersi come “l’ambiente virtuale generato dall’interazione tra persone, software e servizi Internet ottenuti attraverso l’uso di sistemi informatici e telematici interconnessi tra loro.

Attualmente tale ambiente operativo non è formalmente definito in specifiche norme del nostro sistema giudiziario, ma oramai per consuetudine possiamo dire che esso è assimilato al concetto di “domicilio informatico” sancito dalla nostra Suprema Corte nel seguente modo: “… deve ritenersi “domicilio informatico” … quello spazio ideale (ma anche fisico in cui sono contenuti i dati informatici) di pertinenza della persona, cui si estende la tutela della riservatezza della sfera individuale, quale bene anche costituzionalmente protetto (art. 15 Cost.)…”[8].

Alla luce di tale asserto, possiamo senza dubbio dire che attualmente l’ordinamento penale conosce un duplice significato del termine “domicilio”:

  • uno in senso reale, inteso come “spazio ideale di pertinenza della persona, al quale estendere la tutela della riservatezza della sfera individuale, quale bene anche costituzionalmente protetto (art. 14 Cost.)[9];
  • uno in senso virtuale, che si differenzia dal primo per la morfologia del perimetro, il quale è caratterizzato da una “geometria variabile” nella disponibilità diretta della parte. Dalla dinamicità di tale ambiente deriva che il suo contenuto informativo non necessariamente coincide con quello del dispositivo fisico assicurato, ma può essere distribuito anche in aree diverse dal territorio nazionale[10], come ad esempio il cloud[11], il cui paradigma ha di fatto stravolto il “modus investigandi” che si era consolidato nel tempo.

L’impatto del Cloud Computing nell’attività investigativa

Come noto il principale problema derivante dalle indagini in materia di criminalità informatica in Internet è l’ “aterritorialità”.

Si pongono dunque problemi che si collocano a diversi livelli:

  • livello investigativo: ampio terreno da monitorare;
  • livello procedurale: chi è competente a fare cosa;
  • livello di diritto penale: a quale legge penale, di quale Stato, bisogna fare riferimento.

Tali difficoltà vengono ulteriormente amplificate quando l’attività antigiuridica viene realizzata per mezzo dei servizi c.d. “cloud based” (es. Social Network, Cloud Storage, ecc.) i quali sono fortemente caratterizzati da elementi come:

  • ubiquità, specie da parte di client leggeri come quelli previsti per i dispositivi mobile (es. smartphone, tablet, ecc.). A riscontro basti pensare che, mentre la Polizia Giudiziaria sta attuando una perquisizione informatica in un account Google, ancorché in presenza della parte, un soggetto terzo potrebbe contemporaneamente accedere e modificare, se non cancellare del tutto, gli elementi di prova utili per le indagini vanificando/compromettendo l’esito della stessa;
  • depemetralizzazione” e condivisione delle risorse secondo un modello multitenant (letteralmente, “con più affittuari” – es. cartelle o file condivisi). In tale modello le risorse fisiche e virtuali sono assegnate e riassegnate dinamicamente ai consumatori, sulla base delle loro esigenze (es. un documento GDoc scritto e revisionato da più soggetti). C’è inoltre un’indipendenza dalla locazione, in cui si trovano di fatto i consumatori e chi gli fornisce il servizio (CSP – Cloud Service Provider) infatti questi, per quanto appreso, non hanno né il controllo né la conoscenza dell’ubicazione geografica delle risorse utilizzate. È tuttavia possibile che i CSP abbiano il controllo sulla locazione a un livello di astrazione più alto, ad esempio la nazione (spesso questo è necessario per motivi prevalentemente legislativi);
  • ridondanza, come una risorsa complessa può essere distribuita in più datacenter, altrettanto la stessa può essere ripetuta più e più volte per bilanciare il carico di lavoro del CSP.

Accertamenti informatici in ambito aziendale

Le attività investigative che vedono coinvolti sistemi informatici e/o telematici possono essere svolti anche in ambito aziendale, il cui contesto operativo necessita di accorgimenti diversi dalla privata dimora.

Ricerca Informativa

Al fine di circoscrivere e dettagliare nella maniera più precisa possibile sia l’area fisica che virtuale della scena criminis, gli eventuali sospettati, nonché gli elementi di reato, si rende necessario dapprima assumere informazioni da chi ricopre il ruolo di “responsabile dei sistemi informativi[12] circa “policy aziendali” in materia di:

  1. sicurezza fisica, relativamente, ad esempio:
    • all’esistenza di apparati di videosorveglianza e rispettivo periodo di data retention[13];
    • policy di accesso all’edificio (es. accesso tramite badge);
    • eventuale gestione in outsourcing (società terze) per la manutenzione dei sistemi precedentemente elencati;
  2. sicurezza logica, relativamente, ad esempio:
    • alla mappatura dell’infrastruttura di rete (subnet[14], assegnazione statica o dinamica degli IP[15], antivirus, firewall[16], IDS[17], DMZ[18] ecc.);
    • regola di accesso al sistema telematico, ossia solo in locale (intranet) o anche da remoto (extranet);
    • ai criteri di autenticazione (es. password, two step verification[19], strong authentication[20]) e rispettivi permessi (amministratore, operatore di sistema, ecc.) degli utenti accreditati al sistema informatico aziendale;
    • presenza di sistemi di cifratura degli hard disk (es. BitLocket, File Vault, Volumi crittografici, ecc.) ed acquisizione delle rispettive passphrase;
    • presenza di un CSIRT[21] ed eventuali ticket aperti nel periodo di interesse per le indagini;
    • metodi di logging e rispettivo periodo di data retention[22] di ciascun sistema di sicurezza;
    • eventuale gestione in outsourcing (società terze) per la manutenzione dei sistemi precedentemente elencati.

Tali dichiarazioni potranno trovare riscontro dalla consultazione del Documento di valutazione rischi, ovvero del Modello di organizzazione e gestione.

Le misure tecniche

Da un punto di vista meramente pratico, le misure tecniche da adottare sui dati, informazioni e programmi ritenuti di interesse per le indagini, potranno essere attuate seguendo le raccomandazioni fornite dall’ISO 27037:2012. Tale documento definisce sia chi sono i soggetti, che le tecniche di acquisizione che questi potranno adottare sulla scena del crimine aziendale nel pieno rispetto dei principi giuridici e requisiti investigativi riconosciuti su scala transnazionale.

In ambito internazionale vengono identificate le seguenti figure professionali, quali soggetti devoluti alla gestione delle fonti di prova digitali rinvenute sulla scena del crimine informatico:

  • DEFR (Digital Evidence First Responder – ISO 27037:2012 Pt. 3.7), questi viene coinvolto nelle fasi di identificazione, repertamento e/o acquisizione e preservazione della fonte di prova digitale. Tale figura professionale non dovrebbe necessariamente svolgere un’attività di analisi.
  • DES (Digital Evidence Specialist – ISO 27037:2012 Pt. 3.8), questi fornisce supporto tecnico al DEFR nelle fasi di identificazione, repertamento e/o acquisizione e preservazione delle fonti di prova digitale. Il DES deve essere caratterizzato da una formazione di tipo accademico e di comprovata esperienza nel settore tecnico-investigativo.

L’operato di tali soggetti deve avvenire nel rispetto dei seguenti principi e requisiti comuni alla maggior parte dei sistemi giurisdizionali internazionali:

  • rilevanza/pertinenza (relevance): secondo cui bisogna dimostrare di aver acquisito e/o repertato solo elementi di pertinenza con il contesto d’indagine, avendo cura di motivarne le ragioni;
  • affidabilità/attendibilità (reliability): secondo cui ogni processo che caratterizza la scena del crimine informatico dovrebbe essere verificabile e ripetibile. L’attuazione di tali processi dovrebbe garantire l’intera riproducibilità dell’attività tecnico-investigativa;
  • sufficienza/proporzionalità (sufficiency): in cui il DEFR si assicura di avere a disposizione sufficiente materiale su cui svolgere le indagini;
  • verificabilità (auditability): secondo cui dovrebbe essere possibile per una parte terza, autorizzata dall’A.G. (es. il Consulente Tecnico), poter accertare tutte le attività poste in essere sia dal DEFR che dal DES sulla scena del crimine informatico;
  • ripetibilità (repeatability): secondo cui si producono gli stessi risultati con lo stesso test nello stesso ambiente;
  • riproducibilità (riproducibility): secondo cui si producono gli stessi risultati con ambiente diverso, quindi anche tool diversi;
  • giustificabilità (justifiability): secondo cui il DEFR dovrebbe essere in grado di poter giustificare la metodologia attuata per quel particolare contesto investigativo caratterizzato da vincoli giuridici, tecnologici e logistici, oltreché di competenze tecniche dello stesso operatore.

Ricostruzione degli eventi

La differenza sostanziale tra le indagini classiche e quelle in materia di criminalità informatica in Internet è l’ “aterritorialità”.

Tale vincolo solleva problemi a diversi livelli:

  • territoriale: assenza di confini ben definiti;
  • livello processuale: chi è competente a fare cosa;
  • legislativo: Autorità Giudiziaria competente ad indagare o giudicare.

Tali elementi, uniti a vincoli di carattere tecnologico, ostacolano, se non rendendo impossibile, l’operazione di ricostruzione del percorso utilizzato dall’autore del reato, non consentendo così l’individuazione della postazione dalla quale è stato posto in essere il comportamento illecito.

A tale risultato potrà pervenirsi unicamente seguendo a ritroso il cammino dell’informazione illecita, dal destinatario ad un provider (sovente con sede all’estero), e da questi sino al client dell’autore del reato.

Nel caso in cui la postazione sia nella disponibilità di più soggetti, sarà necessario correlare l’attività tecnico-investigativa con gli elementi di prova[23] ricavati con modalità classica, al fine di dimostrare una disponibilità univoca del mezzo di un determinato lasso temporale.

Qualora bisognasse svolgere operazioni di analisi inerente un sistema di rete può essere conveniente, in prima approssimazione, suddividere le tematiche legate al Network Forensics in due classi, a seconda si tratti di live analysis o post mortem analysis, per una collocazione nell’ambito codicistico penale procedurale che separi, seppur in modo non esaustivo, lo stato pre – e post – discovery.

In ottica post mortem delle attività correlate all’utilizzo per fini criminali della rete, a contrario del contesto del mondo reale, si avranno a disposizione generalmente solo pochi ed incerti elementi:

  • indirizzo IP[24] (dove IP sta per Internet Protocol) è l’elemento fondamentale che permette, all’interno di una rete di calcolatori, di individuare un nodo della rete stessa. Gli indirizzi IP sono utilizzati dal protocollo IP per gestire l’instradamento delle comunicazioni tra tutte le macchine connesse a Internet;
  • i file di log, sul quale registrati gli eventi in ordine cronologico (consente di stabilire: un determinato utente in un particolare giorno ed ora si è collegato alla rete tramite un provider; data ed ora della sessione di navigazione; quale indirizzo IP temporaneo ha avuto in assegnazione per la durata della connessione; l’indirizzo IP utilizzato per la sessione di navigazione; quali informazioni ha inviato o ricevuto per mezzo dell’indirizzo IP assegnato; anagrafica dell’intestatario di un contratto di utenza Intenet);
  • l’URL, l’Uniform Resource Locator, è una sequenza di caratteri che identifica univocamente l’indirizzo di una risorsa in Internet, come ad esempio un documento o un’immagine.

Risposta alle intrusioni

Nel caso in cui si è vittima di un accesso abusivo nella propria infrastruttura, di seguito vengono proposte le procedure di risposta alle intrusioni:

  1. analisi di tutte le informazioni disponibili che caratterizzano una intrusione:
    • registrazione di tutte le informazioni che possono essere perse o non registrate durante una procedura di backup (connessioni di rete correnti, processi attivi o ibernati, utenti connessi, file aperti, informazioni volatili);
    • backup dei sistemi compromessi: realizzare almeno due backup completi dei sistemi e dei dati utente identificati come compromessi, utilizzare supporti proteggibili via hardware o non riscrivibili;
    • isolare i sistemi compromessi (trasferimento dei file di backup su un sistema di test isolato dai sistemi di produzione, restore dei sistemi compromessi sul sistema di test, analisi diretta da effettuarsi sul sistema di test);
    • ricerca di tracce di intrusione su altri sistemi. Gli intrusori abitualmente creano più di un punto di accesso in una rete dove abbiano conquistato un accesso. Nel caso sia stata rilevata una intrusione sarà necessario controllare tutti gli altri sistemi simili al sistema violato;
    • esame dei log file generati dai firewall, router, e network monitor. Gli attacchi spesso lasciano tracce che possono condurre all’individuazione dei sistemi;
    • identificazione dell’attacco ad un sistema. Dopo aver conquistato l’accesso ad un sistema, l’intrusore può cercare di cancellare tutti i log file o alcuni specifici log entry, e quindi è possibile non trovare alcuna di queste utili informazioni. A volte la cancellazione dei log entry è rilevabile, in questo caso è la prova di una attività sospetta ed è necessario procedere ad analisi più approfondite;
    • identificazione delle attività eseguite durante un attacco ad un sistema (analizzare in vari log file, come quegli specifici sistemi di Intrusion Detection);
  2. raccolta e conservazione delle informazioni associate ad un’intrusione:
    • raccolta di tutte le informazioni relative ad un’intrusione. Raccogliere le informazioni ricavate dai log dei sistemi e delle reti degli ambienti compromessi, dai sistemi di intrusion detection, firewall, router ed altri strumenti. Raccogliere i backup completi e parziali, documentare le schermate dei sistemi con screen-shots, videoregistrazioni e fotografie;
    • raccolta delle prove. Designare un responsabile per la raccolta delle prove e per il mantenimento dei contatti con l’Autorità Giudiziaria e con eventuali agenzie investigative private. Al fine di assicurare che le raccolte abbiano valore legale, le procedure di raccolta e conservazione delle stesse dovranno essere effettuate in accordo con la legislazione vigente;
    • conservazione delle prove. Tutte le informazioni registrate elettronicamente saranno archiviate fuori linea e conservate in luogo fisicamente sicuro;
  3. eliminazione di tutti gli strumenti utilizzati per l’intrusione:
    • modifica di tutte le password su tutti i sistemi ove sia stata riscontrata un’intrusione;
    • reinstallazione completa dei sistemi compromessi. Nel caso in cui sia difficoltoso o troppo oneroso verificare i checksum crittografici del sistema compromesso si dovrà procedere alla reinstallazione integrale del sistema utilizzando i supporti di distribuzione originali o delle copie sicuramente conformi;
    • rimozione di tutti i programmi utilizzati per realizzare l’intrusione e di tutte le modifiche determinate dall’intrusione;reinstallazione dei programmi eseguibili e dei file binari dai supporti di distribuzione originali;
    • revisione delle configurazioni del sistema. Dovranno essere verificati i file di configurazione del sistema;
    • determinare se sussistono vulnerabilità nel sistema e nella rete e correggerle;
    • migliorare gli strumenti di protezione per limitare l’esposizione dei sistemi e della rete;
  4. ripristino dei sistemi alle condizioni di normale operatività:
    • verifica dei requisiti e della tempistica per il ritorno alla normale operatività;
    • ripristino dei dati utente da un backup affidabile;
    • abilitazione dei sistemi e dei servizi;
    • connessione dei sistemi ripristinati alla rete;
  5. azioni conclusive. A seguito di una intrusione e del successivo ripristino della normale operatività sarà utile effettuare una analisi complessiva delle implicazioni determinate dall’evento:
    • valutazione dell’adeguatezza degli strumenti di protezione e individuazione delle violazioni dei sistemi;
    • revisione dei piani di sicurezza, delle politiche e delle procedure;
    • revisione delle direttive ad utenti ed amministratori dei sistemi volte a prevenire ulteriori violazioni;
    • valutazione della necessità di una nuova analisi del rischio in base alla gravità degli effetti dell’intrusione;
    • aggiornamento dell’inventario dei sistemi e dei loro assetti;
    • partecipazione ad azioni investigative e legali.

Cap.5 La Verifica dello Stato dell’Arte in Azienda

Ricognizione della situazione

Sono 5 i fattori critici che devono essere tenuti in debita considerazione al fine di realizzare una strategia di cyber risk efficace.

Il 1° elemento: riuscire ad acquisire una visione globale del rischio:

  • effettuare screening sistematici in ambito information security al fine di prefigurare i possibili scenari di minacce, identificare quali siano i target potenziali e verificare i livelli di protezione in tutte le funzioni ed aree aziendali;
  • ripartizione completa delle informazioni protette, poiché ritenute critiche e potenziali bersagli;
  • valutazione del rischio, a cui sono soggette le informazioni protette, dal punto di vista economico, che includa anche le misure di protezione.

Il 2° elemento: l’identificazione dei target potenziali ed il relativo impatto strategico per l’organizzazione, ciò significa ottenere:

  • una chiara visione del possibile pericolo causato anche da elementi “periferici” dei target potenziali, (es. nuovi processi o servizi connessi … );
  • un abbinamentoefficiente tra il probabile bersaglio e quelli imminenti ed attesi, nonché la loro valorizzazione economica e prioritizzazione per criterio di rischio e di potenziale impatto.

Il 3° elemento prevede lo sviluppo di un percorso di criticità relativamente agli scenari di rischio, ciò significa:

  • utilizzare in modo mirato l’esperienza ed i dati storici aziendali per calcolare sulla base delle probabilità l’insorgenza del potenziale rischio;
  • dare priorità alle minacce più significative, attraverso la rappresentazione di modelli e schemi di attacco creati su tipologie di minaccia analoghe.

Il 4° elemento definisce una strategia di “risk appetite” la quale prevede:

  • la stesura di un’adeguata strategia di “risk appetite”, la quale deve risultare condivisa non solo con i vertici delle aree funzionali ma anche con la Corporate Strategy;
  • la definizione di un’appropriata estensione di misure per la protezione delle informazioni incentratasui potenziali effetti, catalogati secondo criterio di probabilità ed impatto.

Il 5° evidenzia l’esigenza di aggregare le misure di sicurezza adottate per la protezione dei dati, prevedendo:

  • creazione di un processo integrato di misure per la sicurezza delle informazioni che va ad abbracciare le differenti funzioni aziendali;
  • aggregazione di un insieme di strategie di mitigazione del rischio a livello organizzativo, procedurale e di sistemi;
  • attuazione di interventi mirati e processi di controllo relativi al governo delle terze parti (es. fornitori, personale esterno…).

Il Framework Nazionale

Il Framework Nazionale definito in questo capitolo si fonda sul “Framework for Improving Critical Infrastructure Cybersecurity”, sviluppato dal National Institute for Standards and Technology (NIST) statunitense.

Il cuore del Framework NIST è costituito da un insieme di 21 Category e 98 Subcategory, organizzate in 5 Function. Ogni Subcategory rappresenta un’area di raccomandazioni che l’organizzazione può decidere di implementare, se necessario riferendosi a standard o norme specifiche di settore. Il Framework NIST fornisce, per ogni Subcategory, i riferimenti agli standard e Framework esistenti: si tratta di una mappatura parziale, ma che comunque copre la quasi totalità dei riferimenti già adottati dalle organizzazioni internazionali, quali Standard NIST, Standard ISO/IEC e COBIT.

Il Framework Nazionale amplia questa struttura inserendo due nuovi concetti: i livelli di priorità e i livelli di maturità. Questi due concetti permettono di tenere conto della struttura economica del nostro Paese fatta di alcune decine di grandi aziende e infrastrutture critiche e di una galassia di piccole imprese, rendendo dunque, di fatto, il Framework adatto alle PMI, ma conservando tuttavia la sua iniziale vocazione per Grandi Imprese e infrastrutture critiche.

Framework Core, Profile e Implementation Tier

Il Framework Nazionale eredita le tre nozioni fondamentali del Framework NIST: Framework Core, Profile e Implementation Tier[25]:

  1. Framework Core. Il core rappresenta la struttura del ciclo di vita del processo di gestione della cyber security, sia dal punto di vista tecnico sia organizzativo. Il core è strutturato gerarchicamente in Function, Category e Subcategory. Le Function, concorrenti e continue, sono: Identify, Protect, Detect, Respond, Recover e costituiscono le principali tematiche da affrontare per operare una adeguata gestione del rischio cyber in modo strategico. Il Framework quindi definisce, per ogni Function, Category e Subcategory, le quali forniscono indicazioni in termini di specifiche risorse, processi e tecnologie da mettere in campo per gestire la singola Function.
    • Identify, è legata alla comprensione del contesto aziendale, degli asset che supportano i processi critici di business e dei relativi rischi associati;
    • Protect, è associata all’implementazione di quelle misure volte alla protezione dei processi di business e degli asset aziendali;
    • Detect, è associata alla definizione e attuazione di attività appropriate per identificare tempestivamente incidenti di sicurezza informatica;
    • Respond, è legata alla definizione e attuazione delle opportune attività per intervenire quando un incidente di sicurezza informatica sia stato rilevato;
    • Recover, è associata alla definizione e attuazione delle attività per la gestione dei piani e delle attività per il ripristino dei processi e dei servizi impattati da un incidente.
  2. Profile rappresentano il risultato della selezione, da parte di un’organizzazione, di specifiche Subcategory del Framework;
  3. Implementation Tier forniscono contesto su come l’azienda, nel suo complesso, veda il rischio cyber e i processi posti in essere per gestirlo. Sono previsti quattro livelli di valutazione, dal più debole al più forte: (1) Parziale, (2) Informato, (3) Ripetibile, (4) Adattivo.

I livelli di priorità

I livelli di priorità permettono di supportare le organizzazioni e le aziende nell’identificazione preliminare delle Subcategory da implementare per ridurre maggiormente i livelli di rischio a cui sono sottoposte, bilanciandone l’impegno da profondere per la loro attuazione. Il Framework suggerisce l’utilizzo di una scala di priorità a tre livelli tra le Subcategory.

I livelli di maturità

I livelli di maturità permettono di fornire una misura della maturità di un processo di sicurezza, della maturità di attuazione di una tecnologia specifica o una misura della quantità di risorse adeguate impiegate per l’implementazione di una data Subcategory. I livelli di maturità forniscono un punto di riferimento in base al quale ogni organizzazione può valutare la propria implementazione delle Subcategory e fissare obiettivi e priorità per il loro miglioramento. I livelli devono essere in progressione, dal minore al maggiore. Ogni livello deve prevedere pratiche e controlli incrementali rispetto al livello di maturità inferiore

Pentration Testing

Nella “sicurezza informatica” è compreso anche il processo di prevenzione, ovvero quell’insieme di misure atte alla protezione di informazioni dall’accesso, dalla modica o dal furto da parte di “attività” non previste.

Un penetration test, occasionalmente pen test, è un metodo per la valutazione della sicurezza di un sistema informatico o di una rete simulando un attacco da parte di attaccanti esterni (che non hanno di norma accesso ai sistemi informatici) e/o di attaccanti interni (che hanno un qualche livello di accesso autorizzato ai sistemi)[26]

Auditor è colui che svolge tutte le attività di verifica operando con logiche medesime a quelle di un hacker. L’analisi intrapresa da un auditor comprende più fasi ed ha l’obiettivo di evidenziare in un report le debolezze rilevate nella piattaforma, fornendo il maggior numero di informazioni sulle vulnerabilità sfruttate per ottenere l’accesso non autorizzato.

L’auditor non si fermerà ad analizzare i soli sistemi informatici ma potrà sfruttare tecniche di ingegneria sociale per verificare eventuali carenze formative del personale aziendale di fronte a tentativi di intrusione; questa modalità definita Hidden Mode prevede l’accordo esclusivamente con il consiglio amministrativo dell’azienda che commissiona le verifiche lasciando all’oscuro tutto il personale, compreso il settore IT dell’azienda.

A livello metodologico il NIST descrive inoltre un concetto a cui spesso viene data poca importanza: il penetration test – per sua natura – è un processo iterativo e non ha un andamento lineare. Ogni volta che si hanno maggiori informazioni sul bersaglio queste vengono riutilizzate e si reitera su quanto già fatto. Non a caso Offensive Security[27] definisce il penetration test come “un ciclo continuo di ricerca e di attacco”.

E’ estremamente importante notare come la definizione si focalizzi sul metodo e non sullo strumento. Il penetration test non è un attività in cui lo strumento fa da padrone e non è un caso.

L’attacco ad un sistema si può suddividere in cinque fasi principali:

  1. Information Gathering; raccolta d’informazioni. Ha l’obbiettivo di raccogliere informazioni utili sul bersaglio come una lista di nomi di dominio, l’architettura della piattaforma, delimitazione di indirizzi IP, sistemi e porte attive, servizi offerti ed infine un elenco di nominativi ed e-mail utili in caso di attacco social engineering. I dati raccolti in questa fase permetteranno di scegliere la linea di attacco da seguire nel passo successivo;
  2. Vulnerability Assessment; ricerca di vulnerabilità. Un Vulnerability Assessment (VA) è un processo grazie al quale si identificano e quantificano le vulnerabilità di un sistema. Questa attività permette di avere una panoramica dello stato di sicurezza della infrastruttura tecnologica consentendo ad evidenziarne le potenziali vulnerabilità e ad implementare conseguentemente migliori politiche di sicurezza. Le informazioni elaborate in un vulnerability assessment, riportate in appositi report, consentono di delineare piani di analisi più mirati. Dato l’alto numero di nuove vulnerabilità che vengono scoperte ogni giorno è fondamentale svolgere un vulnerability assessment con la giusta frequenza al fine di assicurarsi che le configurazioni dei sistemi siano corrette e le opportune patch di sicurezza applicate
  3. Exploitation; Exploit delle vulnerabilità. La fase successiva di exploitation permette di ricercare all’interno di un software una vulnerabilità in grado di provocare un imprevisto nel sistema bersaglio dell’attacco. Con il termine exploit (la cui traduzione significa “sfruttare”) si identifica un pezzo di software o una sequenza di comandi che sfrutta un bug o una vulnerabilità per causare inaspettati comportamenti su un computer, sia per quanto riguarda lato software che hardware;
  4. Privilege Escalation; Scalata dei privilegi. Durante questa fase viene sfruttato l’accesso ricavato attraverso l’exploit per innalzare i propri privilegi; questo può avvenire sfruttando ulteriori vulnerabilità di sistema, sniffando pacchetti che transitano nella rete o semplicemente cercando di ottenere in chiaro le password di un utente amministratore. Possiamo distinguere due tipi di scalata:
    • scalata verticale: quando si ottengono autorizzazioni o privilegi superiori a quelli normalmente avuti;
    • scalata orizzontale: quando si ottiene l’accesso a risorse con gli stessi privilegi che normalmente concessi ma in un’area di competenza diversa;
  5. Reporting; infine l’attività di Pen Testing si conclude con la stesura di un Report dettagliato includendo tutte le vulnerabilità riscontrate, l’analisi dell’impatto di rischio ed eventualmente una possibile soluzione tecnica al problema.

Cap.6 Dinamiche di Reazione

Il reato informatico nella prassi giudiziaria: le linee guida internazionali per il contrasto ai nuovi fenomeni criminali

La Convenzione di Budapest per il contrasto al Cybercrime[28] ha adottato una tecnica di tipizzazione delle fattispecie incriminatrici che non riproduce pedissequamente i fenomeni criminali, riscontrati nella prassi giudiziaria ed investigativa delle attività di contrasto ma individua, secondo una tecnica di tipizzazione radicata nell’esperienza della codicistica italiana, una serie di fattispecie penalmente illecite caratterizzate dalle modalità della condotta, finalità perseguite ed evento realizzato. Di modo che, nella Convenzione e nelle norme che le hanno dato recepimento nell’ambito degli ordinamenti nazionali, non troveremo riscontro esplicito e diretto alle modalità specifiche attraverso le quali la criminalità concretamente opera: non troveremo cioè riferimenti a prassi criminali molto frequenti nell’esperienza quotidiana quali il phishing, il bombing, i botnet, lo spamming, in quanto si è ritenuto preferibile focalizzare l’attenzione sulle condotte criminali piuttosto che sulla tecnologia da questi utilizzata.

La scelta assunta dai compilatori della Convenzione ha l’innegabile pregio di fornire strumenti sanzionatori che, non essendo finalizzati a fotografare e qualificare giuridicamente le mutevoli fenomenologie dell’illecito cibernetico, non sono condannati a cadere in desuetudine e divenire inutilizzabili quando le tecniche di commissione degli illeciti dovessero mutare ed evolversi.

Offrono, quindi, strumenti di qualificazione giuridica sempre attuali. Al contempo, la tecnica di normazione prescelta, presenta il difetto di non consentire l’immediata riconduzione ad una unica fattispecie incriminatrice delle condotte illecite rilevate nella prassi.

Se da un lato l’operazione interpretativa finalizzata a qualificare giuridicamente le condotte criminali appare complessa e produttiva di risultati non sempre omogenei, l’esigenza sottesa alla Convenzione di Budapest è certamente quella di rendere omogenei i sistemi sanzionatori nazionali, al fine di facilitare la cooperazione giudiziaria, volta al contrasto di fenomeni criminali che presentano una eminente connotazione trans-nazionale. In questo ambito uno dei principi cardine della collaborazione internazionale è quello della reciprocità, ovvero il presupposto della comune qualificazione penale della condotta criminale da perseguire. Diventa quindi di centrale importanza che, non solo tutti i Paesi aderenti si dotino di un omogeneo sistema sanzionatorio ma che siano anche omogenei i canoni interpretativi che consentono di qualificare illecitamente le diverse condotte complesse nelle quali si estrinsecano le prassi criminali più ricorrenti. Propri alla standardizzazione dei canoni interpretativi tendono le linee guida adottate periodicamente dal Cybercrime Convention Committee (T-CY) istituito presso il Consiglio d’Europa in virtù dell’art. 46 della Convenzione e finalizzato a darle attuazione, ad arricchirne e potenziarne i contenuti, a favorire lo scambio di informazioni e di esperienze attuative tra gli Stati aderenti. In particolare le linee guida costituiscono l’espressione del comune intendimenti delle parti del trattato circa le modalità concrete di darvi attuazione, superando, attraverso una condivisa interpretazione delle sue norme (e delle norme di recepimento dei singoli stati) le ricadute negative che potrebbero verificarsi, sul piano della cooperazione giudiziaria, per effetto della differente interpretazione di ciò che sia o meno qualificabile come reato in base alla convenzione.

Sul piano del diritto nazionale le linee guida, pur non assumendo alcun valore normativo e tanto meno vincolante per l’interprete, offrono un valido strumento di ausilio nell’attività di interpretazione delle norme e di qualificazione giuridica dei fatti di reato, che presenta il pregio dell’uniformità ed il prestigio culturale proveniente, oltre che dall’elevata qualificazione tecnico giuridica della sua fonte, anche dall’attenzione e dalla completezza con le quali sono redatte.

Delitti informatici e trattamento illecito dei dati

Il Legislatore Italiano, spesso in adempimento di obblighi di cooperazione europea od internazionale, ha, nell’ultimo ventennio, introdotto nell’ordinamento diverse disposizioni aventi come oggetto la tutela dei “Sistemi Informatici o Telematici”.

Prima della legge n. 547 del 1993, nel nostro ordinamento non esisteva alcuna disposizione normativa specifica sui reati informatici. La legge 547/93 è intervenuta in quattro diverse direzioni, punendo le seguenti forme di aggressione:

  • le aggressioni alla riservatezza dei dati e delle comunicazioni informatiche;
  • le aggressioni all’integrità dei dati e dei sistemi informatici;
  • le condotte in tema di falso, estese ai documenti informatici;
  • le frodi informatiche.

In data 5 aprile 2008 è entrata in vigore la Legge n. 48, recante la ratifica ed esecuzione della Convenzione del Consiglio d’Europa sulla criminalità informatica.

Con tale norma il Legislatore ha apportato modifiche al codice penale in materia di reati informatici ed ha introdotto diverse disposizioni in relazione ai delitti informatici e al trattamento illecito dei dati.

Cap.7 Responsabilità dell’Azienda

La sicurezza delle informazioni nella legislazione italiana

Il legislatore italiano già da tempo si è preoccupato di dettare delle norme volte ad individuare alcune misure minime di sicurezza per tutti quei casi in cui la qualità delle informazioni contenute nei sistemi informatici di un’azienda renda opportuna e giuridicamente necessaria la loro protezione.

In particolare, la normativa italiana vigente – contenuta per poco tempo ancora nel D.Lgs. 196/2003 e comunemente denominata “Codice della privacy” – si applica esclusivamente al trattamento di dati personali. Essi sono definiti come “qualunque informazione relativa a persona fisica, identificata o identificabile, anche indirettamente, mediante riferimento a qualsiasi altra informazione, ivi compreso un numero di identificazione personale”.

Accanto alla definizione di dato personale e di dato identificativo, però, il legislatore ha espressamente previsto anche i concetti di dato sensibile e di dato giudiziario, protetti dalla normativa vigente in maniera ancora più stringente, dato l’alto valore delle informazioni in essi contenuto.

I dati sensibili, infatti, riguardano i dati personali idonei a rivelare l’origine razziale ed etnica, le convinzioni religiose, filosofiche o di altro genere, le opinioni politiche, l’adesione a partiti, sindacati, associazioni od organizzazioni a carattere religioso, filosofico, politico o sindacale, nonché i dati personali idonei a rivelare lo stato di salute e la vita sessuale di un soggetto.

I dati giudiziari, invece, sono i dati personali idonei a rivelare provvedimenti in materia di casellario giudiziale, di anagrafe delle sanzioni amministrative dipendenti da reato e dei relativi carichi pendenti, o la qualità di imputato o di indagato.

In merito alla loro protezione, l’art. 31 del Codice della privacy pone come regola generale quella secondo cui i dati personali oggetto di trattamento debbano essere “custoditi e controllati, anche in relazione alle conoscenze acquisite in base al progresso tecnico, alla natura dei dati e alle specifiche caratteristiche del trattamento, in modo da ridurre al minimo, mediante l’adozione di idonee e preventive misure di sicurezza, i rischi di distruzione o perdita, anche accidentale, dei dati stessi, di accesso non autorizzato o di trattamento non consentito o non conforme alle finalità della raccolta”.

Occorre evidenziare come il legislatore italiano preveda esplicitamente ed analiticamente solo le misure minime di sicurezza da applicare al trattamento dei dati, ovvero quelle dell’art. 34 e dell’Allegato B al Codice della privacy, lasciando invece indefinite le misure di sicurezza idonee previste dall’art. 31.

La non applicazione delle misure minime ha come conseguenza sanzioni di tipo penale, laddove la mancata predisposizione di misure di sicurezza idonee per lo specifico trattamento dei dati comporta l’applicazione delle sole sanzioni amministrative.

Le norme da prendere in considerazione, però, non si esauriscono con quanto finora accennato.

Il 25 maggio 2016, infatti, è entrato in vigore il “Regolamento europeo generale sulla protezione dei dati personali” n. 2016/679[29], che stabilisce norme relative alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché norme relative alla libera circolazione di tali dati.

Questo Regolamento diventerà definitivamente applicabile in ogni Stato membro dell’Unione Europea a partire dal 25 maggio 2018, abrogando la Direttiva 95/46/CE sinora vigente e andando a sostituire anche quanto attualmente previsto in Italia dal Codice della privacy.

In linea generale, tutto il Regolamento si poggia su due principi fondamentali, che ispirano l’intero costrutto normativo: il principio di privacy by design, che mira a proteggere ogni dato personale sin dal momento di determinare i mezzi o i processi utili al trattamento, oltre che ovviamente all’atto del trattamento stesso (attraverso, ad esempio, i “sotto-principi” di pseudonimizzazione[30] e minimizzazione dei dati trattati); e il principio di privacy by default, che mira a garantire che siano trattati, per impostazione predefinita, solo i dati personali necessari per ogni specifica finalità del trattamento e che va ad incidere, pertanto, sulla quantità dei dati personali raccolti, sulla portata del trattamento, nonché sul periodo di conservazione e sulla loro accessibilità.

Il Decreto Legislativo n. 231/2001

Il Decreto Legislativo n. 231 dal titolo “Disciplina della responsabilità amministrativa delle persone giuridiche, delle società e delle associazioni anche prive di personalità giuridica[31], ha introdotto nell’ordinamento italiano un regime di responsabilità amministrativa (riferibile sostanzialmente alla responsabilità penale) a carico degli enti (da intendersi come Società, associazioni, consorzi, ecc., di seguito denominati “enti” e, singolarmente, “Ente”) per alcuni reati commessi, nell’interesse o a vantaggio degli stessi:

  • da persone fisiche che rivestano funzioni di rappresentanza, di amministrazione o di direzione degli enti stessi o di una loro unità organizzativa dotata di autonomia finanziaria e funzionale, nonché da persone fisiche che esercitino, anche di fatto, la gestione e il controllo degli enti medesimi;
  • da persone fisiche sottoposte alla direzione o alla vigilanza di uno dei soggetti sopra indicati.

Tale responsabilità si aggiunge a quella della persona fisica che ha realizzato materialmente il fatto.

Il D.Lgs. 231/01 prevede, all’art. 6, una forma specifica di esonero dalla responsabilità amministrativa (c.d. esimente) qualora l’Ente sia in grado di dimostrare:

  1. di aver adottato ed efficacemente attuato, prima della commissione di eventuali fatti illeciti, modelli di organizzazione e di gestione idonei a prevenire la commissione di reati della specie di quelli verificatisi;
  2. che il compito di vigilare sul funzionamento e l’osservanza dei Modelli nonché di curare il loro aggiornamento sia stato affidato a un organismo dell’Ente dotato di autonomi poteri di iniziativa e controllo (di seguito, “l’Organismo di Vigilanza” o “OdV”);
  3. che le persone che hanno commesso il reato abbiano agito eludendo fraudolentemente i suddetti modelli di organizzazione e gestione;
  4. che non vi sia stata omessa o insufficiente vigilanza da parte dell’Organismo di cui alla precedente lett. b).

Le circostanze appena elencate devono concorrere congiuntamente affinché la responsabilità dell’Ente possa essere esclusa.

Tipologie di reato previste dal D.Lgs. 231/01

Il Legislatore ha individuato diverse tipologie di reati che possono essere commessi da persone fisiche nell’interesse o a vantaggio della società, fino ad includere fattispecie anche non necessariamente tipiche dell’attività di impresa.

La responsabilità amministrativa dell’Ente, inoltre, sussiste anche se non sia stato identificato l’autore del reato, o se il reato si sia estinto per una causa che sia diversa dall’amnistia.

L’Autorità competente a contestare l’illecito all’Ente è il Pubblico Ministero, mentre è il giudice penale che ha la responsabilità e l’autorità per irrogare la sanzione.

L’Ente può essere chiamato a rispondere per un numero chiuso di reati, ovvero soltanto per i cd. “Reati Presupposto[32] indicati negli artt. 24 e seguenti del Decreto, che appartengono alle categorie indicate di seguito:

  • reati commessi nei rapporti con la P.A. (artt. 24 e 25);
  • delitti informatici e trattamento illecito dei dati (art. 24-bis);
  • delitti di criminalità organizzata (art. 24-ter);
  • reati di falsità in monete, in carte di pubblico credito, in valori di bollo e in strumenti o segni di riconoscimento (art. 25-bis);
  • delitti contro l’industria e il commercio (art. 25-bis.1);
  • reati societari (art. 25-ter);
  • delitti con finalità di terrorismo o di eversione dell’ordine democratico (art. 25-quater);
  • pratiche di mutilazione degli organi genitali femminili (art.25-quater.1);
  • delitti contro la personalità individuale (art. 25-quinquies);
  • abusi di mercato (art. 25-sexies);
  • omicidio colposo e lesioni colpose gravi o gravissime, commessi con violazione delle norme sulla tutela della salute e sicurezza sul lavoro (art. 25-septies);
  • ricettazione, riciclaggio e impiego di denaro, beni o utilità di provenienza illecita (art. 25-octies);
  • delitti in materia di violazione del diritto d’autore (art. 25-novies);
  • induzione a non rendere dichiarazioni o a rendere dichiarazioni mendaci all’Autorità Giudiziaria (art. 25-novies);
  • reati transnazionali (art. 10, L. 146/2006).

Criteri di imputazione della responsabilità all’Ente

l’Ente è punibile solamente nel caso in cui si verifichino determinate condizioni, definite come criteri di imputazione del reato all’Ente.

La prima condizione è che il reato sia stato commesso da un soggetto legato all’Ente da un rapporto qualificato: soggetti apicali, soggetti subordinati, collaboratori.

La seconda condizione è che il reato sia stato commesso nell’interesse o a vantaggio dell’Ente:

  • “l’interesse” sussiste quando l’autore del reato ha agito con l’intento di favorire la società, indipendentemente dalla circostanza che poi tale obiettivo sia stato realmente conseguito;
  • il “vantaggio” sussiste quando la società ha tratto, o avrebbe potuto trarre, dal reato un risultato positivo, economico o di altra natura.

Delitti informatici e trattamento illecito dei dati

La legge 18 marzo 2008, n. 48, “Ratifica ed esecuzione della Convenzione del Consiglio d’Europa sulla criminalità informatica, fatta a Budapest il 23 novembre 2001, e norme di adeguamento dell’ordinamento interno” ha ampliato le fattispecie di reato che possono generare la responsabilità della società. L’art. 7 del provvedimento, infatti, ha introdotto nel D.Lgs. 231/01 l’art. 24-bis per i reati di:

  • accesso abusivo ad un sistema informatico o telematico (art. 615-ter c.p.);
  • detenzione e diffusione abusiva di codici di accesso a sistemi informatici o telematici (art. 615-quater c.p.);
  • diffusione di apparecchiature, dispositivi o programmi informatici diretti a danneggiare o interrompere un sistema informatico o telematico (art. 615-quinquies c.p.)
  • intercettazione, impedimento o interruzione illecita di comunicazioni informatiche o telematiche (art. 617-quater c.p.);
  • installazione di apparecchiature atte ad intercettare, impedire o interrompere comunicazioni informatiche o telematiche (art. 617-quinquies c.p.);
  • danneggiamento di informazioni, dati e programmi informatici (art. 635-bis c.p.);
  • danneggiamento di informazioni, dati e programmi informatici utilizzati dallo Stato o da altro ente pubblico o comunque di pubblica utilità (art. 635-ter c.p.);
  • danneggiamento di sistemi informatici o telematici (art. 635-quater c.p.);
  • danneggiamento di sistemi informatici o telematici di pubblica utilità (art. 635-quinquies c.p.).
  • falsità in un documento informatico pubblico o avente efficacia probatoria (art. 491-bis c.p.);
  • frode informatica del certificatore di firma elettronica (art. 640-quinquies c.p.).

Le sanzioni

Le sanzioni che il legislatore ha voluto collegare alla responsabilità penale e amministrativa delle persone giuridiche sono di varia natura a seconda della forma di commisurazione e dell’incidenza che le stesse hanno sullo svolgimento dell’attività di impresa. Esse possono essere suddivise come segue:

  • sanzioni pecuniarie, è incentrata sul concetto di “quota” e viene applicata in un numero non inferiore a cento né superiore a mille;
  • sanzioni interdittive, possono comportare conseguenze dirette sull’attività di impresa (nella sospensione o nella revoca delle autorizzazioni, licenze o concessioni funzionali alla commissione dell’illecito, nel divieto di contrattare con la Pubblica Amministrazione, esclusione da agevolazioni, finanziamenti);
  • confisca del profitto del reato, con la sentenza di condanna, il Giudice dispone sempre la confisca del prezzo o del profitto del reato, ovvero di somme di denaro, beni o altre utilità di valore equivalente, salvo la parte che possa essere restituita al danneggiato;
  • pubblicazione della sentenza, a seguito dell’applicazione di una sanzione interdittiva, il Giudice può disporre la pubblicazione della sentenza di condanna in uno o più giornali ovvero mediante affissione nel comune ove la società ha la sede principale, misura capace di recare un grave impatto sull’immagine dell’Ente.

Linee guida per la costruzione dei modelli di organizzazione, gestione e controllo

Il Decreto 231 prevede sanzioni per l’Ente che non si sia organizzato per evitare fenomeni criminosi in seno all’impresa, quando soggetti funzionalmente riferibili all’Ente abbiano commesso taluno dei reati indicati dallo stesso decreto.

Individuazione dei rischi e protocolli

L’art. 6, comma 2, del Decreto 231 indica le caratteristiche essenziali per la costruzione di un modello di organizzazione, gestione e controllo. In particolare, le lettere a) e b) della disposizione si riferiscono espressamente ad alcune attività correlate ad un processo di sana e prudente gestione dei rischi.

La procedura di identificazione e valutazione dei rischi deve essere applicata durante le seguenti fasi:

  • fase iniziale d’implementazione del Modello Organizzativo 231 in conformità con il D.Lgs. 231/2001, in quanto costituisce la base per potere poi intervenire con la definizione di specifici protocolli/procedure atte a prevenire la commissione del reato ritenuto a rischio di realizzazione e comunque prima di ogni riesame del sistema al fine di garantire un aggiornamento sistematico della valutazione dei rischi;
  • ogni qualvolta si verifichi una variazione di processo, di prodotto o del sito o contesto in cui l’Ente opera, quali ad esempio modifiche nel quadro legislativo di riferimento ovvero vi siano mutamenti nell’organizzazione o nell’oggetto sociale dell’Ente tali da richiedere una valutazione dei rischi connessi;
  • ogni qualvolta, a fronte di valutazioni o attività di controllo (ad esempio da parte dell’ODV) si presenti la necessità/volontà di verificare l’efficacia del Modello.

Rischio = probabilità che sia raggiunta la soglia di commissione di un reato/illecito presupposto della responsabilità amministrativa ai sensi del D. lgs. 231/01.

L’organismo di vigilanza è la figura prevista dal Legislatore con il preciso compito di valutare l’adeguatezza ed efficacia del Modello, la sua applicazione da parte dell’Ente, nonché curarne l’aggiornamento.

I contenuti minimi di un Codice Etico

L’adozione di principi etici rilevanti ai fini della prevenzione dei reati ex D. Lgs. 231/2001 costituisce un elemento essenziale del sistema di controllo preventivo.

In termini generali, i codici etici (o codice di comportamento), sono documenti ufficiali dell’Ente che contengono l’insieme dei principi, dei diritti, dei doveri e delle responsabilità dell’Ente nei confronti dei “portatori d’interesse” (dipendenti, fornitori, clienti, Pubblica Amministrazione, azionisti, mercato finanziario, ecc.).

Mentre i protocolli di condotta implementati all’interno del modello organizzativo di gestione e controllo perseguono la finalità di prevenire la commissione di reati presupposto nell’interesse e a vantaggio di un ente da parte dei rispettivi destinatari, i codici etici mirano a raccomandare, promuovere o vietare determinati comportamenti, al di là ed indipendentemente da quanto previsto a livello normativo e quindi dalla rilevanza penale delle condotte.

Iter procedurale per l’elaborazione di un modello organizzativo di gestione e controllo ex d.Lgs 231/01

Non esiste una soluzione standard di elaborazione di un modello organizzativo di gestione e controllo ex D. Lgs. n. 231/01.

Il “decalogo 231”

Un riferimento per capire quali debbano essere le caratteristiche di un modello organizzativo 231 è l’ordinanza cautelare del Giudice per le indagini preliminari del Tribunale di Milano (dott.ssa Secchi) depositata il 9 novembre 2004, conosciuta anche come “decalogo 231”, in cui vengono delineate le dieci caratteristiche che un modello organizzativo deve avere per essere effettivamente considerato valido ai fini 231.

Modello Organizzativo per i reati informatici

L’art. 7 della legge 18 marzo 2008 n. 48, mediante l’inserimento nell’ambito del D. Lgs. 231/01 dell’art 24 bis sui delitti informatici e trattamento illecito dei dati, ha introdotto nuove fattispecie di reato che possono generare una responsabilità in capo alle aziende.

L’adozione di un “Modello di Organizzazione, Gestione e Controllo” ai sensi del D.Lgs 231/01 in grado di prevenire adeguatamente le differenti ipotesi di illecito introdotte con tale normativa, trova il proprio presupposto fondamentale nella volontà di gestire la propria rete informatica attraverso l’adozione di regole e procedure alla cui osservanza tutti i propri dipendenti sono chiamati.

A tale proposito, le aziende potrebbero adottare specifiche procedure e misure operative finalizzate a garantire una gestione ed un utilizzo lecito e sicuro del proprio sistema informatico.

A tale scopo le aziende dovrebbero appositamente designare un soggetto qualificato, al quale attribuire la funzione di Responsabile IT, con lo specifico incarico di gestire i sistemi informatici della rete, anche attraverso un costante monitoraggio avente ad oggetto un corretto e sicuro utilizzo dei medesimi.

Per ciò che specificamente attiene i controlli aziendali, l’Ente dovrebbe istituire la funzione Security Operations Center (SOC).

Cap.8 Le Conseguenze di un Attacco Cyber

I danni provocati da un attacco cyber all’interno di un computer privato o una rete aziendale possono risultare di natura ed entità completamente diverse: si va da un lieve aumento del traffico in uscita (nel caso in cui il computer sia stato infettato da un trojan preposto all’invio di messaggi di spam) al crollo completo del network aziendale, o alla perdita di dati sensibili di vitale importanza. In alcuni casi i risultati di un’infezione da malware possono essere impercettibili all’utente, altre volte possono avere conseguenze ben evidenti e di particolare gravità.

Le conseguenze potenziali di un evento cibernetico (accidentale o deliberato) posso essere ad esempio:

  • interruzione dell’attività, computer e reti di sistemi inutilizzabili, guasti hardware;
  • danno reputazionale/di immagine;
  • diffusione di informazioni sensibili (clienti, pazienti, impiegati, fornitori);
  • violazione informazioni finanziarie;
  • violazione conti bancari;
  • violazione proprietà intellettuale;
  • perdita quote di mercato;
  • appropriazione identità;
  • azioni legali da terzi;
  • frodi e social engineering.

Difronte alla moltitudine di danni causati da un attacco cyber è possibile tutelarsi con un’assicurazione

Cap.9 La Possibilità di Copertura Assicurativa del Rischio

Nel Report Clusit 2016, con un approfondimento dedicato allo strumento assicurativo a supporto della gestione del cosiddetto Cyber Risk, si sono date le indicazioni basilari su terminologia, aspetti chiave ed utilità delle polizze cyber.

È emerso che si può affidare la gestione del Cyber Risk e in particolare l’aspetto del trasferimento del rischio, alle Assicurazioni attraverso un tavolo collaborativo che ha nel CIO[33] e nel CFO[34], gli attori principali.

I cyber-danni

Avvalendoci della terminologia e delle definizioni tratte dalle polizze tradizionali, per calarci nel mondo dei danni cyber, si possono distinguere tre grandi famiglie di danni:

  1. danni materiali diretti, riguardano i danni (distruzione parziale o totale, furto) subiti da beni materiali (un server, la fibra ottica, i PC, un cellulare o altro device elettronico) e direttamente causati dall’evento che sarà normalmente di natura “analogica” o tradizionale (incendio, terremoto, fulmine, furto, atto maldestro o doloso, ecc.); per la loro natura essi rientrano già nella polizza Incendio, nella polizza Trasporti, nella polizza All Risks (che proprio “tutti i rischi” non copre …), e naturalmente nella Polizza storicamente definita “Elettronica”. I danni materiali e diretti possono anche non essere previsti nella Polizza Cyber, se si è provveduto alla corretta strutturazione delle coperture assicurative tradizionali;
  2. danni materiali indiretti (o consequenziali), si tratta ugualmente di danni a beni materiali, ma conseguenza di danni diretti: per esempio, un fenomeno elettrico che abbia danneggiato una scheda, il cui malfunzionamento danneggi a sua volta la macchina di produzione da essa controllata. I danni materiali indiretti possono rientrare sia nelle polizze tradizionali che nella Cyber, ma vanno esplicitamente inclusi;
  3. danni immateriali diretti e indiretti, sono tutti quelli che non riguardano la materialità delle cose assicurate e che sono conseguenzadi un evento garantito in polizza, anche di tipo Cyber. L’evento dannoso distrugge, compromette l’integrità di un software e/o l’insieme logico di informazioni – ovvero rende indisponibili i dati aziendali.

Il mercato degli assicuratori e metodologie di indennizzo

Il mercato assicurativo delle polizze cyber risks oggi è in rapida evoluzione e offre la possibilità di creare tutele ad hoc per il cliente. Tale personalizzazione offre un ottimo livello di aderenza al rischio cyber reale cui è esposta l’azienda, ma presuppone ovviamente un precedente processo di analisi e valutazione, così come descritto precedentemente. Tuttavia va tenuto presente che, ancorché in rapida evoluzione, il mercato assicurativo italiano si trova ancora in una fase embrionale. Ciò perché, come sempre in questo tipo di mercato, la risposta a un rischio si attua nel momento in cui tale rischio diviene conosciuto e valutabile. La situazione di novità riguarda però il solo mercato italiano in quanto, nei paesi dell’America settentrionale e anglosassoni, le problematiche afferenti i rischi cibernetici vengono affrontate da circa una decina d’anni. Delle circa 50 compagnie di assicurazioni operanti in Europa che specificamente si dichiarano pronte a sottoscrivere rischi cibernetici, soltanto un terzo opera direttamente in Italia, la restante parte opera fondamentalmente dal Regno Unito (a copertura di rischi italiani).

Guida all’implementazione di una copertura assicurativa cyber risk

Ai fini dell’implementazione di una copertura assicurativa cyber risk, sarebbe opportuno che l’azienda seguisse i seguenti 4 passaggi:

  1. coinvolgimento di un consulente assicurativo: il settore dei rischi cyber non è ancora maturo né ha standard di riferimento in ambito assicurativo, il coinvolgimento di uno o più consulenti specializzati nel trasferimento dei rischi al mercato assicurativo diventa fondamentale per il trasferimento delle specifiche necessarie agli assicuratori. Interpellare direttamente le compagnie assicurative potrebbe portare le stesse a fornire prodotti non rispondenti alle esigenze dell’assicurando;
  2. risk assessment: ai fini di isolare correttamente il massimo danno probabile e di stimare correttamente l’esposizione al rischio, sarebbe opportuno, prima di stipulare la polizza, effettuare un’analisi e quantificazione del rischio stesso;
  3. compilazione del questionario assicurativo: il questionario in ambito assicurativo ha lo scopo di raccogliere le informazioni base necessarie per una prima valutazione del rischio da parte degli assicuratori. La compilazione del questionario ha come risultato il fatto che possano essere apprezzate le varie ipotesi di limite di indennizzo che stanno alla base del contratto assicurativo e, parallelamente, fa prendere coscienza all’assicurando di quelli che sono i suoi punti di forza e di debolezza;
  4. implementazione della copertura assicurativa: una volta esaurito il processo di valutazione tramite questionario e/o tramite risk assessment strutturato, sarà possibile richiedere una quotazione formale al mercato assicurativo. Anche in questo caso l’apporto negoziale di un consulente specializzato è perlomeno consigliabile, in quanto la conoscenza del settore e la capacità negoziale di chi opera continuativamente nel settore permettono risultati più performanti rispetto a quelli ottenibili dal singolo cliente direttamente con gli assicuratori, oppure da un consulente non specializzato con gli assicuratori.

Cap.10 Protezione Cibernetica e Sicurezza Informativa

I trend di difesa: il contrasto a questo tipo di minacce dovrebbe basarsi su tre elementi chiave:

  • il contrasto a più livelli della minaccia attraverso la comprensione delle sue modalità operative;
  • la prevenzione attiva, grazie all’acquisizione di informazioni sui trend di attacco più probabili;
  • l’adozione di una mentalità – e conseguentemente di un’organizzazione – che consideri sempre presente l’eventualità della violazione.

Di conseguenza, data l’enormità del suo ambito di applicazione, la Cyber Security in primo luogo non può che basarsi su logiche di prevenzione, riduzione e trasferimento del rischio e su processi di Risk Governance, applicati però ad un dominio caotico, dai confini e dalle dinamiche sempre cangianti, il quale pertanto va presidiato costantemente, 24×7, da per­sonale qualificato dotato di metodologie di Risk Management e strumenti adeguati (p.es. tool di analisi comportamentale, big data analytics, intelligenza artificiale, ecc), capaci di operare in tempo reale.

In secondo luogo, per definire puntualmente la componente esogena del rischio, ovvero la probabilità che una minaccia esterna si realizzi, è necessario impiegare metodologie e stru­menti di Cyber Intelligence capaci di osservare, tramite un monitoraggio continuo, l’esterno e l’interno con altrettanta attenzione, e di correlare i due domini. Anche in questo caso si tratta di sviluppare competenze sofisticate e di implementare processi nuovi, diversi rispet­to alle prassi consolidate, considerando che oggi, nel migliore dei casi, le organizzazioni sono strutturate solo per osservare ciò che avviene nell’ambito di propri confini prestabiliti (i quali peraltro stanno ormai diventando sempre più porosi, a causa delle nuove tecnologie).

In terzo luogo è necessario definire e costantemente aggiornare il proprio modello di minac­cia, ovvero individuare quale tra le diverse tipologie di attaccanti vorrà aggredire quale as­set, perché, sfruttando quale vulnerabilità, con quali strumenti, atteggiamento, risorse ecc. Anche questa attività di Threat Modeling[35] non può che essere continuativa ed integrarsi opportunamente con i processi di Risk Management e Cyber Intelligence, per fornire al primo delle metriche precise ed aggiornate su cui ragionare, ed alla seconda indicazione in merito a quale ago cercare nel pagliaio del cyberspazio.


[1] Quadro Strategico Nazionale Per La Sicurezza Dello Spazio Cibernetico, Presidenza del Consiglio dei Ministri. Dicembre 2013.

[2] Il problema della Cyber Security e il Framework Nazionale. CIS-Sapienza http://www.cis.uniroma1.it

[3] International Organization for Standardization.

[4]     Valutazione della minaccia di criminalità organizzata in Internet. https://www.europol.europa.eu/activities-services/main-reports/internet-organised-crime-threat-assessment-iocta-2016 

[5] Una botnet è una rete controllata da un botmaster e composta da dispositivi infettati da malware specializzato, detti bot o zombie.[

[6] Ci si riferisce principalmente agli artt. 2, 3, 4, 5, 6, 7, 8 della convenzione ed alle corrispondenti norme incriminatici del codice penale nazionale.

[7] Il concetto di software on-premises, in contrapposizione al software come servizio (o Saas), si traduce in pratica nell’installazione ed esecuzione del software direttamente su macchina locale, sia essa aziendale che privata, intesa sia come singola postazione di lavoro che come server raggiungibile esclusivamente dall’interno della rete aziendale

[8] Più specificatamente, secondo la Corte di Cassazione (Sez. VI, n. 3067/1999; Sez. V, n. 31135/2007):

  • … deve ritenersi “sistema informatico”, … , un complesso di apparecchiature destinate a compiere una qualsiasi funzione utile all’uomo, attraverso l’utilizzazione (anche parziale) di tecnologie informatiche, che sono caratterizzate – per mezzo di un’attività di “codificazione” e “decodificazione”–  dalla “registrazione” o “memorizzazione”, per mezzo di impulsi elettronici, su supporti adeguati, di “dati”, cioè di rappresentazioni elementari di un fatto, effettuata attraverso simboli (bit), in combinazione diverse, e dalla elaborazione automatica di tali dati, in modo da generare “informazioni”, costituite da un insieme più o meno vasto di dati organizzati secondo una logica che consenta loro di esprimere un particolare significato per l’utente …”;
  • … è “sistema telematico” l’insieme di più sistemi informatici collegati tra loro per lo scambio di informazioni, purché siano connessi in modo permanente, e purché lo scambio di informazioni sia il mezzo necessario per conseguire i fini operativi del sistema. …”.

[9] Cass, sez. VI, 14 ottobre 1999, in Foro it., 2000, II, 133.

[10] Il lettore attento avrà notato che non è stato utilizzato il termine “estero”.

[11] Secondo il NIST (http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf) con il termine cloud è da intendersi “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”, che, tradotto in italiano, potrebbe essere inteso come “un modello di elaborazione, che abilita un accesso in rete, su richiesta, ubiquo e conveniente ad un insieme di risorse di calcolo (CPU, memorie di massa, reti, sistemi operativi, servizi e/o applicazioni) condivise e configurabili, le quali possono essere acquisite e rilasciate rapidamente ed in modo dinamico con uno sforzo di gestione minimo, o comunque con un’interazione minima con il fornitore del servizio”.

[12] È responsabile della gestione, manutenzione ed esercizio dei sistemi informativi dell’organizzazione all’interno della quale opera. Identifica esigenze organizzative e di gestione delle informazioni, pianifica e controlla progetti di miglioramento dei sistemi ICT, garantisce una buona operatività del sistema informativo nel rispetto dei requisiti di legge e di qualità validi nel contesto in oggetto.

[13] Con il provvedimento n. 1712680 del Garante per la Privacy in materia di videosorveglianza datato 8 aprile 2010, le immagini registrate possono essere conservate per periodo limitato e fino a un massimo di 24 ore, fatte salve speciali esigenze di ulteriore conservazione in relazione a indagini di Polizia e giudiziarie. Per attività particolarmente rischiose (ad esempio, banche, videosorveglianza esercitata dai Comuni per esigenze di sicurezza urbana ecc.) è ammesso un tempo più ampio, che non può superare comunque la settimana.

[14] In informatica e telecomunicazioni una sottorete, o subnet, è una parte della suddivisione di una singola rete IP (Internet Protocol). Tale suddivisione è realmente visibile solo dalla parte logica della rete, ciò vuol dire che la differenza tra una rete e una sottorete sta nel tipo di configurazione di rete che si dà al proprio computer. Il processo di subnetting è la divisione di una singola rete in gruppi di computer che hanno in comune nell’indirizzo IP un determinato prefisso di instradamento (routing).

[15] Un’associazione statica può essere utile al supermercato dei limiti di data retention.

[16] Un firewall è un componente di difesa perimetrale di una rete informatica, originariamente passivo, che può anche svolgere funzioni di collegamento tra due o più tronconi di rete, garantendo dunque una protezione in termini di sicurezza informatica della rete stessa.

[17] Un Intrusion Detection System è un dispositivo software e/o hardware utilizzato per identificare accessi non autorizzati ai computer o alle reti locali.

[18] Una DMZ (demilitarized zone) è un segmento isolato di LAN (una “subnet”) raggiungibile sia da reti interne sia esterne, ma caratterizzata dal fatto che gli host (o nodi) attestati sulla DMZ hanno possibilità limitate di connessione verso host specifici della rete interna.

[19] L’autenticazione a due fattori richiede, oltre alla conoscenza della username e password, anche un terzo codice, che potrebbe essere generato tramite un sistema OTP (one time password) tramite SMS o apposita APP.

[20] Il paradigma è basato su qualcosa che sappiamo (es. PIN), qualcosa che abbiamo (es. smart card), qualcosa che siamo (es. elemento biometrico).

[21] Un computer security incident response team (ISO 27035 pt.3.2) è un’unità organizzativa incaricata di raccogliere le segnalazioni di incidenti informatici e potenziali vulnerabilità nei software che provengono dalla comunità degli utenti.

[22] Con la locuzione inglese “data retention” ci si riferisce al periodo di conservazione di dati o documenti elettronici (generalmente dei file di log). A meno che oggetto di indagine non sia un fornitore di connettività (es. un Internet Service Provider), sia i soggetti fisici che giuridici hanno alcun vincolo di memorizzazione.

[23] Elemento di prova: l’informazione che si ricava dal mezzo di prova come dato grezzo, non ancora valutato dal giudice: v. art. 65 comma 1 c.p.p.

[24] Pubblico (statico e dinamico) e privato. NAT Network Address Translation, tecnica che consiste nel modificare gli indirizzi IP dei pacchetti in transito su un sistema che agisce da router.

[25] Livello di implementazione

[26] Così il CREST, http://www.crest-approved.org/, un organizzazione no-profit di base inglese per il supporto al  mercato della sicurezza informatica definisce i penetration test.

[27] https://www.offensive-security.com 

[28] La Convenzione sul Cyber Crime, firmata a Budapest il 23 novembre 2001 ed entrata in vigore l’1 luglio 2004, è stata ratificata dall’Italia con la legge 18 marzo 2008 n. 48 (GU n.80 del 4-4-2008 – Suppl. Ordinario n. 79 ) entrata in vigore il 5-4-2008.

[29]Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati)”, 2016, in http://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX%3A32016R0679. 

[30] La pseudonimizzazione, ovvero il principio per cui le informazioni di profilazione debbano essere conservate in una forma che impedisce l’identificazione dell’utente. Le informazioni personali contengono elementi identificativi come nome, data di nascita, sesso e indirizzo. Quando le informazioni personali vengono pseudonimizzate, gli elementi identificativi sono sostituiti da uno pseudonimo, che si ottiene, per esempio, crittografando gli elementi identificativi contenuti nei dati personali. Il dato pseudonimo è diverso dal dato anonimo: i dati sono anonimizzati quando non contengono più alcun mezzo identificativo, mentre sono pseudonimizzati se i mezzi identificativi sono criptati.

[31] Il decreto 231 indica come destinatari “gli enti forniti di personalità giuridica, le società fornite di personalità giuridica e le società e le associazioni anche prive di personalità giuridica” (art. 1, comma 2). La disciplina, invece, non si applica “allo Stato, agli enti pubblici-territoriali, agli altri enti pubblici non economici nonché agli enti che svolgono funzioni di rilievo costituzionale” (art. 1, comma 3).

[32] Il reato presupposto è il delitto non colposo da cui provengono danaro, beni o altre utilità.

[33] Direttore informatico (Chief Information Officer, in sigla CIO) è il manager responsabile della funzione aziendale tecnologie dell’informazione e della comunicazione.

[34] Direttore finanziario (in sigla CFO – Chief Financial Officer) è il manager responsabile della gestione generale delle attività finanziarie di un’azienda. È una delle cariche più importanti all’interno dell’azienda.

[35] https://en.wikipedia.org/wiki/Threat_model

Exploiting Authentication and Access Control Mechanisms with Burp Suite

Exploiting Authentication and Access Control Mechanisms with Burp Suite.

In questo articolo ho raccolto in maniera più o meno ordinata alcuni appunti presi durante il relativo corso seguito su Hakin9, alla cui piattaforma rimando per il materiale necessario.

Note sulla Burp Suite Community Edition.

È stata utilizzata la versione Community Edition e attese le limitazioni imposte dalla da tale versione, occorre installare alcune  estensioni. Nel tab Extender/BAppStore cercare e installare “Turbo Intruder” e “JWT Editor”.

In Proxy/HTTPhistory viene mostrata l’interazione con sito: request/response
In Target/Scope aggiungere in “Include in scope” l’url del sito target in modo tale da visualizzare solo quello e non eventualmente altro contenuto web visitato. Quindi in Proxy/HTTPhistory cliccare sulla riga dei filtri e spuntare “Show only in-scope items”.

User Enumeration.

Con Burp Suite professional: clic tasto destro del mouse sulla riga nell’HTTPhistory (host/method/url …) quindi “Send to Intruder” e poi tab Intruder.

Con Burp Suite CE: tasto dx, “Extensions>Turbo Intruder>Send turbo intruder”.

Dopo aver tentato il login con credenziali errate, nella finestra “HTTPhistory” seleziono la riga che ha come metodo “POST” (ed ha anche i parametri) e invio a “Intruder”:

Nella finestra “Raw” di Intruder sostituisco il valore assegnato a “username” con l’operatore %s, al quale verranno passati gli username elencati nella lista “users” mediante il ciclo for:

Dall’elenco prodotto dal risultato è possibile notare che l’utente “cathy” ha i campi “Words” e “Length” differenti dal resto degli username, questo significa che la pagina di login ha risposto in maniera diversa per questo utente, probabilmente perché è un username valido:

Nalla finestra “Raw” assegno a username il nome “cathy”, mentre a password l’operatore %s e modifico il ciclo for in modo tale che a “%s” vengano passati gli elementi della lista “passwords”:

Dall’elenco del risultato è possibile notare che la password “1337ing” ha valore “Word” e “Lengh” differenti, a significare che è la password corretta per l’utente “cathy”:

Infatti, inserendo le credenziali “cathy” e “1337ing”, ottengo l’accesso.

Brute Force Evasion.

Nel tab Proxy ci sono le finestre “Request” e “ Response”, poiché in queste non possiamo scrivere  per modificarne il contenuto (Request) e verificarne l’esito (Response), viene usato il “Repeater

Tasto dx mouse sulla riga in HTTPhistory e “Send to Repeater” e verrà attivato il relativo tab.

In alto a sinistra compare un numero, che si raccomanda di cambiare per avere traccia delle modifiche con un doppio clic, ad esempio in “Brute-force evasion” se stiamo tentando un attacco brute force.

Uno dei possibili utilizzi è quello di superare il ban temporaneo quando si tenta di fare login per un certo numero di volte con credenziali errate.

Nella finestra “Request” di Repeater si può modificare il codice inserendo ad esempio la riga “X-Forwarded-For: 192.168.12.92” nella quale si fornisce un IP fittizio da modificare raggiunto il numero dei tentativi concessi:

Sulla finestra “Request” tasto dx del muose > “Extensions>Turbo Intruder>Send turbo intruder”, andiamo a modificare l’html sostituendo le ultime cifre dell’IP con l’operatore di formattazione %s e assegnando a username=%s, mentre con lo script di Python li gestiremo mediante un ciclo for:

e così anche per le passwords:

Note: oltre a “X-Forwarded-For:”, “X-Forwarded-By:” “X-Real-IP:”, “X-Forwarded-Host:


Dopo aver tentato il login con credenziali errate, nella finestra “HTTPhistory” seleziono la riga che ha come metodo “POST” (ed ha anche i parametri) e invio a “Intruder”:

Nella finestra “Raw” di Intruder sostituisco il valore assegnato a “username” con l’operatore %s, al quale verranno passati gli username elencati nella lista “users” mediante il ciclo for:

Purtroppo dopo aver lanciato lo script non ottengo nessuna informazione utile a causa dell’IP-based block protection:

Per aggirare l’ IP-based block protection dalla finestra “HTTPhistory” invio la precedente riga (quella con URL del login e con metodo “POST”) al “Repeater” che mi permetterà di modificare il codice html nella  finestra “Raw” di “Request”. Posso così bypassare la protezione utilizzando l’assegnazione a “X-Real-IP:” di un indirizzo IP fittizio. Poi premo “Send” per inviare la richiesta e poi invio a “Intruder”:

Ora modifico le ultime cifre dell’IP appena inserito con l’operatore %s e il valore assegnato a username sempre con l’operatore %s, in questo modo con il ciclo for posso inviare oltre i valori della lista “users” anche valori numerici (in questo caso in un intervallo da 0 a 100) come ultime cifre dell’indirizzo IP; questo mi permetterà di avere ad ogni richiesta di login un IP differente e quindi bypassare l’ IP-based block protection:

Infatti, ora riesco a bypassare la protezione sull’IP e posso notare che l’utente “anonymous” ha valori “Words” e “Length” differenti dagli altri username:

Modifico script, nella finestra “Raw” assegno a username il nome “anonymous”, mentre a password l’operatore %s e modifico il ciclo for in modo tale che a “%s” vengano passati gli elementi della lista “passwords”:

L’esecuzione dello script mostra che la password “unknown” ha valori “Words” e “Length” differenti dagli altri a significare che abbiamo trovato la password per l’utente “anonymous”:

Utilizzando le credenziali così ottenute, riesco ad eseguire l’accesso correttamente alla pagina.

Wordlist:

MFA Brute Force.

MFA: autenticazione multi fattore. Esempio in cui il login richiede oltre a utente e password anche l’inserimento di un codice:

Dall’analisi del codice della pagina, appuriamo che il l’MFA richiede un codice numerico di 4 cifre e quindi modifico lo script come segue:

L’esecuzione del brute force trova il codice MFA corretto:

Ottenendo così l’accesso.

MFA No Restrictions.

Provo ad accedere alla pagine “/admin”:

e credenziali errate restituiscono “non autorizzato”:

Inserisco le credenziali di login “admin/admin” e mi viene richiesto l’MFA:

Attivo “Repeater”:

Torno all’HTTPhistory:

noto che nel “Request” non ci sono cookie, mentre nel “Response” trovo un “Set-Cookie: session=”, questo sta a significare che il server web comunque sta mantenendo traccia della sessione.

Copio la sessione col cookie:

e incollo nel “Request” del “Repeater” (NB: va incollato nella Raw “Request” selezionando in HTTPhistory un URL prima che si acceda a “/mfa”, cioè in quello di “/login” subito prima):

premo “Send” e nel “Response” avrò “200 OK”:

così ho superato il MFA perchè sono rimasto nella stessa sessione. 
Tasto dx su “Request” e invio al browser “In original session”:

Copio l’url:

e incollo al posto dell’url di richiesta MFA:

e ottengo l’accesso bypassando l’MFA.

Endpoint Enumeration

Accedendo con le corrette credenziali vengo indirizzato alla “dashboard”. Invio la pagina all’Intruder:

Sostituisco l’endpoint “dashboard” con l’operatore di conversione “%s” in modo da iterare i valori di una lista di endpoints:

Ho filtrato i risultati affinché vengano esclusi quelli con status http 404. L’esecuzione dello script mi permette di trovare come payload l’endpoint “.htaccess” e un commento che dice “# Remember to add .htaccess on the /sUp3r_s3cr3t_4dm1n”.

Nell’URL della pagina, sostituisco l’endpoint “dashboard” con “sUp3r_s3cr3t_4dm1n” e trovo il flag.

Origin-Based AC

Invio la pagina con method GET al repeater:

E modifico il parametro di GET al fine di trovare una pagina valida:

Si potrebbe usare un dizionario già pronto, tipo:

Invio il Request al Turbo Intruder e modifico il RAW in modo che attraverso lo script invio i diversi “endpoints”:

Posso migliorare l’output dello script, filtrando le risposte attraverso l’esclusione delle “404 NOT FOUND”, allo scopo usiamo i “DECORATOR”, supportati da Turbo Intruder:

Nella fattispecie, scelgo il “FiltersStatus”:

E lo modifichiamo alla scopo che escluda le pagine “404”, ecco lo script completo:

Quindi “Attack” ed ecco la risposta:

Noto che col suffisso “admin” ho tentato l’accesso ad una pagina alla quale non sono autorizzato, ciò significa che la pagina esiste. Raffino l’iterazione aggiungendo il suffisso “admin”:

Rilancio lo script, ma purtroppo ottengo nuovamente una pagina alla quale non sono autorizzato accedere:

Provo un’altra strada, accedo con le classiche credenziali: hakin9/burpsuite:

Riesco ad accedere ma non ottengo flag:

Allora mi sposto sul tab “Proxy” e noto che vi è una sessione cookie relativa all’accesso appena ottenuto:

Quindi invio al “Repeater”, dove al posto di “dashboard” sostituisco “admin/secret”, clicco su “send” ed ottengo questa volta “Invalid referer”:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer

Poiché “Referer” tiene traccia anche della pagina da dove “provengo”, aggiungo un “Referer” alla pagina “admin” che so che esiste, infatti invio con “Send” e ottengo “200 OK”:

Quindi invio al browser:

Copio ed incollo il link al posto dell’url della pagina e ottengo l’accesso:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

RBACRole Based Access Control

Invio la pagina di login iniziale all’Intruder:

Quindi aggiungo l’operatore di conversione %s per iterare fra le varie pagine (endpoint enumeration):

In questo caso però ottengo un risultato diverso dai precedenti, intanto un codice di stato 302. Si tratta di un codice status HTTP della pagina web che indica lo spostamento temporaneo della risorsa. Come tutti gli status code 3XX si riferisce a un cambiamento di indirizzo della pagina. Ma mentre il redirect 301 si riferisce a un reindirizzamento permanente – la pagina non esiste più e sposto su un nuovo URL – con la condizione HTTP 302 c’è un cambio momentaneo. Che presuppone un ritorno alla condizione precedente. Possiamo dire che un reindirizzamento 302 è una modifica temporanea che porta gli utenti verso una nuova risorsa per un periodo limitato, fino a quando il reindirizzamento non viene rimosso del tutto.Infatti, come indicato dai “Location”, il reindirizzamento è verso “/m3/v2/”, ovvero la pagina iniziale di login.

Provo a sfruttare questa caratteristica accedendo con le credenziali “hakin9/burpsuite” e una volta stabilita una sessione:

sostituisco “dashboard” con “admin” e ottengo:

… questo mi permette di sfruttare il “roleID”, quindi nvio la pagina al “Repeater”:

quindi “Send”:

Aggiungo dopo “admin?roleId= seguito dall’ID che si solito è un numero, per esempio “0” restituisce un “Invalid role ID”:

Invio il tutto all’Intruder:

Quindi programmo un attacco a brurteforce al roleId e filtro escludendo le risposte http con status 401:

ed ecco la risposta:

Ora possio chiedere la relativa sessione:

e copiarla nella pagina di admin, oppure inserire direttamente il roleId individuato:

e trovare il flag.

Insecure Deserialization

La deserializzazione non sicura si verifica quando i dati controllabili dall’utente vengono “deserializzati” da un sito web. Ciò consente potenzialmente a un utente malintenzionato di manipolare oggetti serializzati per passare dati dannosi nel codice dell’applicazione. È persino possibile sostituire un oggetto serializzato con un oggetto di una classe completamente diversa.

Accedo con le classiche credenziali e noto che oltre al cookie di sessione ho quello relativo all’user:

Se ricarico la pagina, trovo quel cookie user anche nel “Request”:

Cerchiamo di capire cosa sono queste stringhe. Invio la pagina all’Intruder, quindi sostituisco l’endpoint “dashboard” con l’operatore di conversione %s al quale passare i valori della lista “endpoints” e filtro i risultati escludendo HTTP Status 404:

Ed ecco il risultato:

mando la stessa pagina al “Repeater”:

Se invio “Send” con endpoint “dashboard”, ovviamente la pagina funziona:

e funziona anche se sostituisco con “admin”, infatti la pagina mi restituisce un http status “UNAUTHORIZED”. Notiamo due cose, però: l’uso del linguaggio di programmazione Python e che il cookie user non è cambiato:

Perciò provo a intervenire su quel cookie utente. Noto che modificando ottengo un 500 INTERNAL SERVER ERROR a causa di una stringa in codifica base64 non valida:

È possibile manipolare le stringhe per operazioni di codifica e decodifica codificate direttamente in Burp Suite attraverso le funzioni chre troviamo nel tab “Decoder”:

Oppure usare la libreria “pickle” di Python per serializzare/deserializzare dato che che l’applicazione usa appunto Python:

decodifico il cookie user:

>>> pickle.loads(base64.b64decode(‘.......’))

infatti restituisce esattemante l’username:

{‘currente_user’: ‘hakin9’}

il risultato lo assegno al coockie:

>>> cookie = pickle.loads(base64.base64decode(‘.......’)) 

Quello che voglio ottenere è la codifica di un altro utente, ovvero “admin”  che possa garantire l’accesso, quindi ne assegno il nome a current_user:

>>> current_user = {‘current_user’: ‘admin’}

>>> base64.b64encode(pickle.dumps(current_user))

ed ecco “admin” codificato in base64:

b ‘....’ 

Quindi copio il valore tra gli apici e lo incollo sostituendo il precedente cookie user  e con “send” posso verificare che la risposta mi da un HTTP 200 OK status:

Invio a browser:

Incollo il link nella pagina di accesso:

E ottengo l’accesso come admin e trovo il flag.

Forging JWT

I token Web JSON (JSON Web Tokens o JWT) sono uno standard aperto (RFC 7519) per la creazione di token di accesso sicuri e compatti. Vengono ampiamente utilizzati per l’autenticazione e l’autorizzazione in applicazioni web e API.

Un token JWT è una stringa codificata che consiste di tre sezioni separate da punti: l’intestazione (header), il payload (contenuto) e la firma (signature). Ognuna di queste sezioni è codificata in Base64 e può essere facilmente decodificata per ottenere i dati contenuti all’interno del token.

L’intestazione contiene informazioni sull’algoritmo di firma utilizzato e il tipo di token. Il payload contiene le informazioni aggiuntive specifiche dell’applicazione, come l’identità dell’utente, i diritti di accesso o altre informazioni pertinenti. La firma viene utilizzata per verificare l’integrità del token e garantire che non sia stato manomesso.

Un aspetto importante dei token JWT è che sono stateless, ovvero tutte le informazioni necessarie per verificare l’autenticità e l’autorizzazione sono contenute nel token stesso. Questo consente ai server di evitare di dover memorizzare lo stato del token o di eseguire query al database per ogni richiesta.

I token JWT offrono diversi vantaggi, tra cui:

  • sicurezza: i token JWT possono essere firmati digitalmente utilizzando algoritmi crittografici, garantendo l’integrità e l’autenticità dei dati;
  • portabilità: i token JWT sono autocontenuti e possono essere trasportati facilmente come stringhe nei campi delle richieste HTTP o come dati in formato JSON;
  • scalabilità: i server possono verificare l’autenticità dei token in modo efficiente senza dover accedere a un database o a una memoria condivisa;
  • estensibilità: è possibile aggiungere campi personalizzati nel payload dei token per includere informazioni aggiuntive specifiche dell’applicazione;
  • interoperabilità: JWT è uno standard ampiamente adottato e supportato da numerosi linguaggi di programmazione e framework.

Tuttavia, è importante notare che i token JWT devono essere utilizzati correttamente e con precauzione. Alcuni aspetti da considerare includono la corretta gestione delle chiavi di firma, la scadenza dei token e l’uso di connessioni sicure per trasmettere i token.

In conclusione, i token JWT offrono un meccanismo flessibile e sicuro per l’autenticazione e l’autorizzazione nelle applicazioni web e API. Consentono l’implementazione di flussi di autenticazione come OAuth 2.0 e forniscono un modo efficiente per trasportare e verificare le informazioni di autenticazione e autorizzazione tra le parti coinvolte.

https://jwt.io/ consente di decodificare, verificare e generare JWT.

Prima di accedere con le consuete credenziali, verifichiamo se sono abilitate le estensioni JWT:

questo consentirà di vedere evidenziate le richieste che utilizzano tali token:

Alcuni siti web usano il JWT per l’autorizzazione:

Se nell’url della pagina sostituisco dashboard con admin ottengo come risultato “Unauthorized”:

Invio allora quest’ultima risposta al repeater e avendo l’estensione JWT abilitata, trovo il tab “JSON Web Token” disponibile:

dove trovo i dettagli del JWT:


Provo a cambiare lo “username” da hakin9 a admin, quindi send  e vediamo cosa succede:

Purtroppo restituisce un errore di “signature” perchè è fallita ovviamente la verifica della firma:

Provo a cancellare la firma:

e riusco a ottenere uno stato HTTP 200:

Quindi chiedo la sessione browser:

che una volta utilizzata mi darà accesso al flag.


Accedo con le consuete credenziali e sostituisco nell’url l’endpoint “dashboard” con “admin”, ma non ottengo l’accesso in quanto non autorizzato. Dall’HTTPhistory invio quest’ultima pagina al “Repeater” quindi apro la scheda “JSON Web Token”:

Cambio il valore di “username” da “hakin9” a “admin”, quindi “Send”, ma ottengo un errore sulla validità della “firma”:

Mi sposto nella scheda “Raw” e provo a eliminare la “firma” e ottengo un altro errore che mi dice che “Algorithm is not set to None”:

Torno alla scheda “JSON Web Token” e cambio il valore di “alg” da “HS256” a “None” ottenendo così un HTTP 200 status OK:

Quindi “Request in browser” > “In original session” e l’url così ottentuto lo incollo sl posto di quello della pagina web e ottengo il flag.

Cracking Keys

Accedo con le solite credenziali, quindi nell’url della pagina sostituisco dashboard con admin e ottengo come risposta “Unauthorized”.
Dal Raw del Request copio il JWT e lo uso con lo script python “jwt_tool.py” (dove -C sta per cracking e -d per indicare quale dizionario da utilizzare):

e ottengo “hidden” come valore di chiave corretto.

Utilizzando jwt.io creo la firma corretta: assegno “admin” a “username” e “hidden” al campo “secret”, quindi copio il JWT così ottenuto:

Torno su Burp Suite e invio la pagina con “admin” al Repeater, quindi sostituisco il JWT presente con quello appena calcolato e verifico con “send”:

Questa volta lo status HTTP è 200 Ok, per cui richiedo la sessione browser:

 quindi incollo url nel browser e ottengo l’accesso.


Effettuato come la solito il login, invio la pagina al Turbo Intruder, quindi sostituisco “dashboard” con l’operatore di conversione “%s” al quale passo la lista degli “endpoint” e filtro i risultati per ottenere solo lo stato HTTP 404:

Il risultato dello script restituisce l’endpoint “admin” e come errore lo stato HTTP 401 UNAUTHORIZED dovuto a “Invalid role for accessing the admin page”:

… quindi devo cambiare il ruolo per l’utente “admin”:

Per fare questo ho bisogno della chiave segreta necessaria per la “firma”, quindi utilizzo il “jwt_tool.py” per recuperarlo utilizzando il JWT dell’utente “hakin9” come input:

Copio il JWT e lo inserisco nel modulo di codifica del sito “jwt.io”:

Quindi cambio il valore di “username” e “role” entrambi in “admin” e inserisco la chiave segreta “123NotAParticularyGreatSecret!!!”:

Mando la pagina al “Repeater” e sostituisco il vecchio JWT con quello nuovo appena creato, poi “Send” e controllo di avere uno stato HTTP 200 OK:

Richiedo la sessione originale nel browser e la incollo nell’url ottenendo così l’accesso voluto.

Implementation Flaws

Accedo con le solite credenziali e sostituisco “dashboard” con “admin” e anche in questo caso risulta che non sono autorizzato. Invio la pagina con “admin” al Repeater e apro il tab “JWT Web Token”, qui posso notare un altro tag nell’header, ovvero il “kid”:

L’attestazione “kid”’ (ID chiave) è un’attestazione facoltativa in un JSON Web Token (JWT) che viene utilizzata per identificare la chiave usata per firmare il JWT. Lo scopo dell’attestazione “kid” è consentire ai destinatari del JWT di determinare quale chiave è stata utilizzata per firmare il token, in modo che possano cercare la chiave pubblica corrispondente e verificare la firma. Ciò è particolarmente utile quando sono in uso più chiavi, ad esempio quando si ruotano le chiavi o si utilizzano chiavi diverse per scopi diversi.

L’attestazione “kid” è inclusa nell’intestazione JWT e il suo valore è una stringa che identifica in modo univoco la chiave usata per firmare il token. Quando il destinatario di un JWT riceve il token, può utilizzare l’attestazione “kid” per cercare la chiave pubblica corrispondente alla chiave utilizzata per firmare il JWT e quindi utilizzare quella chiave pubblica per verificare la firma.

È importante notare che l’attestazione “kid” è facoltativa e non tutti i JWT la includeranno. Tuttavia, è consigliabile includerla quando possibile, in quanto può migliorare notevolmente la sicurezza e la facilità d’uso dei JWT nelle applicazioni.

Una possibile vulnerabilità relativa al “kid” è che a volte può indicare il percorso dove la chiave è memorizzata all’interno del server, infatti se copio il percorso e lo sostituisco ad “admin” nell’url, otteniamo la chiave che ha generato il token:

Copio l’intero JWT e lo incollo sul sito “jwt.io”, quindi modifico con “admin” lo “username” e nel campo “secret” inserisco il valore della chiave che ha generato il JWT:

La firma è stata verivicata, allora posso utilizzare il nuovo JWT così ottenuto al posto di quello presente nel “Raw” del “Repeater”, verifico con “send” e quindi richiedo le sessione browser: 

Utilizzando l’url così ottenuto guadagno l’accesso.

OAuth 2.0 and CSRF

OAuth (Open Authorization) è un protocollo di autorizzazione standardizzato che consente a un utente di concedere l’accesso a una risorsa protetta a un’applicazione di terze parti senza condividere le proprie credenziali di accesso.

In altre parole, OAuth consente a un utente di autorizzare un’applicazione di terze parti (ad esempio, un’applicazione mobile o un’applicazione web) ad accedere alle proprie informazioni senza dover fornire le proprie credenziali di accesso a questa applicazione. OAuth utilizza un token di accesso che viene concesso all’applicazione di terze parti dall’utente, con il quale l’applicazione può accedere alla risorsa protetta.

Questo protocollo di autorizzazione è ampiamente utilizzato per consentire l’accesso a servizi web e API, come i social network (ad esempio Facebook, Twitter, LinkedIn) e i servizi di archiviazione cloud (ad esempio Google Drive, Dropbox). OAuth viene utilizzato anche per la federazione delle identità e per l’autenticazione unica, consentendo all’utente di utilizzare le proprie credenziali di accesso per accedere a più servizi, senza dover effettuare l’accesso separatamente per ciascun servizio.

OAuth è un protocollo aperto e standardizzato, il che significa che può essere utilizzato da qualsiasi sviluppatore per integrare i propri servizi con altri servizi esistenti.

Una volta caricata la pagina di login, notiamo nell’HTTPhistory due diversi host: “h9burpsuite” e “oauth2.h9burpsuite”, quest’ultimo relativo all’autenticazione mediante il protocollo “oauth” appunto:

Sono importanti nel “Raw” i valori relativi a “client_id”,  “response_type=code” e “scope” come visto in precedenza. 
Andata a buon fine l’autenticazione, veniamo reindirizzati alla pagina di “h9burpsuite”, con il nuovo “code” ovvero il token d’accesso:

Infatti se torno alla pagina principale e clicco sul login di ottengo l’accesso senza immettere nuovamente le credenziali.

Vediamo come poter sfruttare l’oauth. Dapprima effettuo il logout, quindi di nuovo login e inserisco le credenziali, ma prima di inviare mi sposto su Burp Suite e dal tab “Intercept” abilito l’ “Intercept on”:

solo a questo punto completo il login inviando le credenziali, vedreò popolarsi la pagina “Raw” dell’ “Intercept”:

A questo punto, sempre nella pagina dell’ “Intercept”, cliccho su “Forward” e interagisco con la pagina web del login, ripeterò le operazioni alcune volte finchè non otterrò una risposta con “code=…”. Quindi tasto destro e copiamo l’URL.:

Ora non andiamo più avanti col “Forward” perchè avrei un reindirizzamento alla pagina precedente, ovvero quella che richiede l’accettazione della mail, ma clicco su “Drop” e interrompo l’ “Intercept”:

Posto su off l’ “Intercept”, mio sposto sulla pagina web e nell’URL cancello tutto quello che riguarda il precedente oauth:

Nella nuova pagina di login, inserisco l’URL precedentemente copiata e ottengo così l’accesso.


Caricata la pagina , dall’http history di Burp Suite, invio l’URL al Turbo Intruder

Usando lo script, itero fra gli endpoints, filtrando i risultati affinché vengano escluse le pagine con http STATUS 404:

Ottengo come risultato positivo l’endpoint “.well-known”:

Invio al Repeater e verifico con “send” ottengo uno stato HTTP 200 OK, ma nessun’altra informazione:

Mediante Turbo Intruder, allora, ripeto nuovamente la stessa operazione sull’endpoint appena trovato:

Ed ottengo un nuovo endpoint positivo:

Nel Repeater verifico con “send” e questa volta ho una risposta positiva ma con maggiori informazioni:

Su quanto ottenuto effettuo “Request in Browser” -> “In original session” e copio l’url:

E lo incollo nel mio browser ottenendo così il flag.

Redirect URI

Nell’ HTTP history è possibile notare il link del “redirect_uri”:

Invio dunque al “Repeater” così da modificare il valore del “redirect_uri” all’interno del “Decoded from”:

Provo a decodificare “google.com”:

Applico le modifiche “Apply changes” e invio con “Send”, il test non ha funzionato perchè viene segnalato un errore di “Invalid URI”:

Questo accade perché il redirect si aspetta “h9burpsuite:4499” all’interno dell’URI. Un modo per farlo è quello di “ancorare” il dominio richiesto all’interno dell’URI mediante il simbolo del “cancelletto#:

Quindi applico la modifica, “Send” e questa volta ottengo uno status HTTP OK:

Copio l’URI:

Quindi su Proxy-> Intercept, ma senza attivarlo, carico nuovamente la pagina per il login e solo ora, prima di fare login, attivo l’Intercept. Quindi sostituisco il valore dell’URI presente nell’Intercept con quello copiato in precedenza:

Quindi “Forward” e fermo l’Intercept, torno sulla pagina di login, inserisco la credenziali, ma questa volta vengo reindirizzato sulla pagina di google:

Note su OpenID Connect + SAML

OpenID Connect (OIDC) è un protocollo di autenticazione basato su OAuth 2.0, che permette di ottenere informazioni di autenticazione e identità di un utente. OIDC è stato sviluppato per fornire un’alternativa più sicura e interoperabile rispetto all’originale protocollo OpenID.

OIDC consente a un’applicazione web di autenticare l’utente tramite il flusso di OAuth 2.0 e di ricevere un ID Token che contiene informazioni sull’utente, come l’ID dell’utente e il nome. L’ID Token è firmato digitalmente e può essere verificato dall’applicazione per garantire che sia stato emesso da un’autorità di sicurezza attendibile.

Inoltre, OIDC fornisce un endpoint denominato UserInfo che consente alle applicazioni di richiedere informazioni sull’utente come ad esempio l’indirizzo email o la data di nascita.

OIDC è diventato un protocollo popolare per l’autenticazione su Internet ed è stato adottato da molte aziende, come Google, Microsoft, Amazon e molti altri, per consentire l’autenticazione degli utenti sui loro servizi e applicazioni web.

SAML (Security Assertion Markup Language) è un protocollo standard per lo scambio di informazioni di autenticazione e autorizzazione tra diverse applicazioni web. SAML è stato sviluppato per consentire l’accesso sicuro a risorse web attraverso le frontiere organizzative, come ad esempio tra fornitori di servizi e fornitori di identità.

SAML si basa su una struttura di messaggi basata su XML e utilizza la crittografia per garantire la sicurezza delle informazioni di autenticazione e autorizzazione durante la trasmissione. Il protocollo SAML prevede tre ruoli principali:

  • Fornitore di Identità (Identity Provider – IdP): il sistema che autentica l’utente e fornisce un assertion (asserzione) SAML contenente informazioni di autenticazione e autorizzazione;
  • Fornitore di Servizi (Service Provider – SP): il sistema che fornisce la risorsa protetta e che richiede l’autenticazione e l’autorizzazione tramite un assertion SAML;
  • Utente Finale: l’utente che accede alla risorsa protetta.

Il processo di autenticazione e autorizzazione con SAML prevede l’invio di un Assertion SAML dal Fornitore di Identità al Fornitore di Servizi per autorizzare l’accesso all’utente finale. L’Assertion SAML contiene informazioni sulle credenziali di autenticazione dell’utente, come l’ID dell’utente e le autorizzazioni.

SAML è stato adottato da molte organizzazioni come standard per l’autenticazione sicura e l’autorizzazione tra applicazioni web, in particolare in ambito Enterprise.