Passa al contenuto principale

11. Considerazioni sulla sicurezza

Questa sezione analizza le possibili minacce al protocollo. Il suo scopo è informare gli sviluppatori di protocolli e applicazioni sulle limitazioni di sicurezza di CoAP come descritto nel presente documento. Poiché CoAP realizza un sottoinsieme delle funzionalità di HTTP/1.1, le considerazioni sulla sicurezza della Sezione 15 di [RFC2616] sono pertinenti anche a CoAP. Questa sezione si concentra sulla descrizione delle limitazioni specifiche di CoAP.

11.1. Analisi del protocollo ed elaborazione degli URI​

Un'applicazione esposta alla rete può presentare vulnerabilità nella propria logica di elaborazione dei pacchetti in ingresso. I parser complessi sono noti come una probabile fonte di tali vulnerabilità, come la capacità di mandare in crash un nodo da remoto o persino di eseguire codice arbitrario su di esso da remoto. CoAP cerca di ridurre le occasioni di introdurre tali vulnerabilità riducendo la complessità del parser, attribuendo per quanto possibile un significato all'intera gamma di valori codificabili e riducendo in modo aggressivo la complessità spesso causata dalla scelta non necessaria tra più rappresentazioni che significano la stessa cosa. Gran parte dell'elaborazione degli URI è stata spostata sui client, riducendo ulteriormente le occasioni di introdurre vulnerabilità nei server. Anche così, il codice di elaborazione degli URI nelle implementazioni CoAP è probabilmente una grande fonte di vulnerabilità residue e dovrebbe essere implementato con particolare cura. Le implementazioni del controllo di accesso di CoAP devono assicurarsi di non introdurre vulnerabilità attraverso discrepanze tra il codice che deriva le decisioni di controllo di accesso da un URI e il codice che alla fine fornisce la risorsa indirizzata dall'URI. Il parser più complesso rimasto potrebbe essere quello per il CoRE Link Format, sebbene anche questo sia stato progettato con l'obiettivo di ridurre la complessità implementativa [RFC6690]. (Vedere anche la Sezione 15.2 di [RFC2616].)

11.2. Uso del proxy e caching​

Come menzionato nella Sezione 15.7 di [RFC2616], i proxy sono per loro stessa natura man-in-the-middle, e infrangono qualsiasi protezione IPsec o DTLS che uno scambio diretto di messaggi CoAP potrebbe avere. Sono quindi bersagli interessanti per violare la riservatezza o l'integrità degli scambi di messaggi CoAP. Come osservato in [RFC2616], sono anche bersagli interessanti per violare la disponibilità.

La minaccia alla riservatezza e all'integrità dei dati di richiesta/risposta è amplificata quando i proxy effettuano anche caching. Si noti che CoAP non definisce nessuna delle opzioni Cache-Control di soppressione della cache che HTTP/1.1 fornisce per proteggere meglio i dati sensibili.

Per un'implementazione di caching, tutte le considerazioni sul controllo di accesso che si applicherebbero all'effettuazione della richiesta che ha generato la voce di cache devono essere applicate anche al valore presente nella cache. Ciò è rilevante sia per i client che implementano più domini di sicurezza, sia per i proxy che possono servire più client. Inoltre, un proxy di caching non deve rendere disponibili i valori memorizzati nella cache a richieste che hanno proprietà di sicurezza del trasporto inferiori a quelle che il proxy richiederebbe per eseguire in primo luogo l'inoltro della richiesta (MUST NOT).

A differenza dello schema "coap", le risposte a richieste identificate da "coaps" non sono mai "public" e pertanto non devono essere riutilizzate per il caching condiviso, a meno che la cache non sia in grado di prendere decisioni di controllo di accesso equivalenti a quelle che hanno portato alla voce memorizzata nella cache (MUST NOT). Esse possono tuttavia essere riutilizzate in una cache privata se il messaggio è memorizzabile in cache per impostazione predefinita in CoAP.

Infine, un proxy che distribuisce Separate Responses (in contrapposizione alle piggybacked Responses) a più richiedenti originali può fornire un'amplificazione aggiuntiva (vedere la Sezione 11.3).

11.3. Rischio di amplificazione​

