Cisco IOS XE expose le problème de responsabilité des plans de gestion laissés sur Internet

Résumé

• Registre public confirmé:Cisco a divulgué l'exploitation active de la fonctionnalité d'interface utilisateur web du logiciel IOS XE et a déterminé plus tard que les attaquants ont exploité deux problèmes inconnus auparavant: CVE-2023-20198 pour l'accès initial et la création d'un compte de privilège 15, suivi de CVE-2023-20273 pour élever les privilèges à root et écrire un implant dans le système de fichiers. (Avis de sécurité Cisco)
• Guidance gouvernementale:La CISA a déclaré que les deux vulnérabilités affectaient l'interface utilisateur web d'IOS XE et pouvaient permettre à un acteur distant non authentifié de prendre le contrôle d'un système affecté; la CISA a exhorté les organisations à désactiver la fonctionnalité de serveur HTTP sur les systèmes exposés à Internet, à rechercher les activités malveillantes et à mettre à niveau vers les versions logicielles corrigées lorsque disponibles. (Guidance de la CISA)
• Problème de plan de gestion:Le registre public soutient une défaillance de surface de contrôle impliquant la gestion web exposée, la création de comptes, l'injection de commandes et l'installation d'implants. Il ne soutient pas une affirmation générale selon laquelle chaque périphérique IOS XE était affecté, que chaque périphérique exposé était compromis, ou que Cisco seul contrôlait l'exposition Internet de chaque client.
• Évaluation:Les attaquants contrôlaient l'exploitation. Cisco contrôlait le code du produit, le contenu des avis, la livraison des correctifs, les guides de durcissement et le support de détection. Les clients, les fournisseurs de services gérés et les agences publiques contrôlaient l'exposition, l'inventaire, la configuration, la segmentation, la surveillance et la discipline de récupération. L'événement a transformé la question « l'interface utilisateur web est-elle activée sur Internet? » en une question de continuité au niveau du conseil d'administration.

Le périphérique réseau était le point de contrôle, pas seulement un autre serveur

L'incident de l'interface utilisateur web de Cisco IOS XE est important parce qu'un routeur, un commutateur ou un contrôleur sans fil n'est pas seulement une charge de travail. C'est un point de contrôle pour d'autres charges de travail. Un périphérique réseau compromis peut se trouver sur le chemin de l'authentification, du routage du trafic, de la segmentation, de la connectivité de succursale, de l'accès sans fil, de la voix, de la surveillance et de la réponse aux incidents elle-même. Lorsque la compromission du plan de gestion atteint un tel périphérique, la question de la récupération n'est pas seulement de savoir si un CVE a été corrigé. Il s'agit de savoir si le périphérique peut encore être digne de confiance pour décrire, appliquer et protéger le réseau qui l'entoure.

L'avis de Cisco a situé l'événement dans la fonctionnalité d'interface utilisateur web du logiciel IOS XE et a clairement indiqué que la chaîne d'attaque impliquait une exploitation active. L'attaquant a d'abord utilisé CVE-2023-20198 pour obtenir un accès initial et émettre une commande de privilège 15 pour créer une combinaison d'utilisateur local et de mot de passe. L'attaquant a ensuite exploité un autre composant de la fonctionnalité d'interface utilisateur web, CVE-2023-20273, en utilisant l'utilisateur local nouvellement créé pour élever le privilège à root et écrire l'implant dans le système de fichiers. Cisco a attribué un CVSS de 10,0 à CVE-2023-20198 et de 7,2 à CVE-2023-20273. (Avis de sécurité Cisco)

La guidance publique de la CISA a traduit les mêmes faits en urgence pour les opérateurs. La CISA a décrit une exploitation active et généralisée de CVE-2023-20198 et CVE-2023-20273 affectant l'interface utilisateur web du logiciel Cisco IOS XE, a déclaré qu'un acteur distant non authentifié pouvait exploiter les vulnérabilités pour prendre le contrôle d'un système affecté, et a demandé aux organisations exécutant l'interface utilisateur web IOS XE de mettre en œuvre les atténuations de Cisco, y compris la désactivation de la fonctionnalité de serveur HTTP sur les systèmes exposés à Internet, et de rechercher les activités malveillantes. (Guidance de la CISA)

L'aspect du plan de gestion fait la différence entre une histoire de vulnérabilité et une histoire de responsabilité. Une faille d'application dans un serveur web ordinaire peut être grave; une faille dans une interface de gestion pour des périphériques qui orientent les paquets et appliquent des politiques est un risque de plan de contrôle. L'attaquant ne se contente pas de voler des données d'une seule application. L'attaquant peut acquérir une position à partir de laquelle il peut observer, modifier, persister ou préparer un accès supplémentaire contre la machinerie de confiance du réseau.

Cela ne signifie pas que chaque périphérique affecté a été utilisé pour l'interception du trafic ou des actions destructrices. Le registre public principal ne soutient pas une telle affirmation universelle. Cisco et la CISA ont documenté la création de comptes, l'élévation de privilèges à root et l'écriture d'implants comme modèle d'exploitation. La question de responsabilité est de savoir ce que cet accès pourrait signifier et quelles preuves sont nécessaires avant qu'un opérateur puisse à nouveau considérer le périphérique comme digne de confiance.

