🔐 OneLogin : quand ton gestionnaire d’identité devient la faille d’identité — ou comment prêter tes clés à un inconnu élégant

Imagine : tu confies toutes les clés de la baraque à un super coffre-fort numérique censé garder la maison. La promesse de OneLogin 🤔. Puis, un matin, tu découvres qu’un tiroir — celui qui devrait être scellé à double tour — renvoyait ses clés en clair via une simple requête API. Eh bien, bienvenue dans l’épisode CVE-2025-59363, protagoniste principal : One Identity OneLogin.

💥 Le cœur du problème (en clair, pas comme les secrets)

Avant la version 2025.3.0, une requête GET Apps API v2 retournait… le client_secret OIDC d’une app. Oui, le secret qui doit rester confidentiel — celui qu’on cache dans un coffre et qu’on change avec une tronçonneuse en cas de doute — était renvoyé comme si c’était l’URL d’un logo. Concrètement : un acteur malveillant disposant d’identifiants API valides pouvait lister les applications et extraire leurs client secrets, puis les utiliser pour usurper des applications, générer des tokens, pivoter et faire des dégâts façon domino.

OneLogin a corrigé ça dans le release 2025.3.0 et affirme n’avoir aucune preuve d’exploitation in the wild. Magnifique timing : patch, communiqué, et tout le monde respire (relativement). Mais “aucune preuve” ne veut pas dire “impossible”. Les logs manquent parfois, les milieux underground ont le chic pour rester discrets, et les attaquants adorent les secrets opportuns.

🧨 Pourquoi c’est plus qu’un simple vilain bug

• Federation down the drain : quand tu voles un client_secret OIDC, tu peux prétendre être une appli de confiance — Single Sign-On, accès aux SaaS, automatisations, tout y passe. L’attaquant n’a plus besoin d’un mot de passe humain : il se fait passer pour l’application elle-même.
• Effet cascade : beaucoup d’intégrations cloud s’appuient sur les mêmes mécanismes OIDC/SAML — compromission d’un tenant = compromission potentielle d’un catalogue d’applis.
• Post-exploit friendly : l’info circulait déjà autour de OneLogin (AD Connector et autres joyeusetés révélées plus tôt cette année), donc ce n’est pas une première surprise. On a eu d’autres incidents où des clés ou signing keys ont fui et permis la forge de JWTs valides. Bref, l’écosystème a été secoué plusieurs fois cette année.

🛠️ Le plan de bataille (pratique, pas spirituel)

Si tu gères un tenant OneLogin (ou quelqu’un dans ton SI en gère un), fais ceci tout de suite — oui, maintenant, pas “après le café” :

1. Applique la mise à jour 2025.3.0 si ce n’est pas déjà fait. C’est la correction officielle qui empêche l’exposition systématique des client_secrets.
2. Rotation forcée de tous les client_secrets OIDC et des API keys ayant accès aux endpoints d’administration. Traite-les comme compromis tant que tu n’es pas sûr à 100 %.
3. Audit des logs OIDC/SAML : recherche d’anomalies — appels inhabituels au endpoint /api/2/apps, IP suspectes, tokens générés hors heures ouvrées, ou usages d’ID client insérés là où ils n’auraient pas dû l’être.
4. Bloque l’usage d’API keys à privilèges larges : principe du moindre privilège. Si un token/API key n’a pas besoin de lister toutes les apps, ne lui donne pas ce droit.
5. MFA everywhere : même si un attaquant a des secrets d’appli, limiter les possibilités d’actions humaines via MFA diminue l’échappée belle.
6. Plan de réponse : préparer playbooks — revocation d’API keys, rotation, notification des tiers, vérification des intégrations critiques.

⚖️ Conclusion — un peu de morale (et de colère contenue)

Il y a une ironie qui pique : on paie pour des solutions d’Identity qui sont censées être le rempart ultime, puis on découvre que la merde passe parfois par la porte d’administration. La leçon ? Ne jamais centraliser la confiance sans multiplier les garde-fous : logs, rotation, principe du moindre privilège, surveillance et, oui, un vrai playbook d’incident. OneLogin a patché — très bien — mais la responsabilité de la sécurité finale revient à toi, à moi, à nous qui assemblons ces services en production.

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com