I server CoAP generalmente rispondono a un pacchetto di richiesta con un pacchetto di risposta. Questo pacchetto di risposta può essere significativamente più grande del pacchetto di richiesta. Un attaccante potrebbe usare i nodi CoAP per trasformare un piccolo pacchetto di attacco in un pacchetto di attacco più grande, un approccio noto come amplificazione. Esiste quindi il pericolo che i nodi CoAP possano essere coinvolti in attacchi denial-of-service (DoS) sfruttando le proprietà di amplificazione del protocollo: un attaccante che tenta di sovraccaricare una vittima ma è limitato nella quantità di traffico che può generare può usare l'amplificazione per generare una quantità maggiore di traffico.

Questo è particolarmente problematico nei nodi che abilitano l'accesso NoSec, sono accessibili da un attaccante e possono accedere a potenziali vittime (ad esempio, su Internet generale), poiché il protocollo UDP non fornisce alcun modo per verificare l'indirizzo di origine indicato nel pacchetto di richiesta. A un attaccante basta inserire l'indirizzo IP della vittima nell'indirizzo di origine di un opportuno pacchetto di richiesta per generare un pacchetto più grande diretto alla vittima.

Come fattore attenuante, molte reti vincolate saranno in grado di generare solo una piccola quantità di traffico, il che può rendere i nodi CoAP meno attraenti per questo attacco. Tuttavia, la capacità limitata della rete vincolata rende la rete stessa una probabile vittima di un attacco di amplificazione.

Pertanto, fattori di amplificazione elevati non dovrebbero essere forniti nella risposta se la richiesta non è autenticata (SHOULD NOT). Un server CoAP può ridurre la quantità di amplificazione che fornisce a un attaccante utilizzando le modalità slicing/blocking di CoAP [BLOCK] e offrendo rappresentazioni di risorse di grandi dimensioni solo in slices relativamente piccoli. Ad esempio, per una risorsa di 1000 byte, una richiesta di 10 byte potrebbe produrre una risposta di 80 byte (con un block di 64 byte) invece di una risposta di 1016 byte, riducendo considerevolmente l'amplificazione fornita.

CoAP supporta anche l'uso di indirizzi IP multicast nelle richieste, un requisito importante per M2M. Le richieste CoAP multicast possono essere la fonte di attacchi DoS accidentali o deliberati, specialmente su reti vincolate. Questa specifica cerca di ridurre gli effetti di amplificazione delle richieste multicast limitando il momento in cui viene restituita una risposta. Per limitare la possibilità di uso malevolo, i server CoAP non dovrebbero accettare richieste multicast che non possano essere autenticate in qualche modo, crittograficamente o tramite qualche confine multicast che limiti le potenziali fonti (SHOULD NOT). Se possibile, un server CoAP dovrebbe limitare il supporto per le richieste multicast alle risorse specifiche in cui la funzionalità è richiesta (SHOULD).

Su alcuni sistemi operativi general-purpose che forniscono un'API in stile POSIX [IEEE1003.1], non è semplice stabilire se un pacchetto ricevuto fosse indirizzato a un indirizzo multicast. Mentre molte implementazioni sapranno se hanno aderito a un gruppo multicast, ciò crea un problema per i pacchetti indirizzati a indirizzi multicast del tipo FF0x::1, che vengono ricevuti da ogni nodo IPv6. Le implementazioni dovrebbero fare uso di API moderne come IPV6_RECVPKTINFO [RFC3542], se disponibili, per effettuare questa determinazione (SHOULD).

11.4. Attacchi di spoofing dell'indirizzo IP​

