CRACKs – Crackato il protocollo WPA2 del Wi-Fi, ecco le reali conseguenze ...e un'analisi senza allarmismi inutili

<span class="entry-title-primary">CRACKs – Crackato il protocollo WPA2 del Wi-Fi, ecco le reali conseguenze</span> <span class="entry-subtitle">...e un'analisi senza allarmismi inutili</span>

Cos’è CRACKs (Key Reinstallation Attacks)?

Si tratta di una falla rilevata di recente nel protocollo WPA2, usatissimo sia a livello domestico che aziendale al fine di garantire la protezione delle reti wireless. La protezione riguarda, nello specifico, la possibilità di intercettare le comunicazioni e vedere il traffico in chiaro che transita sulle wireless, quindi username, numeri di carte di credito digitati in chiaro, email, chat, password, pagine web visionate e così via. La gravità della situazione deriva dal fatto che è stata scoperta a livello progettuale, per l’appunto, per cui non interessa specifici modelli di wireless in dotazione su determinati dispositivi, bensì potenzialmente tutti i dispositivi con WPA2 sono esposti, almeno in teoria. La ricerca è piuttosto attendibile ed autorevole, risale all’inizio dell’anno ed è stata svelata ai produttori a fine estate: sarà presentata a breve alla prestigiosa conferenza Black Hat Europe (il paper dettagliato, Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2, è visionabile liberamente, e molte delle sue informazioni sono riassunte qui in forma comprensibile anche per i meno esperti).

La notizia ha avuto ampio risalto sui media generalisti, ovviamente per via della grandissima popolarità dell’interfaccia sui più comuni dispositivi.

Quali dispositivi sono sicuramente a rischio?

Buona parte dei dispositivi più popolari sono affetti dalla falla: Broadcom, Windows, Cisco, TP-Link, Ubuntu, … e così via; ci sono alcuni dubbi sulla possibilità di manipolare i pacchetti per dispositivi Apple, McAfee, IBM, … mentre su altri il problema non sembra sussistere (MikroTik, WMWare ad esempio). La lista aggiornata dei dispositivi vulnerabili a Crack è disponibile sul sito del CERT.

Per i dispositivi a rischio normalmente i produttori mettono a disposizione delle patch correttive.

Equivoci sulla falla wireless WPA2

La stampa generalista ha riportato in maniera sostanzialmente corretta la falla, ma è necessario fare qualche precisazione per non generare inutili paranoie nell’uso quotidiano di internet. A livello tecnico, infatti, sono stati scoperti solo in seguito vari bug nel protocollo, e questo avviene non a livello di specifiche implementazioni (come alcuni, erroneamente, hanno voluto intendere) bensì a livello progettuale, per cui qualsiasi tipo di dispositivo è potenzialmente attaccabile (cito: The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected). Cosa decisamente importante da sottolineare, l’attacco non permette al malintenzionato di visionare solo username e traffico bensì tutto il nostro traffico indifferentemente.

CRACKs e Android / Linux

In alcuni casi specifici  come Android/Linux con wpa_supplicant dalla v2.4 in poi (per inciso, il supplicant è il componente IEEE 802.1X/WPA utilizzato dai client, implementa la negoziazione della chiave con un WPA Authenticator, controlla il roaming e l’associazione / autenticazione del driver wireless), diventa possibile forzare la reinstallazione di una chiave di cifratura nota, formata da byte tutti a “0”, fornendo all’attaccante accesso completo.  In particolare è possibile riciclare maliziosamente un nonce, cioè un numero (pseudo)casuale che viene utilizzato una sola volta, e che – ammesso che sia rigenerabile – può invalidare l’intero processo di crittografia della wireless e renderla equivalente ad una trasmessa in chiaro.  Tecnicamente, pertanto, chiunque sia in grado di riutilizzare pacchetti di autenticazione che dovrebbero essere univoci nel tempo (nonce) avrebbe la possibilità di violare la crittografia usata dalla wireless stessa, rendendo così equivalente WPA2 ad una connessione in chiaro.

Si stima che circa la metà dei dispositivi Android sul mercato sia affetto da questa falla.

Come risolvere

Semplicemente, bisogna quanto prima – non appena i vendor li renderanno disponibili – tablet, telefoni, PC, Mac e così via; non è chiaro se ci siano attacchi in corso o tool di malware disponibili sul mercato che sfruttino questo attacco, anche se molte testate hanno affermato non essercene, almeno in apparenza.

CRACKs e HTTPS

In ambito web, l’uso di connettività su siti esclusivamente HTTPS tende a mitigare almeno in parte la possibilità di un attacco, almeno per certa misura ed in attesa di aggiornare i propri dispositivi (questo dipende esclusivamente dalla volontà e dalle priorità dei rispettivi costruttori Microsoft, Apple, TP-Link per i router e così via), ed è sicuramente preferibile all’uso di HTTP in chiaro che dovrebbe, col tempo, essere dismesso del tutto in favore di HTTPS EveryWhere. Per quanto ciò fornisca uno strato addizionale di protezione non di poco conto, i ricercatori segnalano responsabilmente che è possibile bucare comunque la wireless in un numero abbastanza considerevole di situazioni: validando il certificato in modo illecito attraverso l’uso di particolari librerie come Amazon EC2, Amazon e PayPal, osCommerce, ZenCart, Ubercart, Prestashop, AdMob, alcune app di mobile banking, app Android, middleware java (Apache Axis, Axis 2), utilizzando iPhone jailbreakati, in alcune vecchie versioni di MacOS, su molte versioni di Android e su alcune app in VPN per Android.

Inoltre, nel video proof of concept (cioè il “test sul campo” della falla), viene mostrato chiaramente come sia possibile dirottare un sito in HTTPS nella sua forma HTTP (cioè rimuovendo il certificato) e facendo passare tutto il nostro traffico in chiaro; molti utenti infatti non si accorgono e non fanno caso al fatto di trovarsi o meno in HTTPS, e questo viene sfruttato ampiamente dalla vulnerabilità in questione. Questo tipo di attacco è un TCP hijack, e francamente sorprende che nessuno abbia esplicitato, ad oggi, questo aspetto: l’attacco infatti può avvenire a danno di un utente inconsapevole, che potrebbe trovarsi a visitare un sito HTTPS in HTTP: bisogna sempre controllare che il lucchetto verde sul browser sia sempre attivo, in sostanza, altrimenti rischiamo di condividere la nostra password o dati personali con chiunque.

Come avviene l’attacco (esempio pratico)

Qui viene esplicitato una proof of concept del processo in questione.

A questo si aggiunge un aspetto importante, che è l’attacco basato sulla reinstallazione delle chiavi di accesso, il che permette (per quanto con le dovute eccezioni e specifiche tecniche) di intercettare qualsiasi pacchetto venga trasmesso in rete.

(fonte, fonte)

0 voti


Informazioni sull'autore

Salvatore Capolupo

Consulente SEO, ingegnere informatico e fondatore di Trovalost.it, Pagare.online, Lipercubo.it e tanti altri. Di solito passo inosservato e non ne approfitto.