CVE-2024-45328 : élévation de privilèges dans la console GUI de FortiSandbox

CVE-2024-45328 permet à un administrateur restreint d’exécuter des commandes que son profil devrait lui interdire. Selon Fortinet, la faille se trouve dans la console CLI accessible depuis l’interface graphique de FortiSandbox. Elle touche les versions 4.4.0 à 4.4.6 incluses. Fortinet indique les corrections dans 4.4.7 ou supérieure et 5.0.0 ou supérieure.

Le test du 29 juin 2024 a été réalisé sur FortiSandbox VM 4.4.6-build0397 (GA). Le compte utilisé finit par exécuter reboot, alors que la console lui refusait cette commande au départ. L’appliance cesse de répondre au ping, puis revient. Cet article présente les étapes du test, les commandes utilisées et leurs résultats, avec deux schémas.

1. Identification, versions et chronologie

L’identifiant a été réservé le 27 août 2024, puis la fiche CVE publiée le 11 mars 2025. Le test de Thomas SAUTIER est antérieur : il a été réalisé le 29 juin 2024. Nous n’avons pas ici les dates du signalement au PSIRT, de son accusé de réception ou de la sortie initiale des correctifs.

La fiche consultée le 12 octobre 2026 indique une mise à jour au 26 février 2026. Les données fournies par Fortinet, dans le bloc CNA, restent datées du 11 mars 2025. La date de mise à jour de la fiche inclut donc les enrichissements d’autres organismes ; elle ne signale pas forcément un changement de l’avis de Fortinet.

Les versions 4.4.7 et 5.0.0 sont les seuils de correction indiqués pour cette CVE. Pour une mise à jour aujourd’hui, choisissez une version encore prise en charge et vérifiez sa compatibilité avec votre modèle et vos intégrations. Ce test ne permet pas de conclure que d’autres branches sont affectées.

2. Comment les droits sont contournés

L’interface graphique de FortiSandbox peut ouvrir une console CLI dans le navigateur. Le profil du compte détermine quelles commandes il peut exécuter. Ces restrictions doivent s’appliquer aussi bien à la première connexion qu’aux reconnexions de la console.

Le test montre deux contournements successifs : l’URL saisie directement ouvre une console que le profil interdit, puis le bouton Connect permet de retrouver cette console avec davantage de commandes. Le timeout GUI réglé sur une minute ne ferme pas la session CLI.

Fortinet classe cette faille en CWE-863, Incorrect Authorization : le produit vérifie mal les droits. Dans le test, reboot est d’abord refusé, puis accepté après la reconnexion. Le compte affiché reste le même.

Un menu masqué n’empêche pas forcément d’ouvrir sa page directement. FortiSandbox doit aussi vérifier les droits à l’ouverture de la console et à l’exécution des commandes. Le test montre que le refus ne tient pas après la reconnexion ; il ne donne pas accès au code du produit pour en expliquer la cause exacte.

3. Le laboratoire et les permissions exactes

Deux sessions de navigateur distinctes

Deux fenêtres sont utilisées : admin avec le profil Super Admin dans la première, et user_ro dans une seconde fenêtre en navigation privée. Cette analyse porte sur les droits appliqués par la console ; elle ne détaille pas les échanges de cookies ou de jetons.

Un compte local user_ro est créé et associé au profil no_access_profile. Les autorisations de Menu Access sont toutes sur None, et aucun accès API/CLI n’est accordé. Seul Data Access reste sur Full Access. Les noms du compte et du profil sont choisis pour le test, pas des rôles prédéfinis.

Malgré son nom, no_access_profile n’interdit donc pas tout : Data Access reste sur Full Access. En revanche, le profil interdit bien la console GUI et les commandes CLI. C’est le contournement de ces restrictions que montre le test.

L’Idle timeout est volontairement abaissé à une minute. Une seconde fenêtre est ensuite ouverte en navigation privée pour se connecter avec user_ro. Le délai d’une minute ne ferme pas la session CLI Console. Le message de déconnexion qui apparaît plus tard est un événement séparé ; sa cause interne n’est pas identifiée par ce test.

