Un pare-feu qui lisait son propre trafic
Le détail qui distingue FortiBleed d'une alerte de routine, c'est l'origine des identifiants. Un outil sur mesure que les chercheurs appellent FortigateSniffer détourne la commande de diagnostic de paquets intégrée à FortiOS, la fonction même dont un administrateur se sert pour dépanner, afin d'intercepter passivement le trafic d'authentification sur près de deux douzaines de protocoles. Aucune nouvelle vulnérabilité n'est nécessaire. L'appareil vendu pour garder le périmètre est devenu l'instrument qui lisait les connexions qui le traversaient.
SOCRadar a suivi l'opération jusqu'au terrain du rançongiciel après avoir découvert un seul opérateur connecté en même temps aux panneaux de négociation d'INC Ransom et de Lynx. La CISA a exhorté les organisations à durcir les appareils Fortinet le 18 juin, après les premiers signalements d'exposition d'identifiants, et l'équipe de sécurité produit de Fortinet a elle-même publié une analyse de la compromission.
Les chiffres derrière la campagne
Les premiers comptes rendus de Recorded Future et de Help Net Security situaient l'exposition près de 74 000 systèmes FortiGate. Une analyse ultérieure de SOCRadar a élargi le tableau à 430 000 appareils visés, environ la moitié de tout le matériel Fortinet exposé à internet, et 86 644 identifiants valides vérifiés répartis sur 194 pays. Le recoupement des serveurs FortiBleed avec un répertoire ouvert distinct lié à INC a fait ressortir les mêmes organisations victimes dans les deux jeux de données, la signature d'une filière partagée.
Au moins 12 déploiements de rançongiciel confirmés remontent déjà directement à l'accès FortiBleed, avec des centaines de terminaux chiffrés. INC Ransom est actif depuis juillet 2023 et a revendiqué plus de 800 victimes, ce qui en fait l'une des opérations de rançongiciel en tant que service les plus prolifiques au nombre confirmé. La récolte d'identifiants n'est pas un avertissement de ce qui pourrait arriver ; c'est l'amorce d'attaques qui ont déjà eu lieu.
Le correctif n'est pas la solution cette fois
Parce que le point d'entrée est un identifiant valide et non une faille non corrigée, le réflexe habituel échoue. Un FortiGate sous le dernier micrologiciel avec un compte VPN exposé reste une porte ouverte, et il le reste tant que ce compte n'est pas renouvelé. Les actions requises sont le renouvellement des identifiants sur chaque compte de pare-feu et de VPN, l'authentification multifacteur imposée sur l'accès distant, et la capture de paquets de diagnostic désactivée ou étroitement surveillée là où elle n'est pas nécessaire.
L'hypothèse prudente pour tout appareil de l'ensemble exposé est que ses identifiants ont fuité et qu'il doit être considéré comme compromis jusqu'à preuve du contraire. Cela transforme le travail, d'un cycle de correctifs en un nettoyage des identités, plus lent, moins gratifiant, et la seule chose qui referme vraiment la porte.
Sous NIS2 le compte à rebours est le vôtre
Pour les opérateurs européens, le tranchant réglementaire est vif. Sous NIS2, un incident qui atteint votre réseau via un appareil de périphérie tiers est votre événement à déclarer, avec une alerte précoce due sous 24 heures et une notification plus complète sous 72. Les entreprises financières portent les obligations parallèles de DORA. La responsabilité n'incombe ni à Fortinet ni au groupe de rançongiciel ; elle incombe à l'organisation qui a subi la violation.
L'indicateur qui compte désormais n'est pas de savoir si le pare-feu est à jour, mais à quelle vitesse chaque identifiant qu'il contient peut être renouvelé. Les équipes qui supposent déjà que leurs connexions de périphérie ont fuité, et qui peuvent prouver le renouvellement et la MFA sur demande, sont celles qui ne liront pas leur propre nom dans le prochain billet de rançongiciel.
À lire ensuite: Quatre agents de code sortis sans forcer la moindre barrière | Le correctif nginx est là, l'exploit arrive en août
