Shellcode: differenze tra le versioni

Versione delle 16:13, 18 lug 2021

Versione attuale delle 18:41, 30 lug 2025

(4 versioni intermedie di 4 utenti non mostrate)

Riga 13:

Lo shellcode remoto è invece utilizzato quando un attaccante vuole sfruttare una vulnerabilità di un processo di un'altra macchina sulla rete locale o su una rete intranet. Se lo Shellcode è eseguito correttamente, questo ritorna il controllo della macchina bersaglio attraverso la rete. Gli shellcode remoti utilizzano normalmente lo standard socket [[TCP/IP]] per consentire l'accesso alla shell della macchina bersaglio.

Si possono classificare ulteriori distinzioni in base al metodo con cui la connessione viene stabilita. Se è lo shellcode stesso che può stabilire la connessione, questo viene chiamato "reverse shell" o ''connect-back'' shellcode, perché lo shellcode in esecuzione sulla macchina remota si connette alla macchina dell'attaccante. Se invece l'attaccante ha bisogno di creare la connessione, lo shellcode viene chiamato ''bindshell'', in quanto lo shellcode esegue il bind su una determinata porta, che verrà utilizzata dall'attaccante per connettersi e controllare la macchina bersaglio. Un terzo tipo di shellcode, meno comune, è il ''socket-reuse'' shellcode. Questo tipo di shellcode è di solito utilizzato quando un exploit stabilisce una connessione al processo vulnerabile che non viene chiusa prima che lo shellcode venga eseguito.

Lo shellcode può riutilizzare questa connessione per comunicare con l'attaccante. Il Socket re-use shellcode è di più complessa realizzazione, perché lo shellcode deve identificare quale connessione può utilizzare (fra le possibili aperte sulla macchina).<ref>{{Cita web|url=http://www.blackhatlibrary.net/Shellcode/Socket-reuse

|titolo=Shellcode/Socket-reuse

|cognome=BHA |data=6 giugno 2013 |accesso=7 giugno 2013 }}</ref>

Si può utilizzare un [[firewall]] per identificare le connessioni in uscita effettuate da una connect-back shellcode e il tentativo di connessione in ingresso da parte di una bindshell.

Riga 22:

==== Download and execute ====

Download and execute è un tipo di shellcode remoto che effettua un [[download]] ed esegue una qualche forma di [[malware]] sul sistema bersaglio. Questo tipo di shellcode non crea una shell, ma istruisce la macchina di scaricare un certo [[file eseguibile]] dalla rete, salvarlo su disco e poi eseguirlo. Al giorno d'oggi, è comunemente utilizzato negli attacchi [[drive-by download]], quando una vittima visita un sito malevolo che cerca di avviare un download e di eseguire una shellcode per installare software sulla macchina vittima. Una variazione di questo tipo di shellcode è “download and loads a library”.<ref>{{Cita web |url=http://skypher.com/index.php/2010/01/11/download-and-loadlibrary-shellcode-released/ |titolo=Download and LoadLibrary shellcode released |cognome=SkyLined |data=11 gennaio 2010 |accesso=19 gennaio 2010 |urlmorto=sì |urlarchivio=https://web.archive.org/web/20100123014637/http://skypher.com/index.php/2010/01/11/download-and-loadlibrary-shellcode-released/ |dataarchivio=23 gennaio 2010 }}</ref><ref>{{Cita web|url=https://code.google.com/p/w32-dl-loadlib-shellcode/

|titolo=Download and LoadLibrary shellcode for x86 Windows

|cognome=SkyLined |data=11 gennaio 2010 |accesso=19 gennaio 2010 }}</ref> I vantaggi di questa tecnica è che il codice dello shellcode può essere più piccolo, non richiede la creazione di un nuovo processo sulla macchina bersaglio e che lo shellcode non ha bisogno di implementare il codice per la pulizia del processo bersagliato, ma questo può essere effettuato da una libreria caricata all'interno del processo.

Riga 54:

===== Percent encoding =====

Gli exploit che hanno come obiettivo i browser, codificano comunemente lo shellcode in una stringa [[JavaScript]] usando la notazione di [[percent-encoding]] o URL-encoding, tramite caratteri di escape “\uXXXX” o mediante [[entity]]. Alcuni exploit fanno un' ulteriore offuscamento dello shellcode codificato tramite stringhe per evitare di essere rilevati da strumenti di [[intrusion detection system|IDS]].

Per esempio, sul una architettura [[IA-32]], due istruzioni di <code>[[NOP (informatica)|NOP]]</code> (no-operation) prima di essere codificate hanno questa forma.

90 NOP

Riga 69:

==== Shellcode Null-Free ====

Molti shellcode vengono scritti senza utilizzare il bytes [[null]], perché sono progettati per essere inseriti nel processo bersaglio attraverso ununa stringa null-terminata. Quando una stringa null-terminata viene copiata, la copia includerà il primo [[carattere null]], ma i bytes successivi a questo non verranno processati. Quando lo shellcode che contiene il null viene inserito in questa maniera, verrà inserita solo una parte dello shellcode non rendendolo in grado di eseguire successivamente.

