È possibile estrarre i programmi caricati sulla scheda NodeMCU?

13

Sto usando una scheda NodeMCU con funzionalità WiFi per creare un semplice tracker di risorse. Sono riuscito a trovare alcuni schizzi di Arduino che abilitano la connettività all'hub IoT di Azure e postano messaggi.

Una delle chiavi che devo "caricare" sulla scheda è la stringa di Connessione dispositivo di Azure e, naturalmente, un SSID WiFi e una password.

La mia paura è che qualcuno potrebbe semplicemente prendere il consiglio e "scaricare" i file per ottenere l'accesso alle credenziali di sicurezza.

La mia paura è ingiustificata o la perdita di credenziali è una vera minaccia che devo mitigare?

security

— martinetti
fonte

3

Penso che le risposte di @Mike Ounsworth e Bence Kaulics prese insieme mi offrano un'opzione decente. Purtroppo non posso contrassegnare entrambi come risposte accettate.

— ariete

12

[dichiarazione di non responsabilità: sono un professionista della sicurezza / crittografia e mi occupo di domande di architettura di sicurezza come questa ogni giorno.]

Ti sei imbattuto nel problema di archiviare le credenziali in modo tale che un processo incustodito possa accedervi, ma un attaccante non può. Questo è un problema ben noto e molto difficile da risolvere.

Se il tuo dispositivo IoT ha un keystore hardware integrato nella scheda madre, come alcuni TPM, o l'equivalente del Keystore supportato da hardware Android o Apple Secure Enclave, puoi usarlo.

Con i server tradizionali è possibile utilizzare HSM o Smart Card, ma l'unica soluzione software di cui sono a conoscenza è derivare una chiave AES da una sorta di "impronta digitale hardware" costruita combinando i numeri di serie di tutti i dispositivi hardware. Quindi utilizzare quella chiave AES per crittografare le credenziali. Un processo in esecuzione sullo stesso server può ricostruire la chiave AES e decrittografare le credenziali, ma una volta estratto il file dal server, è essenzialmente non decodificabile.

IoT lancia una chiave in questo per due motivi:

Il presupposto che i numeri di serie dell'hardware siano univoci probabilmente non regge, e
A differenza dei server, gli aggressori hanno accesso fisico al dispositivo, quindi probabilmente possono ottenere una shell sul dispositivo per eseguire il programma di decodifica.

Sia la crittografia hardware (TPM) sia la crittografia "hardware fingerprint" sono al massimo offuscate perché, fondamentalmente, se un processo locale può decrittografare i dati, anche un utente malintenzionato in grado di eseguire quel processo locale può anche decrittografarlo.

Quindi il trucco standard sembra che non funzioni qui. La prima domanda che devi porsi è:

Qual è il mio modello di minaccia / dove si colloca questo progetto sulla Secure <--> Convenientscala?

In definitiva, penso che sia necessario decidere che security > conveniencee avere un essere umano inserire le credenziali dopo ogni avvio (usando qualcosa come la risposta di @ BenceKaulics ), oppure decidere security < conveniencee mettere le credenziali sul dispositivo, magari usando qualche offuscamento se si sento che fa la differenza.

Questo è un problema difficile reso più difficile dalla natura dei dispositivi IoT.

Per completezza, la soluzione industriale completa a questo problema è:

Assegna a ciascun dispositivo IoT una chiave pubblica RSA univoca al momento della produzione. Registrare questa chiave pubblica in un db con il numero di serie del dispositivo.
Memorizza le credenziali sensibili su un server appropriato, chiamiamolo "gateway".
Quando un dispositivo IoT si autentica sul gateway (utilizzando la sua chiave RSA), il gateway apre una sessione per esso utilizzando le credenziali archiviate e restituisce il token di sessione al dispositivo.
Per la massima sicurezza, il gateway è un gateway fisico (o VPN) in modo che tutto il traffico dal dispositivo IoT passi attraverso il gateway e si abbia un maggiore controllo sulle regole e sugli elementi del firewall, impedendo idealmente al dispositivo di avere un tunnel diretto (non VPN) accesso a internet.

In questo modo e un utente malintenzionato che compromette un dispositivo può aprire una sessione, ma non ha mai accesso diretto alle credenziali.

— Mike Ounsworth
fonte

2

