CVE-2024-45326 : un compte sans droits peut modifier le manager de FortiDeceptor

CVE-2024-45326 est un défaut de contrôle d’accès dans FortiDeceptor. Fortinet décrit un attaquant authentifié sans privilèges pouvant effectuer des opérations sur l’appliance de management centrale au moyen de requêtes forgées. La faille est classée CWE-284 — Improper Access Control et référencée dans l’avis FG-IR-24-285.

Le test de Thomas SAUTIER du 27 juillet 2024 porte sur FortiDeceptor VM 6.0.0-build0044 (GA). Son résultat principal est une modification de paramètres du manager acceptée pour un compte dont le profil interdit les fonctions d’administration. L’accès à la console et les contrôles REST API sont détaillés séparément : ils ne donnent pas tous le même résultat.

1. Versions concernées, correction et dates

L’avis recommande 6.0.1 ou supérieure pour 6.0.0 et une migration vers une version corrigée pour les branches 5.x. Il indique que 6.1 n’est pas affectée. Le record CVE mentionne également 6.1.0 ou supérieure dans les solutions. Choisissez une version prise en charge, compatible avec votre modèle et vos intégrations, en suivant le chemin de mise à jour de l’éditeur.

Le tableau reprend le périmètre de l’avis PSIRT : toutes les versions des branches 5.0, 5.1, 5.2 et 5.3. Les champs structurés du record CVE donnent des plages plus courtes ; elles ne doivent pas servir à déclarer un correctif 5.x sûr. Aucun correctif dans ces branches n’est annoncé dans l’avis.

Les branches anciennes listées comme non affectées le sont pour cette faille précise. Cela ne constitue pas une recommandation de revenir vers ces versions ni une indication de leur statut de support.

• 27 juillet 2024 : date du test, corroborée par l’horloge système de l’appliance.
• 27 août 2024 : réservation de l’identifiant CVE.
• 14 janvier 2025 : publication du record CVE.
• 4 février 2026 : dernière mise à jour du bloc CNA Fortinet consulté.
• 12 octobre 2026 : consultation des sources pour cet article.

La date de réservation de la CVE n’est pas celle du signalement. Les échanges avec le PSIRT permettent de compléter la chronologie :

• 27 juillet 2024 : accusé de réception automatique du signalement, le jour du test.
• 29 juillet : ouverture de l’investigation annoncée par le PSIRT.
• 31 juillet : reproduction confirmée pour les pages de manager et de tunnels ; clarification sur les commandes CLI et le jeton API.
• 11 septembre : attribution de CVE-2024-45326 et annonce des corrections en 6.0.1 et 6.1.0.
• 14 janvier 2025 : le PSIRT transmet l’avis public FG-IR-24-285.

2. Configuration du test : un compte local sans droits

Avec le compte admin, le profil none_access_profile est créé sans aucune permission dans Menu Access ni CLI Commands. Le compte local none_access_user est ensuite créé avec ce profil comme Admin Profile. Le nom du profil n’est pas la preuve de sa restriction : ce sont ses valeurs qui comptent.

Toutes les rubriques de Menu Access sont réglées sur None : Dashboard, Deception, Incident, Fabric, Network, System, Log et REST API. Les permissions détaillées affichées sont également sur None. Dans CLI Commands, les catégories Configuration, System, Utilities et Diagnostics sont sur None.

Le champ Trusted Host affiché ne limite pas les adresses sources. Cela ne dispense pas de se connecter et ne permet pas de conclure que l’interface est exposée sur Internet.

L’administrateur se déconnecte, puis none_access_user se connecte dans le même navigateur. L’interface est alors presque vide : les fonctions du menu ne sont pas proposées. L’identité du compte restreint reste affichée pendant la suite du test, sans modification du profil ni nouvelle authentification avec admin.

L’appliance est en mode Standalone, avec une licence valide et aucun leurre VM actif affiché sur le dashboard. Le test ne montre donc pas de modification propagée à des leurres en production ni de connexion à un manager distant.

3. Commandes accessibles : la clarification du PSIRT

Depuis l’en-tête, le compte restreint ouvre Web CLI Terminal. Cette observation ne suffit pas à classer l’accès comme une vulnérabilité : le PSIRT précise que certaines commandes restent volontairement disponibles à tout administrateur authentifié, même avec un profil sur None. La fenêtre indique :

Connected to Web CLI Console.

