Password cracking con John The Ripper: come funziona

John The Ripper scopre le password partendo dagli hash: due indicazioni per utilizzare il programma in Windows con WSL.

Quante volte ci siamo soffermati sull’importanza di creare password sicure e utilizzare algoritmi di hashing sufficientemente forti, non certo l’ormai obsoleto MD5.
Gli algoritmi di hashing sono funzioni crittografiche progettate per funzionare in un’unica direzione: quando si crea l’hash di una password non deve essere possibile risalire alla password originale.

È importante che anche i gestori di siti Web salvino le password utilizzando funzioni di hashing sicure: ne parliamo nell’articolo in cui spieghiamo come i siti online conservano le password, talvolta in modo non sicuro.

Essenziale è evitare algoritmi di hashing vulnerabili (già nel 2009 parlavamo delle vulnerabilità di MD5); nel 2017 Google ha dimostrato una collisione nell’algoritmo SHA-1 mentre SHA-256 resta oggi il punto di riferimento.

John The Ripper è un software libero che semplifica le attività di cracking delle password: partendo dagli hash è possibile provare a risalire alle password in chiaro. Utilizzare John The Ripper aiuta a capire ancor meglio perché le password devono essere lunghe e complesse nonché salvate con un algoritmo di hashing sicuro.

Una caratteristica interessante di John The Ripper è che il software può rilevare automaticamente l’algoritmo crittografico utilizzato per generare gli hash di ciascuna password.
La stessa utilità è in grado di tentare il password cracking usando un “dizionario” di parole utilizzate comunemente dagli utenti per proteggere i loro account. Conoscendo gli hash di ciascun elemento del dizionario, John The Ripper può risalire alle password originali anche per quegli algoritmi di hashing che non soffrono di alcuna vulnerabilità. Un dizionario molto usato è rockyou.txt: contiene più di 14 milioni di possibili password di uso più o meno comune.

Come usare John The Ripper in Windows con WSL e Kali Linux

Per provare subito John The Ripper in Windows 10 e Windows 11 basta digitare cmd nella casella di ricerca del sistema operativo, selezionare Esegui come amministratore quindi impartire il comando seguente:

wsl --install -d kali-linux

In questo modo viene attivata la possibilità di eseguire Linux in Windows all’interno di una finestra WSL (Windows Subsystem for Linux).

Dopo aver creato un account utente all’interno della distribuzione Kali Linux, si può impartire il comando seguente per aggiornare tutti i software della distribuzione:

sudo apt update && sudo apt upgrade -y

A questo punto è possibile scaricare e installare John The Ripper con il seguente comando:

sudo apt install john -y

Nella cartella home dell’utente si può scaricare il dizionario rockyou.txt.

Scrivendo il comando che segue, è possibile ottenere l’elenco degli algoritmi di hashing che John The Ripper è in grado di riconoscere e gestire:

john --list=formats

Le possibili modalità d’uso di John The Ripper sono quattro:

Single Crack Mode (Modalità a singolo crack)
In modalità single crack John The Ripper prende in considerazione una stringa e genera variazioni di quella stringa per ottenere un insieme di password.
In questa modalità si può digitare semplicemente quanto segue:

john --single hash.txt

In alternativa, si può anche specificare il formato dell’hash delle password, qualora lo si conoscesse:

john --single --format=raw-sha1 hash.txt

Il file hash.txt, ovviamente, contiene gli hash delle password che si desiderano riportare in chiaro.

Usando ad esempio la sintassi john --format=lm hash.txt è possibile risalire alle password degli account Windows memorizzate nel registro di sistema nel formato LM/NTLM (database SAM, Security Account Manager).

Word List Mode (Modalità dizionario)
In questa modalità John The Ripper prova tutti gli hash corrispondenti alle password già note inserite in un dizionario, salvato in locale come file di testo:

john --wordlist=rockyou.txt --format=raw-sha1 hash.txt

Si noti il riferimento al già citato dizionario rockyou.txt. Nell’esempio gli hash vengono indicati come di tipo SHA-1.

Incremental Mode (Modalità incrementale)
La modalità incrementale è la modalità più potente offerta da John The Ripper: quanto attivata, infatti, essa prova tutte le possibili combinazioni di caratteri per cercare di risalire alla password in chiaro.
Il cracking delle password può ovviamente richiedere molto tempo se la password è lunga o presenta una combinazione di caratteri alfanumerici e simboli. La sintassi da usare, in questo caso, è la seguente:

john --incremental hash.txt

External Mode (Modalità esterna)
In questo caso John The Ripper utilizza “funzioni personalizzate” sviluppate dall’utente stesso che permettono di rendere più specifica la ricerca della password corretta a partire dal suo valore hash.

Interessante è il tool zip2john che permette di estrarre l’hash delle password utilizzate a protezione di archivi compressi Zip e RAR.
Per utilizzarlo, ci si può servire della sintassi seguente:

zip2john file.zip > hash.txt

Dopo aver estrapolato l’hash, è possibile utilizzare le varie modalità descritte poco sopra per provare a risalire alla password utilizzata a protezione del file compresso.

Ti consigliamo anche

WebKit espone IP e DNS anche con proxy e iCloud Private Relay

Alcune funzioni di WebKit possono aggirare il proxy del browser e iCloud Private Relay, esponendo l'indirizzo IP pubblico o informazioni sul resolver DNS usato da iPhone, iPad e Mac.