État de l’appliance et limites du laboratoire

status affiche v4.4.6-build0397 (GA), une licence VM invalide, des VM Windows non initialisées et leur accès Internet désactivé. Une notification signale que les moteurs Tracer et Rating ne sont pas installés. Le test porte sur l’administration de cette VM ; il ne montre pas d’analyse de fichier malveillant.

Le navigateur accède à une adresse privée en HTTPS et affiche « Non sécurisé ». La cause de cet avertissement n’a pas été établie et aucun lien avec la faille n’a été démontré. Dans les extraits, les adresses du laboratoire sont remplacées par des adresses de documentation. Les identifiants d’infrastructure inutiles à l’explication sont retirés.

4. Déroulé de la démonstration

Voici les étapes de la démonstration, dans leur ordre d’exécution.

La session admin à droite revient au formulaire de connexion, mais la session CLI de user_ro reste ouverte au-delà de la minute. Le message de déconnexion apparaît ensuite dans la console. Il ne faut donc pas présenter ce message comme l’effet du timeout GUI, ni l’expiration de la session Super Admin comme une condition de la faille.

5. Commandes, messages et résultats retranscrits

Les extraits suivants reprennent les commandes utilisées et les messages retournés par la console. L’alignement des colonnes est adapté à la lecture. Les sorties marquées « extrait » ne reprennent que les lignes utiles.

5.1. Accès à la console malgré les restrictions GUI

Après l’authentification du compte user_ro, l’interface affiche cette notification :

You do not have any gui permission, please contact system admin.

Dans la fenêtre privée connectée avec user_ro, l’URL est forgée en saisissant directement /ng/system/console-from-menu. Le panneau CLI Console s’ouvre alors que le profil interdit son accès, avec ce message :

Connected to Web CLI Console.

Il s’agit de la page Web de la console. L’URL de son canal WebSocket et les jetons utilisés par le service ne sont pas documentés ici.

5.2. Une première aide limitée

La commande d’aide utilisée est ?. Voici la liste courte affichée initialement :

FortiSandbox Console
General:
    ?       Synonym for 'help'.
    exit    Exit from the CLI.
    help    Display this text.
Configuration:
    show    Show bootstrap configuration.
Diagnostics:
HA-Cluster:
Scan:
System:
    status  Display some status information.
VM:
Utilities:

status et show fonctionnent dans cette première console. Ils affichent la version et la configuration de démarrage. Ils figurent déjà dans l’aide limitée, avant le contournement.

status

System:
    Version:              v4.4.6-build0397 (GA)
    FSA-VM License:        Invalid
Windows VM:               Not-Initialized
    VM Internet Access:   Off

show

Configured parameters:
    port1  IPv4 IP: 192.0.2.10/24
           MTU: 1500
    Administration interface(s): port1 port2
    API interface(s):

show affiche aussi les autres interfaces, leurs adresses IP et MAC, ainsi que la passerelle. Ces valeurs ne sont pas nécessaires pour comprendre la faille. Le texte « just wait time out... » saisi ensuite est une note du démonstrateur, pas une commande FortiSandbox.

5.3. Le refus initial de reboot

Une tentative de reboot retourne explicitement :

The user does not have privilege to execute this command.

La restriction ne se limite donc pas à masquer la commande dans l’aide : la console refuse de l’exécuter. Un second refus est visible juste avant la reconnexion.

5.4. Session conservée, puis reconnexion avec Connect

Le délai d’inactivité GUI est réglé sur une minute, mais la session CLI est conservée. Les commandes ?, status et show restent accessibles ; reboot est encore refusé.

Plus tard, le panneau affiche You have disconnected from the CLI Console. et le bouton Connect. Un clic sur ce bouton suffit à reconnecter la console : aucune nouvelle authentification n’est demandée à cet instant. Une ligne Connected to Web CLI Console. apparaît. Les deux messages successifs sont :

You have disconnected from the CLI Console.
Connected to Web CLI Console.

L’en-tête affiche toujours user_ro. On ne voit ni connexion avec admin, ni changement du profil. Pourtant, une nouvelle demande d’aide affiche beaucoup plus de commandes.