Pour de nombreuses organisations, en particulier les PME et les agences publiques disposant d'équipes réseau réduites, les interfaces de gestion sont historiquement des commodités pratiques. L'administration via l'interface utilisateur web peut faciliter la configuration à distance. Les fournisseurs de services gérés peuvent l'utiliser pour le support client. Les équipes de succursale peuvent la laisser accessible après le déploiement. Un contrôle qui commence comme une commodité peut devenir une surface d'attaque exposée à Internet si l'exposition n'est pas continuellement inventoriée et restreinte.

Cisco a divulgué la chaîne alors que l'histoire des correctifs était encore en cours

La chronologie publique est importante parce que l'exploitation, les atténuations et les versions corrigées ne sont pas arrivées en un seul ensemble bien emballé. Cisco a d'abord averti d'une exploitation active et a recommandé des mesures défensives, y compris la désactivation de la fonctionnalité de serveur HTTP sur les systèmes exposés à Internet. Les mises à jour ultérieures de l'avis ont ajouté le deuxième CVE, les informations sur les versions corrigées et un vérificateur de logiciel. La page de la CISA a été mise à jour avec la disponibilité des versions corrigées pour plusieurs trains IOS XE et a renvoyé les opérateurs vers l'avis et la documentation de correction de Cisco. (Avis Cisco,Guidance CISA)

Cette séquence a créé une fenêtre de responsabilité pratique. Lorsque l'exploitation est active et que la matrice complète des correctifs est encore en cours d'assemblage, la charge des atténuations se déplace fortement vers la réduction de l'exposition et la détection. Les opérateurs ne peuvent pas attendre un plan de correctifs parfait si l'interface de gestion est accessible. Ils doivent désactiver ou restreindre la fonctionnalité de serveur HTTP/HTTPS sur les systèmes exposés à Internet, rechercher les utilisateurs nouvellement créés ou inexpliqués, examiner les indicateurs, conserver les preuves et décider si un périphérique est potentiellement compromis.

Le document de disponibilité des correctifs logiciels de Cisco a par la suite donné aux opérateurs un moyen plus concret de mapper l'ID de bogue CSCwh87343 aux versions corrigées d'IOS XE. La mise à jour du 1er novembre de la CISA a répertorié les versions corrigées pour les trains de versions, y compris 17.9, 17.6, 17.3 et 16.12 pour certains périphériques Catalyst 3650 et 3850. La distinction est importante: pendant la première fenêtre d'exploitation, le contrôle le plus important pouvait être de « fermer immédiatement l'exposition du plan de gestion ». Une fois que les versions corrigées existent, le contrôle devient « mettre à niveau, vérifier, rechercher et récupérer ». (Disponibilité des correctifs Cisco,Vérificateur de logiciel Cisco)

Les entrées de la National Vulnerability Database et les enregistrements CVE fournissent des points d'ancrage publics supplémentaires pour les vulnérabilités. La page NVD de CVE-2023-20198 renvoie à l'avis Cisco et décrit le contexte d'exploitation active. Les enregistrements CVE.org conservent les identifiants de vulnérabilité dans le cadre du registre public des vulnérabilités. (NVD CVE-2023-20198,NVD CVE-2023-20273,Enregistrement CVE CVE-2023-20198,Enregistrement CVE CVE-2023-20273)

La chaîne montre également pourquoi le CVSS seul est insuffisant pour la gouvernance. Un score de 10,0 pour CVE-2023-20198 signale une sévérité technique, mais le risque commercial varie en fonction de l'exposition, du rôle et de la capacité de récupération. Un routeur de succursale exposé à Internet avec une journalisation faible et aucune image propre connue crée un problème opérationnel différent de celui d'un périphérique de laboratoire interne derrière des contrôles VPN de gestion. La sévérité indique aux dirigeants de prêter attention. Les preuves d'inventaire et d'exposition indiquent aux dirigeants ce qu'il faut faire en premier.

L'exposition à Internet était le multiplicateur de conséquences

La variable la plus importante contrôlée par l'opérateur était de savoir si la surface de gestion de l'interface utilisateur web était accessible depuis Internet. Le langage d'atténuation de Cisco et de la CISA était centré sur la désactivation de la fonctionnalité de serveur HTTP sur les systèmes exposés à Internet. Le guide de durcissement de Cisco est cohérent avec ce contrôle: les documents de durcissement Cisco IOS et IOS XE indiquent que le serveur HTTP peut être désactivé avecno ip http serveret le serveur HTTP sécurisé peut être désactivé avecno ip http secure-server. (Guide de durcissement du logiciel Cisco IOS XE,Guide Cisco pour durcir les périphériques Cisco IOS)

Ce n'est pas un nouveau principe de sécurité. Les interfaces de gestion ne devraient pas être largement exposées à Internet à moins d'avoir une raison solide, surveillée, restreinte et documentée. La directive opérationnelle contraignante 23-02 de la CISA sur les interfaces de gestion exposées à Internet a demandé aux agences civiles fédérales de réduire le risque lié aux interfaces de gestion exposées, et ses recommandations ont une pertinence plus large en dehors de la sphère fédérale. (CISA BOD 23-02)

