Ultima modifica:
Durante un pentest possono capitare cose che suonano "strane" ad un principiante, ad esempio:
- Il processo che stava hostando la shell rimane idle nel task manager, anche dopo essere usciti;
- Hai fatto dll injection in un processo, non importa se tramite uno script personalizzato o tramite il volgare comando "migrate" di Meterpreter, ma quando esci dalla sessione il processo che la stava hostando muore, provocando l'instabilità di Windows;
- L'applicazione vulnerabile a buffer overflow spawna una reverse shell, ma dopo un po' quest'applicazione crasha inspiegabilmente;
Questi eventi, sono in realtà un errore nella gestione degli EXITFUNC. Quali sono, cosa sono esattamente, e come si categorizzano?
Prima di tutto, c'è un imprecisazione che verrà rettificata. Gli EXITFUNC non sono un "comando speciale" di Metasploit, bensì un metodo di Windows che chiama le funzioni corrette per garantire l'esecuzione e la stabilità di un programma. In Metasploit, è possibile specificare l'EXITFUNC che ciascun payload dovrebbe utilizzare, e ora le ripasseremo:
- EXITFUNC: process. La più semplice, e presente anche di default, questa va usata se stiamo pianificando di eseguire shellcode attraverso un PE (.exe), il metodo più tradizionale. Quando "process" è chiamato come funzione d'uscita, il payload terminerà la sua esecuzione insieme al processo annesso che ha generato. Questa funzione non dovrebbe essere chiamata quando si pianifica di hostare shellcode in processi legittimi, come explorer.exe, perché nel momento in cui si terminerà la sessione, il payload causerà l'arresto di explorer.exe, generando indicatori di compromissione per il blue team;
- EXITFUNC: thread. Questa viene usata nello scenario di compromissione di un processo legittimo. Attraverso questo metodo, è possibile iniettare shellcode in ogni processo (assunto che si abbiano i dovuti privilegi) e il payload risultante spawnerà come un sub-thread del processo infetto. Non va utilizzata se il metodo d'attacco prevede l'inizializzazione di un processo indipendente (come nel caso di una reverse shell che spawna da un .exe). Se usata scorrettamente in questo scenario, "thread" lascerà in esecuzione un processo idle, che andrà terminato manualmente nel Task Manager. Anche quest'errore lascia indicatori di compromissione evidenti;
-EXITFUNC: SEH (o Structured Exception Handling). Questa funzione non è molto popolare, specialmente per chi è alle basi con il penetration testing. Questa funzione, dovrebbe essere usata solo quando si lavora con le applicazioni affette da buffer overflow (una tecnica che prevede l'inserimento di una quantità eccessiva di dati in un buffer di memorizzazione), quando le applicazioni sono affette da buffer overflow, al momento del triggering inizieranno a funzionare anomalmente e a quel punto può essere fornito un input arbitrario, che nell'exploit development, per semplicità di cose, consiste di solito nel far eseguire all'app vulnerabile un'altra app, come calc.exe, notepad o paint. Tuttavia, sui sistemi Windows dotati di un processore AMD64 esistono tecniche di attack surface reduction contro i buffer overflow, come ad esempio DEP o ASLR. Come sono relazionati questi sistemi di protezione con SEH? L'attaccante può semplicemente sovrascrivere l'handler SEH piuttosto che l'indirizzo di ritorno, ottendo un controllo più fluido sul workflow dell'exploit. Se si usano "thread" o "process" come metodi, l'exploit potrebbe sovrascriversi in regioni di memoria proibite dai meccanismi di protezione, risultando in un errore che causa l'arresto dell'app. Anche se ASLR randomizza gli indirizzi di base delle librerie e delle regioni di memoria durante l'avvio di un programma, l'handler SEH è un indirizzo noto e prevedibile. Quindi, grazie a questo metodo, non è necessario conoscere l'indirizzo esatto dove andrà collocato un blocco di shellcode, perché è sufficiente conoscere l'indirizzo dell'handler SEH per dirigere l'esecuzione verso lo shellcode. Per quanto riguarda DEP, non è altro che un altro meccanismo di difesa che può essere gestito dall'handler SEH. DEP, sostanzialmente ha il compito di prevenire l'esecuzione di codice in regioni di memoria contrassegnate come "dati". Ma dato che SEH è una syscall che risiede in una regione di memoria eseguibile, DEP non ne preverrà l'esecuzione. Si può dire sommariamente, dunque, che SEH è un EXITFUNC optabile nel listener di Metasploit solo quando si vogliono bypassare questi sistemi di sicurezza, in un contesto in cui desideriamo far comportare anomalmente un app affetta da buffer overflow. Alcuni exploit basati sui buffer overflow in Metasploit, partiranno con EXITFUNC => SEH come metodo di default, per garantire una maggior stabilità d'esecuzione.
Curiosità:
Fino alla build precedente, in Avast Free Edition era presente una vulnerabilità che consentiva di bypassare la detection sfruttando SEH come EXITFUNC in un contesto in cui viene servito alla mini-sandbox "CyberCapture" un PE che resiste all'analisi statica ma dovrebbe essere tecnicamente catturato ed eliminato in runtime. Nel momento dell'esecuzione di un .exe malevolo che ha questa caratteristica, Avast avviava la sua scansione di routine con il modulo chiamato "CyberCapture", dopo circa 10 secondi rivelava il codice che veniva decriptato per la sovrascrittura in memoria. Tuttavia, se nel listener di Metasploit veniva impostato SEH come metodo di gestione del workflow, Avast falliva nell'eliminare completamente il malware, risultando nell'eliminazione formale dell'.exe, ma tralasciando un file ".tmp" che hostava correttamente shellcode in runtime. Questa tecnica, se ripetuta più di 2 volte, causava l'instabilità della RAM, forzando un restart. La vulnerabilità risiedeva in un difetto di emulazione della CyberCapture di Avast, che erroneamente restituiva il message box "Tutto a posto, il file non ha alcun problema". Vulnerabilità già nota ed evidente come un cavallo sul balcone, è in corso di esaminazione da parte del team di Avast, perché si dubita che non sia risolta del tutto. Disabilitando la sandbox, il PE veniva regolarmente eliminato in runtime dal modulo "anti-exploit shield".
- Il processo che stava hostando la shell rimane idle nel task manager, anche dopo essere usciti;
- Hai fatto dll injection in un processo, non importa se tramite uno script personalizzato o tramite il volgare comando "migrate" di Meterpreter, ma quando esci dalla sessione il processo che la stava hostando muore, provocando l'instabilità di Windows;
- L'applicazione vulnerabile a buffer overflow spawna una reverse shell, ma dopo un po' quest'applicazione crasha inspiegabilmente;
Questi eventi, sono in realtà un errore nella gestione degli EXITFUNC. Quali sono, cosa sono esattamente, e come si categorizzano?
Prima di tutto, c'è un imprecisazione che verrà rettificata. Gli EXITFUNC non sono un "comando speciale" di Metasploit, bensì un metodo di Windows che chiama le funzioni corrette per garantire l'esecuzione e la stabilità di un programma. In Metasploit, è possibile specificare l'EXITFUNC che ciascun payload dovrebbe utilizzare, e ora le ripasseremo:
- EXITFUNC: process. La più semplice, e presente anche di default, questa va usata se stiamo pianificando di eseguire shellcode attraverso un PE (.exe), il metodo più tradizionale. Quando "process" è chiamato come funzione d'uscita, il payload terminerà la sua esecuzione insieme al processo annesso che ha generato. Questa funzione non dovrebbe essere chiamata quando si pianifica di hostare shellcode in processi legittimi, come explorer.exe, perché nel momento in cui si terminerà la sessione, il payload causerà l'arresto di explorer.exe, generando indicatori di compromissione per il blue team;
- EXITFUNC: thread. Questa viene usata nello scenario di compromissione di un processo legittimo. Attraverso questo metodo, è possibile iniettare shellcode in ogni processo (assunto che si abbiano i dovuti privilegi) e il payload risultante spawnerà come un sub-thread del processo infetto. Non va utilizzata se il metodo d'attacco prevede l'inizializzazione di un processo indipendente (come nel caso di una reverse shell che spawna da un .exe). Se usata scorrettamente in questo scenario, "thread" lascerà in esecuzione un processo idle, che andrà terminato manualmente nel Task Manager. Anche quest'errore lascia indicatori di compromissione evidenti;
-EXITFUNC: SEH (o Structured Exception Handling). Questa funzione non è molto popolare, specialmente per chi è alle basi con il penetration testing. Questa funzione, dovrebbe essere usata solo quando si lavora con le applicazioni affette da buffer overflow (una tecnica che prevede l'inserimento di una quantità eccessiva di dati in un buffer di memorizzazione), quando le applicazioni sono affette da buffer overflow, al momento del triggering inizieranno a funzionare anomalmente e a quel punto può essere fornito un input arbitrario, che nell'exploit development, per semplicità di cose, consiste di solito nel far eseguire all'app vulnerabile un'altra app, come calc.exe, notepad o paint. Tuttavia, sui sistemi Windows dotati di un processore AMD64 esistono tecniche di attack surface reduction contro i buffer overflow, come ad esempio DEP o ASLR. Come sono relazionati questi sistemi di protezione con SEH? L'attaccante può semplicemente sovrascrivere l'handler SEH piuttosto che l'indirizzo di ritorno, ottendo un controllo più fluido sul workflow dell'exploit. Se si usano "thread" o "process" come metodi, l'exploit potrebbe sovrascriversi in regioni di memoria proibite dai meccanismi di protezione, risultando in un errore che causa l'arresto dell'app. Anche se ASLR randomizza gli indirizzi di base delle librerie e delle regioni di memoria durante l'avvio di un programma, l'handler SEH è un indirizzo noto e prevedibile. Quindi, grazie a questo metodo, non è necessario conoscere l'indirizzo esatto dove andrà collocato un blocco di shellcode, perché è sufficiente conoscere l'indirizzo dell'handler SEH per dirigere l'esecuzione verso lo shellcode. Per quanto riguarda DEP, non è altro che un altro meccanismo di difesa che può essere gestito dall'handler SEH. DEP, sostanzialmente ha il compito di prevenire l'esecuzione di codice in regioni di memoria contrassegnate come "dati". Ma dato che SEH è una syscall che risiede in una regione di memoria eseguibile, DEP non ne preverrà l'esecuzione. Si può dire sommariamente, dunque, che SEH è un EXITFUNC optabile nel listener di Metasploit solo quando si vogliono bypassare questi sistemi di sicurezza, in un contesto in cui desideriamo far comportare anomalmente un app affetta da buffer overflow. Alcuni exploit basati sui buffer overflow in Metasploit, partiranno con EXITFUNC => SEH come metodo di default, per garantire una maggior stabilità d'esecuzione.
Curiosità:
Fino alla build precedente, in Avast Free Edition era presente una vulnerabilità che consentiva di bypassare la detection sfruttando SEH come EXITFUNC in un contesto in cui viene servito alla mini-sandbox "CyberCapture" un PE che resiste all'analisi statica ma dovrebbe essere tecnicamente catturato ed eliminato in runtime. Nel momento dell'esecuzione di un .exe malevolo che ha questa caratteristica, Avast avviava la sua scansione di routine con il modulo chiamato "CyberCapture", dopo circa 10 secondi rivelava il codice che veniva decriptato per la sovrascrittura in memoria. Tuttavia, se nel listener di Metasploit veniva impostato SEH come metodo di gestione del workflow, Avast falliva nell'eliminare completamente il malware, risultando nell'eliminazione formale dell'.exe, ma tralasciando un file ".tmp" che hostava correttamente shellcode in runtime. Questa tecnica, se ripetuta più di 2 volte, causava l'instabilità della RAM, forzando un restart. La vulnerabilità risiedeva in un difetto di emulazione della CyberCapture di Avast, che erroneamente restituiva il message box "Tutto a posto, il file non ha alcun problema". Vulnerabilità già nota ed evidente come un cavallo sul balcone, è in corso di esaminazione da parte del team di Avast, perché si dubita che non sia risolta del tutto. Disabilitando la sandbox, il PE veniva regolarmente eliminato in runtime dal modulo "anti-exploit shield".
