Fortinet vient de publier un avis de sécurité confirmant l’exploitation active d’une vieille faille patchée… depuis 2020. En cause, une combinaison de réglages LDAP et une gestion imparfaite de la casse des noms d’utilisateur.
S’il fallait encore le démontrer, un patch publié ne règle rien tant qu’il n’est pas installé. Les mises à jour de sécurité ne sont pas juste là pour pimenter un changelog, mais bien pour corriger des failles concrètes et protéger des machines, des comptes, parfois des réseaux entiers. La preuve encore cette semaine avec Fortinet, qui confirme l’exploitation toujours active d’une vulnérabilité pourtant corrigée depuis cinq ans, utilisée pour contourner la double authentification sur certains pare-feu FortiGate mal configurés et décrocher un accès VPN à partir d’identifiants compromis. Si vous l’aviez jusqu’ici négligée, il va sérieusement falloir vous y attaquer.
Offre partenaire
Protection avancée des e-mails, des calendriers, des mots de passe, du réseau… de votre entreprise grâce à la suite d'applications professionnelles sécurisées.
Offre partenaire
Une incohérence entre comptes locaux et LDAP qui neutralise la 2FA
Pour comprendre de quoi il retourne, il faut revenir au fonctionnement de l’authentification sur FortiGate. Dans la configuration visée par la faille en question, estampillée CVE-2020-12812, le pare-feu gère l’authentification aux accès VPN SSL, voire à l’administration, à partir de comptes locaux qui déclenchent un second facteur via FortiToken, tout en déléguant la vérification du couple identifiant + mot de passe à un annuaire LDAP. Cet annuaire d’entreprise, souvent relié à Active Directory, centralise les comptes et leurs groupes. FortiGate s’appuie ensuite sur ces informations au moment d’appliquer ses règles d’accès, notamment celles qui autorisent certains groupes à initier une connexion VPN ou à accéder à l’interface d’administration.
Dans un scénario nominal, le parcours est assez linéaire. L’utilisateur ou l’utilisatrice saisit son identifiant, son mot de passe et se connecte au VPN. FortiGate commence par chercher un compte local correspondant, constate que ce compte est sécurisé par une authentification à deux facteurs et interroge l’annuaire LDAP pour vérifier le mot de passe. Si LDAP confirme que les identifiants sont valides, le pare-feu demande alors le code FortiToken associé au compte local avant d’autoriser l’accès. En clair, tant que tout est aligné entre le compte local et l’entrée LDAP, la double authentification fait ce qu’on attend d’elle.
Le problème naît d’un décalage entre la manière dont FortiGate et LDAP traitent la casse du nom d’utilisateur. Par défaut, le pare-feu exige une correspondance exacte, là où l’annuaire considère jsmith, JSmith ou JSMITH comme une seule et même personne. Si la casse du login change, FortiGate ne retrouve donc plus le compte local et, au lieu d’appliquer la règle 2FA associée, se met à examiner d’autres chemins d’authentification. S’il existe une règle fondée sur un groupe LDAP déclaré sur le pare-feu, et que ce groupe autorise la connexion, cette règle peut alors prendre le relais.
Par conséquent, dès lors que LDAP accepte le couple identifiant + mot de passe et que l’utilisateur ou l’utilisatrice appartient à un groupe autorisé à se connecter au VPN, la 2FA saute, puisque le pare-feu ne peut pas appliquer un second facteur à un login qu’il ne reconnaît pas de son côté, et l’authentification peut aboutir sans que le FortiToken ne soit jamais demandé.
Dans certains environnements, le risque ne concerne pas seulement les comptes VPN. Fortinet indique que le même problème peut aussi toucher des comptes d’administration, voire des comptes locaux désactivés, dès lors qu’une règle d’authentification basée sur des groupes LDAP est susceptible de s’appliquer. Dans ce cas, un identifiant compromis ne donne plus seulement accès à une session utilisateur, mais peut servir de point d’entrée vers la console du pare-feu, puis vers le reste du réseau interne.
Comment sécuriser les installations encore vulnérables
La bonne nouvelle, c’est que les moyens de prévention existent depuis 2020. La première étape consiste donc à vérifier que les pare-feu concernés tournent bien sur une version de FortiOS (le système d’exploitation qui équipe les boîtiers FortiGate) corrigée, à savoir 6.0.10, 6.2.4 ou 6.4.1 au minimum. Si ce n’est pas le cas, vous savez ce qu’il vous reste à faire.
Vient ensuite le réglage qui bloque le contournement. Fortinet a introduit une option de sensibilité à la casse des identifiants, username-case-sensitivity ou username-sensitivity selon les versions. Sur les comptes locaux qui s’authentifient via LDAP avec un FortiToken, cette option doit être désactivée afin que toutes les variantes de jsmith renvoient au même compte local et déclenchent systématiquement la 2FA, au lieu de confier l’authentification à un groupe LDAP plus permissif.
Il faut aussi revoir le rôle des groupes LDAP dans les règles d’accès du pare-feu. Les groupes secondaires, utilisés comme roue de secours lorsque l’authentification locale échoue, sont à examiner en priorité. S’ils n’ont plus d’utilité claire, ils doivent être supprimés. S’ils sont toujours nécessaires, il faut vérifier précisément quelles règles les invoquent et avec quels niveaux de droits, en particulier pour les accès VPN et l’administration, afin d’éviter qu’un simple identifiant validé par LDAP ouvre une session sans deuxième facteur.
Enfin, en cas d’exploitation avérée, Fortinet indique qu’il faut considérer la configuration comme compromise, passer les journaux d’accès au crible, surveiller les connexions inhabituelles et les variations de casse sur les logins, puis renouveler les identifiants sensibles, y compris ceux utilisés pour la liaison LDAP ou Active Directory.
Source : Fortinet
