Apres CVE-2026-20184 Cisco Webex — 7 etapes pour auditer votre perimetre SAML SSO en 48h

— Pourquoi CVE-2026-20184 declenche une revue SAML globale

CVE-2026-20184 a expose une faille de validation SAML dans Cisco Webex permettant a un attaquant authentifie de manipuler des assertions et d obtenir un acces eleve a des espaces de meeting et workspaces normalement restreints. Au-dela de l incident specifique a Cisco, le CVE est l occasion pour les RSSI francais de revoir leur posture SAML SSO globale, qui souffre de defauts recurrents dans la grande majorite des organisations que j audite : assertions sans signature, audience restrictions absentes, NotOnOrAfter trop laxistes, certificats IdP non rotates depuis des annees.

L objectif de cet article est de fournir un plan d audit de 48 heures, executable par un consultant senior ou un binome RSSI plus ingenieur IAM, qui couvre les 7 etapes critiques d une revue SAML SSO complete. Le perimetre cible : une entreprise francaise typique avec 1 IdP central (Azure AD, Okta, Ping ou ADFS) et 30 a 80 Service Providers federes. Pour les grandes entreprises avec multi-IdP et federation cross-cloud, le meme plan s execute en 5 a 10 jours.

— Etape 1 (heures 0-4) : cartographie des Service Providers

Premiere question : quels sont les SP federes a votre IdP ? Sur Azure AD, exporter via PowerShell Get-MgServicePrincipal -All | Where-Object {$_.PreferredSingleSignOnMode -eq 'saml'}. Sur Okta, l export AdminConsole ou l API /api/v1/apps?filter=signOnMode eq "SAML_2_0". Sur Ping, Federation Manager > Connections SP. Sur ADFS, Get-AdfsRelyingPartyTrust.

Le livrable de cette etape est une liste exhaustive : nom du SP, EntityID, AssertionConsumerService URL, NameID format, attributes mappes, statut actif/inactif, date de creation, owner business. Mon experience : 30 a 50% des SP listes ne sont plus utilises mais restent actifs avec des certificats expires ou des configurations qui datent de 2018. C est le premier low-hanging fruit : desactiver les SP inactifs. Sur le perimetre WebGuard que j ai audite en mars 2026 chez un client banque francaise, on est passe de 142 SP a 87 SP utiles, soit une reduction de 39% de la surface d attaque IAM.

— Etape 2 (heures 4-8) : inventaire IdP et configuration globale

Audit de l IdP central. Verifier (1) la version exacte de l IdP et la presence de patchs critiques recents : Okta a publie 4 patchs SSO en 2025-2026, Azure AD a corrige 3 vulnerabilites SAML en 2025. (2) La rotation des certificats de signature IdP : un certificat de plus de 24 mois est suspect, plus de 36 mois est inacceptable. (3) Les algorithmes de signature actifs : RSA-SHA256 minimum, jamais SHA1 ni MD5 (encore present dans 12% des configs ADFS legacy). (4) La politique d acces conditionnel : MFA pour les comptes admin SSO, geo-blocking pour les pays non-business, blocage des authentifications anciennes (POP, IMAP).

Documenter dans un tableau standardise pour reference future : version IdP, date dernier patch, certificats signature avec dates expiration, algorithmes acceptes, polices d acces conditionnel actives. Ce document devient une piece du dossier audit NIS2 obligatoire pour les entites OSE et OIV.

— Etape 3 (heures 8-16) : audit des assertions SAML

Pour chaque SP critique (top 20 en nombre d utilisateurs), capturer une assertion SAML reelle via SAML Tracer (extension Firefox ou Chrome). Verifier ligne par ligne : (a) <Signature> presente sur Response ET Assertion, (b) <AudienceRestriction> avec EntityID exact du SP, (c) <NotOnOrAfter> a 5 minutes maximum (pas 30 minutes ni 1 heure), (d) <SubjectConfirmationData> avec Recipient, NotOnOrAfter et InResponseTo, (e) <NameID Format> approprie au cas d usage (persistent pour MFA enrolled, transient pour ephemere).

Les defauts les plus communs que je rencontre : NotOnOrAfter a 30 minutes ou 1 heure (laxiste, augmente la fenetre de replay), absence de Signature sur Response (acceptable seulement si Assertion signee separement), absence de SubjectConfirmationData (replay attaques facilites), AudienceRestriction generique avec wildcards (totalement non-conforme).

— Etape 4 (heures 16-24) : audit signatures, certificats et chaines de confiance