Safari e gran parte dei browser disponibili su iPhone e iPad affidano il caricamento delle pagine a WebKit, il motore di rendering sviluppato da Apple. È il componente che interpreta HTML, CSS e JavaScript, gestisce molte comunicazioni di rete e permette anche alle applicazioni di mostrare contenuti web attraverso le viste integrate nel sistema operativo.

Una ricerca elaborata da Talal Haj Bakry e Tommy Mysk mostra però che non tutte le richieste generate da WebKit seguono necessariamente il percorso di rete scelto dal browser. Alcune funzioni possono ignorare il proxy configurato dall’applicazione e collegarsi direttamente a Internet, rivelando il vero indirizzo IP pubblico dell’utente oppure informazioni sul resolver DNS utilizzato.

Il comportamento riguarda anche Safari quando la navigazione risulta protetta da iCloud Private Relay, il servizio incluso in iCloud+ che nasconde l’indirizzo IP durante il normale accesso ai siti. La pagina può apparire correttamente instradata attraverso i relay di Apple, mentre una richiesta secondaria parte dalla connessione reale del dispositivo.

Perché un proxy configurato in WebKit non protegge ogni connessione

I ricercatori hanno individuato tre percorsi distinti: il precaricamento dei nomi DNS, una verifica utilizzata dalle passkey sui domini correlati e le connessioni WebTransport basate su QUIC. Non si tratta di tre varianti dello stesso attacco, ma di funzioni differenti che condividono un problema di fondo: usano componenti di rete che non ereditano sempre le impostazioni applicate alla normale sessione del browser.

In pratica, il caricamento principale della pagina continua a passare attraverso il proxy o Private Relay; alcune operazioni collaterali possono invece aggirare la protezione. Un normale sito di controllo dell’IP pubblico potrebbe non segnalare alcuna anomalia, nonostante la pagina abbia già stabilito un secondo collegamento fuori dal canale protetto.

La configurazione non equivale però a una VPN. Un proxy applicativo protegge soltanto le comunicazioni che passano dalla sessione di rete a cui risulta associato. Una VPN interviene infatti a un livello più basso: modifica l’instradamento IP del dispositivo o di determinate applicazioni. Perciò, una richiesta che sfuggisse alla sessione WebKit transiterebbe comunque per il tunnel VPN.

Tre funzioni di WebKit possono aggirare il proxy

Come anticipato nell’introduzione, i ricercatori hanno individuato tre funzioni capaci di generare traffico fuori dal proxy usato dal browser.

La prima è il DNS prefetching: una pagina può chiedere a WebKit di cercare in anticipo l’indirizzo IP associato a un dominio, così da velocizzare un collegamento successivo. Su iOS tale richiesta può raggiungere direttamente il resolver DNS configurato sul dispositivo; il sito non vede necessariamente l’IP dell’utente, ma può ricavare informazioni sul provider, sulla posizione approssimativa e sulla rete utilizzata.

Il secondo caso riguarda le passkey condivise tra più domini della stessa organizzazione. Per controllare che la condivisione sia autorizzata, il sistema scarica uno specifico file dal dominio interessato; su iOS la verifica passa però attraverso il servizio che gestisce le credenziali, senza rispettare il proxy del browser, e il server può quindi ricevere l’indirizzo IP pubblico. Non si parla di furto delle passkey: a uscire dal percorso protetto è soltanto la richiesta di controllo.

La terza tecnica sfrutta WebTransport, una tecnologia destinata alle applicazioni Web che richiedono comunicazioni rapide e interattive. Nei test, WebKit ha aperto una connessione diretta verso il server indicato dalla pagina, rivelando subito l’IP reale del dispositivo.

In tutti e tre i casi il problema è lo stesso: alcune operazioni secondarie non ereditano il proxy applicato al normale caricamento dei siti e possono quindi vanificare, almeno in parte, la protezione attesa dall’utente.

Perché iCloud Private Relay non blocca le richieste

Private Relay protegge soprattutto il traffico web di Safari. Il servizio divide le informazioni tra due relay: il primo, gestito da Apple, conosce l’indirizzo IP dell’utente ma non il sito visitato; il secondo conosce il dominio di destinazione e assegna un indirizzo temporaneo, ma non vede l’IP originale.

Il meccanismo riduce la possibilità che un singolo operatore conosca contemporaneamente identità e destinazione: non rappresenta però una VPN completa e non intercetta ogni comunicazione generata dal dispositivo.

Proxy del browser e VPN non offrono la stessa protezione

Lo studio appena pubblicato mette in evidenza che alcune API possono uscire dal percorso previsto.

Chi necessita di una protezione più ampia dovrebbe usare una VPN affidabile, verificando che non esistano eccezioni per determinate applicazioni. Una VPN non assicura comunque anonimato assoluto: cookie, fingerprinting, account autenticati, identificatori locali e abitudini di navigazione possono collegare le sessioni anche senza conoscere l’IP originale.

Un browser non attiva un solo canale di comunicazione: usa processi di rete, servizi per le credenziali, resolver DNS e protocolli specializzati. Applicare un proxy al caricamento delle pagine non basta: ogni funzione capace di generare traffico deve rispettare le stesse regole, altrimenti la protezione resta incompleta proprio nei punti meno visibili all’utente.

Link copiato negli appunti