5.5. Confirmation et effet opérationnel de reboot

Une invite Windows est ouverte pour suivre la joignabilité. La commande observée, avec remplacement de l’adresse du laboratoire par une adresse de documentation, est :

ping 192.0.2.10 -t

L’option -t de Windows maintient le ping en continu. Elle n’a pas la même signification dans toutes les implémentations Unix. La console FortiSandbox reçoit à nouveau reboot. Cette fois, elle demande :

Do you want to continue? (y/n)

La réponse y est visible après la question. Elle est suivie de la perte de la connexion CLI et d’une interruption des réponses ICMP. La séquence utile des messages ping est reproduite ci-dessous, avec quelques lignes représentatives ; le nombre de lignes n’est pas une mesure de durée :

Réponse de 192.0.2.10 : octets=32 temps<1ms TTL=64
Réponse de 192.0.2.10 : octets=32 temps<1ms TTL=64
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Réponse de 192.0.2.10 : octets=32 temps<1ms TTL=64

reboot redémarre réellement l’appliance. Cette opération a été réalisée dans le laboratoire ; elle n’est pas une commande à lancer sur une production pour vérifier sa version. Toute reproduction nécessite une autorisation explicite préalable. Utilisez une VM de laboratoire sur laquelle l’interruption est autorisée.

5.6. Retour de l’appliance et de la restriction

Quand le ping répond de nouveau, le démonstrateur se reconnecte avec user_ro. Le message d’absence de permission GUI revient. status affiche toujours v4.4.6-build0397 (GA) et l’aide est de nouveau limitée. Aucun correctif n’a été installé pendant ce test.

6. Les commandes supplémentaires visibles après reconnexion

L’aide affiche désormais des commandes dans les rubriques Configuration, Diagnostics, HA-Cluster, Scan, System, VM et Utilities. Voici les noms relevés dans cette aide, regroupés par rubrique. Leur présence dans l’aide ne prouve pas qu’ils ont tous été exécutés.

Configuration : set, unset
Diagnostics : diagnose-clilog, diagnose-debug, diagnose-krnlog,
              diagnose-sys-perf, diagnose-sys-top, hardware-info,
              redis-info, tac-report, test-network
HA-Cluster : hc-primary, hc-settings, hc-status, hc-worker
Scan : ai-mode, anti-phishing, device-clean-pdf, filesize-limit,
       fortimail-expired, inline-block-timeout, pending-jobs,
       prescan-config, processing-jobs, sandboxing-adaptive,
       sandboxing-embeddedurl, sandboxing-parallel,
       sandboxing-pexbox, sandboxing-pipeline,
       sandboxing-prefilter, sandboxing-ratio,
       sandboxing-rse, url-recheck
System : backup-sysconf, cleandb, client-lenc, cm-status,
         config-reset, confirm-id, device-authorization,
         factory-reset, fsck-storage, fw-upgrade, iptables,
         log-dropped, log-purge, oftpd-con-mode, reboot,
         remote-auth-timeout, rename-admin, reset-sandbox-engine,
         reset-scan-profile, reset-widgets, resize-hd,
         restore-sysconf, sandbox-engines, set-cfg-backup-key,
         set-maintainer, set-tcp-timestamp-response, set-tlsver,
         shutdown, status, system-admin, upload-license,
         upload-settings, usg-license
VM : vm-customized, vm-internet, vm-license, vm-reset, vm-status
Utilities : ping, tcpdump, traceroute

Plusieurs de ces commandes peuvent arrêter l’appliance, modifier ses comptes ou effacer des données. Le tableau distingue ce que l’aide annonce de ce qui a réellement été testé.

L’aide plus complète signale que les commandes proposées ont changé. Pour reboot, on voit aussi l’acceptation de la commande et son effet sur l’appliance. Les autres commandes n’ont pas été testées.

7. Ce que le test montre

Les faits visibles