Sì. Una grande parte del problema è che ciò che sta cercando di essere protetto qui è il segreto condiviso che è una password wifi. I segreti condivisi sono una cattiva idea quando un dispositivo può essere sezionato fisicamente. Una progettazione migliore dovrebbe separare ogni istanza del dispositivo (o altro computer) nel proprio ambiente di sicurezza con un canale in modo univoco sicuro tra ogni singolo gadget e i sistemi con cui devono comunicare. In ogni caso, il wifi potrebbe non adattarsi molto bene all'applicazione rispetto a qualche schema da 2,4 GHz punto-punto o persino al protocollo "Esp Now".

— Chris Stratton,

1

Buon punto. È possibile risolvere il problema segreto condiviso utilizzando i certificati client enterprise WPA2 anziché una password SSID (se il dispositivo IoT è abbastanza grande da avere uno stack TLS, molti non lo sono). Non so nulla sull'hub IoT di Azure, ma presumo che le stringhe di Connessione dispositivo di Azure siano già univoche per dispositivo. Sfortunatamente, questo sembra essere un bianco e nero piuttosto pulito tra "Fai da te senza sicurezza" e "Sicurezza su scala industriale" senza molto in mezzo.

— Mike Ounsworth,

2

Mi chiedo, se posso aprire una sessione a piacimento, perché dovrei avere bisogno delle credenziali?

— Andrew Savinykh,

1

@AndrewSavinykh Dipende da quali sono le credenziali. Forse tutto ciò che fanno è aprire una sessione, nel qual caso sì, non molte ragioni. Ma forse sono credenziali AD di dominio Windows o danno accesso ad API aggiuntive non normalmente utilizzate / accessibili dal dispositivo IoT. Forse stai bene con le sessioni provenienti da dispositivi compromessi, ma non con le sessioni provenienti dai laptop degli aggressori. Sì, diventa abbastanza specifico per il caso d'uso.

— Mike Ounsworth,

3

Numeri seriali??? Trovare un numero seriale univoco non dovrebbe essere un problema, ma i numeri seriali non sono segreti. Sono inutili per formare una chiave. Dove diavolo sta usando i numeri di serie per formare una chiave un "trucco standard"?

— Gilles 'SO- smetti di essere malvagio' il

6

La minaccia è reale ma fortunatamente non sei tu il primo o l'unico con questo tipo di problemi di sicurezza.

Ciò di cui hai bisogno è ESP WiFi Manager è ciò di cui hai bisogno qui.

Con questa libreria l'ESP che non ha una sessione salvata passerà alla modalità AP e ospiterà un portale web. Se ti connetti a questo AP con un PC o uno smartphone, sarai in grado di configurare le credenziali WiFi tramite una pagina web.

Non è necessario codificare le informazioni critiche e è possibile utilizzare il dispositivo su qualsiasi rete WiFi desiderata senza la necessità di ricollegarle.

Come funziona

quando ESP si avvia, lo configura in modalità Stazione e tenta di connettersi a un punto di accesso precedentemente salvato

in caso contrario (o se non è stata salvata alcuna rete precedente), sposta l'ESP in modalità Access Point e avvia un DNS e un WebServer (ip predefinito 192.168.4.1)

utilizzando qualsiasi dispositivo abilitato wifi con un browser (computer, telefono, tablet) connettersi al punto di accesso appena creato

a causa del Captive Portal e del server DNS si otterrà un tipo di popup "Partecipa alla rete" o si otterrà qualsiasi dominio a cui si tenta di accedere reindirizzato al portale di configurazione

scegli uno dei punti di accesso scansionati, inserisci la password, fai clic su salva

ESP proverà a connettersi. In caso di successo, rinvia il controllo alla tua app. In caso contrario, riconnettersi ad AP e riconfigurare.

(Documentazione ESP WiFi Manager)

— Bence Kaulics
fonte

1

Oppure scarica semplicemente i record o qualsiasi altra cosa mentre è in modalità AP. Spero che il poster non stia cercando di utilizzare il wifi stesso per il monitoraggio delle risorse.

— Chris Stratton,

1

@ChrisStratton :-) in realtà, sto cercando di utilizzare il WiFi per il monitoraggio delle risorse. Fortunatamente, la rete WiFI che utilizzo è pubblica e aperta, ma sono preoccupato per le implicazioni quando ho bisogno di usare un altro che ha bisogno di una password. Inoltre, la stringa di connessione dell'hub AzureIoT si trova sul dispositivo.

— ram

2

@rams Sicuramente, leggere la EEPROM del dispositivo non sarebbe un grosso compito.

— Bence Kaulics,

3

