ChatControl è morto? No: l’UE prova a imporre la sorveglianza “volontaria”
Si è parlato molto, ma non abbastanza, del naufragio della “variante danese” di ChatControl. In pratica, un testo di compromesso che bene o male va a consolidare l’idea di un’Unione Europea che coltiva da tempo l’ambizione d’esser tiranna digitale in nome della difesa di alcuni diritti e un proclamato quanto indimostrato “bene comune”.
Il tutto bellamente fregandosene delle motivate opposizioni a riguardo, perché in fondo la piccola Europa digitale probabilmente ha maturato molta frustrazione guardando tanto verso Oriente quanto verso Occidente, e dunque in qualche modo potrà volersi affermare in questo modo. Di fatto, con un sistematico approccio a volersi fare sovrana dei propri cittadini riducendone di fatto lo spazio dei diritti digitali.
Cosa che, vista la storia egoriferita del Vecchio Continente, non dovrebbe affatto sorprenderci.
Adesso che il testo della proposta danese non è stato portato in Parlamento, onde evitarne la bocciatura e, per i malpensanti, la discussione, si fa avanti il Consiglio dell’Unione che è l’organismo in cui si riuniscono i ministri dei governi degli Stati membri. In questo simpatico gioco delle tre carte è stato così riproposto ChatControl ma senza un obbligo per le piattaforme bensì come opzione volontaria. Ovviamente liberissime le piattaforme di adottare misure di monitoraggio per rendere sicuro l’ecosistema online, contrastare la pedopornografia e un sacco di blablabla indimostrati. Chissà, magari un domani potranno inventarsi qualche “bollino” per le piattaforme virtuose…
Anche perché, di fatto, non è tutt’ora stata presentata una singola evidenza circa la correlazione fra monitoraggio e sicurezza. Eppure di centri studi compiacenti o in cerca di un qualche compiacimento politico ce ne dovrebbero essere, no? E i dati, si sa, quando vengono torturati abbastanza sono in grado di dire un po’ tutto quel che vogliamo che dicano.
I problemi del monitoraggio volontario delle piattaforme.
Rinunciare ad un obbligo di legge e delegare di fatto alla piattaforma di determinare i monitoraggi del caso per proteggere i minori fa emergere almeno due contraddizioni. La prima in cui tanto si parla di sovranità tecnologica ma poi di fatto si va ad attribuire poteri d’indagine e correttivi ad una piattaforma online, con poteri senza contrappesi propri dell’ordinamento. La seconda, enunciare diritti e libertà fondamentali e poi inquadrare il tutto in modelli as-a-service.
Meravigliosa la narrazione di fondo, che convulsamente richiama esigenze di sicurezza come tutti coloro che vogliono ingegnerizzare una svolta autoritaria. L’exploit è servito, basterà distribuire fra qualche opinion-maker alcuni argomenti, quali “Dobbiamo tutelare i più fragili” o “Non possiamo lasciare i minori indifesi negli ecosistemi digitali” per accusare velatamente che chiunque possa opporsi all’avviare un’abitudine (Overton docet) di monitoraggi online persistenti in realtà non abbia cura della protezione dei minori.
E anche qui, viene da chiedersi: al di là dello slogan, ripetuto innumerevoli volte fino a vestire le sembianze della realtà, c’è qualche argomento nel merito che possa correlare in modo chiaro un aumento della sicurezza con la riduzione della privacy online? Ricordiamoci che nel dibattito è chi presenta un’affermazione a doverla motivare e sostenere, non il contrario. Ricordiamoci che dire “dimostrami il contrario” è il 101 del trolling sin dai tempi dei canali IRC.
Dalla cultura alla partecipazione.
Potremmo scomodare una facile chiosa del discorso, invocando il solito problema di cultura digitale. Che santo cielo, c’è e non manca mai di produrre ogni danno possibile, ma che non può essere l’unica causa di tutto questo.
Ci si dovrebbe domandare come mai ci sia questa deriva di autoritarismo digitale da parte di un’Unione Europea sempre pronta ad enunciare diritti inviolabili sempre più quando strumentalmente utili per essere al tavolo delle trattative con Big Tech o grandi potenze economiche.
Come si contrasta questa volontà di tirannide digitale? Un approccio bottom-up può essere sufficiente?
Molte iniziative, fra cui Fight Chat Control, puntano su questo. Gli attivisti sensibilizzano.
Dopodiché, volendo essere pratici, bisogna rendere elettoralmente sconveniente appoggiare iniziative analoghe a Chat Control, ma per farlo occorre essere cittadini informati, consapevoli ed attivi. Tutte cose che completano la cittadinanza digitale attraverso una partecipazione, individuale o collettiva, alla società di oggi e di domani.
Optare per l’inerzia, pensare che qualcun altro farà qualcosa è invece la radice di ogni problema che porta ad autoritarismi, più o meno digitali.
L'articolo ChatControl è morto? No: l’UE prova a imporre la sorveglianza “volontaria” proviene da Red Hot Cyber.
Deauth attack: l’arma più comune contro le reti Wi-Fi domestiche
Il Deauth attack è uno degli attacchi più noti e storicamente utilizzati contro reti WPA2-Personal, soprattutto come fase preparatoria per altri attacchi.
Sfrutta diverse vulnerabilità intrinseche nel processo d’autenticazione che permettono all’attaccante, tra le altre cose, di estrapolare alcuni dati utilizzabili per il cracking della chiave. È efficace contro la quasi totalità delle reti WPA2 standard IEEE 802.11.
L’efficienza dell’attacco allo scopo di ottenere la chiave di autenticazione è proporzionale alle risorse hardware dell’attaccante ed inversamente proporzionale alla complessità della chiave d’autenticazione.
Può essere lanciato da qualsiasi dispositivo dotato del giusto software e di una scheda di rete compatibile che supporti la monitor mode (una modalità che permette di operare la scheda wireless a più basso livello, avendo così più controllo sull’hardware).
Panoramica
Glossario: AP: Access point (comunemente router Wi-Fi)
Client: Il dispositivo che intende connettersi
Cos’è il Deauth Attack
Il Deauth attack è un attacco informatico il cui scopo principale è quello di forzare la deautenticazione, e quindi la disconnessione, anche temporanea, di uno o più dispositivi Client da una rete Wi-Fi.
Obbiettivi
Gli obbiettivi di questo attacco possono essere di vario genere e natura.
Il più elementare è quello di indurre un disservizio nella rete interrompendo la comunicazione tra questa ed i dispositivi ad essa collegati.
In questo caso l’attacco ricade sotto la categoria dei DoS (Denial of Service).
Un altro caso in cui si vede utilizzato questo attacco è in combinazione con un Evil Twin attack.
Si tratta di un altro attacco informatico ai danni di una rete Wi-Fi e dei dispositivi ad essa connessi che consiste nell’installazione di una rete Wi-Fi apparentemente identica all’originale allo scopo di indurre i dispositivi a connettersi ad essa per perpetrare poi ulteriori attacchi come lo sniffingdel traffico e la manipolazione delle informazioni trasmesse (MITM).
Lo scopo più comune del Deauth attack, tuttavia, è quello di indurre una disconnessione forzata allo scopo di ascoltare e registrare il processo di autenticazione che avviene tra i client e l’access point durante la successiva autenticazione. Questo attacco verrà particolarmente approfondito nell’articolo.
L’autenticazione
Glossario:
AP: Access point (comunemente router Wi-Fi)
Client: Il dispositivo che intende connettersi
Supplicant: Il client, durante l’autenticazione
PSK: Passphrase o password
Pacchetto: dato trasmesso (terzo livello OSI)
Frame: dato trasmesso (secondo livello OSI)
Canale radio: intervallo di frequenze radio definito
Richiesta di autenticazione:
Per comprendere appieno questo attacco, è necessario conoscere il processo di autenticazione delle reti WPA2 personal.
Dopo alcune fasi preliminari non dettagliate in questo articolo (Beacon, Probe request, associazione…) ha inizio il vero e proprio processo di autenticazionecon la richiesta da parte del supplicant verso l’AP tramite l’invio di un frame “Authentication request” (da ora semplicemente “request”). Questo frame viene trasmesso sul canale radio dedicato alla connessione Wi-Fi (2.4GHz / 5Ghz) ed innesca il processo di seguito descritto.
L’handshake
Il cuore dell’autenticazione è senza dubbio la negoziazione che avviene tra il Client e l’AP allo scopo di dimostrare che il Client possiede la chiave d’accesso. Questo dialogo prende il nome di 4 way handshake e può essere così sintetizzato:
MESSAGGIO 1 – ANONCE ED INIZIO DELLA DERIVAZIONE
Il 4-way handshake inizia quando l’Access Point (AP), chiamato Authenticator, invia al client (Supplicant) il primo frame “EAPOL-Key” contenente il proprio dato “ANonce” (Authenticator Nonce), un numero casuale di 256 bit (32 byte) generato sul momento dall’AP. Questo frame contiene anche il Replay Counter (8 byte), numero che serve ad identificare in modo univoco ogni messaggio dell’handshake ed evitare replay (messaggi duplicati).
MESSAGGIO 2 – CALCOLO DELLA PTK ED INVIO DEL SNonCE
Il client genera ora il proprio SNonce (Supplicant Nonce), anch’esso di 256 bit, in modo casuale e non riutilizzabile. Con entrambi i nonce e con le altre informazioni note, il client calcola la PTK (Pairwise Transient Key, una chiave di cifratura temporanea).
La PTK è derivata da una funzione pseudo-casuale definita nello standard IEEE 802.11i, chiamata PRF (Pseudo-Random Function). La formula generale è:
PTK = PRF(PMK, “Pairwise key expansion”, Min(MAC_AP, MAC_STA) ‖ Max(MAC_AP, MAC_STA) ‖ Min(ANonce, SNonce) ‖ Max(ANonce, SNonce))
dove:
PMK (Pairwise Master Key) è una chiave di 256 bit ottenuta dalla passphrase (in WPA2-Personal) tramite PBKDF2-HMAC-SHA1(Password, SSID, 4096, 256).
La stringa “Pairwise key expansion” è un’etichetta fissa che serve come diversificatore per la PRF.
MAC_AP e MAC_STA sono gli indirizzi MAC dell’AP e del client.
L’uso di Min e Max garantisce che entrambe le parti concatenino i valori nello stesso ordine,
indipendentemente da chi esegue il calcolo. Queste funzioni sono infatti di ordinamento e restituiscono il primo (MIN) e l’ultimo (MAX) indirizzo MAC secondo l’ordine alfabetico.
La PTK è lunga 384 bit (48 byte) che vengono suddivisi in tre sottochiavi:
KCK (Key Confirmation Key, 128 bit) → per il calcolo del MIC.
KEK (Key Encryption Key, 128 bit) → per cifrare le chiavi nel messaggio 3.
TK (Temporal Key, 128 bit) → per cifrare il traffico unicast successivo.
Il client calcola poi un MIC (Message Integrity Code) sul messaggio “EAPOL-Key” usando la KCK secondoMIC=HMAC-SHA1(KCK, EAPOL-Frame) ed invia il secondo frame all’AP. In questo messaggio sono inclusi: SNonce, Replay Counter aggiornato ed il MIC. La presenza del MIC dimostra all’AP che il client possiede la PMK valida, poiché senza di essa il calcolo della PTK e di conseguenza del MIC non sarebbe possibile.
MESSAGGIO 3 – VERIFICA E DISTRIBUZIONE DELLA GTK
L’AP, ricevendo il messaggio 2, possiede tutto il necessario per calcolare la PTK in modo identico al client (ha PMK, ANonce, SNonce, MAC_AP e MAC_STA). Verifica quindi il MIC ricevuto: se è corretto, l’AP sa che il client possiede la PMK e valida l’autenticazione.
A questo punto, l’AP installa localmente la PTK e genera o seleziona la GTK (Group Temporal Key, generata dall’AP come numero di 128bit pseudocasuale), usata per il traffico multicast e broadcast. La GTK viene cifrata con la KEK (parte della PTK) per impedirne la lettura da parte di terzi.
Il messaggio 3, inviato dall’AP al client, contiene quindi:
Il Replay Counter aggiornato.
Il campo “Key Information” con flag impostati per indicare che la GTK è inclusa.
Il campo “Key Data”, dove la GTK è cifrata con KEK.
Un nuovo MIC, calcolato con la KCK.
Questo messaggio serve sia a consegnare la GTK, sia a confermare la validità della PTK calcolata da entrambe le parti.
MESSAGGIO 4 – CONFERMA FINALE DEL CLIENT
Il client, ricevuto il messaggio 3, decifra il campo Key Data usando la KEK e ottiene la GTK. Dopo aver verificato il MIC, installa la PTK e la GTK nella propria interfaccia radio per abilitare la cifratura del traffico (ad esempio con AES-CCMP).
Infine invia il quarto messaggio, che contiene solo un MIC calcolato con la KCK ed il Replay Counter incrementato, come conferma della corretta ricezione e installazione delle chiavi.
A questo punto, sia AP che STA condividono la stessa PTK (per il traffico unicast) e la stessa GTK (per il traffico multicast). Il 4-way handshake termina e la connessione cifrata WPA2 è pronta a trasmettere dati in modo sicuro.
La deautenticazione
Glossario: Checksum: codice, calcolato sulla base del contenuto del dato trasmesso, utile per rilevare interferenze nella trasmissione
Il primo passo del Deauth attack (dopo alcune operazioni preliminari atte ad individuare la rete target) è la deautenticazione forzata di uno o più client dalla rete. Questo può essere fatto tramite l’invio di un frame deauth. Questo frame è legittimamente utilizzato per “espellere” un dispositivo dalla rete in caso di necessità costringendolo ad autenticarsi nuovamente, ad esempio in seguito ad una nuova generazione delle chiavi, in caso di inattività prolungata, o per rispettare una policy interna.
Il Deauth frame
I Deauth frames, appartenenti ai Management Frames, non sono in alcun modo cifrati nelle reti WPA2 perché non considerati possibile vettore d’attacco al tempo della definizione dello standard 802.11 (che definisce la maggioranza delle reti WPA2 oggi attive), e per questo la loro falsificazione è molto semplice. Ad oggi esiste uno standard che mitiga questa vulnerabilità (802.11w), ma tuttora quasi inutilizzato.
Il Deauth frame è composto da:
Un header contenente:
Un dato “frame control” di 2 bytes che identifica il tipo (in questo caso, management frame) ed il sottotipo (in questo caso, deauthentication) del frame
Un dato “duration” di due bytes che indica il tempo per il quale il canale sarà occupato
Un dato “destination address” di 6 bytes che indica l’indirizzo MAC del destinatario a cui è rivolto il frame
Un dato “source address” di 6 bytes che indica l’indirizzo MAC del mittente (facilmente falsificabile)
Un dato “BSSID” che indica il nome della rete a cui il frame si riferisce
Un dato “sequence control” utile per il controllo dell’ordine dei pacchetti ricevuti
E da un body (corpo del messaggio) contenente:
Un dato “reason code” di 2 bytes che indica il motivo della deautenticazione (non importante ai fini dell’attacco)
Un dato “frame check sequence” di 4 bytes che contiene un checksum del frame
L’invio del frame
L’attacco ha inizio con l’invio, spesso in broadcast, di uno o più deauth frames.
Il frame viene quasi sempre inviato falsificando l’indirizzo MAC dell’AP, salvo in caso di alcune configurazioni estremamente rare, probabilmente non più esistenti, non coperte da questo articolo.
I client autenticati e connessi accettano il frame e si deautenticano.
La cattura dell’handshake
Dopo un certo tempo dalla deautenticazione (tipicamente alcuni secondi), i client tentano automaticamente di riautenticarsi (salvo diversa impostazione manuale da parte dell’utente, rara negli smartphone e nei dispositivi IoT).
A questo punto, l’attaccante può ascoltare i canali radio e registrare la negoziazione che avviene tra i client (in questo momento “supplicant”) e L’AP.
Il cracking della passphrase
Purtroppo per l’attaccante, i dati trasmessi che hanno a che fare con la chiave (password o passphrase) sono frutto di algoritmi non reversibili. Questo significa che non è possibile ottenere la PSK invertendo l’operazione partendo da un risultato.
È possibile tuttavia procedere per tentativi, introducendo il concetto di bruteforcing.
Il bruteforcing
Conosciuto anche come attacco bruteforce, a volte erroneamente tradotto in attacco di forza bruta, è uno dei più elementari attacchi informatici. Può essere perpetrato contro ogni dato la cui cifratura si basa sull’utilizzo di un secret (un dato che funge da chiave per la decrittazione, come un PIN, una password, un token…).
Consiste nel compiere numerosi tentativi in rapida sequenza allo scopo di indovinare il secret richiesto. Nella forma più elementare, il secret viene generato da un algoritmo pseudocasuale.
In altre forme più sofisticate, il secret può essere estratto da una lista di probabili candidati detta wordlist. In quest’ultimo caso, l’attacco prende il nome di “attacco dizionario”.
Esistono ulteriori forme di attacco bruteforce.
È importante dire che, senza limiti di tempo e/o di risorse, il brute force attack ha il 100% di probabilità di crackare il secret.
La ricostruzione della chiave
L’attacco bruteforce viene in questo caso utilizzato per crackare la PSK. Lo si fa ricostruendo l’handshake registrato, simulandolo localmente tante volte in rapida sequenza, ogni volta utilizzando una nuova chiave candidata, che può essere generata casualmente o letta da una wordlist.
Per ogni chiave candidata viene quindi calcolata la PMK, dunque la PTK ed il MIC, il quale viene confrontato con quello registrato durante la cattura dell’handshake autentico.
Nel caso in cui uno dei tentativi porti ad una corrispondenza dei due MIC, la chiave candidata viene considerata vincitrice.
Post exploitation
Glossario: Backdoor: punto di accesso persistente installato da un attaccante allo scopo di collegarsi al sistema violato con maggiore semplicità
In seguito ad un attacco deauth andato a segno, l’attaccante può utilizzare l’accesso alla rete per i propri scopi.
È tipico bersagliare infrastrutture interne come server locali, computer, dispositivi di rete.
Essendo la rete wireless locale di difficile accesso, poiché richiede vicinanza fisica tra l’interfaccia radio dell’attaccante e l’AP, solitamente si utilizza per accedere più facilmente ad altri dispositivi sui quali installare una backdoor attraverso la quale accedere tramite Internet o altra rete di più semplice utilizzo.
Strumenti
Esistono numerosi strumenti utili all’esecuzione del Deauth attack.
Tra i più conosciuti e storici troviamo Aircrack-ng (contenente Airmon-ng ed Aireplay-ng) ed MDK4 per la deautenticazione, mentre Hashcat e John the ripper per il cracking.
Alternative più complete e moderne come Airgeddon automatizzano il processo ed includono tutti i software menzionati.
L'articolo Deauth attack: l’arma più comune contro le reti Wi-Fi domestiche proviene da Red Hot Cyber.
Cybersecurity & cyberwarfare