OWASP Guida alla sicurezza in stile 10 per l'implementazione nei dispositivi hardware

1. Account di test backdoor.

Gli ingegneri spesso includono meccanismi di backdoor e test di conti in hardware a scopo di debug, con misure di sicurezza banali o non messe in atto per proteggerli. Sfortunatamente, un gran numero di dispositivi arriva sul mercato senza che questi meccanismi e account siano disabilitati, consentendo agli aggressori di ottenere l'accesso illegittimo al dispositivo.

2. Protocolli di gestione della rete non protetti.

Molti dispositivi implementano SNMP o UPnP per la gestione remota, ma non riescono a implementare livelli di sicurezza di base. Le apparecchiature per ufficio, l'hardware di rete, i sistemi di controllo industriale, ecc. Spesso perdono dati sensibili (come la tabella di routing) tramite SNMP e possono fornire varie funzioni di controllo tramite UPnP. Molti dispositivi abilitati UPnP implementano le funzioni standard di gestione dell'interfaccia di rete, che consentono a un utente malintenzionato di disabilitare un'interfaccia di rete. Ulteriori funzioni possono consentire a un utente malintenzionato di danneggiare in modo permanente il dispositivo o causare gravi problemi di funzionalità.

3. Overflow del buffer.

Le implementazioni hardware sono notoriamente negative per non controllare le dimensioni del buffer di destinazione e possono consentire il completo danneggiamento dello stato della memoria. Ciò può comportare l'esecuzione di codice, ma più comunemente si traduce semplicemente in una condizione di negazione del servizio, in cui il dispositivo deve essere hard-reset prima che possa essere riutilizzato.

4. Intero overflow / underflow.

Si verificano quando un input intero senza segno viene trattato come firmato, oppure un tipo intero più grande viene lanciato direttamente su un tipo intero più piccolo. Entrambi questi problemi possono causare casi in cui un valore non rientra nell'intervallo previsto, il che può causare il superamento dei controlli dell'intervallo dell'array e del buffer di lunghezza nonostante il buffer di input sia troppo grande. Questi possono anche risultare in condizioni di lettura-dove-dove, dove un indice di array negativo porta a operazioni di memoria che accedono a regioni di memoria precedenti.

5. Controlli sanitari insufficienti.

I valori di input nelle implementazioni hardware sono generalmente considerati con una strong integrità, quindi i controlli di integrità spesso non vengono eseguiti. Ciò potrebbe consentire a un utente malintenzionato di fornire un valore imprevisto e modificare il comportamento del dispositivo. Un esempio comune di questo è quando viene utilizzato un set di bit-flag e vengono impostati bit in conflitto.

6. Segreti condivisi e codificati incorporati nella memoria non volatile.

I progettisti dell'hardware a volte sono delusi dal fatto che, poiché qualcosa è memorizzato in un chip EEPROM su una scheda, i dati al suo interno non possono / non possono essere letti da qualcuno che desidera interferire con il dispositivo. È comune trovare chiavi crittografiche codificate e altre credenziali memorizzate nel firmware di un dispositivo. Questi potrebbero essere usati per compromettere il dispositivo o le sue comunicazioni e sono spesso gli stessi su tutti i dispositivi dello stesso modello.

7. Crypto di scarsa qualità, autoprogettato o mancante.

Spesso è complicato implementare algoritmi crittografici adeguati nei sistemi embedded, specialmente quando si lavora con meno microcontrollori e microprocessori widesrpead. Le implementazioni di riferimento assumono spesso architetture simil-x86 o ARM, che aumentano il fattore lavoro. Gli ingegneri di solito non hanno le conoscenze e l'esperienza per implementare correttamente la crittografia. Di conseguenza, gli algoritmi crittografici presenti nei sistemi embedded tendono a essere implementati in modo inadeguato o sono progetti di brew casalinghi con gravi difetti di sicurezza. Molti sistemi mancano completamente di qualsiasi forma di hashing su password e altre credenziali. Questo tipo di dati può essere in genere estratto dalla memoria non volatile utilizzando strumenti disponibili in commercio.

8. Mancanza di strong integrità e controllo dell'autenticità sugli aggiornamenti del firmware.

L'integrità del firmware del dispositivo viene spesso controllata tramite un hash CRC32 o MD5, ma raramente viene autenticata tramite qualsiasi mezzo strong. Molti produttori si affidano all'oscurità come misura di sicurezza. Mentre il costo del reverse engineering del firmware di un dispositivo può essere considerevole, sta diventando meno con l'avvento di architetture a microprocessore comuni (ad esempio ARM) in sistemi embedded. Una volta che un utente malintenzionato ottiene la possibilità di caricare un'immagine del firmware, potrebbe sovvertire completamente il sistema.

9. Vari difetti di applicazione web nei pannelli di controllo.

Molti dei difetti delle applicazioni Web di Top 10 OWASP sono fastidiosamente comuni nei pannelli di controllo Web per dispositivi incorporati. CSRF, XSS e la funzionalità di furto di sessione sono presenti nell'elenco delle vulnerabilità comuni, sebbene SQLi sia meno comune a causa del numero relativamente basso di sistemi che implementano un database relazionale completo.

