Un file Zip compresso con una doppia password? Si, è possibile!

Gli archivi ZIP protetti da password sono mezzi comuni per comprimere e condividere set di file, da documenti sensibili a campioni di malware fino a file anche dannosi (ad es. “fatture” di phishing nelle e-mail).

Ma sapevi che è possibile che un file ZIP crittografato abbia due password corrette, con entrambe che producono lo stesso risultato quando viene estratto il file ZIP?

Arseniy Sharoglazov, un ricercatore di sicurezza informatica presso Positive Technologies, ha condiviso durante il fine settimana un semplice esperimento in cui ha prodotto un file ZIP protetto da password chiamato x.zip.

La password scelta da Sharoglazov per crittografare il suo ZIP era un gioco di parole sul successo del 1987  che è diventato un popolare meme tecnologico:

Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You

Ma il ricercatore ha dimostrato che durante l’estrazione di x.zip  utilizzando una password completamente diversa, non ha ricevuto messaggi di errore.

Infatti, l’utilizzo della password diversa ha comportato la corretta estrazione del file ZIP, con il contenuto originale intatto.

La rivista BleepingComputer ha cercato di riprodurre l’esperimento utilizzando  diversi programmi ZIP come p7zip (equivalente a 7-Zip per macOS) e Keka .

Come l’archivio ZIP del ricercatore, il file è stato creato con la medesima password e con la modalità di crittografia AES-256 abilitata.

Mentre lo ZIP è stato crittografato con la password più lunga, utilizzando una delle due password è stato estratto l’archivio con successo.

La password in questione è la seguente:

pkH8a0AqNbHcdw8GrmSp

Quando si producono archivi ZIP protetti da password con la modalità AES-256 abilitata, il formato ZIP utilizza l’ algoritmo  PBKDF2 e esegue l’hashing della password fornita dall’utente, se la password è troppo lunga. Per troppo lunga si intende più di 64 byte, spiega il ricercatore.

Invece della password scelta dall’utente (in questo caso ” Nev1r-G0nna-G2ve-…” ) questo hash appena calcolato diventa la password effettiva del file.

Quando l’utente tenta di estrarre il file e inserisce una password più lunga di 64 byte (” Nev1r-G0nna-G2ve-…  “), l’input dell’utente verrà nuovamente sottoposto a hash dall’applicazione ZIP e confrontato con quello corretto password (che ora è esso stesso un hash). Una corrispondenza porterebbe a un’estrazione di file riuscita.

La password alternativa utilizzata in questo esempio (” pkH8a0AqNbHcdw8GrmSp “) è in effetti una rappresentazione ASCII dell’hash SHA-1 della password più lunga .

Checksum SHA-1 di “Nev1r-G0nna-G2ve-…” = 706b4838613041714e624863647773847726d5370.

Questo checksum quando convertito in ASCII produce: pkH8a0AqNbHcdw8GrmSp

Si noti, tuttavia, che durante la crittografia o la decrittografia di un file, il processo di hashing si verifica solo se la lunghezza della password è maggiore di 64 caratteri.

In altre parole, le password più brevi non verranno sottoposte a hash in nessuna fase di compressione o decompressione dello ZIP.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

Pietro Melillo

Membro e Riferimento del gruppo di Red Hot Cyber Dark Lab, è un ingegnere Informatico specializzato in Cyber Security con una profonda passione per l’Hacking e la tecnologia, attualmente CISO di WURTH Italia, è stato responsabile dei servizi di Cyber Threat Intelligence & Dark Web analysis in IBM, svolge attività di ricerca e docenza su tematiche di Cyber Threat Intelligence presso l’Università del Sannio, come Ph.D, autore di paper scientifici e sviluppo di strumenti a supporto delle attività di cybersecurity. Dirige il Team di CTI "RHC DarkLab"

Aree di competenza: Cyber Threat Intelligence, Ransomware, Sicurezza nazionale, Formazione