Une vulnérabilité dans Service Location Protocol (SLP) sur les terminaux connectés à Internet pourrait créer un facteur d’amplification DDoS allant jusqu’à 2200X
Des chercheurs des entreprises de sécurité Bitsight et Curesec alertent contre une vulnérabilité qu’ils ont découvert dans un service réseau basé sur le protocole UDP appelé Service Location Protocol (SLP). La faille pourrait être exploitée de manière abusive pour amplifier les attaques DDoS. Des dizaines de milliers de systèmes et de terminaux sont exposés à ce service sur Internet et des attaquants pourraient les utiliser pour générer des attaques massives. Et il faudra probablement beaucoup de temps pour les nettoyer. La brèches offrent aux attaquants d’exploiter les points d’extrémité SLP de manière à générer des réponses importantes et de les répercuter ensuite sur les victimes.
Des attaques par réflexion et amplification DDoS
La technique d’attaque dite de réflexion DDoS consiste à envoyer du trafic à un serveur et à lui faire envoyer sa réponse à une adresse IP différente. Ce genre d’attaque fonctionne généralement avec des protocoles de communication basés sur le protocole UDP (User Datagram Protocol). L’UDP est, avec TCP (Transmission Control Protocol), l’un des principaux protocoles de transmission de données sur Internet. Cependant, contrairement au TCP, l’UDP a été conçu pour la vitesse et ne dispose pas de contrôles supplémentaires, ce qui le rend vulnérable à l’usurpation d’adresse source. Cela signifie qu’un attaquant peut envoyer un paquet UDP à un serveur, mais en mettant une adresse IP source différente dans le paquet au lieu de la sienne. Le serveur enverra alors sa réponse à l’adresse IP source définie.
Outre l’effet de réflexion, qui masque l’origine réelle du trafic, certains protocoles UDP amplifient le trafic résultant, ce qui signifie que la réponse générée est beaucoup plus importante que la demande initiale. C’est ce qu’on appelle l’amplification DDoS, très utile pour les attaquants, car elle génère plus de trafic non sollicité vers une cible qu’ils ne pourraient le faire en lui envoyant directement des paquets à partir des machines contrôlées. L’amplification DDoS fonctionne avec divers protocoles, notamment DNS (Domain Name System), mDNS (multicast DNS), NTP (Network Time Protocol), SSDP (Simple Service Discovery Protocol), SNMP (Simple Network Management Protocol) et d’autres, car ils utilisent tous le protocole UDP pour la transmission. Les serveurs exposés à Internet qui acceptent des paquets sur ces protocoles et génèrent des réponses peuvent donc être exploités de manière abusive pour l’amplification des attaques par saturation. Historiquement, ces protocoles ont déjà été utilisés pour générer certaines des plus grandes attaques DDoS connues.
La vulnérabilité du SLP
Créé en 1997, le Service Location Protocol (SLP) est un protocole ancien, destiné l’origine à la découverte automatisée de services et à la configuration dynamique entre les applications sur les réseaux locaux. Le daemon SLP d’un système maintient un répertoire des services disponibles comme les imprimantes, les serveurs de fichiers et autres ressources du réseau. Il écoute les requêtes sur le port UDP 427. Même si le SLP n’était pas censé être exposé hors des réseaux locaux, les chercheurs de Bitsight et de Curesec ont identifié plus de 54 000 terminaux qui acceptent des connexions SLP sur Internet. Ces équipements appartiennent à plus de 2000 entreprises du monde entier et couvrent 670 types de produits différents, dont les instances de l’hyperviseur VMware ESXi, les imprimantes Konica Minolta, les routeurs Planex, l’Integrated Management Module (IMM) d’IBM et l’IPMI de SMC.
Comme beaucoup d’autres protocoles basés sur UDP, les instances SLP publiques peuvent servir pour l’amplification des DDoS car les attaquants peuvent interroger les services disponibles sur un serveur SLP. Pour cette requête de 29 octets, la réponse du serveur est généralement comprise entre 48 et 350 octets, soit un facteur d’amplification de 1,6 à 12 fois. Mais les chercheurs ont constaté que de nombreuses implémentations SLP octroient à des utilisateurs non authentifiés d’enregistrer de nouveaux services arbitraires sur un point de terminaison SLP, augmentant ainsi les réponses ultérieures du serveur jusqu’à la limite pratique des paquets UDP, qui est de 65 536 octets.
La seule chose à faire pour les attaquants est d’envoyer des paquets au serveur SLP pour enregistrer d’autres services jusqu’à ce que sa mémoire tampon soit pleine et que le serveur n’accepte plus d’autres enregistrements. Ils peuvent ensuite procéder à une attaque par réflexion courante en envoyant des demandes de listes de services avec une adresse IP source usurpée. Le facteur d’amplification possible peut atteindre x2200, les requêtes de 29 octets générant des réponses de 65 000 octets. Étant donné le grand nombre de produits concernés, les chercheurs ont coordonné la divulgation de la vulnérabilité par l’intermédiaire de l’agence américaine de cybersécurité et de sécurité des infrastructures (Cybersecurity and Infrastructure Security Agency, CISA), qui a émis sa propre alerte. VMware a également publié un avis pour ESXi, en précisant que seules les versions en fin de vie de l’hyperviseur étaient concernées. La vulnérabilité est répertoriée sous la référence CVE-2023-29552 et est affectée d’un score de gravité CVSS de 8.6 (élevée).
Atténuation de la vulnérabilité SLP
« Le protocole SLP doit être désactivé sur tous les systèmes fonctionnant sur des réseaux non fiables, notamment ceux qui sont directement connectés à Internet », ont déclaré les chercheurs. « Si cela n’est pas possible, les pare-feux doivent être configurés pour filtrer le trafic sur les ports UDP et TCP 427. Cela empêchera les attaquants externes d’accéder au service SLP », ont-ils ajouté. La vulnérabilité CVE-2023-29552 n’est pas la première à affecter le SLP. Au fil des ans, VMware a corrigé de nombreuses failles dans son implémentation OpenSLP dans ESXi, et en 2021, le fournisseur a désactivé le service par défaut dans les dernières versions. VMware conseille désormais à tous ses clients de désactiver ce service, d’autant plus que des gangs de ransomwares ont commencé à exploiter l’une de ces vulnérabilités référencée CVE-2021-21974, qui facilite un débordement de la mémoire tampon.
Les pays qui comptent le plus grand nombre de terminaux vulnérables sont les États-Unis, le Royaume-Uni, le Japon, l’Allemagne et le Canada. Malheureusement, comme ces équipements appartiennent à de nombreuses entreprises, il est probable qu’un pourcentage important d’entre eux restera encore longtemps exposé à Internet, ce qui augmentera les chances de voir bientôt des attaques DDoS exploitant l’amplification SLP.
L’injecteur de malware BellaCiao poussé par le groupe iranien APT35 est utilisé pour des attaques visant spécifiquement les serveurs Microsoft Exchange. Le vecteur d’infection est encore incertain.
Un groupe de cyberespions très probablement lié au gouvernement iranien a infecté des serveurs Microsoft Exchange avec un nouvel implant de malware appelé BellaCiao qui agit comme un injecteur pour le dépôt de futures charges utiles. Le logiciel malveillant exploite les requêtes DNS pour recevoir des commandes des attaquants codées en adresses IP. Selon les chercheurs de Bitdefender, il semble que les attaquants personnalisent leurs attaques en fonction de chaque victime, y compris le binaire du malware, qui contient des informations codées en dur comme le nom de l’entreprise, des sous-domaines personnalisés et des adresses IP. Les informations de débogage et les chemins d’accès aux fichiers de compilation laissés dans l’exécutable laissent penser que les attaquants ont classé leurs victimes par code de pays, comme IL (Israël), TR (Turquie), AT (Autriche), IN (Inde) ou IT (Italie).
Le groupe à l’origine du malware est connu dans l’industrie de la sécurité sous le nom de Charming Kitten, APT35 ou Phosphorus. Cette équipe de pirates informatiques opérerait pour le compte du Corps des gardiens de la révolution islamique (CGRI), communément appelé Pasdaran, une organisation paramilitaire de la république islamique d’Iran qui dépend directement du Guide de la révolution. Récemment, Microsoft a signalé que, depuis la fin de l’année 2021, Charming Kitten s’en prend à des infrastructures américaines critiques, notamment les ports maritimes, les entreprises du secteur de l’énergie, les systèmes de transport, ainsi qu’une grande entreprise de services publics et de gaz. Le groupe est également connu pour mettre à jour et développer fréquemment son arsenal de logiciels malveillants avec des outils personnalisés. Si sa méthode d’attaque préférée est l’hameçonnage très ciblé et sophistiqué, qui comprend l’usurpation d’identité de personnes réelles, il n’hésite pas non plus à adopter des exploits de vulnérabilités récemment corrigées, comme ce fût le cas par exemple de Log4Shell et Zoho ManageEngine (CVE-2022-47966).
Déploiement et fonctionnement du malware BellaCiao
Même si les attaquants de Bitdefender ne sont pas sûrs du vecteur d’infection utilisé pour déployer BellaCiao, ils ont trouvé l’implant sur des serveurs Exchange. Ils soupçonnent donc les attaquants d’exploiter l’un des exploits Exchange connus de ces dernières années, comme ProxyLogon, ProxyShell, ProxyNotShell ou OWASSRF. Une fois déployé, l’implant désactive Microsoft Defender à l’aide d’une commande PowerShell et crée un nouveau service de persistance appelé Microsoft Exchange Services Health ou Exchange Agent Diagnostic Services. Les noms choisis visent à se fondre dans les processus et services légitimes liés à Exchange. Outre BellaCiao, les pirates ont également déployé des portes dérobées qui fonctionnent comme des modules pour Internet Information Services (IIS), le serveur web qui sous-tend Exchange. L’une d’entre elles est une porte dérobée IIS open-source appelée IIS-Raid et l’autre est un module IIS écrit en .NET et utilisé pour l’exfiltration d’identifiants.
Certains échantillons de BellaCiao sont conçus pour déployer un webshell, un script web qui fonctionne comme une porte dérobée et permet aux attaquants d’envoyer des commandes à distance. Le webshell n’est pas téléchargé à partir d’un serveur externe, mais il est encodé dans l’exécutable BellaCiao lui-même sous la forme de chaînes en base64 malformées. Cependant, pour savoir à quel moment déposer le webshell, dans quel répertoire et avec quel nom, l’implant BellaCiao interroge un serveur de commande et de contrôle par DNS à l’aide d’un canal de communication personnalisé mis en place par les auteurs de l’attaque. Le logiciel malveillant effectue une requête DNS pour un sous-domaine codé en dur dans son code toutes les 24 heures. Comme les attaquants contrôlent le DNS pour le sous-domaine, ils peuvent renvoyer l’adresse IP qu’ils souhaitent et, ce faisant, ils transmettent des commandes au logiciel malveillant, car BellaCiao possède des routines spéciales pour interpréter ces adresses IP.
Des échantillons aussi conçus pour déployer des scripts PowerShell
Une adresse IP se compose de quatre valeurs numériques (octets) séparées par des points, par exemple 111.111.111.111. Le logiciel malveillant a une adresse IP codée en dur au format L1.L2.L3.L4 qu’il compare ensuite à l’adresse IP reçue de la requête DNS, par exemple R1.R2.R3.R4. Si les derniers octets R4 et L4 correspondent, le webshell est déployé. S’ils ne correspondent pas, le webshell n’est pas déployé et si R4 est égal à L4-1, toutes les traces du webshell sont supprimées. Les autres octets R1, R2 et R3 sont également utilisés pour déterminer les noms de répertoires et de fichiers à choisir dans une liste lors du déploiement du webshell. Le webshell surveille les requêtes web qui incluent une chaîne particulière, laquelle agit comme un mot de passe secret dans l’en-tête et offre aux attaquants trois possibilités : le téléchargement de fichiers, le chargement de fichiers et l’exécution de commandes.
D’autres échantillons de BellaCiao ont été conçus pour déployer des scripts PowerShell qui agissent comme un serveur web local et un outil de connexion en ligne de commande appelé Plink, utilisé pour établir une connexion proxy inverse au serveur web. Cela permet aux attaquants d’exécuter des commandes et des scripts, de charger et de télécharger des fichiers, de télécharger des journaux Web, etc. Le rapport de Bitdefender comprend une liste d’indicateurs de compromission comme les noms de domaine, les noms de fichiers et les chemins d’accès, les hachages de scripts PowerShell et les adresses IP. Il n’inclut pas les hachages de fichiers pour les échantillons de BellaCiao, car ces derniers contiennent des informations codées en dur sur les victimes.
Désormais corrigée, la vulnérabilité de la plateforme MLflow expose les modèles d’IA et d’apprentissage machine stockés dans le cloud. Une faiblesse qui ouvre la voie à du possible déplacement latéral d’un attaquant.
MLflow, un framework open source utilisé par de nombreuses entreprises pour gérer leurs tests d’apprentissage machine et enregistrer les résultats, est touchée par une faille critique. Celle-ci ouvre la voie à des attaquants pour extraire des informations sensibles des serveurs, comme des clés SSH et des identifiants AWS. Les attaques peuvent être exécutées à distance sans authentification, car MLflow n’implémente pas d’authentification par défaut sachant qu’un nombre croissant de déploiements MLflow sont directement exposés à lnternet. « En clair, chaque entreprise qui utilise cet outil risque de perdre ses modèles d’IA, d’avoir un serveur interne compromis et d’avoir son compte AWS compromis », a déclaré Dan McInerney, ingénieur de la sécurité senior pour la startup de cybersécurité Protect AI. « C’est assez brutal ». M. McInerney a découvert la vulnérabilité et l’a signalée au projet MLflow en privé. Elle a été corrigée dans la version 2.2.1 du framework publiée il y a trois semaines, mais les notes de version ne mentionnent aucun correctif de sécurité.
Inclusion de fichiers locaux et distants via une attaque Path traversal
Écrit en Python, MLflow automatise les workflows d’apprentissage machine. Du fait de ses nombreux composants, les utilisateurs peuvent déployer des modèles à partir de diverses bibliothèques d’apprentissage machine, gérer leur cycle de vie, y compris la version du modèle, les transitions d’étape et les annotations, suivre les expériences pour enregistrer et comparer les paramètres et les résultats, et même empaqueter le code d’apprentissage machine sous une forme reproductible pour le partager avec d’autres scientifiques des données. MLflow peut être contrôlé via une API REST et une interface en ligne de commande. Toutes ces capacités font de ce framework un outil précieux pour toute entreprise qui expérimente l’apprentissage machine. Les analyses effectuées à l’aide du moteur de recherche Shodan confirment ce constat : au cours des deux dernières années, les instances MLflow exposées publiquement n’ont cessé d’augmenter, le nombre actuel s’élevant à plus de 800. Cependant, on peut supposer que de nombreux autres déploiements de MLflow existent au sein de réseaux internes et pourraient être atteints par des attaquants qui gagneraient un accès à ces réseaux. « Plusieurs entreprises du Fortune 500 que nous avons contactées nous ont toutes confirmé qu’elles utilisaient MLflow en interne pour leur flux de travail d’ingénierie de l’IA », a encore déclaré M. McInerney.
Répertoriée sous la référence CVE-2023-1177, la vulnérabilité critique découverte par Dan McInerney a un score CVSS remarquable de 10. Selon ce référentiel, celle-ci – de type inclusion de fichiers locaux (LFI) ou distants (RFI) donne la possibilité à un attaquant distant et non authentifié d’envoyer des requêtes spécifiquement conçues au point d’extrémité de l’API forçant MLflow à exposer le contenu de n’importe quel fichier lisible sur le serveur. Par exemple, l’attaquant peut inclure JSON dans une requête où le paramètre source est un fichier de son choix sur le serveur et l’application le renverra. L’un de ces fichiers peut être les clés ssh, généralement stockées dans le répertoire .ssh à l’intérieur du répertoire personnel de l’utilisateur local. Cependant, la connaissance préalable du répertoire personnel de l’utilisateur n’est pas une condition à l’exploitation, car l’attaquant peut d’abord lire le fichier /etc/passwd, disponible sur tous les systèmes Linux, qui répertorie tous les utilisateurs disponibles et leurs répertoires personnels.
Des déploiements non sécurisés faute d’authentification par défaut
Aucun des autres paramètres envoyés dans le cadre de la requête malveillante n’a besoin d’exister et peut être arbitraire. La vulnérabilité est d’autant plus grave que la plupart des entreprises configurent leurs instances MLflow pour qu’elles utilisent Amazon AWS S3 afin de stocker leurs modèles et autres données sensibles. Selon l’analyse de la configuration des instances MLflow accessibles au public effectuée par Protect AI, sept configurations sur dix utilisaient AWS S3. Cela signifie que les attaquants peuvent définir le paramètre source de leur requête JSON comme étant l’URL s3:// du bucket utilisé par l’instance pour voler des modèles à distance. Cela signifie également que les identifiants AWS sont probablement stockés localement sur le serveur MLflow afin que le framework puisse accéder aux buckets S3, et ces identifiants sont généralement stockés dans un dossier appelé ~/.aws/credentials dans le répertoire personnel de l’utilisateur. L’exposition des informations d’identification AWS peut constituer une violation grave, car, en fonction de la politique IAM, elle peut donner aux attaquants des capacités de mouvement latéral dans l’infrastructure AWS d’une entreprise.
Exiger une authentification pour accéder au point d’extrémité de l’API empêcherait l’exploitation de cette faille, mais MLflow n’implémente aucun mécanisme d’authentification. Il est possible d’ajouter une authentification de base avec un nom d’utilisateur et un mot de passe statiques en déployant un serveur proxy comme nginx devant le serveur MLflow et en forçant ainsi l’authentification. Malheureusement, presque aucune des instances exposées publiquement n’utilise une telle configuration. « Il est difficile de dire que ce mode de déploiement de l’outil est sûr, mais à tout le moins, le déploiement le plus sûr de MLflow tel qu’il est actuellement est de le garder sur un réseau interne, dans un segment de réseau séparé de tous les utilisateurs, sauf ceux qui ont besoin de l’utiliser, et de le placer derrière un proxy nginx avec une authentification de base », a expliqué M. McInerney. « Cela n’empêche pas un utilisateur ayant accès au serveur de télécharger les modèles et artefacts d’autres utilisateurs, mais cela limite au moins l’exposition. L’exposition sur un serveur public orienté vers lnternet suppose qu’absolument rien de ce qui est stocké sur le serveur ou sur le serveur de stockage d’artefacts à distance ne contient de données sensibles », a-t-il ajouté.
L’utilisation accrue des passerelles et des routeurs cellulaires industriels expose les dispositifs IIoT aux attaquants et augmente la surface d’attaque des réseaux OT.
L’utilisation accrue des passerelles et des routeurs cellulaires industriels expose les dispositifs IIoT aux attaquants et augmente la surface d’attaque des réseaux OT (technologies opérationnelles). Les équipes OT sont souvent amenées à connecter des systèmes de contrôle industriel (ICS) à des centres de contrôle et de surveillance à distance via des solutions sans fil et cellulaires, parfois avec l’aide d’interfaces de gestion basées sur le cloud et gérées par les fournisseurs. Or, ces solutions de connectivité, également appelées dispositifs IoT industriels sans fil, augmentent la surface d’attaque des réseaux OT et peuvent fournir aux attaquants distants un raccourci vers des portions de réseau précédemment segmentés contenant des contrôleurs critiques. Cette semaine, un rapport publié par l’entreprise de cybersécurité industrielle Otorio met en évidence les vecteurs d’attaque auxquels ces terminaux sont sensibles ainsi que les vulnérabilités que les chercheurs d’Otorio ont trouvées dans plusieurs de ces produits. « Les appareils IoT sans fil industriels et leurs plateformes de gestion basées sur le cloud sont des cibles attrayantes pour les attaquants qui cherchent à prendre pied dans les environnements industriels », indiquent les chercheurs d’Otorio dans leur rapport, en pointant « des exigences minimales en termes d’exploitation et d’impact potentiel ».
Un changement dans l’architecture traditionnelle des réseaux OT
La sécurité des technologies de l’information a généralement suivi le modèle PERA (Purdue Enterprise Reference Architecture) pour décider de l’emplacement des couches de contrôle d’accès et de la segmentation. Ce modèle, qui date des années 1990, divise les réseaux informatiques et OT des entreprises en six niveaux (Levels) fonctionnels.
Level 0 : il désigne l’équipement qui influence directement les processus physiques et comprend des éléments comme les vannes, les moteurs, les actionneurs et les capteurs.
Level 1, ou couche de contrôle de base : il comprend les contrôleurs de terrain comme les automates programmables industriels (Programmable Logic Controllers, PLC) et les unités terminales distantes (Remote Terminal Unit, RTU) qui contrôlent ces capteurs, vannes et actionneurs en fonction de la logique (programmes) déployée par les ingénieurs.
Level 2, ou couche de contrôle de supervision : il comprend les systèmes de contrôle de supervision et d’acquisition de données (Supervisory Control and Data Acquisition, SCADA) qui collectent et traitent les données reçues des contrôleurs de niveau Level 1.
Level 3, ou couche de contrôle du site : il comprend les systèmes qui soutiennent directement les opérations d’une usine, comme les serveurs de base de données, les serveurs d’applications, les interfaces homme-machine, les postes de travail d’ingénierie utilisés pour programmer les contrôleurs de terrain, etc. Généralement appelée Centre de contrôle (Control Center), cette couche est connectée au réseau IT général de l’entreprise (Level 4) par une zone démilitarisée (DMZ).
C’est dans cette DMZ que les entreprises ont concentré leurs efforts en matière de sécurité du périmètre afin de disposer d’une segmentation solide entre les parties informatique et technique de leurs réseaux. Des contrôles supplémentaires sont souvent mis en place entre le niveau Level 3 et le niveau Level 2, dans le but de protéger les appareils de terrain contre les intrusions dans les centres de contrôle. Cependant, il arrive que certaines entreprises aient besoin de connecter des installations industrielles distantes à leurs centres de contrôle principaux. Cette situation est plus courante dans des secteurs comme le gaz et le pétrole, où les exploitants peuvent avoir plusieurs champs pétroliers et puits de gaz en exploitation à différents endroits, mais cette configuration peut se retrouver couramment dans d’autres secteurs.
Ces liens entre les dispositifs distants de niveau 0-2 et les systèmes de contrôle de niveau Level 3 sont fréquemment assurés par des passerelles cellulaires industrielles ou des points d’accès WiFi industriels. Ces dispositifs IoT industriels sans fil peuvent dialoguer avec les appareils de terrain via plusieurs protocoles, comme Modbus et DNP3 (Distributed Network Protocol), puis se reconnecter au centre de contrôle de l’entreprise via Internet en utilisant divers mécanismes de communication sécurisés comme le VPN. De nombreux fabricants d’appareils fournissent également des interfaces de gestion basées sur le cloud pour que les propriétaires d’actifs industriels puissent gérer leurs appareils à distance.
Vulnérabilités des dispositifs industriels IoT sans fil
Ces terminaux, comme tout autre connecté à Internet, augmentent la surface d’attaque des réseaux OT et affaiblissent les contrôles de sécurité traditionnellement mis en place par les entreprises, offrant ainsi aux attaquants une option de contournement vers les niveaux inférieurs des réseaux OT. « En utilisant des moteurs de recherche comme Shodan, nous avons observé une exposition généralisée des passerelles et routeurs cellulaires industriels, ce qui les rend faciles à découvrir et potentiellement vulnérables à l’exploitation par des acteurs de la menace », indiquent les chercheurs d’Otorio dans leur rapport.
Voici quelques-unes de leurs conclusions concernant les appareils dotés de serveurs et d’interfaces web accessibles par Internet :
Les chercheurs affirment avoir trouvé 24 vulnérabilités dans les interfaces web des appareils de trois de ces fournisseurs – Sierra, InHand et ETIC – et avoir réussi à exécuter du code à distance sur les trois.
Alors que la plupart de ces failles sont encore en cours de divulgation, l’une d’entre elles, référencée CVE-2022-46649, a déjà été corrigée sur les routeurs AirLink de Sierra Wireless. Il s’agit d’une vulnérabilité par injection de commande dans la fonction de journalisation IP d’ACEManager, l’interface de gestion web du routeur, et c’est une variante d’une autre faille trouvée par les chercheurs de Talos en 2018 et suivie sous la référence CVE-2018-4061. Il s’avère que le filtrage mis en place par Sierra pour traiter la vulnérabilité CVE-2018-4061 ne couvrait pas tous les scénarios d’exploitation et les chercheurs d’Otorio ont pu le contourner.
Dans la CVE-2018-4061, les attaquants pouvaient joindre des commandes shell supplémentaires à la commande tcpdump exécutée par le script ACEManager iplogging.cgi en utilisant le drapeau -z. Ce drapeau est supporté par l’utilitaire tcpdump en ligne de commande et est utilisé pour passer des commandes dites postrotate. Sierra a corrigé le problème en appliquant un filtre qui supprime tout drapeau -z de la commande passée au script iplogging s’il est suivi d’un espace, d’une tabulation, d’un saut de page ou d’une tabulation verticale, ce qui bloquerait, par exemple, « tcpdump -z reboot ». Mais, selon Otorio, une chose leur a échappé : c’est que le drapeau -z ne nécessite aucun de ces caractères et qu’une commande comme « tcpdump -zreboot » s’exécuterait parfaitement et contournerait le filtrage. Ce seul contournement limiterait toujours les attaquants à l’exécution de fichiers binaires qui existent déjà sur l’appareil. Les chercheurs ont donc développé un moyen de cacher leur charge utile dans un fichier PCAP (package capture) téléchargé sur l’appareil via une autre fonction d’ACEManager appelée iplogging_upload.cgi. Ce fichier PCAP spécifiquement conçu peut également se comporter comme un script shell quand il est analysé par sh (l’interpréteur shell) et son analyse et son exécution peuvent être déclenchées en utilisant la vulnérabilité -z dans iplogging.cgi.
Risques liés à la gestion du cloud
Même si ces dispositifs n’exposent pas leurs interfaces de gestion basées sur le Web directement à Internet, ce qui n’est pas une pratique de déploiement sécurisée, ils ne sont pas totalement inaccessibles aux attaquants distants. En effet, la plupart des fournisseurs proposent des plates-formes de gestion dans le cloud qui permettent aux propriétaires d’appareils d’effectuer des changements de configuration, des mises à jour de firmware, des reboots d’appareils, de faire passer du trafic par les appareils, etc. Généralement, les appareils communiquent avec ces services de gestion cloud à l’aide de protocoles M2M (machine-to-machine), tels que MQTT, un protocole de messagerie publish-subscribe basé sur le protocole TCP/IP, et leur mise en œuvre peut présenter des faiblesses. Les chercheurs d’Otorio ont découvert des vulnérabilités critiques dans les plateformes cloud de trois fournisseurs, qui permettent aux attaquants de compromettre à distance tout appareil géré par le cloud sans authentification. « En ciblant la plateforme de gestion cloud d’un seul fournisseur, un attaquant à distance peut exposer des milliers d’appareils situés sur différents réseaux et secteurs », ont déclaré les chercheurs. « La surface d’attaque sur la plateforme de gestion cloud est large. Elle comprend l’exploitation de l’application web (interface utilisateur cloud, Cloud-UI), notamment l’abus des protocoles M2M, l’abus des politiques de contrôle d’accès faibles ou l’abus d’un processus d’authentification faible ».
Les chercheurs illustrent ces risques par une chaîne de trois vulnérabilités trouvées dans la plateforme de gestion cloud « Device Manager » d’InHand Networks et dans le firmware de ses appareils InRouter, qui auraient pu entraîner l’exécution de code à distance avec des privilèges root sur tous les appareils InRouter gérés dans le cloud. En premier lieu, ils ont examiné la manière dont les appareils communiquent avec la plateforme via MQTT et la manière dont l’authentification, ou « l’enregistrement », est réalisée et dont la sécurité est assurée. Ils ont découvert que l’enregistrement utilise des valeurs insuffisamment aléatoires et peut être abusé par force brute. En d’autres termes, en exploitant deux de ces vulnérabilités, les chercheurs ont réussi à obliger un routeur à fournir son fichier de configuration en usurpant l’identité d’une connexion authentifiée et à lui demander d’accomplir des tâches, par exemple de modifier son nom d’hôte. La troisième vulnérabilité concernait la manière dont le routeur analysait les fichiers de configuration via MQTT, en particulier la fonction utilisée pour analyser les paramètres d’une fonction appelée auto_ping. Les chercheurs ont découvert qu’ils pouvaient activer auto_ping, puis concaténer une ligne de commande reverse shell à la fonction auto_ping_dst, qui s’exécutait avec les privilèges de l’utilisateur root sur l’appareil.
Attaques sans fil sur les réseaux OT
En plus des vecteurs d’attaque à distance disponibles sur Internet, ces terminaux exposent également les signaux WiFi et cellulaires localement, de sorte que toute attaque sur ces technologies pourrait être utilisée contre eux. « Différents types d’attaques locales peuvent être utilisés contre les canaux de communication WiFi et cellulaires, depuis les attaques sur les cryptages faibles comme le WEP et les attaques de déclassement vers le GPRS (General Packet Radio Service) vulnérable, jusqu’aux vulnérabilités complexes des chipsets qui peuvent prendre du temps à corriger », ont déclaré les chercheurs. Même si ces derniers n’ont pas étudié les vulnérabilités des modems WiFi ou cellulaires en bande de base, ils ont effectué une reconnaissance en utilisant WiGLE, un service public de cartographie des réseaux sans fil qui collecte des informations sur les points d’accès sans fil dans le monde entier. « En exploitant les options de filtrage avancées, nous avons écrit un script Python pour rechercher des environnements industriels ou d’infrastructures critiques potentiellement de grande valeur, en mettant en évidence ceux qui sont configurés avec un cryptage faible », ont déclaré les chercheurs. « Notre analyse a permis de découvrir des milliers de dispositifs sans fil liés aux infrastructures industrielles et critiques, dont des centaines étaient configurés avec des cryptages faibles connus du public », ont-ils ajouté. En utilisant cette technique, les chercheurs ont réussi à trouver des dispositifs avec un cryptage sans fil faible, déployés dans le monde réel, dans des usines de fabrication, des champs pétrolifères, des sous-stations électriques et des installations de traitement des eaux. Les attaquants pourraient utiliser cette reconnaissance pour identifier les appareils faibles, puis se rendre sur place pour les exploiter.
Atténuer les vulnérabilités des dispositifs IoT sans fil
Même si la correction des vulnérabilités de ces systèmes, quand elles sont découvertes, est d’une importance capitale en raison de leur position privilégiée dans les réseaux OT et de leur accès direct aux contrôleurs critiques, des mesures préventives supplémentaires sont nécessaires pour atténuer les risques. Les chercheurs d’Otorio recommandent notamment : de désactiver et d’éviter tout cryptage non sécurisé (WEP, WAP) et, dans la mesure du possible, de ne pas autoriser les anciens protocoles comme le GPRS ; de cacher les noms de ses réseaux (SSID) ; d’utiliser une liste blanche basée sur le MAC, ou d’utiliser des certificats, pour les appareils connectés ; de vérifier que les services de gestion sont limités à l’interface LAN uniquement ou qu’ils sont sur liste blanche IP ; de s’assurer qu’aucun justificatif d’identité par défaut n’est utilisé ; d’être attentif aux nouvelles mises à jour de sécurité disponibles pour ses appareils ; de vérifier que ces services sont désactivés s’ils ne sont pas utilisés (activés par défaut dans de nombreux cas) ; de mettre en œuvre des solutions de sécurité séparément (VPN, pare-feu), en traitant le trafic provenant de l’IIoT comme non fiable.