Ripple20 : la sécurité de l’IoT menacée par un « effet supply chain »

Lumière est faite sur Ripple20.

On a donné ce nom à un ensemble de failles de sécurité qui affectent potentiellement des centaines de millions, voire des milliards d’objets connectés.

À l’origine de ces révélations, il y a les travaux d’une entreprise israélienne de conseil en cybersécurité. Et au bout du compte, une procédure à grande échelle qui a impliqué plusieurs CERT nationaux.

Ce périmètre d’action s’explique par l’« effet supply chain » que présentent les failles en question. À savoir qu’on a fini, au fil du temps, par perdre la trace des technologies qui les abritent.

Pour mieux saisir le problème, il faut revenir à la nature même des vulnérabilités. Au nombre de 19, elles touchent une bibliothèque TCP/IP qui date des années 90.

L’éditeur américain Treck, concepteur de cette bibliothèque, la commercialise au format code source. Ses acheteurs peuvent ensuite l’exploiter à leur guise, y compris sous d’autres marques. Il est d’autant plus difficile d’en garder trace au fil des implémentations.

Le phénomène est renforcé par le fait que la bibliothèque n’est pas systématiquement installée directement sur les appareils auxquels elle apporte la pile TCP/IP. Les fournisseurs de ces systèmes tiers ne sont, a fortiori, plus forcément en activité.

Treck lui-même n’a pas été en mesure de fournir une liste fiable des utilisateurs de sa bibliothèque. Pour toutes ces raisons, doublées d’accords de non-divulgation.

C’est cette complexité qui a poussé à une coordination avec les CERT. Plus encore quand on considère que la bibliothèque a fait, pendant un temps, l’objet d’un codéveloppement avec l’entreprise japonaise Elmic Systems. Devenue Zuken Elmic, elle vend aujourd’hui une variante du produit en Asie, sous le nom Kasago TCP/IP.

Ripple20 : le DNS, danger numéro un ?

Parmi les 19 failles recensées, 4 sont considérées comme critiques de par leur score sur l’échelle CVSSv3.

Deux d’entre elles atteignent le maximum (10/10).

L’une (CVE-2020-11896) est liée à un problème dans le tunneling IPv4. Démontrée sur un appareil Digi International, elle pose un risque d’exécution de code à distance. Treck l’a corrigée dans la version 6.0.1.66 de sa bibliothèque, publiée le 3 mars 2020.

L’autre (CVE-2020-11987) naît d’un souci dans la gestion IPv6. Conséquence éventuelle : une écriture hors limites… et les corruptions de mémoire qui peuvent s’ensuivre. Elle fait partie des 4 vulnérabilités corrigées au gré des mises à jour du code (en juin 2019), avant que l’enquête sur Ripple20 ne démarre.

Aucune de ces deux failles n’est cependant la plus critique, assurent les chercheurs à l’origine des révélations. Il faut, selon eux, s’intéresser à la CVE-2020-11901, créditée d’un score de 9/10.
Elle pose des risques d’exécution de code à distance à travers la manipulation des réponses aux requêtes DNS des systèmes ciblés.

Un rapport consacré à cette faille sera présenté à la Black Hat USA, qui se tiendra du 1^er au 6 août prochains. Avec un PoC réalisé sur un onduleur Schneider Electric.

Outre Schneider Electric, au moins 7 autres fournisseurs sont touchés. Parmi eux, HP et Intel. La liste risque de s’allonger, avec plus d’une soixantaine en cours d’examen.

Le meilleur remède consiste à mettre à jour la bibliothèque dans sa dernière version (6.0.1.67).
À défaut, on prendra au possible des mesures de filtrage du trafic. Par exemple, bloquer le multicast IPv6, forcer l’inspection TCP ou désactiver DHCP dans le cas où des IP statiques sont utilisables.

Illustration principale © metamorworks – stock.adobe.com