FreeIPA : un client LDAP anonyme peut obtenir les droits administrateur

12 septembre 2026 à 12:00|Auteur: Équipe éditoriale de QUASA|5 min de lecture| 4

Le 7 septembre 2026, la fiche CVE de Red Hat a été actualisée pour qualifier CVE-2026-76578 de faille critique, avec un score CVSS 3.1 provisoire de 9,8. Un client LDAP distant sans identifiants peut obtenir une véritable appartenance au groupe des administrateurs de FreeIPA et exécuter des opérations privilégiées.

Une installation doit être considérée comme prioritaire si son service LDAP est joignable depuis Internet ou depuis un segment non fiable et si les paquets correctifs ne sont pas déployés. La réponse immédiate consiste à restreindre cette joignabilité, à envisager la désactivation des binds anonymes après vérification des dépendances, puis à appliquer les mises à jour de FreeIPA et de 389 Directory Server fournies par la distribution.

La chaîne combine deux défauts de contrôle d’accès

Une session LDAP anonyme aboutit à une identité Kerberos dotée de privilèges administrateur dans FreeIPA

La vulnérabilité ne repose pas sur le vol d’un mot de passe existant. Elle associe une règle de contrôle d’accès de FreeIPA insuffisamment restrictive à un défaut d’évaluation dans 389 Directory Server, le service d’annuaire sous-jacent.

La règle concernée permet l’auto-gestion de jetons à usage unique sans imposer correctement une identité authentifiée ni limiter suffisamment les informations ajoutées à l’entrée. Dans le même temps, l’évaluateur SELFDN de l’annuaire peut considérer le nom vide d’une session anonyme comme correspondant à des champs de propriétaire eux-mêmes vides.

Cette combinaison ouvre la voie à la création d’une identité Kerberos contrôlée par l’attaquant, puis à l’acquisition de privilèges administratifs. Cette description expose le mécanisme de sécurité défaillant sans détailler les requêtes, attributs ou commandes nécessaires à son exploitation.

Une analyse indépendante publiée le 8 septembre rapporte deux reproductions sur une installation FreeIPA 4.13.1 standard et non modifiée, dont la plus récente depuis un client sans accès préalable. Les vérifications ont porté sur l’appartenance administrative ainsi que sur de véritables lectures, écritures et suppressions réservées à ce rôle ; aucune exploitation dans une attaque réelle n’était documentée dans les éléments publics examinés.

L’exposition se décide d’abord au niveau du réseau

Contrôle de la joignabilité LDAP de serveurs et réplicas FreeIPA depuis plusieurs zones réseau

Le premier critère est la possibilité pour un système non fiable d’atteindre LDAP sur un serveur ou un réplica FreeIPA. L’inventaire doit couvrir toutes les interfaces, adresses publiées et routes traversant pare-feu, VPN, répartiteurs ou passerelles. Un test négatif depuis un seul poste ne permet pas d’écarter une autre voie d’accès.

Internet n’est pas le seul périmètre à considérer. Un réseau invité, un segment utilisateur peu maîtrisé ou une zone contenant des postes susceptibles d’être compromis peuvent également fournir la joignabilité nécessaire. À l’inverse, un service limité à des hôtes strictement identifiés réduit immédiatement la surface exposée, sans corriger le logiciel.

Le deuxième critère est l’acceptation des binds anonymes. Leur désactivation bloque le chemin décrit, mais certaines applications peuvent encore utiliser des recherches anonymes pour découvrir la base de l’annuaire, des comptes ou des groupes. Ce changement temporaire doit donc être précédé d’un inventaire des dépendances et suivi d’une vérification fonctionnelle.

Le chiffrement du transport ne résout pas le problème d’autorisation : une connexion LDAP protégée peut toujours être anonyme. De même, une segmentation imparfaite ne suffit pas si un poste compromis situé dans la zone autorisée conserve un accès au service.

La réduction du risque ne remplace pas les paquets corrigés

FreeIPA 4.13.4 refuse une modification LDAP anonyme après le durcissement des contrôles d’accès

Les règles de pare-feu et la segmentation constituent des mesures compensatoires, pas une correction permanente. Elles doivent limiter LDAP aux seuls systèmes qui en ont réellement besoin, sur chaque serveur et chaque réplica, tout en tenant compte des flux d’administration, d’authentification et de réplication légitimes.

La version FreeIPA 4.13.4 durcit les règles d’auto-gestion, exige une identité authentifiée pour les opérations concernées et refuse les modifications anonymes. La chaîne impliquant aussi 389 Directory Server, les environnements administrés au moyen des paquets d’une distribution doivent suivre les avis de cette distribution pour les deux composants.

Le seul numéro de version amont ne permet pas toujours de conclure. Un éditeur peut rétroporter un correctif dans une branche plus ancienne ; l’état réel doit être établi à partir de la version complète du paquet, de son dépôt d’origine et de l’avis correspondant au système installé.

Recenser tous les serveurs et réplicas FreeIPA ainsi que les zones capables de joindre leur service LDAP.
Restreindre l’accès aux hôtes de confiance et évaluer les usages qui dépendent encore des binds anonymes.
Comparer les paquets FreeIPA et 389-ds installés avec les avis de sécurité de la distribution, puis appliquer les mises à jour disponibles.
Après correction, vérifier chaque nœud, confirmer les règles réseau et contrôler que les modifications anonymes sont refusées sans perturber les usages autorisés.

Une mise à jour n’exclut pas une compromission antérieure

Installer les correctifs ferme le chemin vulnérable, mais ne démontre pas qu’il n’a jamais été utilisé. Les publications disponibles ne fournissent pas d’indicateur de compromission officiel, de règle de détection exhaustive ni de garantie qu’une identité créée auparavant serait supprimée automatiquement.

La recherche doit donc se concentrer sur les créations ou modifications d’identités Kerberos, de jetons OTP et de membres du groupe des administrateurs qui ne correspondent à aucun changement autorisé. Les opérations LDAP privilégiées associées doivent être rapprochées des journaux d’authentification, d’administration et de réplication, en conservant les données avant leur rotation.

Une anomalie isolée ne prouve pas une intrusion : elle doit être corrélée avec les comptes, les horaires, les adresses réseau et les opérations légitimes connues. En cas d’indice cohérent, l’analyse de compromission et la rotation des secrets concernés relèvent d’une réponse à incident, distincte de la simple mise à jour.

À ce stade, la compromission administrative distante sans identifiants et la correction amont sont documentées. Le numéro exact des paquets corrigés reste propre à chaque distribution et à chaque branche prise en charge ; les restrictions réseau doivent donc rester en place jusqu’à la mise à jour et à la vérification de tous les nœuds exposés.