Vulnérabilité critique dans Shibboleth ODBC : injection SQL possible

Mauvaise nouvelle pour les équipes d’authentification fédérée : le CERT-FR a publié un avis de sécurité le 4 septembre 2025 révélant une faille dans le Service Provider de la solution Shibboleth, très utilisée dans l’enseignement supérieur et la recherche. Le coupable ? Le greffon ODBC, un petit composant souvent oublié… jusqu’à ce qu’il permette une injection SQL.

Que s’est-il passé ?

La vulnérabilité réside dans la gestion des requêtes SQL du greffon ODBC. Un attaquant peut insérer du code malveillant dans les paramètres de connexion via une URL ou un formulaire mal protégé. Résultat : accès non autorisé à la base de données, exfiltration d’identifiants, altération de données ou même escalade de privilèges sur le serveur.

Pourquoi c’est sensible

Shibboleth centralise les accès à des ressources critiques (ENT, bibliothèques, nuance pédagogique, etc.). Si le greffon ODBC sert à synchroniser des comptes depuis un annuaire externe, la compromission peut se propager à l’ensemble du système d’information. Autrement dit, une injection SQL ici peut devenir un passeport pour le réseau complet.

Que faire immédiatement ?

1. Repérer : listez tous les SP Shibboleth exposés sur Internet et vérifiez la présence du greffon ODBC (fichier odbc.so ou configuration <DataConnector id=" ODBC">).
2. Patcher : appliquez la version corrigée dès sa sortie ou désactivez totalement le greffon si vous ne l’utilisez pas.
3. Surveiller : activez la journalisation SQL et scruter les logs pour les payloads suspects (apostrophes imbriquées, commentaires SQL, UNION SELECT, etc.).
4. Compartimenter : isolez la base accessible par ODBC derrière un pare-feu strict et un compte aux droits minimaux.

Bonus : un test rapide en 30 secondes

Depuis un terminal, lancez :

curl -s "https://votre-sp.shibboleth.fr/entity-id?uid=admin'%20OR%201=1--" | grep -i "error"

Si la page révèle une erreur SQL brute, c’est le signal d’alarme. Arrêtez-le service et passez à l’action.

Et demain ?

Cette affaire rappelle que même les briques d’authentification « éprouvées » ont besoin d’un audit régulier. Intégrer le greffon ODBC dans vos scénarios de test automatisés, abonnez-vous aux flux du CERT-FR et, surtout, réduisez la surface exposée : un composant non utilisé est un composant à retirer.

Votre expérience : Avez-vous déjà croisé cette vulnérabilité ou une variante similaire sur un autre connecteur ? Partagez vos retours et scripts de mitigation dans les commentaires ; la communauté vous en remerciera !