Le problème est que les réseaux réels accumulent des exceptions. Un périphérique déployé lors d'une fusion conserve d'anciennes règles d'accès. Un fournisseur de services gérés ouvre un chemin de gestion pour un dépannage urgent et ne le ferme jamais. Un bureau de succursale hérite d'un modèle avec HTTP activé. Une adresse IP publique change de propriétaire. Une règle de pare-feu destinée à une migration temporaire devient permanente. L'interface utilisateur web n'est pas nécessairement exposée parce qu'un ingénieur a pris une décision imprudente. Elle peut être exposée parce que l'inventaire des actifs, le contrôle des modifications et la transition du service géré n'ont pas réussi à suivre l'historique du réseau.

Cet historique est important pour le blâme. Cisco contrôlait si la vulnérabilité du produit existait et la rapidité avec laquelle elle était diagnostiquée et corrigée. Les clients contrôlaient si la surface de gestion vulnérable était accessible. Les fournisseurs de services gérés contrôlaient de nombreuses configurations de clients. Les agences publiques contrôlaient leurs propres inventaires et processus de désactivation d'urgence. Les attaquants ont exploité les systèmes accessibles. La responsabilité suit ces points de contrôle plutôt que de s'effondrer en une seule phrase.

Pour les PME, le problème d'exposition est particulièrement difficile. Une petite organisation peut s'appuyer sur un fournisseur de services gérés pour la configuration des périphériques réseau et peut ne pas savoir si l'interface utilisateur web IOS XE est activée, exposée, restreinte en interne ou inutilisée. Elle peut ne pas savoir quel train de versions elle exécute, si un logiciel corrigé est disponible, ou si un utilisateur local inexpliqué est apparu. Lorsque la CISA dit de désactiver la fonctionnalité de serveur HTTP sur les systèmes exposés à Internet et de rechercher des activités malveillantes, une PME peut avoir besoin que son fournisseur traduise cela en vérifications spécifiques de périphériques et en preuves.

C'est pourquoi l'incident ne concerne pas seulement Cisco et les grandes entreprises. C'est un test de l'économie du support réseau géré. Si les fournisseurs de services gérés peuvent centraliser l'administration du réseau des clients, ils doivent également centraliser un inventaire précis de l'exposition, une atténuation rapide et une preuve de récupération. Le client ne peut pas accepter un simple « nous l'avons corrigé » si le périphérique a pu avoir un implant au niveau root avant la correction.

L'implant a transformé la correction en récupération

Les faits publics incluent l'écriture d'un implant, et cela change le travail. Lorsqu'une vulnérabilité ne permet que la création de comptes non authentifiés, la suppression du compte et l'application du correctif peuvent être suffisantes dans certains cas. Lorsque la chaîne inclut l'élévation de privilèges à root et un implant écrit dans le système de fichiers, les opérateurs doivent traiter les périphériques affectés comme des systèmes potentiellement compromis nécessitant un tri médico-légal et une validation de récupération.

Les conseils de la CISA incitent les organisations à rechercher des activités malveillantes et font référence aux méthodes de détection de Cisco Talos. Le blog Cisco Talos est une source de détection publique clé même lorsque l'accès automatisé à la page est restreint; la CISA l'a cité pour le conseil pratique selon lequel les organisations devraient rechercher des utilisateurs inexpliqués ou nouvellement créés sur les périphériques comme preuve d'une activité potentiellement malveillante. (Blog Cisco Talos,Guidance CISA)

L'expression « utilisateur nouvellement créé » peut sembler banale. Sur un périphérique réseau, elle ne l'est pas. Un utilisateur local avec privilège créé par exploitation peut survivre à un examen superficiel, être réutilisé pour un accès ultérieur ou fournir une preuve de falsification. L'exécution de commandes au niveau root soulève des questions plus profondes sur l'intégrité de la configuration, l'état du système de fichiers, les images de démarrage, la persistance, les journaux et la fiabilité de la télémétrie du périphérique lui-même.

L'application du correctif ferme le chemin de vulnérabilité connu. Cela ne prouve pas automatiquement qu'un périphérique compromis n'a pas d'implant restant, de compte non autorisé, de configuration modifiée ou de persistance cachée. Les preuves de récupération nécessitent donc plusieurs couches: identifier si l'interface utilisateur web était activée; déterminer si elle était accessible depuis Internet; rechercher les utilisateurs suspects et les indicateurs; collecter et conserver les journaux lorsqu'ils sont disponibles; supprimer les comptes non autorisés; mettre à niveau vers le logiciel corrigé; comparer les configurations en cours et de démarrage; vérifier l'intégrité de l'image; reconstruire ou réimager là où la compromission est suspectée; et surveiller après le retour en service.

Le guide de gestion des incidents du NIST est utile ici car il traite la récupération comme une phase, pas comme une case à cocher. La détection, le confinement, l'éradication et la récupération sont liés mais pas identiques. Un périphérique peut être corrigé alors que les preuves sont encore en cours de collecte. Un périphérique peut être remis en service alors que la surveillance est encore élevée. Un périphérique peut être « corrigé » du point de vue de la gestion des vulnérabilités mais toujours non résolu du point de vue de la réponse aux incidents. (NIST SP 800-61 Rév. 2)

