Cisco met en garde contre les vulnérabilités critiques d’API dans l’ISE et l’ISE-PIC

Le défaut derrière les deux vulnérabilités: trous dans les interfaces de programmation d’applications (API).

«Prenez cette vulnérabilité au sérieux», a déclaré Moses Frost, instructeur de cours principal sur les tests de pénétration du cloud au SANS Institute. «D’après mon expérience, l’évaluation des réseaux, j’ai trouvé à travers des tests que beaucoup manquent de correctifs essentiels et de durcissement de sécurité sur leurs appareils de réseau central. J’ai vu des déploiements Cisco ISE où les utilisateurs réguliers peuvent également accéder librement à tous les ports de l’ISE, y compris les pages administratives. Supposons que les acteurs de la menace auraient également accessible à l’intérieur du réseau.

Quelle est la taille du risque? Cisco ISE est souvent utilisé comme système d’authentification sans fil, a indiqué Frost, qui comprend fréquemment des portails de réseau invité, et il est également probablement intégré à Microsoft Active Directory en tant que système très fiable. Il est également utilisé pour authentifier l’accès aux couches d’administration des routeurs, commutateurs, pare-feu et autres périphériques réseau – et il peut être utilisé comme produit de contrôle d’accès au réseau (NAC).

‘L’un des pires que j’ai vus’

«C’est probablement l’un des pires (défauts) que j’ai vus en termes d’impact», a déclaré Kellman Meghu, architecte principal de la sécurité chez Deepcove Cybersecurity. «C’est un chemin pour un attaquant non authentifié et distant d’obtenir le privilège de plus haut niveau possible, donc je ne sais même pas comment cela empire, et puis c’est le cas.»

«Cela est plus grave pour les entreprises qui ne parviennent pas à effectuer l’hygiène de sécurité appropriée», a déclaré Robert Beggs, PDG de la société canadienne de réponse aux incidents Digital Defence.

Par cela, il signifie ceux qui n’ont pas d’inventaire matériel qui inclut les composants du réseau, qui ne surveillent pas les annonces des fournisseurs ou des médias de vulnérabilités récentes, ou qui n’ont pas la licence qui facilite les mises à niveau et les correctifs du système.

Cisco a des correctifs pour ces problèmes, mais ils ne sont pas livrés automatiquement, a-t-il souligné et les administrateurs doivent suivre le processus de Cisco pour obtenir le correctif.

Parce que l’ISE est le gardien de l’accès au réseau (câblé, sans fil, VPN ou accès invité), il a averti, l’accès racine permettra aux attaquants d’obtenir les informations d’identification pour un mouvement complet à travers tous les segments de réseau.

Critique nominal

Les vulnérabilités – évaluées par Cisco comme critiques – sont: sont:

• Le CVE-2025-20281 affecte les versions Cisco ISE et ISE-PIC 3.3 et ultérieurement, quelle que soit la configuration de l’appareil. Un attaquant ne nécessite aucune information valide pour exploiter cette vulnérabilité.
  Cette vulnérabilité dans une API spécifique est due à une validation insuffisante de l’entrée fournie par l’utilisateur. Un attaquant pourrait exploiter cette vulnérabilité en soumettant une demande d’API fabriquée, puis en bénéficiant des privilèges sur un appareil affecté;
• Le CVE-2025-20282 n’affecte que Cisco ISE et ISE-PIC Release 3.4, quelle que soit la configuration de l’appareil.
  Cette vulnérabilité API est due à un manque de vérifications de validation des fichiers qui empêcheraient les fichiers téléchargés d’être placés dans des répertoires privilégiés sur un système affecté. Un attaquant pourrait exploiter cette vulnérabilité en téléchargeant un fichier fabriqué sur l’appareil. Un exploit réussi pourrait permettre à l’attaquant de stocker des fichiers malveillants sur le système affecté, puis d’exécuter du code arbitraire ou d’obtenir des privilèges sur le système.

Pas de solution de contournement

Les correctifs doivent être installés pour les deux vulnérabilités; Il n’y a pas de solution de contournement.

De plus, les vulnérabilités ne dépendent pas les unes des autres, Cisco souligne dans son avis. L’exploitation de l’une des vulnérabilités n’est pas nécessaire pour exploiter l’autre vulnérabilité. De plus, une version logicielle affectée par l’une des vulnérabilités peut ne pas être affectée par l’autre.

