Connexion Premium

80 000 pare-feux Fortinet compromis à cause d’une mauvaise gestion des mots de passe

Sans foi sur le métier

80 000 pare-feux Fortinet compromis à cause d’une mauvaise gestion des mots de passe

Illustration : Flock

Il y a une semaine, une importante campagne d’attaque a été détectée contre les pare-feux Fortinet. 80 000 mots de passe ont été récupérés par des pirates, ce qui représenterait la moitié environ des pare-feux Fortinet exposés à Internet.

L’attaque a été découverte par le chercheur Volodymyr Diachenko (souvent appelé Bob). Dans une publication LinkedIn le 15 juin, il avertit qu’une « campagne massive de force brute/exploitation » a été découverte en pleine action sur des pare-feux Fortinet. Il évoque alors 21 634 noms de domaine uniques, liés à des entreprises allant de Chevron à Fortinet elle-même. Les mots de passe ont été obtenus par craquage du hachage, puis utilisés pour obtenir des données et la prise de contrôle de réseaux internes.

Selon les chercheurs de SOCRadar, le mode opératoire et les traces laissées sont à rapprocher des acteurs malveillants russes. L’attaque est décrite comme particulièrement sophistiquée, ayant abouti à un lot de données comprenant à la fois des mots de passe et des identifiants SSL VPN depuis des fichiers de configuration compromis.

Toujours selon SOCRadar, les équipements attaqués étaient répartis dans 194 pays. Les plus touchés sont l’Inde, les États-Unis et le Mexique, avec près de 12 000 identifiants compromis entre eux. La France est présente dans la liste avec 1 116 identifiants.

La répartition par type de « credentials » révèle une prédominance de comptes organisationnels, pointant vers un ciblage délibéré des entreprises. Foxconn, Samsung, Comcast, Siemens, Lenovo, PwC, Accenture et Oracle, ainsi que de nombreuses entités gouvernementales et opérateurs d’infrastructures critiques ont été touchés. Un contractant turc de l’OTAN figure également parmi les cibles.

Convergence de défaillances

Si l’attaque a été nommée FortiBleed, le cas n’a rien à voir avec Heartbleed : il s’agit bien d’une campagne industrielle de vol et d’utilisation d’identifiants. À la racine de l’attaque, il n’y a pas une faille unique et cataclysmique, mais une série de défaillances en lien avec l’hygiène numérique.

Selon le chercheur Kevin Beaumont dans un billet du 18 juin, les pirates ont commencé par scanner internet à la recherche d’instances Fortinet dont l’interface de gestion FortiGate était accessible publiquement. Ils se sont ensuite intéressés à celles présentant un profil spécifique.

Dans les versions 7.2.11, 7.4.8 et 7.6.1 de FortiOS, le système d’exploitation équipant ses pare-feux, Fortinet a en effet introduit la fonction de hachage PBKDF2 pour les identifiants administrateurs, pour remplacer l’ancien SHA-256. Cependant, lors d’une mise à jour depuis des versions antérieures, les mots de passe existants restent stockés en SHA-256 jusqu’à ce que l’administrateur se reconnecte après l’opération. De nombreuses organisations ont donc appliqué une nouvelle version sans déclencher de nouveau hachage : leurs firewalls, pourtant mis à jour, demeuraient vulnérables.

Les moyens des ambitions

Les pirates ne se sont pas lancés non plus à l’aveuglette. Ils ont opéré sur la base d’identifiants déjà obtenus par plusieurs sources : la fuite Fortinet de 2021 portant sur environ 500 000 comptes FortiGate VPN, les données obtenues après une faille 0-day en 2022, ou encore d’autres bases existantes. Les mots de passe testés n’étant donc pas aléatoires : ils avaient déjà fonctionné par le passé sur des appareils Fortinet.

L’ampleur de l’attaque est connue, car les chercheurs ont pu remonter jusqu’aux pirates russes, car leur serveur était lui-même exposé publiquement. Les journaux récupérés indiquaient environ 1,16 milliard de tentatives d’identification contre 320 777 cibles FortiGate, ainsi que 2,1 milliards de tentatives supplémentaires contre plus de 163 650 serveurs Microsoft SQL Server, indique le site InfoStealers. Le groupe interceptait les hachages d’authentification SSL VPN et les crackait sur un cluster dédié de 45 GPU géré via Hashtopolis, selon Kevin Beaumont.

Au moins une faille existante pourrait avoir été utilisée : la vulnérabilité CVE-2026-24858, qui permet un contournement d’authentification SAML SSO FortiCloud et est classée comme critique, avec un score CVSS de 9,8 sur 10, comme l’indique RansomNews. Elle a été révélée en janvier et est déjà corrigée, mais des appareils ont pu passer à côté du correctif. Du côté de SOCRadar, on note que deux autres failles ont été activement exploitées pendant cette période, CVE-2026-21643 et CVE-2026-35616. Elles concernent FortiClient EMS, mais le lien avec FortiBleed n’est pas confirmé. Aucune faille 0-day ne semble avoir été utilisée.

Pour Fortinet, tout n’est qu’un recyclage d’anciennes fuites