Cette distinction devrait façonner les rapports au conseil d'administration. Un rapport qui dit « tous les périphériques corrigés » peut être techniquement vrai et encore incomplet. La direction a besoin de savoir combien de périphériques avaient la fonctionnalité vulnérable activée, combien étaient exposés à Internet, combien ont montré des indicateurs de compromission, combien ont été reconstruits, combien avaient des utilisateurs non autorisés, si des journaux étaient indisponibles et si les clients des services gérés ont reçu des preuves. Ce sont des mesures de récupération, pas seulement des mesures de correctifs.

Les preuves de détection étaient inégales par conception

Les périphériques réseau sont souvent traités comme des sources de vérité. Ils produisent des journaux, appliquent des ACL, acheminent le trafic et rapportent l'état. Dans une compromission du plan de gestion, cette hypothèse s'affaiblit. Si un attaquant peut créer des utilisateurs et exécuter des commandes avec des privilèges élevés, les enregistrements propres du périphérique peuvent être incomplets, modifiés ou absents. L'opérateur peut avoir besoin de preuves externes: NetFlow, journaux de pare-feu, enregistrements SIEM, sauvegardes de configuration, journaux de gestion hors bande, journaux TACACS ou RADIUS, télémétrie réseau de type EDR et comparaison avec des configurations connues comme bonnes.

C'est la question des « preuves de ressources réseau » dans le manifeste. La ressource compromise n'est pas seulement porteuse de preuves; elle façonne les preuves. Si le routeur ou le commutateur est l'endroit où les journaux auraient dû être générés et que ce périphérique est compromis, la qualité des preuves dépend de la question de savoir si les journaux ont été exportés et protégés avant l'incident. Un tampon de journal local sur le périphérique peut être utile mais fragile. La journalisation centralisée et les enregistrements AAA deviennent beaucoup plus importants.

Le catalogue des vulnérabilités connues exploitées de la CISA est également une infrastructure de preuves. Le fait de répertorier CVE-2023-20198 et les vulnérabilités exploitées associées donne aux agences et aux opérateurs un signal de priorisation indiquant que le problème n'est pas théorique. Le catalogue KEV et la directive opérationnelle contraignante 22-01 ont créé un processus fédéral pour remédier aux vulnérabilités connues exploitées, et de nombreuses organisations privées utilisent le catalogue comme signal de triage. (Catalogue des vulnérabilités connues exploitées de la CISA,CISA BOD 22-01)

Cependant, l'inclusion dans le KEV ne dit pas à un opérateur si son périphérique a été compromis. Elle dit à l'opérateur que l'exploitation est connue et que la remédiation doit être prioritaire. L'opérateur doit encore répondre aux questions de preuves locales: La fonctionnalité était-elle activée? Était-elle accessible? A-t-elle été sondée? Un utilisateur a-t-il été créé? L'implant était-il présent? Un logiciel corrigé a-t-il été installé? Le périphérique a-t-il été reconstruit? Les routes en aval, les ACL ou les informations d'identification ont-elles été modifiées?

Les preuves d'informations d'identification sont particulièrement importantes. Si un attaquant a créé un compte local, le périphérique peut également avoir eu accès aux serveurs AAA, aux communautés SNMP, aux systèmes de gestion de réseau, aux informations d'identification d'automatisation, aux dépôts de sauvegarde ou aux archives de configuration. Les avis publics de Cisco et de la CISA ne disent pas que tous ces systèmes en aval ont été consultés. Ils créent une raison rationnelle de vérifier si la compromission locale du périphérique aurait pu exposer des informations d'identification de gestion ou des relations de confiance plus larges.

Pour les organisations utilisant une authentification centralisée, un compte local devrait être anormal. Pour les organisations avec un mélange de comptes d'urgence locaux et d'AAA externe, l'enquête est plus difficile. Un compte suspect peut se cacher parmi les comptes de secours légitimes si la dénomination, la documentation et l'examen périodique sont faibles. L'incident récompense donc une gouvernance ennuyeuse: des comptes uniques, une journalisation AAA, des bases de configuration, des sauvegardes fréquentes, le moindre privilège et un inventaire propre.

Le rôle de Cisco était plus large que l'écriture d'un correctif

La responsabilité de Cisco inclut la vulnérabilité du produit, mais elle ne s'arrête pas là. Un fournisseur de logiciel d'exploitation réseau contrôle la conception sécurisée, la revue de code, la posture par défaut, la clarté des avis, la livraison des correctifs, la compatibilité logicielle, les conseils de détection, la capacité du TAC, la documentation de durcissement et la capacité des clients à identifier les versions affectées. Dans cet incident, Cisco a divulgué la chaîne, identifié deux CVE, fourni des recommandations, publié des informations sur les versions corrigées et maintenu des conseils de durcissement.

