Con il termine ZipBomb si indica una particolare tipologia di attacco identificata per la prima volta nel 2001 e che può essere annoverata nella famiglia degli attacchi di tipo DoS (Denial of Service), ovvero volti a rendere un determinato servizio o sistema indisponibile per un certo periodo di tempo.
Lo ZipBomb è stato soprannominato anche Zip of Death, richiamando così il più famoso Ping of Death, vale a dire un attacco DoS in cui un pacchetto IP di dimensioni maggiori del consentito (secondo la norma RFC 791) causava nel sistema vittima un probabile crash dovuto a sovrascrittura della memoria. Lo ZipBomb intende emulare questo comportamento e causare un effetto simile tramite un apparentemente innocuo file “.zip”.
Indice degli argomenti
Attacco ZipBomb: ecco come funziona
La particolarità dell’attacco ZipBomb consiste nel fatto che quando si tenta di aprire il file compresso malevolo dalle dimensioni di pochi kilobytes, l’operazione di decompressione causa l’estrazione di file delle dimensioni totali anche di qualche petabyte!
Possiamo quindi a ragione nominare questo attacco in italiano come “bomba a decompressione”. Il nome, però, non deve ingannare: l’apertura dello ZIP non causa “l’esplosione” del file stesso, ma semplicemente crea una lista di file .zip ognuno dei quali a sua volta contiene a cascata una seconda lista di file .zip, poi una terza lista e così via fino all’estrazione di un ultimo file (ad esempio un file .txt oppure .dll) delle dimensioni di qualche gigabyte.
Questa sorta di estrazione multipla di un gran numero di file compressi può avere tre differenti conseguenze:
- l’antivirus si blocca nel tentativo di aprire di continuo tutti i file compressi, magari ricevuti come allegato in qualche e-mail malevola, alla ricerca di qualche inesistente virus. In questo modo, il sistema diventa automaticamente vulnerabile ad altri attacchi: ad esempio, un malware potrebbe approfittare dell’assenza momentanea di controllo per iniziare ad operare indisturbato;
- il sistema va in crash a causa della completa saturazione della memoria (Denial of Service);
- lo spazio disponibile sull’hard disk di sistema viene velocemente saturato con qualche Petabyte di file nel caso in cui tutti i file compressi venissero aperti in sequenza in modo automatico.
Realizzazione di un file ZipBomb
Vediamo ora nel dettaglio come si costruisce un file ZipBomb.
Creiamo innanzitutto un file di testo con una sequenza casuale di caratteri qualsiasi, ad esempio composta da 10 lettere, e supponiamo per semplicità che la sua dimensione risultante sia di 10 byte.
Duplichiamo questo file 10 volte, poi li uniamo tutti in un unico file binario (ad esempio tramite il comando nella finestra terminale di Windows: copy /a *.txt a.txt), che avrà dimensione di 100 byte.
Duplichiamo quindi ancora per 10 volte il file da 100 byte, così creiamo un file da 1000 byte (sempre con un comando del tipo copy di prima), di nuovo uniamoli insieme in un unico file e poi comprimiamo il tutto.
Dopo questi due passaggi abbiamo un file compresso che avrà una dimensione di circa 100 bytes, molto meno dei 1000 bytes di partenza! Ripetiamo la sequenza altre 5 volte almeno. Noteremo che ogni volta il file compresso ha dimensioni minori rispetto al file costruito con l’unione di file testo di partenza. Il rapporto tra di essi può arrivare dopo pochi passaggi già ad un fattore 1000.
Se ora invece di duplicare l’ultimo file binario in formato .txt si duplica il suo equivalente compresso .zip e poi si comprimono tutti i file compressi così prodotti, allora il file che si ottiene scende a pochi KB di dimensione, sfruttando un rapporto di compressione molto vantaggioso. Alla fine, però, il contenuto può arrivare a svariati petabyte.
Per realizzare questa compressione così “spinta” è possibile utilizzare diversi algoritmi, ma il più usato è sicuramente quello denominato DEFLATE descritto dalla raccomandazione IETF (Internet Engineering Task Force) RFC 1951 e disponibile sia in librerie che in tools di compressione per vari linguaggi di programmazione.
Un famoso esempio di file ZipBomb
Uno dei file più famosi, ancora oggi reperibile in rete, si chiama 42.zip. Il suo nome è dovuto alla sua dimensione che è, per l’appunto, di soli 42 KB. Anche in questo caso, però, non bisogna farsi trarre in inganno: infatti al suo interno contiene 16 file compressi così organizzati:
- ogni file compresso contiene 16 file compressi;
- questi file compressi ne contengono a loro volta altri 16;
- ciascuno di questi secondi file compressi ne contiene altri 16;
- ognuno di questi ultimi file compressi ne contiene altri 16, ognuno dei quali contiene 1 solo file di 4,3 gigabyte.
Ecco la composizione di un fileZipBomb come mostrato nell’esempio dell’articolo. Per motivi di visualizzazione, la composizione è semplificata ai primi 12 file.
A questo punto, il calcolo è facile: decomprimendo il file 42.zip, si otterranno più di un milione di file ognuno da 4,3 GB per un totale di 4,5 petabyte.
Se viene eseguito un tentativo di decomprimere completamente questo archivio, il risultato è facilmente immaginabile. Ci rincuora sapere che oggi tutti i vari sistemi di protezione sono aggiornati e non consentono di non aprire questo tipo di file in modo ricorsivo.
Ciononostante, si possono costruire script che eseguono questa operazione, quindi bisogna sempre fare attenzione quando si ricevono file .zip ed analizzarne il contenuto prima di aprirli.
Utilizzi etici dei file ZipBomb e nuove ricerche
L’utilizzo dei file ZipBomb non è necessariamente malevolo, ma può avere risvolti utili anche nel campo della sicurezza informatica. La ricerca sui file ZipBomb, infatti, può comportare interessanti scoperte innovative nel mondo degli algoritmi di compressione.
Analizziamoli nel dettaglio.
Ethical hacking con i file ZipBomb
La nota organizzazione OWASP (Open Web Application Security Project) ha creato un progetto molto noto in campo Web Application, che rappresenta uno standard da seguire per rendere sicure le proprie applicazioni e il proprio sito web.
È di fatto una guida di testing per sottoporre a controlli di sicurezza il software. In uno di questi test (OTG-BUSLOGIC-009), che riguarda il controllo sulla possibilità di simulare il caricamento di file malevoli su un sito Web, si cita proprio lo ZipBomb, così come si fa riferimento ad altri tipi di malware.
Questo dimostra ancora oggi l’importanza, per chi lavora come ethical hacker, dell’utilizzo di questo tipo di file.
File ZipBomb come strumento anti-scansione
Come sappiamo, i siti Web vengono continuamente scansionati da programmi automatici alla ricerca di vulnerabilità note. Per bloccare questi programmi, un ricercatore ha avuto l’idea di inserire, all’interno dei siti, un file ZipBomb.
Posizionando in maniera strategica l’archivio e utilizzando uno script PHP, la maggior parte degli strumenti di scansione andrebbero in crash o si bloccherebbero in una fase di caricamento infinita. Quanto basta per scoraggiare ulteriori azioni malevole.
Un esercizio interessante, questo, dal punto di vista delle ricerca in questo campo e forse utilizzabile anche nei cosiddetti honeypot, ma circa l’eticità e liceità di questa soluzione lasciamo al lettore le debite considerazioni.
Nuovi tipi di file ZipBomb
Un ricercatore ha dimostrato all’inizio dello scorso mese di luglio 2019 un nuovo metodo “ZipBomb” che può racchiudere 4,5 petabyte a partire da un archivio da 46 MB.
La differenza è che il file 42.zip e le sue varianti simili si basano sulla decompressione ricorsiva. Invece di aprire semplicemente una quantità innumerevole di file “decomprimendo” un singolo archivio, vengono costruiti fino a sei livelli di file “.zip” all’interno di un unico file “.zip”.
Il nuovo metodo non si basa su tale ricorsione, il che potrebbe consentire di eludere i programmi in grado di rilevare gli ZipBomb tradizionali. Il motivo per cui i file ZipBomb usavano la ricorsione è dovuto al fatto che l’algoritmo utilizzato nei software di gestione degli archivi compressi non può superare un certo limite nel rapporto di compressione, da cui la necessità appunto della ricorsione.
Ora sembra sia stato possibile aggirare questa limitazione, cioè sembra funzionare sovrapponendo i file all’interno del contenitore ZIP, per fare riferimento a un “kernel” di dati altamente compressi in più file, senza doverne fare più copie.
Le dimensioni dell’output della “bomba a ZIP” crescono quadraticamente rispetto alla dimensione dell’input; vale a dire, il rapporto di compressione migliora quando la bomba diventa più grande. La soluzione dipende ovviamente dalla scelta dell’algoritmo di compressione: in questo caso è stato utilizzato lo zip64.
Vulnerabilità ad attacchi tramite ZipBomb
Nel database NIST (National Institute of Standards and Technology) è possibile recuperare informazioni su vulnerabilità note, ufficialmente classificate e dovute alla possibilità di essere causate da ZipBomb.
Solo per fare qualche esempio, riportiamo di seguito alcune vulnerabilità CVE (Common Vulnerability Enumeration) catalogate dal 2017 ad oggi, quindi tutte molto recenti, nonostante siano ormai passati quasi 20 anni dalla prima scoperta dei file ZipBomb:
- CVE-2017-6153: Features in F5 BIG-IP 13.0.0-13.1.0.3, 12.1.0-12.1.3.1, 11.6.1-11.6.3.1, 11.5.1-11.5.5, or 11.2.1 system that utilizes inflate functionality directly, via an iRule, or via the inflate code from PEM module are subjected to a service disruption via a “Zip Bomb” attack.
- CVE-2017-16129: The HTTP client module superagent is vulnerable to ZIP bomb attacks. In a ZIP bomb attack, the HTTP server replies with a compressed response that becomes several magnitudes larger once uncompressed. If a client does not take special care when processing such responses, it may result in excessive CPU and/or memory consumption. An attacker might exploit such a weakness for a DoS attack. To exploit this the attacker must control the location (URL) that superagent makes a request to.
- CVE-2018-16131: The decodeRequest and decodeRequestWith directives in Lightbend Akka HTTP 10.1.x through 10.1.4 and 10.0.x through 10.0.13 allow remote attackers to cause a denial of service (memory consumption and daemon crash) via a ZIP bomb.
- CVE-2019-13232: Info-ZIP UnZip 6.0 mishandles the overlapping of files inside a ZIP container, leading to denial of service (resource consumption), aka a “better zip bomb” issue.
Un’ulteriore vulnerabilità di una libreria Python (classificata come CVE-2019) sembra essere in fase di ufficializzazione.
Conclusioni
Oggi lo ZipBomb classico non causa più effetti devastanti sui sistemi, non viene più aperto normalmente in modo ricorsivo senza controllo, ma di fatto un file di questo tipo mantiene la sua pericolosità e caricarlo o lasciarlo all’interno di un sistema non è certo consigliabile.
La ricerca in questo campo progredisce, le vulnerabilità catalogate sono costantemente aggiornate a riprova che anche un attacco di questo tipo non è da sottovalutare o relegare negli annali di Internet come puro elemento storico.