10. Servizi di rete associati in modo errato.

Molti servizi di rete su dispositivi embedded sono configurati per il collegamento a 0.0.0.0, anziché direttamente a un indirizzo IP LAN. Ciò potrebbe consentire a un utente malintenzionato di comunicare con il dispositivo dall'esterno della LAN. La corretta configurazione della segregazione e del firewall può aiutare a mitigarlo, ma è ancora un problema.

La sicurezza delle informazioni è una disciplina di sistema in quanto richiede una conoscenza approfondita di un intero sistema di informazione (comprese le persone) per avere successo. Hardware e software non possono mai essere più di pezzi in un sistema più grande. Fare analisi di sicurezza su un sistema embedded richiede la comprensione di come verrà utilizzato dalle persone nel sistema. Una buona analisi del sistema sarà sempre migliore di una lista di controllo.

1. Facile accesso fisico a parti o componenti critici per la sicurezza.

Alcune parti di un dispositivo incorporato saranno fondamentali per funzionare in modo sicuro e altre parti no. Dispositivi ben progettati renderanno difficile accedere a tali componenti con una varietà di tecniche. Le tecniche semplici includono l'esclusione delle viti e l'uso di piastre solide per coprire l'esterno del dispositivo. I test richiedono un esperto di smontaggio.

2. Mettere troppa fiducia in un componente unico del design.

Dai connettori personalizzati che "nessun altro può ottenere" a frequenze univoche che "nessun altro usa" queste funzionalità di progettazione di solito danneggiano gli utenti autorizzati più degli utenti non autorizzati. Effettivamente rendendo il dispositivo più costoso da usare. Non c'è modo di testare direttamente la concentrazione di fiducia, ma l'analisi delle modalità di errore e degli stati del sistema può aiutare a identificare singoli punti di errore.

3. Non proteggere i progetti, i diagrammi e i manuali di manutenzione.

Questi documenti e informazioni aiutano l'utente malintenzionato a trovare i punti fisici fisici e ad identificare i componenti critici per la sicurezza del dispositivo. La mitigazione riguarda la contabilità di documenti e attrezzature e il controllo regolare

4. Digita tutti i dispositivi dello stesso design con la stessa chiave.

In questo modo, quando un dispositivo viene compromesso, tutti vengono compromessi. A seconda del numero totale di dispositivi e minacce nell'ambiente, le chiavi potrebbero essere modificate per dispositivo o per lotto. Il numero di dispositivi in un lotto sarà un compromesso tra l'efficienza di utilizzo delle chiavi e il danno fatto quando la chiave di un lotto è compromessa.

5. Non progettare un sistema di rekeying.

Quasi tutti i dispositivi sicuri richiedono una o più chiavi crittografiche. Nel tempo, poiché i dispositivi sono esposti a un ambiente di minaccia, una o più chiavi verranno compromesse. Quando ciò accade, è bello poter ri-digitare un dispositivo invece di rimuoverlo per le parti. È particolarmente importante testare le modalità di guasto della funzionalità di rekeying.

6. Non costruire nel rilevamento antimanomissione

Senza il rilevamento della manomissione non è possibile creare alcun meccanismo attivo contro la manomissione. I meccanismi includono la disinfezione dei dati sensibili, la distruzione delle chiavi o il "bricking" del dispositivo.

7. Schermatura RF inadeguata

Ciò potrebbe esporre segnali fuori banda all'ambiente che potrebbero essere utilizzati per inferire informazioni importanti sul funzionamento sicuro del dispositivo. Un semplice esempio sta determinando il successo o il fallimento di una richiesta sicura. Molti sistemi impiegano più tempo quando una richiesta è parzialmente riuscita, quindi quando nessuna parte della richiesta ha esito positivo. Questo è spesso descritto come un attacco di canale laterale.

Potresti dare un'occhiata ai profili di protezione dei criteri comuni , ovviamente un elenco non esaustivo, ma in effetti un elenco dei requisiti per diversi sistemi. Alcuni potrebbero coprire ciò che stai sviluppando.

Ogni profilo di protezione (PP) segue un formato che introduce l'obiettivo di valutazione (TOE) e gli obiettivi per proteggere il TOE. Una PP è quindi una formula dei requisiti formali per la valutazione dei criteri comuni.

Un esempio di PP è PP del governo degli Stati Uniti per i sistemi operativi di rete di uso generale . Un requisito specifico, qui per il controllo, è presentato come segue:

The TSF [the OSes trusted security functions] shall provide authorized administrators with the capability to read all audit information from the audit records

Inoltre, le minacce al sistema sono presentate e formalizzate:

[Threat T.CRYPTO_COMPROMISE:] A malicious user or process may cause key, data or executable code associated with the cryptographic functionality to be inappropriately accessed (viewed, modified, or deleted), thus compromising the cryptographic mechanisms and the data protected by those mechanisms.

In conclusione, le minacce sono considerate:

Each of the identified threats to security is addressed by one or more security objectives. [Provided is a ] mapping from security objectives to threats, as well as a rationale that discusses how the threat is addressed. Definitions are provided (in italics) below each threat and security objective so the PP reader can reference these without having to go back to sections 3 and 4 [, which are sections discussing the security environment and objectives].