Spesso, per testare la sicurezza della nostra rete o delle nostre workstation, ci troviamo a dover utilizzare tool di terze parti che gli antivirus identificano come "Hacker tools" impedendoci di portare a termine il nostro lavoro.
In questo articolo mostrerò alcune tecniche per tentare di nascondere i nostri tools agli antivirus. Non tratterò l’argomento in maniera dettagliata in quanto per farlo sarebbe necessario pubblicare un vero e proprio libro ma cercherò di trattare le tecniche più utilizzate e dare qualche spunto al lettore che potrà, in autonomia, approfondire il tema.
Premessa
Le tecniche che vedremo di seguito non saranno efficaci con tutti gli antivirus. Come sapete i software antivirus adottano diversi sistemi per il riconoscimento di codice maligno: analizzano i file e li confrontano con i database delle "firme", analizzano l’esecuzione dei programmi in memoria e il loro comportamento (scansione euristica), ecc.
La scansione euristica, offerta ormai da quasi tutti i software antivirus, non si basa su database di impronte virali ma cerca di rilevare nuovi virus semplicemente verificando le operazione che il file sta cercando di eseguire. Se tali operazioni risultano sospette, allora l’antivirus provvederà a bloccare il file eventualmente segnalandolo con un messaggio di allerta. Proprio per questo modo di operare la scansione euristica è più difficile da aggirare.
Le tecniche che illustrerò saranno in grado di ingannare solo gli antivirus che analizzano il pattern/firma del file confrontandola con quelle memorizzate nel loro database di impronte virali.
Iniziamo
Uno dei tool che viene bloccato dagli antivirus in quanto considerato "Hacker Tool" è NetCat. NetCat è un programmino opensource a riga di comando molto flessibile che ci permette di ottenere la shell di un sistema remoto, eseguire la scansione delle porte, inviare email, trasferire file, chattare, creare backdoor e tant’altro.
Una versione di NetCat per Windows potete scaricarla dal seguente link
Se avete installato un antivirus è probabile che l’eseguibile venga riconosciuto come virus e bloccato o eliminato, pertanto è consigliabile disabilitare temporaneamente l’antivirus. Se non vi fidate e volete lavorare in tutta sicurezza allora vi consiglio di lavorare su una macchina virtuale.
Scompattate il file .zip in una cartella. All’interno del file zip, oltre al file eseguibile, trovano posto i sorgenti dell’applicazione.
Per verificare quanti e quali antivirus identificano l’eseguibile di NetCat (nc.exe) come virus possiamo effettuare l’upload del file su www.virustotal.com e farlo analizzare.
Virustotal è un servizio che permette l’analisi di file sospetti per la rapida identificazione di virus, malware e trojan. Il file segnalato dall’utente viene verificato confrontandolo con i database delle impronte virali dei maggiori antivirus in circolazione.
Nel nostro caso Virustotal indica che nc.exe viene segnalato
come pericoloso dal 31 dei 55 antivirus in
elenco. Cosa possiamo fare per
migliorare la situazione?
|
FIG 1 - Prima scansione con Virustotal |
Opzione 1: Alterare il codice sorgente
Uno dei metodi che possiamo utilizzare è quello di andare ad alterare il codice sorgente in modo tale da alterarne l’impronta e renderlo non più riconoscibile dagli antivirus.
Nel nostro caso agiremo sul codice sorgente di NetCat che abbiamo scaricato precedentemente. Iniziamo subito con dire che aggiungere commenti al file sorgente non andrà a modificare in alcun modo il file eseguibile, infatti tutti i compilatori ignorano i commenti passando all'istruzione successiva. Quindi dobbiamo trovare un modo per far si che il file eseguibile ottenuto sia diverso da quello originale pur mantenendo le sue funzionalità.
Un metodo per ottenere un file eseguibile leggermente diverso da quello originale è provare a modificare le impostazioni del compilatore o, meglio ancora, utilizzare un compilatore diverso. I compilatori tendono ad ottimizzare aspetti diversi dell’applicazione producendo, in questo modo, eseguibili leggermente diversi tra loro. Ad es. i compilatori Intel tendono ad ottimizzare il codice per i propri processori, il compilatore incluso in Microsoft Visual Studio, invece, ottimizzerà il file eseguibile per essere eseguito sui propri sistemi operativi ecc. Proviamo a verificare quanto ho scritto fin’ora.
|
FIG 2 - Scansione con Virustotal dopo ricompilazione |
- Prima di cantare vittoria verifichiamo se il nuovo file funziona. Dal prompt dei comandi posizioniamoci nella cartella dove è presente il file nc.exe e digitiamo il seguente comando
nc -v -w2 -z 192.168.0.3 1-200
tale comando esegue la scansione delle porte, comprese tra 1 e 200, sulla postazione con indirizzo ip 192.168.0.3 e ci informa quali porte risultano aperte. Il comando funziona correttamente e dimostra che il nostro file è perfettamente funzionante.
- Altre modifiche che possiamo apportare al codice sorgente sono la modifica dei nomi delle variabili globali, il nome dei metodi, modificare leggermente le procedure/funzioni.
Nel caso in cui non
avessimo a disposizione il sorgente del file allora possiamo modificare il
codice aiutandoci con un debugger e un editor esadecimale. In questo caso
l’operazione diventerebbe molto più complicata ma comunque fattibile.
Opzione 2: Utilizzare runtime Packers
L’utilizzo di runtime packers permette di modificare la struttura all'interno di un file eseguibile. I runtime packers non sono altro che dei software che riescono a comprimere un file eseguibile senza però togliergli la capacità di esecuzione: le dimensioni del file diminuiscono ma il file rimane comunque eseguibile. Una volta lanciati si auto decomprimono in memoria e iniziano la loro esecuzione in modo del tutto trasparente all’utente.
Di runtime Packers
ce ne sono molti in circolazione, tra i più diffusi troviamo UPX, ASPack,
PEProtect, UPack, PESpin, MEW, FSG e tanti altri ancora.
- Scarichiamo UPX per Windows dal seguente URL http://upx.sourceforge.net/ e scompattiamolo
- Copiamo il file originale.nc.exe che abbiamo visto nell’Opzione 1 nella cartella dove abbiamo scompattato UPX
- Dal prompt dei comandi accediamo alla cartella di upx e digitiamo il seguente comando:
upx -9 originale.nc.exe
- Una volta che il file è stato compresso eseguiamo l’upload su www.virustotal.com ed eseguiamo l’analisi, vedremo che rispetto al file originale viene riconosciuto da un minore numero di antivirus. Non è molto ma è pur sempre un miglioramento. Nulla ci vieta di eseguire in sequenza più runtime packers per migliorare ulteriormente questo risultato, l’importante è non esagerare anche perché i miglioramenti sono limitati.
Opzione 3: Utilizzare software per proteggere il codice dal reverse engineering
Questo tipo di software, concettualmente, funziona in modo analogo ai runtime packers con la differenza che non si limita a comprimere il codice ma provvede anche a modificarne la struttura e a criptarlo per rendere difficile l’operazione di reverse. Solitamente il codice x86 viene sostituito con un byte code proprietario.
I software più utilizzati in tal senso sono tipo Themida (www.oreans.com) e VMprotect (www.vmprotect.com) entrambi di tipo commerciale. In questo articolo mostrerò il funzionamento di Themida (sul sito www.oreans.com è possibile scaricare una demo del prodotto). La versione di Themida utilizzata è l'ultima disponibile al momento, si tratta della versione 2.3.2.0. La demo non richiede alcuna installazione, basta eseguire la versione a 32 o 64bit in base al software che si intende proteggere.
L'utilizzo del software è molto semplice, una volta avviato non ci resta che indicare il file che vogliamo proteggere e smanettare con le varie opzioni per impostare le protezioni di nostro gradimento quindi non ci resta che cliccare sul pulsante Protect.
|
FIG 3 - Themida |
Anche lasciando tutte le impostazioni di default si ottiene un risultato discreto. Proteggendo il nostro file originale.nc.exe analizzando il file prodotto con virustotal notiamo che il numero di antivirus che segnalano il file ancora come pericoloso è molto ridotto.
|
FIG 4 - Analisi di Virustotal del file protetto da Themida |
Opzione 4: Binding
Nascondere l’estensione del file tramite l’apposita opzione presente nel sistema operativo o effettuare il binding sono due operazioni idonee ad ingannare l’utente ma non l’antivirus, ragione per cui verranno solo accennate in questo articolo.
Il binding consiste nell’unire più eseguibili in uno. Tra i tool più utilizzati in passato il più noto è sicuramente eLiTeWrap piuttosto vecchiotto e ormai riconosciuto da tutti gli antivirus. Veniva utilizzato spesso per creare una backdoor con VNC.
Di programmi che effettuano il binding ce ne sono molti in giro ed è possibile costruirsene di propri con poche righe di codice. Oltre a eLiTeWrap che è gratuito e open source, troviamo File Joiner, Exe Fusion, Quick Batch File Compiler e tanti altri ancora. Possiamo persino utilizzare l’utility IExpress inclusa in Windows oppure, con gli appositi tool di compressione(ad es. Winzip e Winrar), possiamo creare un file autoestraente in cui specifichiamo un file da eseguire al termine dell’estrazione. L’icona dei file creati con utility come IExpress, Winrar e Winzip sono facilmente riconoscibili e possono insospettire l’utente ma possiamo modificarle facilmente utilizzando tool come Resource Hacker (http://angusj.com/resourcehacker).
Basta fare una piccola ricerca con google per trovare tante altre utility adatte a questo scopo.
Altre Opzioni
Modificare con debugger ed editor esadecimale il file eseguibile
Utilizzando software come LordPe, Hex Workshop e Ollydbg è possibile andare a modificare direttamente il file eseguibile magari aggiungendo una routine di codifica/decodifica eseguita a runtime, ad es. una routine XOR, così come dimostrato da Mati Aharoni (esperto di sicurezza informatica che ha contribuito allo sviluppo di BackTrack) allo Shmoocon 2008(convention annuale degli hacker sulla east coast degli Stati Uniti).
L’operazione consiste nell’inserire uno stub all’interno del file con il compito di criptare/decriptare il file. In pratica procediamo nel seguente modo:
Aggiungiamo alla fine del file dei byte in modo da creare spazio per la nostra routine;
- Inseriamo la nostra routine alla fine del file;
- Modifichiamo la prima istruzione del file in modo tale che salti alla prima istruzione della routine appena aggiunta;
- Al termine della nostra routine inseriamo un salto per ritornare al flusso originale del programma
Per semplicità ci atteniamo all'esempio fatto da Mati Aharoni utilizzando una routine che esegue l’XOR pertanto non parliamo più di criptare/decriptare ma di codifica/decodifica.
- Aprire il file binario con LordPE, cliccare sul pulsante Sections quindi, nella nuova finestra dal titolo [ Section Table ], cliccare sulla riga .idata con il tasto destro del mouse e selezionare, dal menu contestuale, la voce edit section header. Andiamo a modificare i campi VirtualSize e RawSice aggiungendo il valore 1000.
|
FIG 5 - LordPE Sections |
|
FIG 6 - LordPE .idata |
- Clicchiamo sul pulsante … accanto al campo Flags e, nella finestra che appare, assicuriamoci di impostare il Flag Executable as a code. Confermiamo la modifica cliccando sul pulsante OK fino a ritornare alla finestra [ Section Table ]
|
FIG 7 - LordPE [ Section Flags] |
- Clicchiamo con il tasto destro del mouse in corrispondenza della riga .text e, dal menu contestuale, selezioniamo la voce edit section header.
- Clicchiamo sul pulsante … accanto al campo Flags e impostiamo il flag Writeable. Tale opzione va abilitata in quanto l’operazione di codifica/decodifica avverrà proprio nella sezione .text. Confermiamo la modifica cliccando sempre su OK fino a ritornare alla finestra [ Section Table ]. Chiudiamo la finestra quindi clicchiamo prima sul pulsante Save e successivamente su OK.
Possiamo chiudere l’applicazione Lord PE
|
FIG 8 - LordPE [ Section Flags ] |
A questo punto tentando di eseguire il file verrà visualizzato un messaggio di errore che avvisa l’utente che non si tratta di un’applicazione Windows valida. Ciò è dovuto al fatto che abbiamo indicato le nuove dimensioni della sezione .idata senza modificare le dimensioni effettive del file e questo manda in tilt l’IP. Ecco che per rimediare utilizziamo un altro tool Hex Workshop.
- Avviamo Hex Workshop e posizioniamoci alla fine del file, clicchiamo con il tasto destro e dal menu selezioniamo la voce Insert
|
FIG 9 - Hex Workshop |
- Nel campo Number of bytes inseriamo 1000 (per il nostro scopo possiamo inserire anche meno byte ma meglio tenerci larghi) e assicuriamoci che l’opzione Hex sia selezionata. Clicchiamo su OK e salviamo il file. Possiamo uscire da Hex Workshop.
|
FIG 10 - Hex Workshop |
Adesso tentando di
eseguire il nostro file non riceveremo più alcun messaggio di errore. Le
operazioni che abbiamo eseguito fino a questo momento hanno aggiunto lo spazio
per l’inserimento della nostra routine XOR. Per questa attività ci serviamo di Ollydbg.
- Apriamo il nostro file da Ollydbg. Il debugger si posiziona subito sulla riga di nostro interesse (entry Point) che è rappresentata dalla prima istruzione. Copiamo le prime 4 righe e incolliamole in blocco note, ci serviranno più tardi per il return dalla nostra routine.
Per semplicità di seguito riporto le righe di nostro interesse che andremo a copiare:
00404C00 > $ 55 PUSH EBP
00404C01 . 8BEC MOV EBP,ESP
00404C03 . 6A FF PUSH -1
00404C05 . 68 00B04000 PUSH nc.0040B000
|
FIG 11 - OllyDbg |
- Visualizziamo la Memory Map: dal menu View selezionare la voce Memory. Nella nuova finestra cliccare 2 volte sulla sezione .idata
.
|
FIG 12 - OllyDbg Memory Map |
- A questo punto si aprirà una
nuova finestra contenente il dump della sezione .idata. Scorriamo e
individuiamo il punto in cui iniziano i byte da noi inseriti. Non è importante
essere estremamente precisi, possiamo anche non selezionare con precisione il
punto di inizio del nostro blocco ma un po’ di indirizzi più avanti. Troviamo
che l’indirizzo 00412830 fa al caso nostro.
- Chiudiamo la schermata e la finestra Memory Dump per ritornare alla schermata principale (CPU - main thread). Posizioniamoci sulla prima riga che abbiamo copiato (Nel nostro caso all’indirizzo 00404C00. Nel caso ci fossimo spostati inavvertitamente: selezionare una riga qualsiasi, cliccarci su con il tasto destro del mouse quindi selezionare go to e successivamente Origins. Se Origins non appare nel menu vuol dire che siamo già sulla prima riga)
- Adesso dobbiamo modificare il flusso di esecuzione. Clicchiamo 2 volte sulla prima riga. Apparirà una finestra che ci permetterà di modificare l’istruzione. Inseriamo nell'apposito campo l’istruzione JMP 00412830 dove 00412830 rappresenta il punto di inizio del nostro blocco vuoto aggiunto precedentemente e da cui faremo iniziare la nostra routine
|
FIG 13 - OllyDbg JMP |
- Dopo l’inserimento dell’istruzione JMP notiamo che anche le righe immediatamente successive sono modificate. Adesso dobbiamo individuare l’intervallo di indirizzi che ci interessa codificare. La codifica dovrà partire dall'istruzione immediatamente successiva a quella di JMP da noi inserita, quindi si parte dall'indirizzo 00404C05. Scorriamo fino a raggiungere quasi la fine del file e notiamo che dall'indirizzo 0040A770 non ci sono più istruzioni. Quindi possiamo concludere che l’intervallo che ci interessa codificare/decodificare va dall'indirizzo 00404C05 al 0040A770
- Salviamo il file nel seguente modo: clicchiamo con il tasto destro del mouse in un qualsiasi punto del codice assembly, selezioniamo la voce copy to executable quindi selezioniamo all modification e successivamente copy all. Nella nuova finestra che appare clicchiamo nuovamente in un punto qualsiasi con il tasto destro del mouse e selezioniamo save file. Diamo il nome al file e procediamo con il salvataggio.
- Apriamo il file appena salvato in Ollydbg. Dovremmo già essere posizionati sull Entry point (00404C00 JMP 00412830). Premiamo il tasto F7 che ci porterà all'indirizzo 00412830 dove aggiungeremo la nostra routine XOR. A partire dall'indirizzo 00412830 dobbiamo inserire le istruzioni della nostra routine così come visto precedentemente con l’istruzione JMP 00412830. Di seguito riporto le istruzioni da inserire:
MOV EAX, 00404C05 # Memorizza l'indirizzo da cui iniziare la codifica/decodifica
XOR BYTE PTR DS:[EAX],0F # Esegue una XOR
INC EAX # incrementa EAX
CMP EAX, 0040A770 #verifica se abbiamo raggiunto la fine della parte da codificare..
JLE SHORT <XOR LOOP> #..altrimenti, salta nuovamente al comando xor
Al posto di <XOR LOOP> va messo l’indirizzo dell’istruzione XOR BYTE PTR DS:[EAX],0F, nel nostro caso tale indirizzo è 00412835
- Sempre proseguendo aggiungiamo anche le istruzioni che abbiamo copiato nel blocco note
PUSH EBP
MOV EBP,ESP
PUSH -1
Al posto dell’istruzione 00404C05 . 68 00B04000 PUSH nc.0040B000 utilizziamo la seguente
JMP 00404C05
Da notare che il salto viene fatto all’indirizzo 00404C05 che rappresenta l’indirizzo della istruzione PUSH originaria
- Salviamo il file come abbiamo fatto precedentemente ed eseguiamolo da Ollydbg. Otteniamo un errore di accesso: Access Violation when reading…
L’errore è dovuto al fatto che il file è stato codificato con la routine XOR quindi il programma sta cercando di eseguire un istruzione codificata che, ovviamente, non riconosce come valida. Adesso non ci resta che copiare le istruzioni codificate e salvarle come un file eseguibile, in questo modo alla successiva esecuzione la routine XOR provvederà a decodificarlo in memoria.
Selezioniamo le righe da 00404c05 - 0040A770 che rappresenta la parte di file codificata dalla routine XOR. Clicchiamo con il tasto destro sulle righe selezionate quindi scegliamo copy to executable e successivamente selection. Nella nuova schermata clicchiamo nuovamente con il tasto destro e selezioniamo Save file.
|
FIG 14 - OllyDbg copy to executable |
Abbiamo terminato. Adesso il file codificato è salvato sul disco. Al successivo avvio del file la routine XOR provvederà ad effettuare la decodifica in memoria.
Adesso non ci resta che verificare, tramite virustotal se il file modificato viene ancora riconosciuto dagli antivirus . Eseguiamo l’upload sul sito www.virustotal.com e procediamo con l’analisi. Il file viene ancora riconosciuto come pericoloso da molti antivirus. Ovviamente utilizzando un tipo di codifica semplice come quella XOR non potevamo aspettarci risultati miracolosi ma nulla ci vieta di sostituire la nostra routine con una più complessa ed efficace.
PE-Scrambler
PE-Scrambler è un tools creato da Nick Harbour che effettua lo scrambler e l’offuscamento del codice in un file binario (istruzioni e chiamate di funzioni). Il tool fu presentato al DEFCON del 2008. Il tool, seppur obsoleto, è ancora possibile trovarlo in rete facendo una ricerca con google
L’utilizzo è molto semplice. Da riga di comando basta digitare
pescrambler -i <INPUT.exe> -o <OUTPUT.exe>
Il punto debole dei compressori tipo UPX sta proprio nel loro modo di operare. Questi tool comprimono/criptano il codice binario ed aggiungono al file uno stub che permette, in fase di esecuzione, di procedere all’operazione inversa in memoria. Una volta eseguito il file, lo stub verrà eseguito prima di ogni altra istruzione e provvederà a decomprimere/decriptare le successive istruzioni in memoria. Gli antivirus che verificano i dati presenti in RAM, confrontandoli con il database delle impronte virali, riconoscono in questo modo il file sospetto bloccandolo.
PE-Scrambler funziona in modo leggermente diverso. Il tool, dopo aver effettuato il disassembler del file binario, effettua lo scrambler dei dati e delle istruzioni presenti. All'interno del file viene aggiunta una funzione di 65-byte che effettua da dispatcher per tutte le altre chiamate a funzione. Il tool, infatti, provvede ad individuare tutte le chiamate a funzione, interne ed esterne, e le dirotta al dispatcher che provvede a richiamarle correttamente utilizzando una tabella di lookup contenente l’indirizzo di ritorno e quello target.
Gli antivirus hanno preso le contromisure adeguate e utilizzando questo tool non si ottengono risultati apprezzabili.
NTFS Alternate Data Streams
Un altro metodo utilizzato per nascondere file sospetti dall’antivirus è quello di utilizzare NTFS Alternate Data Streams, ma nel nostro caso questa opzione è da scartare in quanto, per poter procedere alla creazione di un ADS, è necessario prima che il file binario sia presente sulla macchina target e per fare ciò è necessario aver già ingannato l’antivirus. Inoltre tale tecnica funzionerebbe solo su partizioni NTFS. Trasferendo il file su altri file system, ad es su file system FAT di una penna USB, l’ADS verrebbe perso.
Cygwin
Ricompilare il file con Cygwin è un’altra ipotesi da scartare in quanto in questo caso dovremmo distribuire l’eseguibile con la libreria cygwin.dll, una cosa non molto conveniente.
Conclusioni
Come si può immaginare l’argomento è molto vasto e in continua evoluzione e trattarlo nella sua interezza richiede molto spazio e tempo. Con questo articolo ho trattato una minima parte dell'argomento utilizzando anche tool non più utilizzati ma spero di aver suscitato la curiosità di qualche lettore ad un approfondimento. Ritornerò comunque sull'argomento.