A causa dell'assenza di un handshake in UDP, un endpoint malintenzionato libero di leggere e scrivere i messaggi trasportati dalla rete vincolata (cioè distribuzioni NoSec o PreSharedKey con un rapporto nodi/chiave > 1:1) può facilmente attaccare un singolo endpoint, un gruppo di endpoint, nonché l'intera rete, ad esempio:

  1. falsificando un messaggio Reset in risposta a un messaggio Confirmable o a un messaggio Non-confirmable, rendendo così un endpoint "sordo"; oppure

  2. falsificando un ACK in risposta a un messaggio CON, impedendo così potenzialmente al mittente del messaggio CON di ritrasmettere e soffocando la risposta effettiva; oppure

  3. falsificando l'intera risposta con payload/options contraffatti (questo ha diversi livelli di impatto: dall'interruzione di una singola risposta, ad attacchi molto più audaci all'infrastruttura di supporto, ad esempio avvelenando le cache dei proxy, o ingannando le interfacce di validazione/ricerca nei resource directory e, più in generale, qualsiasi componente che memorizza stato di rete globale e usa CoAP come mezzo di messaggistica per gestire l'impostazione o l'aggiornamento dello stato è un potenziale bersaglio.); oppure

  4. falsificando una richiesta multicast per un nodo di destinazione; ciò può provocare congestione/collasso della rete, un attacco DoS alla vittima, o un risveglio forzato dallo stato di sonno; oppure

  5. falsificando messaggi observe, ecc.

Lo spoofing delle risposte da parte di attaccanti off-path può essere rilevato e mitigato anche senza sicurezza a livello di trasporto scegliendo un token non banale e randomizzato nella richiesta (Sezione 5.3.1). [RFC4086] discute i requisiti di casualità per la sicurezza.

In linea di principio, altri tipi di spoofing possono essere rilevati da CoAP solo nel caso in cui venga usata la semantica dei messaggi Confirmable, a causa di messaggi Acknowledgement o Reset inattesi provenienti dall'endpoint ingannato. Ma questo impone di tenere traccia dei Message IDs utilizzati, cosa non sempre possibile, e inoltre il rilevamento diventa disponibile di solito solo dopo che il danno è già stato fatto. Questo tipo di attacco può essere prevenuto utilizzando modalità di sicurezza diverse da NoSec.

Con o senza spoofing dell'indirizzo di origine, un client può tentare di sovraccaricare un server inviando richieste, preferibilmente complesse, a un server; lo spoofing degli indirizzi rende più difficile risalire all'attacco e bloccarlo. Dato che il costo di una richiesta CON è piccolo, questo attacco può essere eseguito facilmente. Sotto questo attacco, un nodo vincolato con energia totale disponibile limitata può esaurire tale energia molto più rapidamente del previsto (attacco di esaurimento della batteria). Inoltre, se il client usa un messaggio Confirmable e il server risponde con una separate response Confirmable a un indirizzo (possibilmente falsificato) che non risponde, il server dovrà allocare buffer e logica di ritrasmissione per ogni risposta fino all'esaurimento di MAX_TRANSMIT_SPAN, rendendo più probabile che esaurisca le risorse per l'elaborazione del traffico legittimo. Quest'ultimo problema può essere in qualche modo mitigato limitando la frequenza delle risposte come discusso nella Sezione 4.7. Un attaccante potrebbe anche falsificare l'indirizzo di un client legittimo; ciò potrebbe indurre il server, se usa separate responses, a bloccare le risposte legittime a quel client a causa di NSTART=1. Tutti questi attacchi possono essere prevenuti utilizzando una modalità di sicurezza diversa da NoSec, lasciando così solo gli attacchi al protocollo di sicurezza.

11.5. Attacchi cross-protocol​

La capacità di indurre un endpoint CoAP a inviare pacchetti a un indirizzo di origine falso può essere usata non solo per l'amplificazione, ma anche per attacchi cross-protocol contro una vittima in ascolto di pacchetti UDP a un dato indirizzo (indirizzo IP e porta). Ciò si verificherebbe come segue:

  • L'attaccante invia un messaggio a un endpoint CoAP con il dato indirizzo come indirizzo di origine falso.

  • L'endpoint CoAP risponde con un messaggio all'indirizzo di origine dato.

  • La vittima al dato indirizzo riceve un pacchetto UDP che interpreta secondo le regole di un protocollo diverso.