Les commandes show, ?, hardware-info et status sont effectivement exécutées. Il s’agit de la CLI du produit, pas d’un shell Bash. Aucun shell Linux ni accès root n’est démontré.

3.1. L’aide obtenue avec ?

?

FortiDeceptor Console
General:
    help           Display this text.
    exit           Exit from the CLI.
    passwd         Change the password of the current user.
Configuration:
    show           Show bootstrap configuration.
System:
    status         Display some status information.
Utilities:
    ping           Test network connectivity to another network host.
Diagnostics:
    hardware-info  Display general hardware status information.

L’aide annonce aussi passwd, ping et exit. Leur présence dans cette liste ne prouve pas leur exécution : le test ne les utilise pas. Il ne tente pas de redémarrage.

3.2. show : lecture de paramètres de démarrage

show

Configured parameters:
    Port 1 IPv4 IP: 192.0.2.20/24
    Appliance Tag: None
    TLS version for HTTPS service:
        All TLS versions are allowed for HTTPS service

L’adresse 192.0.2.20 remplace celle du laboratoire. L’extrait conserve les indications sur le tag de l’appliance et le réglage TLS. Les autres interfaces et paramètres réseau sont omis. Le message sur TLS décrit le réglage affiché ; ce test ne vérifie pas les versions réellement négociables par le service HTTPS.

3.3. hardware-info et status : informations système

hardware-info

La réponse fournit des informations de processeur, de mémoire, de disques et de RAID, ainsi que l’heure locale et UTC. Ces informations sont retournées par une commande de FortiDeceptor ; elles ne prouvent pas une exécution directe de commandes du système d’exploitation.

status

System:
    Version: v6.0.0-build0044 (GA)
    FDC-VM license: Valid
    Image status check: OK

Le numéro de série et l’identifiant de VM ne sont pas reproduits. La version confirme 6.0.0-build0044 (GA).

3.4. Ouverture de la console dans une page séparée

L’URL forgée /cli_console/ donne également accès à la console avec le compte restreint. Elle se connecte et affiche la même liste limitée de commandes. Cette ouverture n’est pas suivie d’un élargissement des droits démontré.

Dans sa réponse du 31 juillet 2024, le PSIRT considère les commandes encore accessibles comme un comportement prévu et indique que les restrictions des commandes contrôlées sont appliquées. Il donne l’exemple de disk-info, refusée lorsque Diagnostics → Disk Info est sur None, avec le message The user does not have privilege to execute this command. Ce contrôle est celui du PSIRT, pas une commande exécutée dans la démonstration décrite ici.

La faille confirmée porte sur les fonctions de configuration, pas sur une élévation de droits CLI démontrée. Il ne faut pas reprendre le scénario de CVE-2024-45328 sur FortiSandbox : la reconnexion suivie d’un redémarrage appartient à cet autre test.

4. Une URL directe permet de modifier les paramètres du manager

Avec la session de none_access_user, la route /system/config/manager est saisie directement dans la barre d’adresse. Cette URL forgée ouvre Appliance Manager Settings, malgré la permission System sur None. Elle permet de modifier les champs Type, IP/Domain, Port et Auth Key.

Le formulaire propose les types Manager On Premise et DaaS Cloud, puis les champs IP/Domain, Port et Auth Key. Dans la vue DaaS Cloud, le champ Encryption Method affiche plain text. La seule présence de ce libellé ne prouve pas une transmission réseau en clair : aucun échange réseau n’est analysé ici.

Le test saisit des valeurs de laboratoire, notamment a.b.c pour IP/Domain et 1 pour le port, avec une valeur de test dans le champ d’authentification. Après le clic sur Save, la page affiche :

The Manager Settings was updated successfully.

La démonstration ne se limite donc pas à l’affichage d’une page interdite : le formulaire accepte un enregistrement. Le compte ne devrait pas pouvoir modifier ces paramètres, quelle que soit l’adresse choisie.

La suite affiche le mode DaaS Cloud avec daas.forticloud.com et le port 8443, puis le mode Manager On Premise avec un domaine vide et le port 9443. Le message de réussite apparaît pendant cette séquence. Ces valeurs sont celles des vues successives du formulaire ; elles ne prouvent ni la création d’un lien avec FortiCloud ni une prise en charge par un autre manager.

Le PSIRT confirme aussi un défaut d’autorisation sur /system/config/tunnels. Cette seconde page est mentionnée dans son retour du 31 juillet ; elle n’est pas testée dans la démonstration détaillée ici.

