{"id":1313,"date":"2026-11-11T10:00:00","date_gmt":"2026-11-11T09:00:00","guid":{"rendered":"https:\/\/remivernier.com\/?p=1313"},"modified":"2026-11-11T10:00:00","modified_gmt":"2026-11-11T09:00:00","slug":"sap-netweaver-avis-saml2-cvss-10-novembre-2026","status":"publish","type":"post","link":"https:\/\/remivernier.com\/index.php\/2026\/11\/11\/sap-netweaver-avis-saml2-cvss-10-novembre-2026\/","title":{"rendered":"SAP NetWeaver: lire l’avis SAML2 CVSS 10 de novembre"},"content":{"rendered":"

Le 10 novembre 2026, le Patch Day SAP de novembre<\/a> a publi\u00e9 35 nouvelles notes de s\u00e9curit\u00e9 et 4 avis GitHub. Quatre d’entre elles sont not\u00e9es CVSS 10.0, et l’une touche un composant que beaucoup d’entre nous ont activ\u00e9 sans trop y penser: le fournisseur de service SAML2 d’AS ABAP, celui qui permet aux utilisateurs d’arriver dans Fiori ou dans le Web GUI apr\u00e8s s’\u00eatre authentifi\u00e9s aupr\u00e8s d’ADFS ou d’Entra ID.<\/p>\n

Il s’agit de la note 3849308<\/a>, enregistr\u00e9e sous CVE-2026-120017<\/a> et class\u00e9e CWE-347 (v\u00e9rification incorrecte d’une signature cryptographique). La description publique de SAP est courte: dans certaines configurations, AS ABAP ne v\u00e9rifie pas suffisamment les assertions d’authentification qu’il re\u00e7oit, et un attaquant non authentifi\u00e9 peut envoyer des donn\u00e9es forg\u00e9es pour se faire passer pour n’importe quel utilisateur, comptes \u00e0 privil\u00e8ges compris. Le vecteur ne demande ni identifiant ni interaction de l’utilisateur.<\/p>\n

Nous allons voir ce que le SP SAML2 d’ABAP est cens\u00e9 contr\u00f4ler dans une r\u00e9ponse SAML, pourquoi un d\u00e9faut sur la signature fait tomber tout le reste, puis ce qu’il faut v\u00e9rifier sur un syst\u00e8me.<\/p>\n

Que valide un SP SAML2 c\u00f4t\u00e9 ABAP?<\/h2>\n

Dans un SSO SAML 2.0, le syst\u00e8me SAP ne voit jamais le mot de passe. Il re\u00e7oit un document XML \u00e9mis par le fournisseur d’identit\u00e9 (IdP) et la seule chose qui lui permet de croire ce document, c’est la signature, v\u00e9rifi\u00e9e avec le certificat de l’IdP import\u00e9 dans la configuration \u00ab Trusted Providers \u00bb. Nous avions compar\u00e9 SAML \u00e0 OpenID Connect et WS-Federation dans cet article<\/a>.<\/p>\n

\n\n<\/marker><\/defs>\n\nNavigateur<\/text>\n\nAS ABAP (SP)<\/text>\nsrv01.test.local<\/text>\n\nIdP<\/text>\nadfs.test.local<\/text>\n\n\n\n\n1. GET Fiori Launchpad<\/text>\n\n2. Redirection + AuthnRequest<\/text>\n\n3. Authentification aupr\u00e8s de l’IdP<\/text>\n\n4. R\u00e9ponse SAML sign\u00e9e (formulaire POST)<\/text>\n\n5. POST vers l’ACS<\/text>\n\nSignature + certificat IdP<\/text>\nIssuer, Audience, Destination<\/text>\nDates, InResponseTo, NameID<\/text>\n\n6. Session SAP ouverte<\/text>\n<\/svg>
Flux SAML2 initi\u00e9 par le SP: la note 3849308 porte sur l’\u00e9tape 5.<\/figcaption><\/figure>\n

Le navigateur transporte la r\u00e9ponse et la poste lui-m\u00eame sur l’Assertion Consumer Service d’ABAP: n’importe qui peut donc poster n’importe quoi sur ce point d’entr\u00e9e. Prenons le squelette d’une r\u00e9ponse telle qu’ADFS l’envoie \u00e0 notre maquette (domaine test.local, syst\u00e8me srv01, client 100), r\u00e9duite aux \u00e9l\u00e9ments que le SP contr\u00f4le:<\/p>\n

<samlp:Response ID=\"_r01\" InResponseTo=\"_req42\"\n    Destination=\"https:\/\/srv01.test.local:44300\/sap\/saml2\/sp\/acs\/100\">\n  <saml:Issuer>http:\/\/adfs.test.local\/adfs\/services\/trust<\/saml:Issuer>\n  <saml:Assertion ID=\"_a01\">\n    <saml:Issuer>http:\/\/adfs.test.local\/adfs\/services\/trust<\/saml:Issuer>\n    <ds:Signature> ... <ds:Reference URI=\"#_a01\"> ... <\/ds:Signature>\n    <saml:Subject>\n      <saml:NameID Format=\"urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified\">JDUPONT<\/saml:NameID>\n      <saml:SubjectConfirmation Method=\"urn:oasis:names:tc:SAML:2.0:cm:bearer\">\n        <saml:SubjectConfirmationData InResponseTo=\"_req42\"\n            Recipient=\"https:\/\/srv01.test.local:44300\/sap\/saml2\/sp\/acs\/100\"\n            NotOnOrAfter=\"2026-11-11T09:05:00Z\"\/>\n      <\/saml:SubjectConfirmation>\n    <\/saml:Subject>\n    <saml:Conditions NotBefore=\"2026-11-11T09:00:00Z\" NotOnOrAfter=\"2026-11-11T10:00:00Z\">\n      <saml:AudienceRestriction><saml:Audience>https:\/\/srv01.test.local<\/saml:Audience><\/saml:AudienceRestriction>\n    <\/saml:Conditions>\n    <saml:AuthnStatement AuthnInstant=\"2026-11-11T09:00:12Z\"> ... <\/saml:AuthnStatement>\n  <\/saml:Assertion>\n<\/samlp:Response><\/code><\/pre>\n
Sur cette r\u00e9ponse, nous retrouvons les contr\u00f4les que le SP encha\u00eene:<\/p>\n
    \n
  1. La signature XML (sur la r\u00e9ponse, sur l’assertion ou les deux selon la configuration du fournisseur de confiance) est valide et a \u00e9t\u00e9 produite par la cl\u00e9 dont le certificat est d\u00e9clar\u00e9 pour cet IdP.<\/li>\n
  2. La r\u00e9f\u00e9rence de la signature couvre bien l’\u00e9l\u00e9ment qui sera exploit\u00e9 ensuite (URI=\"#_a01\"<\/code> doit d\u00e9signer l’assertion lue, pas une copie plac\u00e9e ailleurs dans le document).<\/li>\n
  3. L’Issuer correspond \u00e0 un fournisseur de confiance, l’Audience au nom du fournisseur local, Destination et Recipient \u00e0 l’URL de l’ACS.<\/li>\n
  4. Les fen\u00eatres NotBefore<\/code>\/NotOnOrAfter<\/code> sont respect\u00e9es et InResponseTo<\/code> correspond \u00e0 une requ\u00eate \u00e9mise par le SP.<\/li>\n
  5. Le NameID est converti en utilisateur SAP selon le mode d\u00e9fini dans l’onglet \u00ab Identity Federation \u00bb: nom d’utilisateur, adresse e-mail, alias ou identifiant externe.<\/li>\n<\/ol>\n
    Nous voyons que les points 3 \u00e0 5 portent sur des valeurs \u00e9crites dans le document: ils ne valent que si le point 1 garantit que l’IdP les a \u00e9crites. Quand la signature n’est pas v\u00e9rifi\u00e9e, ou qu’elle l’est sur un autre \u00e9l\u00e9ment que celui qui est lu (\u00ab signature wrapping \u00bb), il suffit \u00e0 l’attaquant de construire un document coh\u00e9rent avec l’ACS, l’Audience et un nom d’utilisateur, valeurs qui figurent souvent dans les m\u00e9tadonn\u00e9es SAML. SAP ne pr\u00e9cise ni la variante en cause, ni les configurations concern\u00e9es.<\/p>\n
    Attention, dans l’article sur le Golden SAML<\/a>, nous avions vu que l’attaquant devait d’abord voler la cl\u00e9 de signature d’ADFS. Ici il n’a besoin d’aucun secret, le d\u00e9faut est dans le contr\u00f4le fait par le SP.<\/p>\n
    Ce qu’un attaquant en fait<\/h2>\n
    Nous sommes dans les techniques MITRE ATT&CK T1190<\/a> et T1606.002<\/a>. L’ACS doit rester joignable par tous les navigateurs, il est donc souvent publi\u00e9 via le Web Dispatcher pour les nomades ou les partenaires. L’attaquant y poste une r\u00e9ponse forg\u00e9e au nom d’un compte choisi et r\u00e9cup\u00e8re les cookies de session SAP avec les autorisations de ce compte.<\/p>\n
    Si le mapping se fait sur le nom d’utilisateur SAP, tout utilisateur de dialogue du client est une cible, y compris un administrateur avec SAP_ALL, et l’impact d\u00e9passe le syst\u00e8me cibl\u00e9:<\/p>\n