Introduction
Un correctif pour la vulnérabilité critique CVE-2025-25257 (score CVSS : 9.8) affectant les produits FortiWeb a été publié le 8 juillet 2025. Cette mise à jour concerne les versions suivantes :
- FortiWeb 7.6 : versions 7.6.0 à 7.6.3 → Mise à jour recommandée : 7.6.4 ou ultérieure
- FortiWeb 7.4 : versions 7.4.0 à 7.4.7 → Mise à jour recommandée : 7.4.8 ou ultérieure
- FortiWeb 7.2 : versions 7.2.0 à 7.2.10 → Mise à jour recommandée : 7.2.11 ou ultérieure
- FortiWeb 7.0 : versions 7.0.0 à 7.0.10 → Mise à jour recommandée : 7.0.11 ou ultérieure
La vulnérabilité repose initialement sur une injection SQL via un point de terminaison de l’API /fabric/, permettant, par le biais d’une requête particulière, d’exécuter du code arbitraire.
Dans les jours suivant la publication du correctif, plusieurs preuves de concept (PoC) ont été diffusées par différents acteurs de la communauté, notamment WatchTowr1 et BigShaq2.
Le PSIRT de Fortinet a mis à jour le statut de la vulnérabilité le 18 juillet 2025, en ajoutant l’information concernant des campagnes actives d’exploitation.
Dans certains PoC disponibles, l’exploitation inclut l’usage de scripts CGI (Common Gateway Interface) présents par défaut sur une instance FortiWeb afin de déclencher la charge finale contenant un reverse shell, offrant ainsi un accès direct au système compromis.
Bien qu’une interface d’administration de ce type d’outil ne soit pas censée être accessible depuis Internet, un certain nombre d’instances sont identifiables au travers de moteurs de recherche comme Shodan3 :
Artefacts forensic
Les informations suivantes se basent sur une instance Fortiweb version 7.6.1.
Les solutions Fortinet, telles que FortiWeb ou les pare-feux FortiGate, ne sont pas toujours réputées pour leur facilité d'investigation lors d'une compromission. Cependant, il est possible d’en tirer certains artefacts utiles à l’analyse.
Dans cet article, nous passerons en revue les différentes sources de traces exploitables pour détecter une activité malveillante liée à la vulnérabilité CVE-2025-25257, en commençant par les éléments les plus volatiles.
Analyse des processus en cours d’exécution (Live)
Il est possible d'analyser les processus lancés sur l'instance à la recherche de commandes inhabituelles en cours d'exécution. Il est également possible de détecter cette activité en utilisant les commandes de base disponibles dans l’interface en ligne de commande (/bin/cli) de FortiOS. La technique de capture de la mémoire RAM pourrait être utilisée, mais cela implique deux prérequis : réussir à réaliser un dump RAM (accès hyperviseur) et retrouver la table de symbole utilisée notamment par Volatility pour explorer le dump. Cette méthode de capture ne sera pas étudiée dans ce blogpost.
Après s’être connecté en SSH avec un compte administrateur, les commandes suivantes peuvent être utilisées pour afficher les processus en cours d’exécution :
A la différence de la commande ps affichant un instantané des processus à l’instant de l’exécution, top affiche un monitoring en temps réel actualisé à une fréquence de quelques secondes sous forme de sortie dynamique.
La commande top n’est pas très adaptée pour l’analyse mais fait partie du package des quelques commandes communiquant des informations système. Heureusement, la commande ps est également disponible nativement :
On observe dans l’encadré rouge, l’exécution d’un script CGI (webshell) après l’avoir créé par suite de l’exploitation de la vulnérabilité. Ici, il a été utilisé pour obtenir un reverse shell. L’observation du processus indique que l’attaquant possède un accès distant au serveur.
La CLI native FortiOS embarque quelques autres commandes :
- dump : extrait la pile (kernel stack) d’un processus
- lsof : liste les fichiers ouverts par les processus
- trace : affiche un échantillon des instructions exécutées par un processus
Peu d’informations sont utiles, lsof pouvant nous apprendre (à nouveau) un lien avec /migadmin/cgi-bin/.
Ensuite, il est possible d’identifier les connexions externes, notamment sur des ports atypiques en sortie pouvant correspondre à une utilisation active d’un reverse shell, à l’aide de la commande native netstat :
Nous retrouvons dans la liste des connexions ouvertes une connexion suspecte, encadré en rouge dans l’image.
Une connexion entrante est réalisée (IP interne 172.) depuis un port alloué dynamiquement, et la destination est une IP externe sur le port spécifique 4000 au lieu d’un port de retour attribué aléatoirement depuis une fourchette habituelle (ex 40-50000).
Analyse des requêtes web
Un service apache est utilisé sur l’instance par lequel les requêtes HTTP de l’interface d’administration passent. On peut alors consulter les accès et erreurs via le dossier apache_logs/ contenant access.log et error.log.
Dans le cas de la vulnérabilité, ce sont les tentatives d’accès à au chemin api/fabric/device/status qui peuvent être signe d’une tentative d’exploitation suivies de l’accès à ml-draw.py et le fameux fichier cgi forgé par l’attaquant, ici “x.cgi” :
Il peut être intéressant d'analyser les accès uniques à destination de la page api/fabric/device/status afin de déterminer si une simple exfiltration de fichiers a été réalisée. La corrélation d'un accès à la page vulnérable suivi d'un accès à un fichier exposé peut poser la question d'une exfiltration de données. Dans l'image ci-dessous, une seule requête a été utilisée pour exploiter la vulnérabilité SQL afin de copier le contenu d'un fichier dans un nouveau fichier bootstrap.css :
Le répertoire /migadmin/angular/ correspond au dossier utilisé (et exposé) de l'interface web du portail, avec tous les fichiers html, js et css associés. L’attaquant a ensuite accédé au fichier via une simple requête web 10 secondes plus tard :
Analyse des fichiers disques
Les codes d’exploitation existants présentent plusieurs répertoires où des fichiers malveillants peuvent être écrits avant d’être déclenchés par l’exécution de la vulnérabilité :
- lib/python3.10/ (principalement des fichiers Python, .py, remplaçant des packages légitimes)
- lib/python3.10/sites-packages/ (principalement des fichiers .pth)
- /migadmin/cgi_bin/ (fichiers .cgi)
Une rapide vérification peut être réalisée depuis la CLI native de FortiOS à l’aide de la commande ls via fnsysctl :
Dans l’exemple ci-dessus, on retrouve le fichier x.cgi qui a été uploadé par l’attaquant.
Toujours via CLI, et dans la suite de l’exemple de l’exfiltration d’un fichier sensible, on peut retrouver sa trace en identifiant les fichiers modifiés dans le répertoire /migadmin/angular/. Attention cependant aux tentatives de timestomping sur les fichiers manipulés par un attaquant :
Ici la nomenclature bootstrap.css permet de dissimuler la fuite de données en utilisant un nom connu et légitime pour les fichiers liés aux frameworks web.
Les commandes étant toutefois assez limitées, une vérification dans de multiples dossiers et sous-dossiers peut s’avérer particulièrement longue. D’autant plus que l’affichage via la commande cat (via fnsysctl cat) n’a pas fonctionné sur les fichiers utiles pour l’analyse (dossier /migadmin/, /lib/python3.10/) et que la fonctionnalité de condensat en SHA256 n’est pas disponible sur cette version de FortiWeb, contrairement à d’autres produits de la marque Fortinet comme Fortigate.
Pour cela, 2 solutions existent, en fonction de l’environnement disponible :
- Développer un script interne pour se connecter en SSH à la machine, lister les fichiers root et lancer des commandes supplémentaires à chaque détection de dossiers. Cela permet de créer une cartographie du système de fichiers version Forti. Le chemin/nom de fichier, date de modification et droits seront les seules informations disponibles.
- Faire une copie de disque, en cas d’instance virtualisée, afin d’analyser les données plus facilement et obtenir davantage de contexte.
Dans le cas du calcul de hash pour les fichiers, il est possible d’identifier rapidement des fichiers suspects en fonction de la date, du nom/extension et de leur hash :
Attention cependant aux faux positifs (ici distutils-precedence.pth &matplotlib-3.5.2-py3.10-nspkg.pth). Les hashs sont ensuite à comparer avec des bases de CTI à disposition qui peuvent indiquer des fichiers malveillants déjà observés dans d’autres campagnes.
Détection
Il n’existe aujourd’hui pas de solution permettant la collecte des journaux apache d’une instance FortiWeb dans le but de les insérer dans un SIEM et jouer des règles de détection.
Sources
- Pre-Auth SQL Injection to RCE - Fortinet FortiWeb Fabric Connector (CVE-2025-25257) - https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/
- FortiWeb Pre-Auth RCE (CVE-2025-25257) - https://pwner.gg/blog/2025-07-10-fortiweb-fabric-rce
Note de bas de page
1 Pre-Auth SQL Injection to RCE - Fortinet FortiWeb Fabric Connector (CVE-2025-25257) - https://labs.watchtowr.com/pre-auth-sql-injection-to-rce-fortinet-fortiweb-fabric-connector-cve-2025-25257/
2 FortiWeb CVE-2025-25257 exploit - https://github.com/0xbigshaq/CVE-2025-25257
3 http.html:"FortiWeb" - https://www.shodan.io/search?query=http.html%3A%22FortiWeb%22