Nous n’avons pas d’export indépendant de la configuration ni de vérification après redémarrage. Le résultat établi est l’acceptation de la mise à jour par l’interface. Aucun endpoint d’écriture brut, corps de requête ou statut HTTP n’est fourni : il serait trompeur d’en inventer un à partir du seul formulaire.

Pourquoi masquer le menu ne suffit pas

Le menu peut aider un utilisateur à voir ce qu’il est autorisé à faire. Il ne doit pas constituer le contrôle de sécurité. Le serveur doit vérifier les droits du compte pour afficher la page et, surtout, pour accepter chaque modification. Une adresse saisie manuellement doit être soumise aux mêmes règles qu’un lien du menu.

Ce comportement correspond au défaut de contrôle d’accès décrit par Fortinet. Le test ne révèle pas quelle vérification manque dans le code du produit, ni si toutes les routes de management présentent le même défaut.

5. REST API : une réponse accessible, une demande refusée

Deux routes sont consultées directement dans le navigateur, toujours dans la session du compte restreint. Elles retournent des résultats différents.

5.1. État d’activation de l’API

L’URL forgée /apiv4/main/user/api_enabled retourne :

{"status":{"return_code":1},"result":true}

Le corps indique result: true et return_code: 1. Cette réponse ne prouve pas que toutes les opérations de l’API sont autorisées.

5.2. La route token refuse la demande

La route /apiv4/main/user/token retourne :

{"status":{"return_code":0,"error":[{"code":"VE","message":"Permission denied."}]}}

Le message est explicitement Permission denied., avec le code applicatif VE et return_code: 0. Aucun statut HTTP n’est relevé : ce corps JSON ne permet pas d’affirmer une réponse HTTP 403 ou 200.

5.3. Panneau REST API Configuration du compte courant

Depuis la GUI, le compte restreint peut ouvrir le menu REST API Configuration, activer ou désactiver Enable REST API access et générer une nouvelle API Key. Thomas SAUTIER confirme ces possibilités dans son récapitulatif du test. L’utilisation de l’interrupteur produit les notifications suivantes :

REST API has been disabled.
REST API has been enabled.

Le champ API Key est visible et son bouton de copie est utilisé. L’interface confirme :

API key has been copied to clipboard.

La génération d’une nouvelle clé et la copie de la clé sont deux actions distinctes. La première est confirmée par Thomas SAUTIER ; le message ci-dessus correspond à la seconde. Aucune valeur de clé n’est reproduite dans cet article. Le panneau précise que le porteur dispose des privilèges assignés à ce compte : cette indication ne signifie pas que la clé donne tous les droits sur l’appliance.

Aucune requête utilisant la clé copiée n’est effectuée ensuite, et la route token n’est pas retestée après l’activation. Cette séquence ne démontre donc pas un accès API administrateur. Le PSIRT précise, le 31 juillet 2024, que le jeton peut être généré mais ne permet pas les actions interdites au compte ; son essai d’une opération API renvoie Permission denied. La génération d’une clé n’est donc pas une preuve de contournement des permissions API. Pour la recette, vérifiez surtout les autorisations de chaque opération utilisant cette clé.

6. Ce que le test démontre, et ce qu’il ne démontre pas

Le test confirme un défaut d’autorisation avec une opération de configuration acceptée, reproduit par le PSIRT pour les pages de manager et de tunnels. Les lectures CLI et la génération d’une clé restent des observations distinctes ; elles ne sont pas présentées comme des vulnérabilités supplémentaires confirmées. Il ne démontre pas que toutes les fonctions de FortiDeceptor sont accessibles, que les autres comptes peuvent être modifiés ou que des leurres peuvent être détournés. Les versions corrigées n’ont pas été testées dans cette démonstration.

7. Score CVSS et conséquences

Fortinet publie un score de 3,9 — Low avec le vecteur CVSS 3.1 suivant :

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N/E:P/RL:X/RC:R

AV:N décrit un accès réseau, AC:L une complexité faible, PR:L la nécessité de privilèges préalables limités et UI:N l’absence d’action requise d’une autre personne. Le compte doit donc être authentifié, même si ses permissions fonctionnelles sont toutes sur None. S:U signifie que l’impact reste sous la même autorité de sécurité au sens de CVSS.

Les impacts déclarés sont C:N/I:L/A:N : aucun impact de confidentialité, impact limité d’intégrité et aucun impact de disponibilité retenus dans cette cotation. La modification des paramètres du manager illustre l’atteinte à l’intégrité. Les lectures d’informations système sont décrites comme des résultats du test ; elles ne justifient pas à elles seules de modifier le score officiel.