Ciò può essere usato per aggirare regole del firewall che impediscono la comunicazione diretta dall'attaccante alla vittima ma che per caso consentono la comunicazione dall'endpoint CoAP (che può anche ospitare un ruolo valido nell'altro protocollo) alla vittima.

Inoltre, gli endpoint CoAP possono essere vittime di un attacco cross-protocol generato attraverso un endpoint di un altro protocollo basato su UDP, come DNS. In entrambi i casi, gli attacchi sono possibili se le proprietà di sicurezza degli endpoint si basano sulla verifica degli indirizzi IP (e sull'isolamento tramite firewall degli attacchi diretti inviati dall'esterno usando indirizzi IP falsi). In generale, a causa della loro mancanza di contesto, i protocolli basati su UDP sono bersagli relativamente facili per gli attacchi cross-protocol.

Infine, gli URI CoAP trasportati con altri mezzi potrebbero essere usati per indurre i client a inviare messaggi a endpoint di altri protocolli.

Una mitigazione contro gli attacchi cross-protocol è il controllo rigoroso della sintassi dei pacchetti ricevuti, combinato con una differenza sufficiente nella sintassi. Ad esempio, potrebbe aiutare se fosse difficile indurre un server DNS a inviare una risposta DNS che superi i controlli di un endpoint CoAP. Sfortunatamente, i primi due byte di una risposta DNS sono un ID che può essere scelto dall'attaccante e che si mappa nella parte interessante dell'header CoAP, e i due byte successivi vengono quindi interpretati come Message ID di CoAP (cioè qualsiasi valore è accettabile). Le count words DNS possono essere interpretate come più istanze di un'opzione CoAP 0 (inesistente ma elective), o possibilmente come un Token. La query ripetuta (echoed) infine può essere fabbricata dall'attaccante per ottenere un effetto desiderato sull'endpoint CoAP; la risposta aggiunta dal server (se presente) potrebbe quindi essere semplicemente interpretata come payload aggiuntivo.

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       | T, TKL, code
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   | Message ID
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Figura 15: Header DNS ([RFC1035], Sezione 4.1.1) rispetto al messaggio CoAP

In generale, per qualsiasi coppia di protocolli, uno dei protocolli può benissimo essere stato progettato in modo da consentire a un attaccante di causare la generazione di risposte che sembrano messaggi dell'altro protocollo. Spesso è molto più difficile garantire o dimostrare l'assenza di attacchi praticabili che generare esempi che potrebbero non consentire ancora completamente un attacco ma che potrebbero essere ulteriormente sviluppati da menti più creative. Gli attacchi cross-protocol possono quindi essere completamente mitigati solo se gli endpoint non autorizzano azioni desiderate da un attaccante basandosi semplicemente sulla fiducia nell'indirizzo IP di origine di un pacchetto. Al contrario, un ambiente NoSec che si affida completamente a un firewall per la sicurezza di CoAP non deve solo isolare tramite firewall gli endpoint CoAP, ma anche tutti gli altri endpoint che potrebbero essere indotti a inviare messaggi UDP agli endpoint CoAP utilizzando qualche altro protocollo basato su UDP.

Oltre alle considerazioni di cui sopra, si applicano le considerazioni sulla sicurezza per DTLS rispetto agli attacchi cross-protocol. Ad esempio, se la stessa security association ("connection") DTLS viene usata per trasportare dati di più protocolli, DTLS non fornisce più protezione contro gli attacchi cross-protocol tra questi protocolli.

11.6. Considerazioni sui nodi vincolati​

Gli implementatori sui nodi vincolati spesso si trovano senza una buona fonte di entropia [RFC4086]. In tal caso, il nodo non deve essere usato per processi che richiedono buona entropia, come la generazione di chiavi (MUST NOT). Al contrario, le chiavi dovrebbero essere generate esternamente e aggiunte al dispositivo durante la produzione o la messa in servizio.

A causa della loro scarsa potenza di elaborazione, i nodi vincolati sono particolarmente suscettibili agli attacchi temporali (timing attacks). Bisogna prestare particolare attenzione nell'implementazione delle primitive crittografiche.

Grandi quantità di nodi vincolati saranno installati in ambienti esposti e avranno scarsa resistenza alla manomissione, inclusa la compromissione del materiale di chiave. Ciò deve essere considerato quando si definisce l'ambito delle credenziali a essi assegnate. In particolare, assegnare una chiave condivisa a un gruppo di nodi può rendere qualsiasi singolo nodo vincolato un bersaglio per sovvertire l'intero gruppo.