• Le compte restreint et son profil sont visibles dans l’interface d’administration.
• Toutes les autorisations de Menu Access sont sur None ; aucun accès API/CLI n’est accordé.
• L’URL forgée ouvre quand même la console, qui fournit d’abord une aide limitée.
• Le timeout GUI d’une minute, réglé pour le test, ne ferme pas la session CLI.
• La commande de redémarrage est refusée avant la reconnexion.
• Après déconnexion et reconnexion, l’aide s’élargit et cette commande obtient une confirmation.
• L’action confirmée est suivie d’une interruption de joignabilité, d’un retour de l’appliance et d’une nouvelle authentification.

Le problème au moment de la reconnexion

Après la reconnexion, la console autorise des commandes que le profil du compte interdit. La restriction fonctionnait à la première connexion, mais elle ne tient plus lorsque la console se reconnecte. FortiSandbox devrait vérifier le profil à chaque ouverture de console et garder les mêmes restrictions.

Ce résultat correspond au défaut d’autorisation décrit par Fortinet. Le test ne permet pas d’en dire davantage sur le code : le profil est-il oublié, une session mal réutilisée, ou des droits trop larges attribués par défaut ? Sans analyse du produit, ces explications restent des hypothèses.

Les limites du test

Le test ne montre ni accès sans compte, ni shell Linux root, ni exécution de code natif, ni changement permanent de profil, ni vol de données. La console FortiSandbox reste une CLI propre au produit. Nous n’avons pas non plus de tests montrant à quelle fréquence le défaut se reproduit sur chaque version affectée.

Un ping peut s’interrompre pour plusieurs raisons. Ici, il s’arrête juste après l’acceptation de reboot et la perte de la console, puis l’appliance revient. La séquence indique un redémarrage. Sans journaux de démarrage, on ne peut pas préciser les étapes internes ni mesurer exactement le temps de reprise du service.

8. Lecture du CVSS 3.1 : un score publié de 7,1

Le registre renseigné par Fortinet publie une sévérité élevée et un score de 7,1. Il fournit le vecteur suivant, qui comprend des métriques de base et temporelles :

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

La fiche contient une particularité : 7,1 est enregistré dans le champ baseScore. Pourtant, les métriques de base AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H donnent 7,8. En appliquant ensuite les facteurs temporels E:P (0,94), RL:X (1) et RC:R (0,96), puis l’arrondi au dixième supérieur, on obtient 7,1. Nous reprenons le score publié par Fortinet, avec cette précision sur son calcul.

AV:L est la valeur publiée par Fortinet. Elle n’impose pas d’être physiquement devant l’appliance : le test utilise son interface Web. Pour évaluer l’urgence de la mise à jour, regardez qui peut atteindre cette interface et quels comptes peuvent s’y connecter.

9. Conséquences pour une plateforme de sandboxing

Redémarrer FortiSandbox peut interrompre l’analyse des fichiers, l’accès aux résultats et les tâches en cours. Un compte censé être limité peut donc perturber le service utilisé par les équipements qui lui soumettent des fichiers.

La réaction de ces équipements dépend de leur configuration : mise en attente, nouvelle soumission, traitement asynchrone ou décision de laisser passer ou de bloquer lorsqu’aucun résultat n’arrive. Ce test ne montre pas leur comportement. Il faut le vérifier sur votre installation.

Le risque concerne notamment les comptes confiés à des opérateurs ou prestataires auxquels on veut donner un accès limité. Si la console ignore leurs restrictions après reconnexion, un compte valide suffit à atteindre une opération réservée à des administrateurs plus privilégiés.

Fortinet cote aussi les impacts sur la confidentialité et l’intégrité comme élevés. Le test ne les démontre pas : il montre un redémarrage. Les commandes de gestion des comptes, de configuration et de suppression visibles dans l’aide donnent des pistes de vérification, pas la preuve qu’elles fonctionnent toutes pour ce compte.

10. Corriger et réduire l’exposition

10.1. Inventorier précisément

Relevez le modèle, la version complète, le build, le rôle de chaque nœud et ses interfaces d’administration. Un compte autorisé peut consulter la version avec status. « FortiSandbox 4.4 » ne suffit pas : il faut connaître le numéro de correctif.