La matrice des correctifs est importante car IOS XE n'est pas une version unique sur un seul appareil. Les grands réseaux peuvent inclure différents trains de versions, familles de matériel, contrats de support, contraintes opérationnelles et fenêtres de maintenance. Une instruction « corrigez maintenant » est correcte sur le plan directionnel mais incomplète sur le plan opérationnel. Les clients doivent savoir quelles images sont corrigées, quelles SMU existent, quels trains sont encore pris en charge, quels périphériques nécessitent des mises à niveau et si une mise à niveau risque de provoquer des temps d'arrêt. Le document de disponibilité des correctifs et le vérificateur de logiciel de Cisco aident à cette traduction. (Disponibilité des correctifs Cisco,Vérificateur de logiciel Cisco)

La clarté de l'avis est aussi importante que la disponibilité des correctifs. Pendant une exploitation active, l'avis doit indiquer aux opérateurs ce qu'il faut désactiver, ce qu'il faut rechercher, ce qui est affecté, ce qui ne l'est pas, si des contournements existent, quand le logiciel corrigé est disponible et comment interpréter les indicateurs. L'avis de Cisco a fait plus que d'attribuer des CVE; il a expliqué la chaîne observée, de l'accès initial à la création d'un utilisateur local, en passant par l'élévation à root et l'écriture de l'implant. C'est le type d'information qui fait passer la réponse d'un simple correctif à une évaluation de compromission.

Les paramètres par défaut du fournisseur sont une question juste mais prudente. Il ne suffit pas de demander si l'interface utilisateur web existe. Les fonctionnalités de gestion existent souvent pour des raisons légitimes. La meilleure question est de savoir si le produit et la documentation rendent l'exposition non sécurisée difficile, visible ou bruyante. Si un serveur de gestion HTTP/HTTPS est activé, les opérateurs peuvent-ils facilement voir s'il est accessible depuis des réseaux non fiables? Les modèles et les assistants sont-ils biaisés en faveur d'une exposition minimale? Les avertissements indiquent-ils clairement que la gestion exposée à Internet est dangereuse? La télémétrie montre-t-elle l'exposition à Internet? Le logiciel aide-t-il les opérateurs à désactiver les services de gestion inutilisés?

Les documents de durcissement de Cisco conseillent de réduire l'exposition du plan de gestion. C'est utile. Mais les documents de durcissement sont en concurrence avec la pression du déploiement, les configurations héritées et l'habitude opérationnelle du « ça a marché la dernière fois ». Les attentes de sécurité dès la conception demandent de plus en plus aux fournisseurs de rendre le chemin sûr plus facile que le chemin exposé. Le guide de sécurité dès la conception de la CISA soutient que les fabricants de technologies devraient assumer davantage la responsabilité des résultats de sécurité des clients, et pas seulement publier des listes de vérification de durcissement. (CISA Secure by Design)

Appliquer ce principe ici ne rend pas Cisco seul responsable de chaque périphérique exposé. Cela pose la question de savoir si les produits réseau peuvent faire plus pour faire remonter l'exposition de la gestion, décourager l'accessibilité Internet, réduire la dépendance au durcissement post-déploiement et aider les opérateurs à prouver l'état actuel. Un avertissement dans un guide n'est pas la même chose qu'un contrôle dans un produit.

La responsabilité des clients et des fournisseurs de services gérés ne peut pas être externalisée à Cisco

Les clients contrôlaient bon nombre des variables qui déterminaient le rayon d'impact. Ils décidaient ou héritaient si l'interface utilisateur web était activée, si la gestion HTTP/HTTPS était accessible depuis Internet, si l'accès à la gestion était limité au VPN ou aux réseaux dédiés, si les configurations étaient sauvegardées, si les journaux étaient centralisés, si les comptes d'utilisateurs locaux étaient examinés et si les périphériques vulnérables pouvaient être découverts rapidement.

Les fournisseurs de services gérés contrôlaient ces variables pour de nombreux clients. Cela rend le rôle des fournisseurs de services gérés central. Si un fournisseur de services gérés administre les périphériques réseau des clients, il doit maintenir un inventaire précis des périphériques, un inventaire des versions, un inventaire de l'exposition de la gestion, un modèle AAA, un état des sauvegardes, un état de la journalisation et un manuel d'atténuation d'urgence. Lorsqu'un avis Cisco arrive, le fournisseur ne devrait pas commencer par demander quels clients pourraient avoir la fonctionnalité exposée. Il devrait déjà le savoir.

L'impact sur la continuité des PME découle de cette dépendance. Un petit fabricant, une clinique, une école, un détaillant local ou un bureau professionnel peut subir la compromission d'un périphérique réseau comme un temps d'arrêt, une incertitude ou des dépenses d'urgence pour un sous-traitant. Il peut ne pas avoir d'expertise interne pour évaluer les trains de versions IOS XE ou les indicateurs de compromission. Si son fournisseur de services gérés ne peut pas fournir de preuves, le client est coincé entre la confiance et des avis extérieurs coûteux.

Cette incertitude peut devenir une interruption d'activité avant même qu'une manipulation malveillante du trafic ne se produise. Un client peut avoir besoin de planifier une maintenance d'urgence, de remplacer des périphériques, de renouveler les informations d'identification, d'examiner les journaux, d'informer la direction, de suspendre la gestion à distance ou de rassurer les auditeurs. Pour une PME, ces coûts peuvent être importants par rapport à la capacité du personnel. Le fait que le produit vulnérable soit de qualité entreprise ne signifie pas que chaque opérateur affecté a une capacité de réponse de qualité entreprise.

