11. Considérations de sécurité
Cette section analyse les menaces possibles pesant sur le protocole. Elle vise à informer les développeurs de protocoles et d'applications des limitations de sécurité de CoAP telles que décrites dans le présent document. Comme CoAP réalise un sous-ensemble des fonctionnalités de HTTP/1.1, les considérations de sécurité de la section 15 de [RFC2616] sont également pertinentes pour CoAP. La présente section se concentre sur la description des limitations propres à CoAP.
11.1. Analyse du protocole et traitement des URI
Une application exposée au réseau peut présenter des vulnérabilités dans sa logique de traitement des paquets entrants. Les analyseurs syntaxiques (parsers) complexes sont bien connus comme une source probable de telles vulnérabilités, par exemple la capacité de faire planter un nœud à distance, voire d'y exécuter arbitrairement du code à distance. CoAP s'efforce de réduire les occasions d'introduire de telles vulnérabilités en diminuant la complexité des analyseurs, en donnant si possible une signification à toute la plage des valeurs encodables, et en réduisant agressivement la complexité souvent causée par un choix inutile entre plusieurs représentations signifiant la même chose. Une grande partie du traitement des URI a été déplacée vers les clients, ce qui réduit encore les occasions d'introduire des vulnérabilités dans les serveurs. Malgré cela, le code de traitement des URI dans les implémentations de CoAP est probablement une source importante de vulnérabilités résiduelles et devrait être implémenté avec un soin particulier. Les implémentations de contrôle d'accès CoAP doivent s'assurer qu'elles n'introduisent pas de vulnérabilités par des divergences entre le code qui déduit les décisions de contrôle d'accès à partir d'un URI et le code qui finit par servir la ressource adressée par cet URI. L'analyseur le plus complexe qui subsiste pourrait être celui du CoRE Link Format, bien que ce format ait lui aussi été conçu dans le but de réduire la complexité d'implémentation [RFC6690]. (Voir aussi la section 15.2 de [RFC2616].)
11.2. Mise en proxy et mise en cache
Comme mentionné à la section 15.7 de [RFC2616], les proxys sont par nature des hommes du milieu (man-in-the-middle), qui rompent toute protection IPsec ou DTLS qu'un échange direct de messages CoAP pourrait présenter. Ils constituent donc des cibles intéressantes pour briser la confidentialité ou l'intégrité des échanges de messages CoAP. Comme indiqué dans [RFC2616], ce sont aussi des cibles intéressantes pour briser la disponibilité.
La menace pesant sur la confidentialité et l'intégrité des données de requête/réponse est amplifiée lorsque les proxys effectuent aussi de la mise en cache. Notez que CoAP ne définit aucune des options Cache-Control de suppression du cache que HTTP/1.1 fournit pour mieux protéger les données sensibles.
Pour une implémentation avec cache, toutes les considérations de contrôle d'accès qui s'appliqueraient à l'émission de la requête ayant généré l'entrée de cache doivent aussi s'appliquer à la valeur présente dans le cache. Cela est pertinent pour les clients qui mettent en œuvre plusieurs domaines de sécurité, ainsi que pour les proxys susceptibles de servir plusieurs clients. De plus, un proxy avec cache ne doit pas rendre des valeurs mises en cache accessibles à des requêtes présentant des propriétés de sécurité de transport moindres que celles que le proxy exigerait pour effectuer le transfert de la requête (MUST NOT).
Contrairement au schéma "coap", les réponses aux requêtes identifiées par "coaps" ne sont jamais "public" et ne doivent donc pas être réutilisées pour une mise en cache partagée, sauf si le cache est capable de prendre des décisions de contrôle d'accès équivalentes à celles qui ont conduit à l'entrée mise en cache (MUST NOT). Elles peuvent toutefois être réutilisées dans un cache privé si le message est cachable par défaut dans CoAP.
Enfin, un proxy qui diffuse (fan out) des Separate Responses (par opposition aux piggybacked Responses) vers plusieurs demandeurs d'origine peut fournir une amplification supplémentaire (voir la section 11.3).
11.3. Risque d'amplification
Les serveurs CoAP répondent généralement à un paquet de requête par un paquet de réponse. Ce paquet de réponse peut être nettement plus volumineux que le paquet de requête. Un attaquant pourrait utiliser des nœuds CoAP pour transformer un petit paquet d'attaque en un paquet d'attaque plus volumineux, approche connue sous le nom d'amplification. Il existe donc un danger que des nœuds CoAP se trouvent impliqués dans des attaques par déni de service (denial-of-service, DoS) en exploitant les propriétés amplificatrices du protocole : un attaquant qui tente de surcharger une victime mais dont la quantité de trafic qu'il peut générer est limitée peut utiliser l'amplification pour générer un volume de trafic plus important.
C'est particulièrement problématique pour les nœuds qui autorisent l'accès NoSec, sont accessibles depuis un attaquant et peuvent accéder à des victimes potentielles (par exemple sur l'Internet général), car le protocole UDP n'offre aucun moyen de vérifier l'adresse source indiquée dans le paquet de requête. Il suffit à un attaquant de placer l'adresse IP de la victime dans l'adresse source d'un paquet de requête approprié pour générer un paquet plus volumineux dirigé vers la victime.
Comme facteur atténuant, de nombreux réseaux contraints ne seront capables de générer qu'une faible quantité de trafic, ce qui peut rendre les nœuds CoAP moins attrayants pour cette attaque. Toutefois, la capacité limitée du réseau contraint fait du réseau lui-même une victime probable d'une attaque par amplification.
Par conséquent, de grands facteurs d'amplification ne devraient pas être fournis dans la réponse si la requête n'est pas authentifiée (SHOULD NOT). Un serveur CoAP peut réduire la quantité d'amplification qu'il offre à un attaquant en utilisant les modes de découpage/blocage (slicing/blocking) de CoAP [BLOCK] et en ne proposant de grandes représentations de ressources que sous forme de tranches relativement petites. Par exemple, pour une ressource de 1000 octets, une requête de 10 octets pourrait produire une réponse de 80 octets (avec un bloc de 64 octets) au lieu d'une réponse de 1016 octets, ce qui réduit considérablement l'amplification fournie.
CoAP prend également en charge l'utilisation d'adresses IP multicast dans les requêtes, exigence importante pour le M2M. Les requêtes CoAP multicast peuvent être à l'origine d'attaques DoS accidentelles ou délibérées, en particulier sur les réseaux contraints. La présente spécification tente de réduire les effets d'amplification des requêtes multicast en limitant les cas où une réponse est renvoyée. Pour limiter la possibilité d'un usage malveillant, les serveurs CoAP ne devraient pas accepter les requêtes multicast qui ne peuvent pas être authentifiées d'une manière ou d'une autre, que ce soit par des moyens cryptographiques ou par une frontière multicast limitant les sources potentielles (SHOULD NOT). Si possible, un serveur CoAP devrait limiter la prise en charge des requêtes multicast aux ressources spécifiques où cette fonctionnalité est requise (SHOULD).
Sur certains systèmes d'exploitation à usage général fournissant une API de style POSIX [IEEE1003.1], il n'est pas simple de déterminer si un paquet reçu était adressé à une adresse multicast. Bien que de nombreuses implémentations sachent si elles ont rejoint un groupe multicast, cela pose un problème pour les paquets adressés à des adresses multicast de la forme FF0x::1, qui sont reçus par tout nœud IPv6. Les implémentations devraient utiliser des API modernes telles que IPV6_RECVPKTINFO [RFC3542], lorsqu'elles sont disponibles, pour effectuer cette détermination (SHOULD).
11.4. Attaques par usurpation d'adresse IP
En raison de l'absence de poignée de main dans UDP, un point de terminaison malveillant libre de lire et d'écrire les messages transportés par le réseau contraint (c'est-à-dire les déploiements NoSec ou PreSharedKey avec un rapport nœuds/clé > 1:1) peut facilement attaquer un point de terminaison isolé, un groupe de points de terminaison, voire tout le réseau, par exemple en :
-
usurpant un message Reset en réponse à un message Confirmable ou Non-confirmable, rendant ainsi un point de terminaison « sourd » ; ou
-
usurpant un ACK en réponse à un message CON, empêchant ainsi potentiellement l'émetteur du message CON de retransmettre et étouffant la réponse réelle ; ou
-
usurpant la totalité de la réponse avec un payload/des options forgés (cela a différents niveaux d'impact : de la perturbation d'une réponse isolée à des attaques bien plus audacieuses contre l'infrastructure de support, par exemple l'empoisonnement des caches de proxy, ou la tromperie des interfaces de validation/recherche dans les annuaires de ressources ; et, plus généralement, tout composant qui stocke un état réseau global et utilise CoAP comme moyen de messagerie pour définir ou mettre à jour un état est une cible potentielle.) ; ou
-
usurpant une requête multicast pour un nœud cible ; cela peut entraîner une congestion/un effondrement du réseau, une attaque DoS contre la victime, ou un réveil forcé de nœuds en sommeil ; ou
-
usurpant des messages observe, etc.
L'usurpation de réponse par des attaquants hors chemin (off-path) peut être détectée et atténuée même sans sécurité de couche transport en choisissant un token non trivial et aléatoire dans la requête (section 5.3.1). [RFC4086] traite des exigences en matière d'aléa pour la sécurité.
En principe, les autres types d'usurpation ne peuvent être détectés par CoAP que lorsque la sémantique de message Confirmable est utilisée, en raison de messages Acknowledgement ou Reset inattendus provenant du point de terminaison trompé. Mais cela impose de tenir la comptabilité des Message IDs utilisés, ce qui n'est pas toujours possible, et de plus la détection n'est généralement disponible qu'après que le dommage a déjà été causé. Ce type d'attaque peut être empêché en utilisant des modes de sécurité autres que NoSec.
Avec ou sans usurpation d'adresse source, un client peut tenter de surcharger un serveur en lui envoyant des requêtes, de préférence complexes ; l'usurpation d'adresse rend plus difficile la traçabilité et le blocage de cette attaque. Étant donné que le coût d'une requête CON est faible, cette attaque peut facilement être exécutée. Sous cette attaque, un nœud contraint dont l'énergie totale disponible est limitée peut épuiser cette énergie bien plus rapidement que prévu (attaque par épuisement de batterie). De plus, si le client utilise un message Confirmable et que le serveur répond par une Confirmable separate response à une adresse (éventuellement usurpée) qui ne répond pas, le serveur devra allouer de la mémoire tampon et une logique de retransmission pour chaque réponse jusqu'à l'épuisement de MAX_TRANSMIT_SPAN, ce qui rend plus probable l'épuisement de ses ressources pour traiter le trafic légitime. Ce dernier problème peut être quelque peu atténué en limitant le débit des réponses comme discuté à la section 4.7. Un attaquant pourrait aussi usurper l'adresse d'un client légitime ; cela pourrait amener le serveur, s'il utilise des separate responses, à bloquer les réponses légitimes destinées à ce client en raison de NSTART=1. Toutes ces attaques peuvent être empêchées en utilisant un mode de sécurité autre que NoSec, ne laissant ainsi que les attaques contre le protocole de sécurité.
11.5. Attaques inter-protocoles
La capacité d'inciter un point de terminaison CoAP à envoyer des paquets vers une fausse adresse source peut servir non seulement à l'amplification, mais aussi à des attaques inter-protocoles (cross-protocol attacks) contre une victime qui écoute des paquets UDP à une adresse donnée (adresse IP et port). Cela se produirait comme suit :
-
L'attaquant envoie un message à un point de terminaison CoAP en utilisant l'adresse donnée comme fausse adresse source.
-
Le point de terminaison CoAP répond par un message à l'adresse source donnée.
-
La victime à l'adresse donnée reçoit un paquet UDP qu'elle interprète selon les règles d'un autre protocole.
Cela peut servir à contourner les règles de pare-feu qui empêchent la communication directe de l'attaquant vers la victime mais se trouvent autoriser la communication du point de terminaison CoAP (qui peut aussi tenir un rôle valide dans l'autre protocole) vers la victime.
De plus, les points de terminaison CoAP peuvent être victimes d'une attaque inter-protocoles générée via un point de terminaison d'un autre protocole fondé sur UDP, tel que DNS. Dans les deux cas, les attaques sont possibles si les propriétés de sécurité des points de terminaison reposent sur la vérification des adresses IP (et sur le blocage par pare-feu des attaques directes envoyées de l'extérieur à l'aide de fausses adresses IP). En général, en raison de leur manque de contexte, les protocoles fondés sur UDP sont des cibles relativement faciles pour les attaques inter-protocoles.
Enfin, des URI CoAP transportés par d'autres moyens pourraient être utilisés pour inciter des clients à envoyer des messages à des points de terminaison d'autres protocoles.
Une atténuation contre les attaques inter-protocoles consiste en une vérification stricte de la syntaxe des paquets reçus, combinée à une différence de syntaxe suffisante. Par exemple, il pourrait être utile qu'il soit difficile d'inciter un serveur DNS à envoyer une réponse DNS qui passerait les contrôles d'un point de terminaison CoAP. Malheureusement, les deux premiers octets d'une réponse DNS sont un ID qui peut être choisi par l'attaquant et qui se projette sur la partie intéressante de l'en-tête CoAP, et les deux octets suivants sont alors interprétés comme la Message ID de CoAP (c'est-à-dire que toute valeur est acceptable). Les mots de comptage DNS peuvent être interprétés comme de multiples instances d'une option CoAP 0 (inexistante mais élective), ou éventuellement comme un Token. La requête renvoyée en écho peut enfin être fabriquée par l'attaquant pour obtenir un effet souhaité sur le point de terminaison CoAP ; la réponse ajoutée par le serveur (le cas échéant) pourrait alors simplement être interprétée comme un payload ajouté.
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)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 15 : En-tête DNS ([RFC1035], section 4.1.1) par rapport au message CoAP
En général, pour toute paire de protocoles, l'un des protocoles peut très bien avoir été conçu d'une manière qui permet à un attaquant de provoquer la génération de réponses ressemblant à des messages de l'autre protocole. Il est souvent bien plus difficile de garantir ou de prouver l'absence d'attaques viables que de produire des exemples qui ne permettent pas encore complètement une attaque mais pourraient être développés davantage par des esprits plus créatifs. Les attaques inter-protocoles ne peuvent donc être complètement atténuées que si les points de terminaison n'autorisent pas les actions souhaitées par un attaquant sur la seule base de la confiance accordée à l'adresse IP source d'un paquet. Inversement, un environnement NoSec qui s'en remet entièrement à un pare-feu pour la sécurité de CoAP doit non seulement isoler par pare-feu les points de terminaison CoAP, mais aussi tous les autres points de terminaison susceptibles d'être incités à envoyer des messages UDP aux points de terminaison CoAP au moyen de quelque autre protocole fondé sur UDP.
Outre les considérations ci-dessus, les considérations de sécurité relatives à DTLS en ce qui concerne les attaques inter-protocoles s'appliquent. Par exemple, si la même association de sécurité DTLS ("connexion") est utilisée pour transporter des données de plusieurs protocoles, DTLS ne fournit plus de protection contre les attaques inter-protocoles entre ces protocoles.
11.6. Considérations sur les nœuds contraints
Les implémenteurs sur les nœuds contraints se trouvent souvent dépourvus de bonne source d'entropie [RFC4086]. Si tel est le cas, le nœud ne doit pas être utilisé pour des processus exigeant une bonne entropie, tels que la génération de clés (MUST NOT). Les clés devraient plutôt être générées à l'extérieur et ajoutées au dispositif lors de la fabrication ou de la mise en service (commissioning).
En raison de leur faible puissance de traitement, les nœuds contraints sont particulièrement sensibles aux attaques temporelles (timing attacks). Un soin particulier doit être apporté à l'implémentation des primitives cryptographiques.
Un grand nombre de nœuds contraints seront installés dans des environnements exposés et opposeront peu de résistance à la falsification, y compris à la récupération du matériel de clé (keying materials). Cela doit être pris en compte lors de la définition de la portée des credentials qui leur sont attribués. En particulier, attribuer une clé partagée à un groupe de nœuds peut faire de n'importe quel nœud contraint pris isolément une cible permettant de subvertir tout le groupe.