Le record place 3,9 dans le champ baseScore, mais les seules métriques de base du vecteur donnent 4,3. Les facteurs temporels E:P (0,94), RL:X (1) et RC:R (0,96), avec l’arrondi au dixième supérieur, donnent 3,9. L’avis PSIRT affiche lui aussi un score de 3,9 et une sévérité Low ; cet article conserve ce score publié, en précisant la différence de calcul dans le record CVE. E:P signifie preuve de concept, pas exploitation active ; RL:X ne signifie pas qu’aucun correctif n’existe.

En exploitation, l’enjeu est concret : une personne qui possède un compte restreint ne doit pas pouvoir changer la configuration de management. Un changement non prévu peut nécessiter de rétablir les paramètres, vérifier les connexions et contrôler les journaux. Le test ne mesure pas d’interruption de service et ne montre pas de prise de contrôle d’un parc de leurres.

8. Corriger la faille et protéger l’administration

8.1. Installer une version corrigée

Inventoriez les appliances, modèles, versions complètes et builds, y compris les instances de secours et de laboratoire. Pour les branches concernées, préparez la migration vers 6.0.1 ou supérieure ou 6.1.0 ou supérieure, selon les recommandations actuelles de Fortinet.

Avant la mise à jour, conservez une sauvegarde protégée, vérifiez le chemin de migration et les dépendances des managers, leurres, collecteurs et intégrations réellement présents. Définissez une fenêtre de maintenance et une méthode de retour arrière compatible avec le produit. Après l’opération, vérifiez la version installée et les services attendus.

8.2. Réduire les accès en attendant

Limitez l’interface d’administration à un réseau dédié et aux sources nécessaires, avec filtrage, VPN ou bastion selon votre installation. Revoyez les comptes nominatifs, leurs propriétaires et leurs usages ; désactivez ceux qui ne servent plus. Utilisez les restrictions de sources et l’authentification renforcée proposées par votre configuration.

Ces mesures réduisent l’exposition, mais ne corrigent pas le défaut. Un compte sur None atteint déjà certaines fonctions dans ce test. Masquer le menu ou restreindre davantage le même profil ne remplace donc pas la mise à jour.

La fiche CVE fournit des versions corrigées ; elle ne fournit pas de contournement validé. Les mesures de filtrage ci-dessus sont des recommandations d’exploitation, pas une solution provisoire certifiée par l’éditeur pour cette faille.

9. Vérifier les droits après la mise à jour

Les contrôles suivants sont proposés pour un laboratoire autorisé. Ils ne sont pas des résultats déjà obtenus sur 6.0.1 ou 6.1.0. Fixez d’abord le périmètre, les modifications permises, la méthode de restauration et les conditions d’arrêt.

1. Établir une référence : relever le firmware, exporter les profils et noter les paramètres du manager avec un compte autorisé.
2. Isoler les comptes : utiliser des profils de navigateur séparés pour l’administrateur et le compte restreint. Vérifier l’identité active avant chaque essai.
3. Tester les accès directs : contrôler les routes de console et de manager avec le profil sur None. L’absence d’un menu ne suffit pas ; le serveur doit refuser la fonction interdite.
4. Tester le refus d’écriture : uniquement sur un laboratoire ou une opération autorisée, vérifier qu’un enregistrement interdit est refusé et que la configuration effective reste identique. Restaurer toute valeur de test.
5. Contrôler la console : vérifier les commandes selon le profil, à l’ouverture, après fermeture et après reconnexion. Une liste d’aide seule ne suffit pas à valider les restrictions.
6. Vérifier l’API séparément : distinguer lecture d’état, accès au jeton, activation/désactivation, génération et copie de la clé personnelle, et autorisation de chaque opération. Si un essai avec une clé est autorisé, choisir une opération non destructive et vérifier le refus attendu.
7. Conserver les preuves : noter compte, profil, version, horaire, réponse applicative, statut HTTP lorsqu’il est capturé et résultat sur la configuration réelle. Protéger les clés et valeurs d’authentification.
8. Recetter l’exploitation : vérifier les connexions de management, la remontée des événements, les intégrations et les leurres présents sur votre installation.

Un correctif installé et une recette fonctionnelle répondent à deux questions différentes : la version contient-elle la correction annoncée, et votre installation fonctionne-t-elle avec les droits attendus ? Il faut vérifier les deux.