• Identifier toutes les appliances 4.4.0 à 4.4.6, y compris celles de secours ou de laboratoire accessibles.
• Recenser les comptes locaux et ceux issus des annuaires, leurs profils et leurs propriétaires.
• Vérifier séparément les permissions de données, de menus, de console, de CLI et d’API.
• Repérer les sources réseau autorisées à atteindre l’administration et les accès indirects via bastion ou VPN.

10.2. Appliquer la correction du produit

Fortinet recommande FortiSandbox 4.4.7 ou supérieure, ou 5.0.0 ou supérieure. Consultez le chemin de mise à niveau de la version choisie. Préparez la sauvegarde et la restauration, vérifiez les connecteurs et les contraintes du modèle. Si vous avez plusieurs nœuds, respectez leur ordre de mise à jour.

Prévoyez la fenêtre de maintenance et le traitement des flux pendant l’interruption avec les équipes concernées. Ensuite, vérifiez le build installé, les restrictions de compte et le fonctionnement des analyses. La bonne version du firmware ne suffit pas à vérifier que toutes les intégrations ont repris.

10.3. Mesures transitoires à adapter à l’exploitation

En attendant la mise à jour, limitez l’accès à l’administration : réseau dédié, filtrage, bastion et accès distants contrôlés. Utilisez des comptes nominatifs, désactivez ceux qui ne servent plus et revoyez les droits. Activez une authentification renforcée si votre configuration le permet.

Cela réduit le nombre de personnes capables d’atteindre la faille, mais ne la corrige pas. Dans le test, aucun accès GUI Console ou API/CLI n’est accordé. Le timeout GUI d’une minute ne ferme même pas la session CLI. Un délai d’inactivité court ou une authentification renforcée ne remplace donc pas la mise à jour.

La fiche CVE indique des versions corrigées, sans fournir de contournement validé. Les mesures ci-dessus sont des recommandations d’exploitation ; Fortinet ne les présente pas dans cette fiche comme un correctif provisoire.

11. Valider les autorisations après mise à jour

Les versions 4.4.7 et 5.0.0 n’ont pas été testées dans cette démonstration. Voici les contrôles proposés pour votre laboratoire après mise à jour.

Avant de commencer, obtenez l’autorisation du responsable des systèmes et fixez les équipements concernés, les opérations permises, le créneau et les conditions d’arrêt. L’objectif est de vérifier la correction, sans étendre les tests à d’autres systèmes ni à d’autres opérations.

1. Établir une référence : relever version/build et exporter les paramètres du profil avec un compte autorisé. Noter séparément Data Access, GUI Console, JSON API et CLI Commands.
2. Séparer les sessions : utiliser des profils de navigateur distincts pour l’administrateur et le compte restreint. Vérifier le compte affiché et les sessions dans les journaux disponibles.
3. Contrôler l’accès initial : vérifier l’accès à la route de console, pas seulement l’absence du menu. Le refus doit correspondre au profil réellement configuré.
4. Reproduire les changements de session : déconnecter et reconnecter la console, laisser la session expirer, fermer le navigateur puis se reconnecter. Vérifier les droits à chaque fois ; regarder seulement l’aide ne suffit pas.
5. Tester le refus d’une commande : choisir avec l’équipe ou le support une opération qui n’altère pas les données. Si vous testez le redémarrage, faites-le sur une VM de laboratoire dont l’arrêt est autorisé.
6. Vérifier la stabilité des refus : l’opération refusée doit le rester après reconnexion ; aucun rôle plus élevé ne doit être attribué implicitement.
7. Contrôler la traçabilité : associer chaque événement à un compte, une origine et un horaire ; conserver la preuve de refus et la version testée.
8. Recetter le service : soumission d’un échantillon de test autorisé, progression du job, réception du résultat, intégrations et supervision. Vérifier également le comportement lorsque la plateforme est indisponible.

Conservez la version, le profil, la méthode, les messages et les journaux avec le résultat de chaque contrôle. Gardez les configurations et les identifiants dans votre dossier interne de recette.

12. Rechercher les traces et traiter un incident

Cet article ne fournit pas de journaux ni de capture réseau permettant de valider une signature SIEM. Pour rechercher un usage de la faille, rapprochez les connexions des comptes restreints des opérations d’administration et des interruptions de service :