Les contrats devraient refléter cette réalité. Un contrat de réseau géré devrait indiquer qui tient à jour l'inventaire des expositions, qui reçoit les avis des fournisseurs, qui peut désactiver la gestion exposée à Internet, qui approuve les modifications d'urgence, qui conserve les preuves, qui signale les indicateurs au client, qui paie les reconstructions d'urgence et quelles preuves le client reçoit après la clôture. Sans ces conditions, un incident comme IOS XE devient une bousculade entre le fournisseur, le fournisseur de services gérés, le client, l'assureur et l'auditeur.

Les agences publiques ont un devoir parallèle. Elles gèrent souvent des réseaux distribués avec des périphériques hérités, des contraintes d'approvisionnement et des fenêtres de maintenance. Elles peuvent également subir des conséquences sur les services publics si le routage, le sans-fil, les communications d'urgence, les réseaux scolaires ou les services municipaux se dégradent. Les BOD fédérales ne régissent pas automatiquement chaque entité publique locale ou étrangère, mais les principes sont transférables: connaître les interfaces de gestion exposées, prioriser les vulnérabilités connues exploitées et documenter la remédiation. (CISA BOD 23-02,Catalogue KEV de la CISA)

Les avis internationaux ont montré une dépendance partagée

L'incident IOS XE était mondial parce que les périphériques Cisco sont mondiaux. Les agences gouvernementales de cybersécurité en dehors des États-Unis ont émis ou amplifié des avertissements. Le centre australien de cybersécurité a averti que l'exploitation de la vulnérabilité pouvait permettre à un utilisateur distant non authentifié de créer un compte hautement privilégié sur le système vulnérable et d'en prendre le contrôle. Le Centre canadien pour la cybersécurité a publié des mises à jour suivant l'avis de Cisco et la disponibilité des correctifs. (Alerte du Centre australien de cybersécurité,Avis du Centre canadien pour la cybersécurité)

Ces avis sont importants parce que les vulnérabilités des périphériques réseau traversent les frontières nationales plus rapidement que les systèmes d'approvisionnement. Une entreprise multinationale, un FAI régional, un réseau scolaire et une agence municipale peuvent tous exécuter IOS XE de différentes manières, avec différents trains de versions et contrats de support. Le même avis devient un problème opérationnel différent dans chaque environnement.

L'amplification internationale réduit également le risque qu'un incident soit ignoré en tant qu'avis privé d'un fournisseur à ses clients. Lorsque plusieurs agences nationales demandent aux opérateurs d'agir, le problème devient une question d'hygiène de l'infrastructure publique. Cela a des conséquences en matière de responsabilité. Les conseils d'administration et les dirigeants publics ne peuvent pas dire de manière plausible que le risque était obscur après que Cisco, la CISA et d'autres agences de cybersécurité ont publié des conseils.

En même temps, les avis mondiaux ne résolvent pas l'exécution locale. Une page d'agence ne peut pas se connecter au routeur d'un client, désactiver une interface utilisateur web, examiner les utilisateurs locaux, installer un logiciel corrigé ou reconstruire un périphérique compromis. Elle ne peut que donner l'alerte. Le dernier kilomètre appartient toujours aux propriétaires d'actifs et à leurs fournisseurs.

L'événement illustre donc une asymétrie familière: les avertissements sont mondiaux, mais la récupération est locale. Cisco peut publier un correctif. La CISA peut publier des conseils. Les agences nationales peuvent amplifier. Les chercheurs peuvent scanner Internet. Mais un district scolaire, une PME ou une autorité publique doit encore savoir quels périphériques il possède, qui les administre, comment fermer l'exposition, quelle fenêtre d'interruption est acceptable et quelle preuve de nettoyage satisfera sa propre décision de risque.

Le dossier de récupération propre que les opérateurs auraient dû conserver

Un dossier de récupération défendable pour l'incident de l'interface utilisateur web d'IOS XE devrait être plus concret qu'un simple « corrigé ». Il devrait commencer par l'inventaire: tous les périphériques IOS XE, modèles, trains de versions, rôles, adresses de gestion, chemins d'accès à la gestion, état de l'interface utilisateur web, état de l'exposition à Internet et propriétaire responsable. Il devrait ensuite documenter l'atténuation: serveur HTTP et HTTPS désactivé ou restreint le cas échéant, contrôle d'accès appliqué, logiciel corrigé identifié, fenêtre de maintenance planifiée et exceptions d'urgence approuvées.

Vient ensuite l'évaluation de la compromission. L'opérateur doit enregistrer si chaque périphérique a montré des utilisateurs inexpliqués ou nouvellement créés, si des indicateurs connus étaient présents, si les journaux ont montré un accès suspect, si les enregistrements AAA correspondaient à l'administration attendue, si les changements de configuration semblaient non autorisés et si le périphérique a dû être reconstruit. Le dossier doit faire la distinction entre « non vulnérable », « vulnérable mais non exposé », « exposé sans indicateur trouvé », « exposé avec indicateurs » et « compromission confirmée ».