Pour chaque assertion capturee, verifier la signature numerique. Outil : SAMLtester (https://www.samltool.com) ou un script Python avec signxml. Tests obligatoires : (1) signature valide cryptographiquement avec le certificat IdP attendu, (2) algorithme de signature parmi RSA-SHA256, RSA-SHA384, RSA-SHA512 ou ECDSA-SHA256+, (3) canonicalization XML utilisee parmi C14N exclusive (recommande) ou C14N standard, (4) absence de canonicalization vulnerable au XML signature wrapping (xmldsig-core).

Verifier separement la chaine de confiance des certificats IdP cote SP : sont-ils embedded dans la metadata SP, ou recuperes via federation metadata URL (cas plus securise) ? Les certificats sont-ils ancres a une CA fiable ou self-signed ? Pour les self-signed, verifier le pinning cote SP. Sur les ADFS legacy, j ai trouve en 2025 un client avec 3 certificats expires depuis plus de 6 mois mais encore acceptes par 4 SP a cause d une mauvaise configuration de rejet.

— Etape 5 (heures 24-32) : scenarios de test offensifs

Apres l audit statique, executer des scenarios de test offensifs pour valider la robustesse en runtime. Test 1 : XML Signature Wrapping (XSW). Capturer une assertion legitime, dupliquer le bloc Assertion en deplacant la signature, observer si le SP accepte la fausse assertion. Test 2 : assertion replay. Resoumettre une assertion deja consommee avec un IDS attaquant et observer si le SP detecte le replay (champ InResponseTo et OneTimeUse obligatoires). Test 3 : audience confusion. Manipuler le champ AudienceRestriction et observer le comportement SP. Test 4 : NameID injection. Tester des NameID exotiques (transient avec format incorrect, persistent avec caracteres unicode).

Ces tests prennent 4 a 8 heures pour un perimetre standard. Burp Suite Pro ou ZAP Proxy permettent l interception et la manipulation des assertions. Pour les SP qui exposent un endpoint SCIM en plus de SAML (Webex le fait), inclure des tests sur les endpoints SCIM avec attaques d injection JSON.

— Etape 6 (heures 32-40) : review configurations SP et hygiene

Cote SP, verifier configuration : (a) signature des assertions exigee, (b) chiffrement des assertions actif pour les attributs sensibles (NameID, attributes role/groupes), (c) audience restriction strict, (d) replay protection avec store de IDs assertion, (e) horloge IdP-SP synchronisee a moins de 30 secondes (NTP centralise), (f) URL ACS protegee par HTTPS valide, (g) endpoint SLO (Single Logout) configure et fonctionnel.

Pour les principaux SP francais : Microsoft 365, Salesforce, ServiceNow, Workday, SAP SuccessFactors, AWS, GCP, GitHub Enterprise, Atlassian Cloud, Slack, Zoom. Chacun a des subtilites de configuration. Notre check-list interne couvre 38 points de validation par SP. Pour les SP francais comme Cegid, Lucca ou Ringover, la documentation publique sur SSO est moins riche, des tests plus pousses sont recommandes.

— Etape 7 (heures 40-48) : reporting et plan de remediation

Le livrable final consiste en trois documents. Document 1 : rapport executif de 4 a 6 pages pour direction generale et RSSI : criticite globale, top 5 risques, plan d action 30/60/90 jours. Document 2 : rapport technique de 30 a 60 pages pour les equipes IAM : detail des findings par SP, captures d ecran, scripts de remediation, references RFC SAML 2.0 et OASIS Security Considerations. Document 3 : plan de remediation sous forme de Kanban (Trello, Jira, Notion) avec 30 a 100 tickets prioritaires.

Pour les RSSI sous obligation NIS2, ce livrable s integre directement dans le rapport annuel de conformite. Pour les organisations sous obligation BCBS 239 ou DORA (banques), il complete le rapport BCO IT operational risk. Les recommandations sont a planifier sur 90 jours maximum, avec un suivi mensuel jusqu a fermeture de tous les findings critiques.

Pour aller plus loin sur les sujets connexes, l equipe d-open.org a publie une analyse cote developpeurs : implementation SAML securisee pour developpeurs. Pour la dimension IA et automation des audits IAM, voir l analyse Plug-Tech sur les agents IA appliques aux audits IAM. Notre analyse CVE-2026-40372 ASP.NET Core documente une autre vulnerabilite touchant les sessions web a travers DataProtection Key Ring.

— FAQ