Une vulnérabilité a été découverte dans l’implémentation Java du protocole sécurisé SAML de fédération OpenSAML. Cette bibliothèque / librairie est très largement employée par de multiples solutions applicatives « SP » (fournisseurs de service) ou « IdP » (fournisseur d’identité) afin d’être compatible SAML (opensource ou d’éditeurs propriétaires).
La bibliothèque OpenSAML est notamment utilisée dans la solution Shibboleth (solution de SSO cross-domain), CAS, SuisseID, MyProxy, JBoss, OLAT, gLite, et au sein de nombreuses solutions d’éditeurs.
A titre de rappel, les échanges SAML (v1.0, 1.1 ou 2.0) sont au format XML et permettent d’identifier / authentifier une identité au sein d’un trust établie entre deux partis. Cette zone de confiance est régie par des certificats présents au niveau du SP et de l’IdP, afin de s’assurer de la provenance et de l’authenticité des messages SAML.
Les scénarios standards de fédération des identités (authentification) via SAML respectent le profil « IdP-initiated » ou « SP-initiated » dont les représentations schématiques sont les suivantes :
IdP-initated :
SP-initiated :
OpenSAML is a set of open source C++ & Java libraries meant to support developers working with the Security Assertion Markup Language (SAML). OpenSAML 2, the current version, supports SAML 1.0, 1.1, and 2.0. Additionally, various development groups have found the framework created to support OpenSAML 2 useful for their own work. We are in the process of integrating their code supporting WS-Addressing, WS-Security, WS-Trust and XACML.
Description de la vulnérabilité
La bibliothèque Java OpenSAML présente une vulnérabilité sur la vérification de la provenance des certificats, notamment lorsqu’utilisée par Fedora pour gérer des connexions HTTP sur SSL, à l’aide de Apache HttpClient 3.
Pour authentifier un serveur, il est nécessaire que le client voulant authentifier la connexion au serveur ait validé le certificat (signatures cryptographiques, dates de validité, etc.), mais aussi que le certificat présenté corresponde bien au serveur visité. Cette vérification se fait normalement par les noms DNS, parfois par les adresses IP.
Cependant, HttpClient ne vérifie pas la compatibilité entre les noms présents dans le certificat et celui demandé au niveau http, cette deuxième clause de vérification du protocole n’étant pas vérifié, tout certificat ayant été récupéré d’une plateforme légitime et ayant validé la première clause est accepté.
Un attaquant peut donc placer un certificat valide sur un serveur illicite, puis inviter un client OpenSAML Java à s’y connecter, ce client ne vérifiera pas la deuxième clause de sécurité et déclarera donc le certificat comme valide, donnant ainsi la possibilité à l’attaquant d’intercepter toutes les communications transitant par ce serveur malgré l’utilisation du chiffrement.
Ce n’est nullement une vulnérabilité portant sur le protocole SAML en tant que tel, mais bien sur une implémentation de celui-ci dans un contexte particulier. L’implémentation en question « OpenSAML » est l’une des plus employés pour rendre des applications «SAML-Ready »
Nous vous invitons à mettre à jour les versions des bibliothèques OpenSAML employées dans vos applications internes SAML-Ready, ainsi que d’appliquer les éventuels patchs éditeurs / communautaires afin de combler cette brèche sécuritaire.
Sources & ressources :
Georges
Consultant Sécurité