Les recommandations sont claires :

  • réinitialiser immédiatement tous les mots de passe administrateurs et VPN (notamment pour les appareils exposés sur Internet)
  • activer l’authentification multifacteur sur tous les comptes d’accès administrateurs et distants
  • restreindre l’accès à l’interface de gestion aux réseaux internes de confiance
  • mettre à jour FortiOS vers une version supportant PBKDF2 et s’assurer que chaque administrateur se reconnecte ensuite pour déclencher un nouveau hachage

Pour Fortinet, il ne s’agit que d’une exploitation d’anciennes bases de données. « D’après notre analyse, les données impliquées sont un mélange de données d’incidents précédents, ainsi qu’un [cracking par] force brute des identifiants, et ne sont pas liées à un incident récent ni à un avertissement. Les organisations qui suivent les meilleures pratiques, y compris la mise à jour régulière des identifiants de sécurité […] courent un risque minimal lié aux détails de compromission des identifiants mentionnés dans les rapports », a déclaré l’entreprise à TechRadar le 18 juin. Elle ajoutait cependant que l’enquête continuait et que la sécurité de ses clients restait sa priorité.

Kevin Beaumont relativise ces déclarations, précisant que les fuites contiennent des données plus récentes.

Commentaires (14)

votre avatar
Forti qui recommande de passer d'un VPN SSL à VPN IPsec mais, leur client Linux n'a pas d’onglet VPN IPsec. :censored:
votre avatar
faut la version EMS il me semble comme pour MAC
votre avatar
Salut,
Merci pour l'info.
Pour Mac la version VPN Only a bien l'onglet IPsec.
votre avatar
de mémoire il y a l'onglet mais il est grisé non ?
votre avatar
Non, l'onglet est actif et j'ai pu configurer du VPN IPsec sur tous les Mac de mon boulot (client VPN only).
Sous Linux, on passe par strongswan.
votre avatar
ou alors c'est juste IKEV2 qui est bloquer ? je sais plus dsl :(
votre avatar
Une vraie daube leur client Linux. J'utilise openconnect
votre avatar
Aucun lien entre SHA-256 et PBKDF2, l'un étant un algorithme de hashage, l'autre étant un algorithme de dérivation de clé (utilisant au passage un algorithme de hashage).

Le SHA-256 est aujourd'hui toujours considéré comme étant fiable, ce n'est pas le fait que cet algorithme était utilisé qui est un problème, mais probablement la manière dont il a été utilisé.

Et utiliser PBKDF2, en soi, ça ne veut rien dire. Ils utilisent quel algorithme de hash en paramètre ? Ils demandent quelle taille de donnée en sortie ? ...

D'ailleurs, les mots de passe ne sont pas "stockés", seuls le sel et le hash sont stockées (d'où l'obligation de se connecter pour convertir le format)
votre avatar
merci
votre avatar
J'ai reçu un mail de Sophos la-dessus avant-hier, ils ont essayé de brutforcer les accès VPN sur les appliances Sophos (ils ont ciblés en priorités la ou le MFA n'était pas activé) en utilisant les mots de passe qui ont fuités sur les produits Fortinet
votre avatar
Les recommandations sont claires :
Il faut mettre fin aussi à toutes les sessions actives sur le pare-feu ou les pare-feux Fortinet
votre avatar
En même temps il me semble qu'il n'y a pas de moyen automatique de migrer des mots de passe existants quand on veut changer la manière de générer le hash. On est obligé d'attendre que les utilisateurs redonnent leur mot de passe en se connectant.

Sauf peut-être si la situation précédente était tellement moisie qu'il est possible de se bruteforcer sa base soi-même ? Ce serait un peu limite comme méthode. L'autre méthode étant de désactiver l'ancien hash au bout d'un certain temps, en informant ou non l'utilisateur qui récupérera son accès par un autre moyen (fonction mot de passe oublié, contact service client ou admin) sans vraiment savoir ce qui s'est passé. Bon pour ce type de produit c'est pas très adapté.
votre avatar
Bon pour ce type de produit c'est pas très adapté
En même temps, pour ce type de produit, on évite en général d'avoir une base utilisateur qui ne se connecte pas depuis un certain temps. En théorie, on a un suivi des utilisateurs, et un nettoyage/désactivation des utilisateurs inactifs.

Donc un changement d'algo de hash peut se faire en un laps de temps assez court (à la discrétion de l'entreprise). Et pour les autres, tant pis. Procédure de désactivation de compte + mot de passe oublié
votre avatar
Si j'ai bien compris ce sont les mots de passe admin fortinet qui ont été cassés pas ceux des end-users.
Du coup c'est assez dingue le cumul d'erreur de ces admins :

  • mots de passe inchangé depuis 2021 !?

  • Serveur VPN pas à jour, (ou mis à jour sans lire la changelog qui disait de se reconnecter)

  • Absence de MFA (sur un compte admin !!!)



Je croise beaucoup de TME qui utilisent un login générique (i.e. partagé par les consultants de la presta TME au mieux dans un keepass comment, au pire dans .txt sur le bureau !) avec un mot de passe admin partout pareil du genre "NomDeLaBoite1234" (BDD, VPN, Windows AD... :-/).
C'est une aberration totale : les accès doivent être nominatif (surtout/ y compris pour un admin !) toutes les sécurités doivent être activé sur ces comptes: MFA, verrouillage IP, autolock en cas d'erreur...