Vient ensuite la restauration. La version du logiciel corrigé, la source de l'image, la somme de contrôle ou la validation de l'intégrité, la comparaison avec la sauvegarde de la configuration, la suppression des utilisateurs non autorisés, le renouvellement des informations d'identification, l'examen AAA, l'examen des informations d'identification SNMP et d'automatisation, la vérification de la journalisation et la surveillance post-modification doivent être enregistrés. Pour les périphériques de grande valeur, une reconstruction à partir d'un support fiable peut être plus crédible qu'un nettoyage sur place lorsque la compromission est suspectée.

Enfin, il devrait y avoir une communication avec les clients et la direction. Les dirigeants ont besoin d'un résumé qui relie l'état technique au risque commercial. Les clients des fournisseurs de services gérés ont besoin de preuves spécifiques aux périphériques, pas seulement d'un lien vers un avis générique. Les agences publiques ont besoin d'un dossier adapté aux auditeurs, aux assureurs et aux organismes de surveillance. La différence entre une bonne récupération et une mauvaise récupération réside souvent dans les preuves conservées après la fin de l'urgence.

Le guide de gestion des correctifs du NIST renforce l'idée que la remédiation des vulnérabilités est un cycle de vie géré plutôt qu'une action unique. Les organisations ont besoin d'inventaires, de priorisation, de tests, de déploiement et de vérification. Dans un incident de périphérique réseau activement exploité, ce cycle de vie se comprime mais ne disparaît pas. (NIST SP 800-40 Rév. 4)

L'incident plaide également en faveur de tests d'exposition récurrents. Un contrôle trimestriel ou continu des services de gestion exposés à Internet aurait réduit la surprise. Un système de gestion de configuration qui signaleip http serverouip http secure-serversur les périphériques exposés à Internet aurait réduit le temps de réponse. Une AAA centralisée aurait rendu les utilisateurs locaux inattendus plus faciles à repérer. Ce ne sont pas des contrôles exotiques. Ce sont les contrôles silencieux qui deviennent bruyants seulement lorsqu'ils sont absents.

La provenance de la configuration mérite sa propre ligne dans ce dossier. Un périphérique réseau peut passer un scan de vulnérabilité et continuer à fonctionner à partir d'une configuration dont l'origine est mal comprise. Les opérateurs doivent savoir si la configuration en cours provient d'un modèle standard, d'un changement d'urgence, d'une exception du fournisseur de services gérés, d'un réseau d'acquisition hérité ou d'une correction ponctuelle d'un administrateur local. Dans le cas d'IOS XE, la provenance pourrait expliquer pourquoi une interface utilisateur web était activée et accessible. Sans ce contexte, la remédiation peut fermer l'exposition immédiate tout en laissant l'organisation vulnérable au retour du même schéma lors de la prochaine application de modèle ou du remplacement du périphérique.

Les preuves du fournisseur doivent être tout aussi concrètes. Un fournisseur de services gérés devrait être en mesure de fournir à un client une liste datée des périphériques affectés et non affectés, l'état d'exposition avant l'atténuation, les commandes ou les modifications de configuration utilisées pour fermer la surface de gestion, la version du logiciel corrigé cible, le résultat de l'évaluation de la compromission et toute exception restante. Le client n'a pas besoin de chaque capture de paquet ou détail sensible des informations d'identification. Il a besoin de suffisamment de preuves pour décider si la continuité de l'activité, la notification de l'assurance cyber, la communication avec les auditeurs ou la notification du client est nécessaire. Une déclaration générique selon laquelle « les périphériques Cisco ont été examinés » n'est pas la même chose qu'un dossier de récupération.

Ce dossier devrait également identifier qui a approuvé l'état exposé avant l'incident. Dans de nombreux réseaux, une interface de gestion devient accessible en raison d'une ancienne exception, d'un changement temporaire de dépannage, d'un modèle hérité d'un prédécesseur ou d'un modèle de support externalisé qui normalise discrètement un accès étendu. Fermer l'exposition après un zero-day est nécessaire, mais la responsabilité exige de comprendre pourquoi l'exposition existait. Si la raison n'est pas saisie, le même schéma peut réapparaître lorsqu'un périphérique de remplacement est installé, qu'une configuration de sauvegarde est restaurée ou qu'un fournisseur de support standardise le prochain déploiement.

Les lacunes des preuves sont elles-mêmes instructives

Le dossier public ne fournit pas un décompte complet des victimes, une attribution complète des acteurs, tous les détails de l'implant, chaque plate-forme matérielle affectée, l'état d'exposition de chaque client ou une prescription de récupération universelle. Certaines de ces informations peuvent ne pas être connaissables publiquement. Certaines peuvent avoir été partagées en privé avec les clients affectés ou les forces de l'ordre. L'absence ne doit pas être comblée par la spéculation.

La conclusion publique la plus responsable est plus étroite. Cisco et la CISA ont documenté l'exploitation active des vulnérabilités de l'interface utilisateur web d'IOS XE, avec la création de compte de privilège 15, l'élévation à root et l'écriture d'implant. La CISA a exhorté à désactiver l'exposition du serveur HTTP sur Internet, à rechercher et à mettre à niveau. Des versions corrigées sont devenues disponibles dans les différents trains de versions. Les conséquences en matière de responsabilité dépendent de l'exposition locale, de l'inventaire et de la récupération.

