E' stata recentemente scoperta una grave vulnerabilità nel protocollo utilizzato nelle reti WiFi "sicure". Sia in quelle che utilizziamo a casa, sia in quelle utilizzate in ambito cosiddetto "enterprise", come accade ad esempio nella rete eduroam della nostra università.
Sono già state pubblicate molte sintesi ed analisi eccellenti, a vari livelli di complessità tecnica (metto un piccolo elenco in fondo a questo post). Inutile che io tenti di aggiungere la mia. Faccio solo una piccola riflessione più generale.
Non è la prima volta che ciò accade. Nel corso di Reti II parlo da anni di questo fenomeno facendo riferimento a due casi specifici, uno relativo alla scelta dei numeri di sequenza iniziali nelle implementazioni di TCP, l'altro relativo all'interazione tra un client Kerberos e l'Authentication Service.
Ovviamente, ciò non accade per superficialità o per incompetenza. Accade perché i protocolli di sicurezza sono delle brutte bestie, sono temi davvero complicati.
Il motivo è paradossale: i dispositivi Linux e Android hanno implementato il protocollo in maniera perfetta, seguendo tutte le raccomandazioni; gli altri dispositivi invece non hanno seguito tutte le raccomandazioni e, per mera fortuna, rendono l'attacco molto più complesso (il motivo tecnico per questo paradosso è spiegato in alcuni dei link che riporto qui sotto, ma è irrilevante; in parole poverissime Linux e Android azzerano le chiavi già usate in passato; ciò rende tali chiavi prevedibili per un attaccante che riesca a forzarne il riuso).
Quindi: chi ha implementato il protocollo in maniera perfetta adesso è messo malissimo; chi lo ha implementato in maniera imperfetta adesso è messo un pò meglio.
La cosa interessante è che anche in quel caso il problema è nato da una implementazione perfetta del protocollo TCP. Chi aveva implementato TCP perfettamente (Linux) era attaccabile. Chi non lo aveva implementato perfettamente non era attaccabile o era attaccabile con una probabilità di successo molto più bassa.
Anche in quel caso, quindi, chi aveva implementato il protocollo in maniera perfetta era messo malissimo; chi lo aveva implementato in maniera imperfetta era messo un pò meglio.
Ovviamente questo non deve incoraggiare ad implementare i protocolli in maniera scorretta. E' solo una ulteriore evidenza del fatto che la sicurezza è una bruttissima bestia.
PS I problemi di sicurezza dei protocolli sono quisquilie nei confronti dell'altro ben più grande problema: quello degli errori software (vedi ad esempio le "Notable recent security issues" di questo mese qui: https://www.sans.org/newsletters/at-risk/xvii/41).
Alcuni link:
Sono già state pubblicate molte sintesi ed analisi eccellenti, a vari livelli di complessità tecnica (metto un piccolo elenco in fondo a questo post). Inutile che io tenti di aggiungere la mia. Faccio solo una piccola riflessione più generale.
Premessa 1
Si tratta di una vulnerabilità nel protocollo. Non nelle implementazioni software del protocollo. Per molti anni, in questo caso per 13 anni, tecnici, ricercatori ed aziende di tutto il mondo hanno studiato ed utilizzato quel protocollo e nessuno si era accorto del problema.Non è la prima volta che ciò accade. Nel corso di Reti II parlo da anni di questo fenomeno facendo riferimento a due casi specifici, uno relativo alla scelta dei numeri di sequenza iniziali nelle implementazioni di TCP, l'altro relativo all'interazione tra un client Kerberos e l'Authentication Service.
Ovviamente, ciò non accade per superficialità o per incompetenza. Accade perché i protocolli di sicurezza sono delle brutte bestie, sono temi davvero complicati.
Premessa 2
L'impatto della vulnerabilità appena scoperta non è lo stesso su tutti i dispositivi. L'impatto sui dispositivi Linux e Android è molto più catastrofico che non sui dispositivi Windows, Mac e così via.Il motivo è paradossale: i dispositivi Linux e Android hanno implementato il protocollo in maniera perfetta, seguendo tutte le raccomandazioni; gli altri dispositivi invece non hanno seguito tutte le raccomandazioni e, per mera fortuna, rendono l'attacco molto più complesso (il motivo tecnico per questo paradosso è spiegato in alcuni dei link che riporto qui sotto, ma è irrilevante; in parole poverissime Linux e Android azzerano le chiavi già usate in passato; ciò rende tali chiavi prevedibili per un attaccante che riesca a forzarne il riuso).
Quindi: chi ha implementato il protocollo in maniera perfetta adesso è messo malissimo; chi lo ha implementato in maniera imperfetta adesso è messo un pò meglio.
Riflessione
Qualche giorno fa ho trovato il tempo di studiare un lavoro che avevo messo in attesa da tempo e del quale parlerò nel prossimo corso di Reti II. Questo lavoro dimostra la possibilità pratica per un attaccante di iniettare traffico in connessioni TCP già esistenti. Anche per attaccanti che non possono osservare il traffico tra le estremità delle connessioni. Con probabilità di successo altissima (tra 88% e 97%). Con un tempo necessario per raccogliere tutte le informazioni necessarie, compresi i numeri di porta ed i numeri di sequenza ad entrambe le estremità, tra 40 e 60 secondi. Terrificante.La cosa interessante è che anche in quel caso il problema è nato da una implementazione perfetta del protocollo TCP. Chi aveva implementato TCP perfettamente (Linux) era attaccabile. Chi non lo aveva implementato perfettamente non era attaccabile o era attaccabile con una probabilità di successo molto più bassa.
Anche in quel caso, quindi, chi aveva implementato il protocollo in maniera perfetta era messo malissimo; chi lo aveva implementato in maniera imperfetta era messo un pò meglio.
Ovviamente questo non deve incoraggiare ad implementare i protocolli in maniera scorretta. E' solo una ulteriore evidenza del fatto che la sicurezza è una bruttissima bestia.
PS I problemi di sicurezza dei protocolli sono quisquilie nei confronti dell'altro ben più grande problema: quello degli errori software (vedi ad esempio le "Notable recent security issues" di questo mese qui: https://www.sans.org/newsletters/at-risk/xvii/41).
Alcuni link:
- https://www.krackattacks.com/ (blog post del ricercatore che ha scoperto)
- Blog post vari in ordine di complessità grosso modo crescente
Commenti