Prevenire attacchi di doppio gemello WiFi su sistemi embedded

Question

Prevenire attacchi di doppio gemello WiFi su sistemi embedded

#1 da (1 voti)

7

Di recente ho esaminato alcuni dei moduli WiFi di fascia bassa utilizzati nei dispositivi IoT, come TLGUA06 e ESP2866.

Come previsto, è possibile rimuovere la firma di autenticazione di questi dispositivi inviando un frame di deautenticazione. Questo è come da specifiche WiFi.

Tuttavia, entrambi questi dispositivi si uniranno nuovamente a una rete aperta con lo stesso ESSID. Non è necessario clonare il MAC dell'AP o altro.

Questo ovviamente porta a malvagi attacchi gemelli. Combinato con l'uso comune di protocolli insicuri, un utente malintenzionato può facilmente intercettare o le comunicazioni MITM.

OSX si lamenta quando si tenta questo attacco, come fanno molte versioni di Windows. Il mio iPhone si lamenta, ma il mio telefono Android no.

Perché questi dispositivi non proteggono dai malvagi attacchi gemelli? Capisco che questo possa essere un compromesso tra sicurezza e affidabilità, ma non ci sono impostazioni o controlli che consentano a un produttore di scegliere un sistema più sicuro.

Ho perso un altro motivo per spiegare perché questi attacchi sono possibili?

Quali strategie possono essere utilizzate per proteggere dai malvagi attacchi gemelli?

wifi

posta Cybergibbons 20.12.2015 - 18:54

fonte

1 risposta

Leggi altre domande sui tag wifi

Esiste un modo per bloccare (o approvare condizionatamente) iFrame sul lato client? L'utilizzo del client mantiene onesto il server Keybase anche se si utilizza anche l'interfaccia web?

score 1 · Answer 1

Ci sono due parti per questa risposta.

La maggior parte dei browser e dei sistemi operativi mobili avrà un archivio CA con dozzine di società CA e centinaia di certificati con cui convalidare TLS. Gli attacchi Evil Twin si basano sul fatto che non si memorizzano nella cache le richieste che necessitano di TLS con quali certificati, quindi è possibile che MitM passi una richiesta senza CERT. Questo elenco viene aggiornato con il tempo ma è abbastanza pesante per un sistema embedded leggero.

Le piattaforme IoT come Electric Imp utilizzano invece un coprocessore di crittografia dedicato con storage sicuro come l'ATSHA204 o un altro chip in stile TPM2. Tutte le richieste vengono instradate attraverso un gateway conosciuto (come Amazon Bucket di Electric Imp) con una chiave conosciuta prima di uscire su Internet. (Credo che Kindle lo faccia anche con il loro browser "sperimentale"). Se l'handshake ha esito negativo, la connessione viene interrotta. A seconda di come viene fatto, il lato server potrebbe essere in grado di rilevare prove di malversazione e segnalare comportamenti scorretti all'utente come suggerito. La chiave memorizzata sul dispositivo può essere univoca per ogni istanza dell'hardware ed è associata / benedetta in fabbrica prima che venga spedita al consumatore.

Stai essenzialmente scambiando un gemello malvagio per un genitore fidato che trasmette tutte le tue comunicazioni.

Tutte le comunicazioni in uscita passano attraverso un endpoint conosciuto rispetto al quale la convalida è più semplice. L'endpoint può quindi richiedere richieste più sofisticate a risorse esterne. Per richieste a bassa larghezza di banda è semplice e adatto a molte attuali applicazioni IoT.

L'adeguatezza di questo modello dipende dalla tua applicazione. Se sei il canale meteo e stai realizzando un dispositivo che cambia colore in base alla temperatura meteorologica, ci sono pochi dubbi.

Se il tuo dispositivo legge l'e-mail dei tuoi clienti in tutta la sua forma (come quella trovata nelle auto BMW), ci sono grossi problemi con te che tocchi questi dati. Nokia si è messa nei guai con questo qualche anno fa.