Le applicazioni web che facilitano il caricamento di file sono diventate essenziali per numerose organizzazioni, in quanto fungono da portali per clienti, partner e dipendenti per condividere vari tipi di documenti e file. Per esempio, un'azienda che si occupa di risorse umane potrebbe consentire agli utenti di caricare i curriculum, oppure un'azienda potrebbe facilitare la condivisione di file da parte dei partner attraverso una piattaforma web specializzata.
Anche con misure di sicurezza migliorate e processi di convalida più rigorosi, gli aggressori continuano a sfruttare le vulnerabilità con metodi sofisticati. File apparentemente innocui, come le immagini, possono essere manipolati per compromettere la sicurezza di un server Web.
I file poliglotti sono file che possono essere validi come più tipi contemporaneamente, consentendo agli aggressori di aggirare le misure di sicurezza basate sul tipo di file. Ne sono un esempio GIFAR, che funziona sia come file GIF che come file RAR, i poliglotti JavaScript/JPEG che vengono interpretati sia come JavaScript che come JPEG e i file Phar-JPEG, riconosciuti sia come archivio Phar che come immagine JPEG. Questi file poliglotti possono passare inosservati grazie a estensioni ingannevoli o vuote che "ingannano" i sistemi facendogli credere di essere un tipo di file benigno (come un'immagine o un PDF) mentre contengono codice dannoso non rilevato.
Convalida del caricamento dei file
Consentire il caricamento di file da parte degli utenti senza una convalida adeguata o completa rappresenta una minaccia significativa per le applicazioni Web. Se un utente malintenzionato riesce a caricare un file dannoso, come una shell web, può potenzialmente ottenere il controllo del server, compromettendo il sistema e i dati sensibili. Per mitigare questi rischi, sono state stabilite delle best practice che guidano gli sviluppatori nell'applicazione di misure di validazione efficaci. Queste pratiche aiutano a garantire l'elaborazione sicura dei file caricati, riducendo così al minimo il rischio di sfruttamento.
Le principali aree di interesse per la sicurezza del caricamento dei file includono:
- Convalida delle estensioni: Implementare una blocklist o una allowlist di estensioni di file per garantire che vengano accettati solo i tipi di file consentiti.
- Sanitizzazione dei nomi dei file: Genera stringhe casuali per i nomi dei file al momento del caricamento.
- Convalida del tipo di contenuto: Verificare il tipo MIME del file caricato per assicurarsi che corrisponda al formato previsto.
- Convalida dell'intestazione delle immagini: Per il caricamento di immagini, si possono usare funzioni come getimagesize() in PHP per confermare la validità del file verificandone l'intestazione.
Bypass del filtro di caricamento dei file
Nonostante l'implementazione di queste misure di protezione, gli aggressori affinano continuamente i loro metodi per aggirare i meccanismi di validazione. Tecniche come l'iniezione di caratteri nulli, le doppie estensioni e le estensioni vuote possono compromettere la convalida delle estensioni: un file può apparire con un nome come "file.php.jpg", "file.php%00.jpg", "file.PhP" o "file.php/" per eludere il rilevamento. La convalida del tipo MIME può essere aggirata modificando i byte magici iniziali del file, ad esempio cambiandoli in GIF89a, l'intestazione associata ai file GIF, che può indurre il sistema a identificare il file come un formato legittimo. Inoltre, è possibile caricare un file .htaccess dannoso per manipolare le configurazioni del server, consentendo l'esecuzione di file con estensioni non autorizzate.
Attacchi ai file poliglotti
Anche con l'implementazione di processi di convalida rigorosi che combinano diverse misure di sicurezza per prevenire la tecnica di aggiramento del filtro di caricamento dei file, gli attacchi sofisticati che hanno come obiettivo i file poliglotti, o le immagini poliglotte, rimangono una minaccia significativa per la sicurezza. Questo metodo consente agli aggressori di creare file, come le immagini, che sono conformi alla struttura binaria prevista per i file immagine, ma che possono contemporaneamente eseguire codice dannoso se interpretati in un contesto diverso. La doppia natura di questi file consente di aggirare i meccanismi di convalida tradizionali e di sfruttare le vulnerabilità in scenari specifici.
Semplice file poliglotta con ExifTool
Una tecnica semplice per generare un'immagine poliglotta è utilizzare ExifTool. Questa potente applicazione è progettata per leggere, scrivere e modificare vari formati di metadati, come EXIF, XMP, JFIF e Photoshop IRB. Tuttavia, i malintenzionati possono sfruttare ExifTool per eseguire azioni dannose, tra cui la creazione di un'immagine poliglotta con intento malevolo. Utilizzando ExifTool per inserire codice dannoso nei metadati EXIF di un'immagine, in particolare in campi come UserComment e ImageDescription, gli aggressori possono generare un'immagine poliglotta e aumentare le possibilità di sfruttamento.
Di seguito vengono presentati i metadati EXIF dell'immagine, che forniscono informazioni complete su di essa.
Utilizzando ExifTool, un attore malintenzionato può inserire codice dannoso all'interno dei metadati EXIF di un'immagine, creando così un file poliglotta che può eludere i meccanismi di convalida.
Sebbene la convalida del tipo MIME possa limitare il caricamento di file di shell web di base, questa immagine poliglotta può aggirare tali restrizioni, consentendo a un utente malintenzionato di caricare una shell web poliglotta.
L'attaccante può quindi sfruttare la shell web poliglotta per prendere il controllo del server web.
File Javascript/JPEG poliglotta
Un file JavaScript/JPEG poliglotta è strutturato in modo da essere valido sia come immagine JPEG che come script JavaScript. Per ottenere questo risultato, un attore malintenzionato deve avere una comprensione completa della struttura interna di un file JPEG. Questa conoscenza consente di incorporare con precisione i dati binari dannosi all'interno dell'immagine, assicurando che possa essere elaborata da un motore JavaScript senza comprometterne la validità come immagine JPEG.
Un'immagine JPEG ha la seguente struttura:
| Byte | Nome |
| 0xFF, 0xD8 | Inizio dell'immagine |
| 0xFF, 0xE0, 0x00, 0x10, ... | Intestazione predefinita |
| 0XFF, 0XFE, ... | Commento all'immagine |
| 0xFF, 0xDB, ... | Tabella di quantizzazione |
| 0xFF, 0xC0, ... | Inizio del fotogramma |
| 0xFF, 0xC4, ... | Tabella Huffman |
| 0xFF, 0xDA, ... | Inizio della scansione |
| 0xFF, 0xD9 | Fine dell'immagine |
Formato JPEG - fonte: https://github.com/corkami/formats/blob/master/image/JPEGRGB_dissected.png
Nella struttura di un'immagine JPEG, l'intestazione è seguita dalle informazioni sulla lunghezza. Come mostrato nell'esempio precedente, l'intestazione inizia con la sequenza 0xFF 0xE0 0x00 0x10, dove 0x00 0x10 rappresenta specificamente la lunghezza del segmento, che indica 16 byte. Il marcatore 0xFF 0xD9 segna la fine dell'immagine.
Per creare un file JavaScript/JPEG poliglotta, è necessario modificare i valori esadecimali dell'immagine per garantire che il motore JavaScript possa riconoscerli ed elaborarli.
Innanzitutto, in JavaScript, la sequenza 0xFF 0xD8 0xFF 0xE0 può essere interpretata come valori non-ASCII, ma 0x00 0x10 non è valida e deve essere modificata. La sostituzione adatta per questi valori esadecimali è 0x2F 0x2A, che è la rappresentazione esadecimale di /*, una sintassi usata per aprire un commento in JavaScript. Questa sostituzione consente di ignorare i dati binari rimanenti come parte del commento.
Tuttavia, poiché 0x00 0x10 rappresenta originariamente la lunghezza dell'intestazione JPEG, modificarla in 0x2F 0x2A, che in decimale equivale a 12074, richiede una ridefinizione dell'intestazione JPEG per mantenerne la validità. A tal fine, è necessario aggiungere dei byte nulli e posizionare il payload JavaScript dopo il marcatore 0xFF 0xFE, che indica un commento all'immagine nella struttura JPEG.
Ad esempio, se il payload è */=alert(document.domain);/*, che è lungo 28 byte, i byte nulli necessari saranno calcolati come segue: 12074 (nuova lunghezza) - 16 (lunghezza dell'intestazione originale) - 2 (per il marcatore 0xFF 0xFE ) - 28 (lunghezza del payload) = 12.028 byte nulli.
Di conseguenza, il codice JavaScript all'interno dell'immagine JPEG assomiglierebbe al seguente:
Infine, la sequenza 0x2A 0x2F 0x2F 0x2F (corrispondente a *///) deve essere collocata subito prima del marcatore di fine JPEG 0xFF 0xD9. Questo passaggio chiude il commento JavaScript e assicura che il payload venga eseguito correttamente senza interrompere la struttura del file JPEG.
Dopo questa modifica, l'immagine può ancora essere interpretata come un'immagine valida e contemporaneamente contenere codice JavaScript eseguibile.
Quando un file HTML carica questa immagine come codice sorgente JavaScript, rimane valido e può eseguire il codice JavaScript incorporato:
I file immagine poliglotti presentano rischi non solo per lo sfruttamento lato client, ma anche per gli attacchi lato server in particolari circostanze. Un esempio è il file poliglotta Phar/JPEG, che può essere interpretato sia come archivio PHP (Phar) sia come immagine JPEG. La struttura del file Phar consente di incorporare i dati serializzati nei metadati, il che rappresenta un rischio potenziale per le vulnerabilità di deserializzazione, soprattutto in alcune versioni di PHP. Di conseguenza, i file poliglotti Phar/JPEG possono essere sfruttati per aggirare la convalida del caricamento dei file e sfruttare i server vulnerabili.
Il formato dei file Phar è strutturato come stub/manifesto/contenuti/firma e memorizza le informazioni cruciali di ciò che è incluso nell'archivio Phar nel suo manifest:
- Stub: Lo stub è un pezzo di codice PHP che viene eseguito quando si accede al file in un contesto eseguibile. Non ci sono restrizioni sul contenuto dello stub, tranne il requisito che si concluda con __HALT_COMPILER();.
- Manifesto: Questa sezione contiene metadati sull'archivio e sul suo contenuto, che possono includere metadati Phar serializzati e memorizzati nel formato serialize().
- Contenuto del file: I file originali inclusi nell'archivio.
- Firma (opzionale): Contiene informazioni sulla firma per la verifica dell'integrità.
Poiché lo stub non impone alcuna restrizione di contenuto oltre a quanto stabilito da __HALT_COMPILER(), un attore pericoloso può iniettare i valori esadecimali di un'immagine nello stub. Inserendo questi valori all'inizio del file PHAR, questo può essere identificato come un'immagine valida. Di conseguenza, un poliglotta PHAR/JPEG può essere facilmente costruito aggiungendo i byte esadecimali di un'immagine JPEG all'inizio, come dimostrato nell'esempio seguente:
Con questo metodo, il file poliglotta generato funziona sia come un'immagine valida che come un file PHAR legittimo e può quindi essere utilizzato per aggirare alcuni meccanismi di convalida del caricamento dei file.
Sebbene questo file poliglotta sia in grado di aggirare i filtri di caricamento dei file, non è attualmente in grado di sfruttare il server Web. Per sfruttare e compromettere con successo un server Web utilizzando un file PHAR o un file poliglotta PHAR, è essenziale iniettare metadati serializzati dannosi nel manifest del file.
Quando si accede al file PHAR attraverso il wrapper PHAR (phar://) in alcune funzioni PHP (PHP ≤7.x) associate a operazioni sui file - come file(), file_exists(), file_get_contents(), fopen(), rename() o unlink() - viene attivata la funzione unserialize() per i metadati serializzati. In definitiva, utilizzando PHPGGC, uno strumento ampiamente utilizzato per costruire catene di gadget PHP, gli attori delle minacce possono sfruttare la vulnerabilità di deserializzazione tramite un file poliglotta PHAR, compromettendo così il server dell'applicazione web.
La combinazione di file poliglotti PHAR/JPEG e di vulnerabilità di deserializzazione consente agli aggressori di infiltrarsi in un server di applicazioni Web, anche quando sono implementati filtri per il caricamento dei file. In particolare, questa compromissione può verificarsi anche durante l'elaborazione di un file di immagine.
Sfruttando i file poliglotti per aggirare i filtri di caricamento dei file e aggiungendo il wrapper PHAR (phar://) al percorso del file, gli aggressori possono manipolare il server Web in modo che tratti il file come un archivio PHAR. Questa manipolazione può successivamente innescare una vulnerabilità di deserializzazione, che porta all'esecuzione di codice remoto attraverso le funzioni di funzionamento dei file.
Per illustrare i rischi associati ai file poliglotti nell'applicazione, abbiamo simulato un ambiente in cui l'applicazione impiega filtri rigorosi per il caricamento dei file per impedire il caricamento di file dannosi o shell web. Nonostante queste salvaguardie, un'immagine poliglotta può aggirare il processo di convalida e, in certi contesti, può portare all'esecuzione di codice remoto, compromettendo in ultima analisi il server dell'applicazione web vulnerabile.
Questo esempio illustra un'applicazione web convenzionale che consente la condivisione di file tra clienti, partner e organizzazioni:
MetaDefender Core e MetaDefender ICAP Server protegge le applicazioni web da queste minacce e migliora la sicurezza della rete e dell'infrastruttura.
MetaDefender ICAP Server e MetaDefender Core lavorano insieme per proteggere il server web da attacchi sofisticati che coinvolgono file poliglotti PHAR/JPEG dannosi nei seguenti modi:
Quando un file PHAR/JPEG poliglotta viene caricato nell'applicazione web, viene prima inoltrato a MetaDefender Core attraverso MetaDefender ICAP Server per un processo di sanificazione completo che utilizza la nostra tecnologia Deep CDR ™. A differenza dei semplici controllori di tipo di file, Deep CDR analizza a fondo la struttura del file caricato, rimuovendo script, macro e contenuti fuori policy, ricostruendo il file JPEG per includere solo i dati necessari.
Questo processo rimuove il contenuto PHAR dannoso aggiunto dopo il marcatore di fine JPEG(0xFF 0xD9), garantendo che il file sanificato sia rigorosamente un JPEG. Di conseguenza, l'applicazione Web è protetta dagli attacchi poliglotti PHAR/JPEG; anche se un aggressore riesce ad alterare lo schema di elaborazione dei file per iniettare un wrapper PHAR, non può sfruttare il server Web.
Le organizzazioni che dispongono di un'infrastruttura di sicurezza di rete consolidata, sia che utilizzino WAF (web application firewall), proxy o ingress controller, possono ora migliorare i propri meccanismi di difesa attraverso MetaDefender ICAP Server .Questa soluzione crea un'interfaccia tra i server Web esistenti e MetaDefender Core , stabilendo un checkpoint di sicurezza trasparente per tutti i file in entrata. Qualsiasi contenuto instradato attraverso l'interfaccia ICAP verrà scansionato ed elaborato prima di raggiungere il vostro server web, garantendo che solo i contenuti sicuri e legittimi entrino nella vostra rete e raggiungano gli utenti finali.
Questo approccio consente alle organizzazioni di sfruttare gli investimenti esistenti in materia di sicurezza, aggiungendo un ulteriore e potente livello di protezione. Le organizzazioni che utilizzano il controller di ingresso NGINX possono integrare MetaDefender ICAP Server con l'infrastruttura esistente tramite la configurazione del proxy.
OPSWATva oltre il tradizionale rilevamento delle minacce. Invece di limitarsi a segnalare i file sospetti, MetaDefender Core neutralizza attivamente le potenziali minacce, trasformando i file pericolosi in contenuti sicuri e utilizzabili. Se integrato con il vostro server web, MetaDefender ICAP Server fornisce una protezione completa contro le minacce zero-day e gli attacchi poliglotti.
Con il motto "Non fidatevi di nessun file. Trust no device. ™", OPSWAT risolve le sfide dei clienti in tutto il mondo con tecnologie brevettate a ogni livello dell'infrastruttura, proteggendo reti, dati e dispositivi e prevenendo minacce note e sconosciute, attacchi zero-day e malware.