@rams Sull'hardware, sì, è possibile leggere EPROM. I dispositivi più recenti possono avere alcune aree flash sicure che sono meglio protette. Certamente questo è un problema noto che necessita del supporto su chip per provare a fare correttamente.

— Sean Houlihane,

2

@SeanHoulihane - ESP8266 non ha EEPROM. Il flash SPI che utilizza per tutto (incluso il tipo di emulazione della funzionalità Arduino) è esterno all'ESP8266. Anche nel modulo multi-chip, è un dado distinto che può essere sondato in un laboratorio decente.

— Chris Stratton,

3

Sì, possono accedere alla tua password se la lasci come testo normale.

Il punto positivo è che molte interfacce di connessione wifi accettano password con hash. Mentre quelli che ho usato hanno accettato hash md5 e md5 non è super sicuro, è ancora una sfida molto difficile per joe medio. A seconda del file di configurazione, devi indicare il nome dell'algoritmo di hashing e quindi scrivere la password o utilizzare l'impostazione predefinita utilizzata dall'interfaccia wifi.

— atakanyenel
fonte

3

Se riescono a estrarre una password con hash che funziona mentre è hash cosa impedisce loro di usarla senza mai invertirla?

— Chris Stratton,

1

@ChrisStratton hai ragione. Il modo di prevenirlo è per Information Security SE, questa domanda chiede di prevenire la perdita di credenziali. Tuttavia, le password con hash non possono ancora essere utilizzate dai cellulari per connettersi alla rete senza software aggiuntivo.

— atakanyenel,

1

Sì, in effetti offrirebbe una certa protezione nel caso in cui il riutilizzo della password wifi su qualche altro sistema, ma non molto contro la connessione non autorizzata a quel punto di accesso wifi.

— Chris Stratton,

1

@ChrisStratton sì, ad esempio la whitelisting MAC è molto più sicura che avere semplicemente una password e cancellarla, ma questi passaggi sono per la sicurezza del wifi in generale, non per la privacy delle credenziali sui dispositivi pubblici.

— atakanyenel,

2

No, la whitelisting MAC è uno scherzo: non c'è alcun segreto lì. E ovviamente il MAC viene prontamente estratto dall'ESP8266 rubato o dal suo flash SPI. L'unico posto in cui la whitelisting MAC sarebbe utile è contro le persone che usano una GUI per unirsi alle reti wifi, o se un punto di accesso fosse seduto lì in attesa di una connessione da un client che potrebbe presentarsi un giorno, ma che non si era mai connesso ad esso - cioè , spada nella roba tipo pietra.

— Chris Stratton,

1

Risposta semplice - SÌ. Si può fare. Devi almeno eseguire una sorta di offuscamento per fornire una protezione minima.

— Amit Vujic
fonte

1

L'offuscamento rende più difficile scoprire come il dispositivo fa le cose, ma è inutile proteggere dalla clonazione del dispositivo. È inutile proteggere dall'estrazione di credenziali: tutto ciò che devi fare è eseguire il firmware in un emulatore.

— Gilles 'SO- smetti di essere malvagio' il

Completamente d'accordo. La mia motivazione a dare tale risposta è stata quella di notare che <la sicurezza della rete IoT deve essere considerata>. @Mike Ounsworth ha dato una risposta dettagliata suggerendo soluzioni che utilizzano l'infrastruttura AES e / o RSA. Sto pensando di dare un'altra risposta, ma non sono sicuro di come immergermi nella crittografia (sono anche per molti anni nelle soluzioni di pagamento e bancarie). La mia opinione è che dobbiamo fornire consigli pratici / equilibrati perché di solito le persone eviteranno di approfondire la crittografia per proteggere i dispositivi IoT nel suo cortile.

— Amit Vujic,

1

Se le persone vogliono creare dispositivi non sicuri perché non possono essere disturbati a capire come creare dispositivi sicuri, non vedo alcun motivo per abilitarli.

— Gilles 'SO- smetti di essere malvagio' il

La mia esperienza è che le persone vogliono imparare ma, di nuovo, deve esserci un equilibrio tra livello di sicurezza e complessità. C'è una storia famosa nel settore dei pagamenti riguardante SET ( en.wikipedia.org/wiki/Secure_Electronic_Transaction ) che è / era molto sicura ma complessa da implementare e per questo non è riuscita nella pratica.

— Amit Vujic,

2

L'offuscamento aggiunge complessità senza migliorare la sicurezza. Questo non è equilibrio.

— Gilles 'SO- smetti di essere malvagio' il