Cette limite des preuves protège contre deux mauvais récits. Le premier mauvais récit dit que tout l'événement était simplement la faute de Cisco. Cela ignore le contrôle des clients et des fournisseurs de services gérés sur la gestion exposée à Internet. Le deuxième mauvais récit dit que tout l'événement était simplement la faute des clients pour avoir exposé la gestion. Cela ignore la responsabilité de Cisco pour les vulnérabilités, la qualité des avis, la livraison des correctifs et les incitations à la conception du produit.

La vérité est moins satisfaisante et plus utile. Les défauts du produit et l'exposition du déploiement se sont combinés. Les attaquants ont exploité les deux. Une bonne récupération a nécessité des correctifs du fournisseur et une discipline de l'opérateur. Le contrôle d'aucune des parties n'était complet, mais les deux parties avaient suffisamment de contrôle pour être responsables de leur part.

L'événement montre également à quel point il est difficile de prouver la confiance négative après une compromission du plan de gestion. Un périphérique peut être corrigé, mais l'opérateur peut-il prouver qu'il n'y a pas eu de création de compte? Un utilisateur peut être supprimé, mais l'opérateur peut-il prouver qu'aucune configuration n'a changé? Un implant peut disparaître après le redémarrage, mais l'opérateur peut-il prouver qu'il n'y a pas eu de persistance ultérieure? Un message d'état public répond rarement à ces questions. Une architecture des preuves construite avant l'incident le fait.

La responsabilité suit le plan de gestion

Le plan de gestion est le lieu où l'autorité se concentre. C'est là que les administrateurs s'authentifient, que les configurations changent, que les utilisateurs sont créés, que les services sont activés, que les journaux sont consultés et que la récupération commence. Laisser ce plan accessible depuis Internet public crée un pari permanent: que l'authentification, le code, la configuration, la surveillance et les correctifs resteront tous suffisamment solides contre chaque exploit actuel et futur.

L'incident de l'interface utilisateur web d'IOS XE a montré que le pari peut échouer. Le produit de Cisco avait deux problèmes auparavant inconnus dans la chaîne de l'interface utilisateur web. Les clients et les fournisseurs avaient exposé des interfaces de gestion. Les attaquants se sont déplacés assez rapidement pour que l'atténuation et la livraison des correctifs deviennent une urgence. Les agences gouvernementales ont dû amplifier les conseils. Les opérateurs ont dû rechercher la création de comptes et les implants. Les PME ont dû compter sur les fournisseurs pour obtenir des réponses.

La leçon n'est pas d'éliminer toute administration à distance. Les réseaux modernes ont besoin d'une gestion à distance. La leçon est de traiter l'accès à la gestion comme une infrastructure privilégiée avec une surface d'attaque plus petite, une identité plus forte, des restrictions réseau, une journalisation, un contrôle des modifications et un examen continu de l'exposition. L'administration à distance devrait être accessible par des chemins de gestion délibérés, pas par une exposition publique généralisée sur Internet.

Pour Cisco, la leçon continue est une posture de plan de gestion sécurisée dès la conception: rendre l'exposition non sécurisée plus difficile, rendre les configurations dangereuses visibles, rendre les correctifs traçables, rendre les conseils de détection exploitables et rendre le mappage des versions moins confus. Pour les clients et les fournisseurs de services gérés, la leçon est la vérité sur les actifs et l'exposition: savoir ce qui fonctionne, savoir ce qui est accessible, savoir à qui il appartient, savoir comment le désactiver, savoir comment le reconstruire et savoir quelles preuves prouveront le nettoyage.

Pour les agences publiques et les régulateurs, la leçon est que les interfaces de gestion des périphériques réseau méritent la même visibilité que les CVE d'applications à la une. Un routeur ou un commutateur compromis peut fausser l'environnement des preuves autour d'autres incidents. Il peut devenir un angle mort dans l'architecture de réponse. Cela fait de l'exposition du plan de gestion un risque de continuité, pas seulement un problème d'hygiène informatique.

Le dossier de l'exploitation de l'interface utilisateur web de Cisco IOS XE en 2023 est précieux parce qu'il refuse une fin simple. Les correctifs ont compté. Le durcissement a compté. Les avis ont compté. L'inventaire a compté. La responsabilité des fournisseurs de services gérés a compté. L'implant a compté. L'interface exposée a compté le plus parce qu'elle a décidé quels périphériques étaient accessibles avant que les défenseurs n'aient des informations parfaites.

La conclusion responsable est donc pratique. Un périphérique réseau ne devrait pas avoir à être compromis avant que son propriétaire ne découvre qu'une interface utilisateur web de gestion était ouverte au monde. Un fournisseur ne devrait pas compter sur les clients pour trouver chaque exposition non sécurisée après qu'un zero-day a déjà atterri. Un fournisseur ne devrait pas dire à un client « nous l'avons géré » sans preuve. Dans la sécurité du plan de gestion, la confiance n'est pas un sentiment à propos d'une marque ou d'un niveau de correctif. C'est un dossier: exposition fermée, compromission évaluée, logiciel corrigé, périphérique reconstruit si nécessaire et autorité réseau restaurée avec preuve.