Per produrre uno shellcode libero da [[null]] partendo da uno che contiene dei bytes null, possono essere sostituite le istruzioni macchina che contengono gli zeri con istruzioni che producono lo stesso effetto ma che sono prive di bytes null. Per esempio su una architettura [[IA-32]] si potrebbe eseguire questa sostituzione:

B8 01000000 [[MOV (istruzione)|MOV]] EAX,1 // Imposta il registro EAX a 0x000000001

questa istruzione contiene zeri come parte del literal (1 viene espanso come 0x000000001) con queste istruzioni:

33C0 [[XOR (istruzione)|XOR]] EAX,EAX // Imposta il registro EAX a 0x000000000

Riga 78:

==== Shellcode alfanumerici e stampabili ====

In certe circostanze, un processo bersaglio potrebbe filtrare tutti i bytes provenienti dallo shellcode inserito che non sono stampabili o alfanumerici. In queste condizioni, il range di istruzioni che possono essere utilizzate per scrivere uno shellcode diventano molto limitate. Una soluzione a questo problema è stata pubblicata da Rix in [[Phrack]] 57<ref>{{Cita web|url=http://www.phrack.org/issues.html?issue=57&id=15#article |cognome=Rix

|titolo=Writing ia32 alphanumeric shellcodes

|editore=Phrack |data=8 novembre 2001 |accesso=29 febbraio 2008 }}</ref> dove viene mostrato come è possibile convertire ogni tipo di codice in uno alfanumerico. Una tecnica molto utilizzata è quella di creare codice automodificante, perché questo permette al codice di modificare i propri bytes per includerne altri che non rientrano fra quelli ammissibili e di espandere il range di istruzioni utilizzabili. Con questo tipo di trucco, un decoder auto-modificante può essere creato inizialmente utilizzando solamente bytes compresi nell'intervallo ammissibile. Quando lo shellcode in uscita va in esecuzione, il decoder può modificare il proprio codice per essere in grado di utilizzare ogni istruzione richiesta per consentirne il corretto funzionamento e contemporaneamente continuare a decodificare lo shellcode originale. Dopo avere fatto la decodifica, il decoder trasferisce il controllo allo shellcode, in modo tale che possa essere eseguito normalmente. È stato mostrato come è possibile creare shellcode di arbitraria complessità che somigliano a normale testo inglese.<ref>{{Cita web|url=http://www.cs.jhu.edu/~sam/ccs243-mason.pdf |cognome=Mason |nome=Joshua |autore2=Small, Sam |autore3=Monrose, Fabian |autore4= MacManus, Greg

|titolo=English Shellcode

|data=November 2009 |accesso=10 gennaio 2010 }}</ref>

==== Shellcode a prova di caratteri Unicode ====

Molti programmi moderni utilizzano la codifica di stringhe in formato Unicode per permettere l'internalizzazione del testo. Spesso questi programmi convertono le stringhe ASCII in ingresso prima di processarle. Le stringhe Unicode codificate in [[UTF-16]] utilizzano due byte per decodificare ogni carattere ( o quattro bytes per alcuni caratteri speciali). Quando una stringa [[ASCII]] viene convertita in UTF-16, un byte a zero viene inserito dopo ogni bytes della stringa originale. Obscu ha mostrato in [[Phrack]] 61<ref>{{Cita web|url=http://www.phrack.org/issues.html?issue=61&id=11#article |cognome=Obscou

|titolo=Building IA32 'Unicode-Proof' Shellcodes

|editore=Phrack |data=13 agosto 2003 |accesso=29 febbraio 2008 }}</ref> che è possibile scrivere shellcode che possono eseguire correttamente anche dopo questa trasformazione. Esistono programmi in grado di modificare automaticamente ogni shellcode in uno codificato mediante UTF-16 e sono basati sullo stesso principio di un decoder automodificante che decodifica lo shellcode originale.

=== Piattaforme ===

Molti shellcode sono scritti in codice macchina a causa del basso livello a cui la vulnerabilità diventa sfruttabile. Lo shellcode è spesso creato per attaccare una specifica combinazione di processore, sistema operativo e service pack, che vengono chiamati comunemente piattaforma. Per alcuni exploit, a causa dei vincoli imposti dal processo bersaglio, è necessario creare uno shellcode specifico. In ogni caso non è sempre possibile per uno shellocde lavorare per exploit multipli, service pack, sistemi operativi e eventualmente processori.<ref>{{Cita web|url=http://www.phrack.org/issues.html?issue=57&id=14#article |cognome=Eugene

|titolo=Architecture Spanning Shellcode

|editore=Phrack |data=11 agosto 2001 |accesso=29 febbraio 2008 }}</ref> Una versatilità può essere data dalla creazioni di differenti versioni dello shellcode, sulla base delle varie piattaforme da attaccare e creando un header che identifica la versione corretta per la piattaforma in uso. Quando viene eseguito, il codice si comporta differentemente in base alla piattaforma ed è in grado di eseguire la versione corretta dello shellcode.