• Authentifications d’administrateurs restreints et ouvertures/reconnexions de console, si elles sont journalisées.
• Opérations de maintenance ou redémarrages effectués par un compte qui ne devrait pas les autoriser.
• Interruption de supervision corrélée avec une session d’administration.
• Créations ou changements de comptes/profils et modifications de configuration inattendues.
• Suppression de journaux ou arrêt inattendu de leur collecte.

Un redémarrage peut aussi être une maintenance normale. Vérifiez l’horaire prévu, le compte, l’adresse source et les traces de commande disponibles. Des journaux centralisés vous donnent une autre copie que celle stockée sur l’appliance.

Si vous soupçonnez un abus, conservez les traces avant de les effacer par une opération de maintenance et limitez les accès concernés. Comparez les comptes et la configuration à une sauvegarde connue. Installer le correctif n’annule pas les changements qu’un attaquant aurait déjà faits ; la revue des comptes, des paramètres et des secrets exposés reste nécessaire selon les constats.

CISA a indiqué Exploitation: none le 12 mars 2025. Cette appréciation ne permet pas de conclure qu’il n’y a pas eu d’exploitation depuis. De même, E:P signifie preuve de concept, pas exploitation active.

13. Questions fréquentes

Faut-il déjà posséder un compte ?

Oui : la description de Fortinet vise un administrateur peu privilégié et le vecteur indique PR:L. Le test utilise un compte authentifié ; aucun contournement du formulaire de connexion n’a été démontré.

Le compte est-il réellement dépourvu de tous les droits ?

Non. Toutes les autorisations de Menu Access sont sur None et aucun accès API/CLI n’est accordé, mais Data Access est sur Full Access. Le nom du profil ne suffit pas à décrire ses permissions.

Une aide étendue suffit-elle à démontrer une compromission complète ?

Non. Pour le prouver, il faut tester les commandes concernées et vérifier leurs résultats. Ici, seul le redémarrage est démontré ; aucun shell root ni aucune exfiltration n’a été démontré.

Le timeout d’une minute ferme-t-il la console ?

Non, pas dans ce test. Il a été abaissé volontairement à une minute, mais la session CLI est conservée. Le message de déconnexion apparaît plus tard. C’est le clic sur Connect qui permet ensuite de reconnecter la console et d’exécuter reboot. La fiche CVE ne fait pas du réglage d’une minute un prérequis.

Est-ce une vulnérabilité FortiGate ou FortiDeceptor ?

Non : FG-IR-24-261 / CVE-2024-45328 concerne FortiSandbox. La page des publications de recherche présente aussi d’autres contributions ; leurs produits, identifiants et conditions doivent rester distincts.

14. Sources et limites du test

1. Fortinet PSIRT — FG-IR-24-261, avis de référence. Le record CVE référence également l’adresse FortiGuard sous fortinet.com.
2. CVE-2024-45328 — registre CVE. Le record JSON de CVEProject, consulté le 12 octobre 2026, contient le bloc CNA fourni par Fortinet : description, versions affectées, solutions et métriques.
3. Démonstration de Thomas SAUTIER, réalisée le 29 juin 2024 sur FortiSandbox VM 4.4.6-build0397 (GA). Les précisions de l’auteur sur le profil, le timeout et la reconnexion sont intégrées à cet article.
4. MITRE — CWE-863, Incorrect Authorization, référence de classification.
5. FIRST — spécification CVSS 3.1, référence pour distinguer métriques de base et temporelles.

Les versions et le score viennent des données de Fortinet dans la fiche CVE. Les commandes et leurs résultats sont ceux du test de Thomas SAUTIER. Les conseils de mise à jour, de détection et de recette sont proposés à partir de ces éléments. La page PSIRT était inaccessible pendant la rédaction ; nous avons utilisé la fiche CVE officielle qui la référence.

Aucun nouveau test sur appliance ou firmware corrigé n’a été réalisé pour cet article. Pour préparer votre mise à jour, consultez l’avis courant et la documentation de la version cible.