Bien que les API en général soient excellentes, a déclaré Frost, « la partie malheureuse d’entre eux est que de nombreuses vulnérabilités d’application Web standard s’appliquent également. Ce qui est réellement pire que cela, c’est que les bogues que nous avions il y a 10 ans ou plus, qui ont été résolus par les cadres, réapparaissent tous dans les API. »

Il a ajouté: « Si j’avais géré une équipe de développement autour de cela aujourd’hui, je reviendrais sur les bogues OWASP plus anciens (identifiés par le projet de sécurité des applications Web Open) pour m’assurer que certaines classes de bogues qui avaient été éliminées, telles que les vulnérabilités liées aux critères de terminaison non authentifiées ou aux problèmes d’attribution en masse, sont toujours traités. »

Vulnérabilités de l’API communes

En tant que moyen clé de lier les applications et de partager des données, les API sont un élément essentiel des applications mobiles, SaaS et Web. Comme le note OWASP, par nature, les API exposent la logique d’application et les données sensibles telles que les informations personnellement identifiables (PII), il en va de même pour les acteurs de la menace s’ils ne sont pas écrits avec du code sécurisé. Le projet de sécurité API d’OWASP décrit les meilleures pratiques pour les développeurs afin d’éviter les problèmes d’API comme:

• Autorisation au niveau de l’objet cassé. Pour éviter cela, les vérifications d’autorisation au niveau des objets doivent être prises en compte dans chaque fonction qui accède à une source de données à l’aide d’un ID de l’utilisateur;
• Autorisation brisée due à des mécanismes d’autorisation incorrectement mis en œuvre. Cela permet aux attaquants de compromettre les jetons d’authentification ou d’exploiter des défauts d’implémentation pour supposer les identités des autres utilisateurs. Les OSC doivent s’assurer que les développeurs connaissent tous les flux possibles à s’authentifier avec l’API.
  Les clés de l’API ne doivent pas être utilisées pour l’authentification des utilisateurs, souligne OWASP. Ils ne doivent être utilisés que pour l’authentification des clients d’API. OAuth n’est pas l’authentification, ajoute OWASP, et les clés API ne sont pas non plus;
• La consommation de ressources sans restriction des API, ce qui peut entraîner des attaques de déni de service;
• accès sans restriction aux flux commerciaux sensibles;
• Fonctionnement des demandes côté serveur (SSRF), causé par une API récupérant une ressource distante sans valider l’URI fourni par l’utilisateur (identifiant de ressources uniformes). Cela permet à un attaquant de contraindre la demande d’envoyer une demande fabriquée à une destination inattendue, même lorsqu’elle est protégée par un pare-feu ou un VPN;
• Merfection des erreurs de sécurité. Les API et les systèmes qui les soutiennent contiennent généralement des configurations complexes. Cela, dit OWASP, est destiné à rendre les API plus personnalisables. Cependant, les ingénieurs de logiciels et de DevOps peuvent manquer ces configurations ou ne pas suivre les meilleures pratiques de sécurité en ce qui concerne la configuration, ouvrant la porte à différents types d’attaques.

OWASP dit que le cycle de vie de l’API devrait inclure un processus de durcissement reproductible conduisant à un déploiement rapide et facile d’un environnement correctement verrouillé; Une tâche pour examiner et mettre à jour les configurations sur toute la pile API. L’examen doit inclure: les fichiers d’orchestration, les composants de l’API et les services cloud (par exemple, les autorisations S3 Bucket); et un processus automatisé pour évaluer en continu l’efficacité de la configuration et des paramètres dans tous les environnements.

En outre, les leaders du développement d’applications doivent s’assurer que toutes les communications d’API du client vers le serveur API et tous les composants en aval / en amont se produisent sur un canal de communication crypté (TLS), qu’il s’agisse d’une API interne ou orientée publique.

Et ceux qui pensent que le code généré par l’AI sera plus sûr peut constater qu’ils sont en fait plus susceptibles d’exposer les clés d’API et d’autres secrets, selon cette étude.

Plusieurs couche de défense nécessaire

Étant donné que des automatisations plus fraîches et plus lisses sont ajoutées aux systèmes informatiques existants, les erreurs de codage sont inévitables, a noté Meghu.