10. Rechercher une modification non autorisée

Aucun journal ni échange HTTP complet n’est fourni pour établir une signature de détection. Une investigation peut rapprocher les authentifications des comptes restreints des changements de configuration, notamment :

• Les paramètres du manager : type, domaine ou adresse, port et valeurs d’authentification.
• Les accès aux pages de console et de configuration, lorsque les journaux disponibles les enregistrent.
• Les changements d’activation API et les opérations utilisant des clés, s’ils sont tracés.
• Les changements de profils et les opérations de management réalisées en dehors des maintenances prévues.

Comparez la configuration à une référence fiable, puis recherchez le compte, l’origine et l’heure des changements. Un accès à une route n’est pas à lui seul la preuve d’une modification réussie. De même, la copie de sa propre clé ne prouve pas un usage malveillant.

En cas d’écart, préservez les traces disponibles, limitez les accès concernés et vérifiez les comptes et paramètres. Révoquez ou remplacez les secrets effectivement exposés selon les procédures du produit. Installer le correctif ne restaure pas automatiquement une configuration déjà altérée.

L’avis PSIRT indique Known Exploited: No. Ce statut décrit les informations de l’éditeur dans l’avis consulté ; il ne garantit pas une absence d’exploitation ultérieure.

L’évaluation CISA datée du 14 janvier 2025 indique Exploitation: none et un impact technique partiel. C’est une appréciation datée, pas la preuve d’une absence d’exploitation depuis.

11. Questions fréquentes

Sans droits signifie-t-il sans compte ?

Non. Le compte est authentifié ; ses autorisations fonctionnelles sont réglées sur None. Aucun contournement de l’authentification n’est montré.

Le manager distant a-t-il été compromis ?

Non démontré. L’enregistrement de paramètres est accepté sur l’appliance testée. Aucun rattachement à un manager contrôlé par un tiers ni effet sur des leurres n’est vérifié.

La clé API donne-t-elle des droits Super Admin ?

Le test ne le montre pas. Il s’agit de la clé du compte courant, et aucune opération utilisant cette clé n’est exécutée ensuite. La route token a par ailleurs répondu Permission denied. Le PSIRT a également confirmé le refus d’une opération effectuée avec un jeton généré pour ce compte.

Faut-il attendre un impact plus spectaculaire pour corriger ?

Non. Une modification de configuration par un compte qui n’en a pas le droit suffit à justifier la correction. Le score faible ne rend pas ce comportement acceptable.

Est-ce la même faille que celle de FortiSandbox ?

Non. Cet article concerne FortiDeceptor, CVE-2024-45326 et FG-IR-24-285. Le scénario FortiSandbox de reconnexion et de redémarrage concerne CVE-2024-45328 / FG-IR-24-261.

12. Sources et périmètre de l’analyse

1. Fortinet PSIRT — FG-IR-24-285, avis de référence consulté le 12 octobre 2026, également référencé sous fortiguard.fortinet.com.
2. CVE-2024-45326 et record JSON CVEProject, consultés le 12 octobre 2026. Le bloc CNA est fourni par Fortinet.
3. Test de Thomas SAUTIER du 27 juillet 2024 sur FortiDeceptor VM 6.0.0-build0044 (GA), pour les actions et réponses décrites ici. Son récapitulatif du 12 octobre 2026 précise la création du profil et du compte, les accès par URL forgée, les champs du manager modifiables et la génération d’une nouvelle clé API.
4. MITRE — CWE-284, Improper Access Control.
5. FIRST — spécification CVSS 3.1, pour le calcul et la lecture du vecteur.

Le tableau des versions, les solutions, le score, la date de publication et le statut d’exploitation proviennent de l’avis PSIRT de Fortinet, vérifié avec le record CVE officiel. L’avis remercie Thomas SAUTIER pour son signalement dans le cadre de la divulgation responsable. Les réponses de console et de formulaire viennent de son test. Les confirmations et clarifications du PSIRT de juillet 2024 à janvier 2025 distinguent les pages vulnérables, les commandes prévues et les permissions API maintenues. Les recommandations de protection, d’investigation et de recette sont proposées à partir de ces éléments.

Aucun nouveau test sur appliance ni sur firmware corrigé n’a été réalisé pour cet article. Les extraits réseau sont limités aux corps JSON affichés dans le navigateur ; ils ne constituent pas une capture complète des requêtes et réponses. Les informations privées de l’appliance et les clés sont exclues.