FortiBleed montre comment les identifiants Edge deviennent du carburant pour les rançongiciels

Graphique des directives CISA StopRansomware Image source : guide CISA StopRansomware.

FortiBleed est un nom utile pour une classe de risques désordonnée mais importante : dispositifs périmétriques, identifiants volés, mots de passe réutilisés, exposition VPN et courtage d'accès aux ransomwares convergeant tous autour du même plan de contrôle.

Des rapports récents ont décrit un large ensemble de données de credentials Fortinet et FortiGate contenant des dizaines de milliers d'entrées de pare-feu ou de VPN. Le chercheur en sécurité Volodymyr Diachenko aurait trouvé une archive avec 73 932 URL, noms d'utilisateur, e-mails et mots de passe en clair de pare-feu Fortinet ou FortiGate. ITPro a rapporté que Hudson Rock a caractérisé l'incident comme une campagne plus large impliquant le bruteforce, la collecte de hachages d'authentification SSL VPN et un accès ultérieur aux environnements Active Directory. Fortinet a contesté l'idée que les données proviennent d'une violation récente de produit, affirmant que le matériel semblait être un partage de données plus anciennes et de credentials récupérés par bruteforce plutôt qu'un nouvel avis de Fortinet.

Cette distinction est importante, mais elle ne rend pas le risque faible. Si un identifiant fonctionne, l'attaquant se moque de savoir s'il provient d'une nouvelle vulnérabilité, d'un incident ancien, de la réutilisation d'un mot de passe ou d'un hash craqué.

Cette histoire est importante car elle montre comment la compromission d'un appareil en périphérie devient une chaîne d'approvisionnement pour des intrusions ultérieures. Un identifiant de pare-feu volé n'est pas l'impact final. C'est de l'inventaire.

Pourquoi les dispositifs périphériques sont attractifs

Les pare-feu, les VPN, les passerelles et les dispositifs d'accès à distance sont des cibles de grande valeur car ils se trouvent à la périphérie et ont souvent des relations de confiance privilégiées. Si les attaquants obtiennent des identifiants ou du matériel de session à partir de ces systèmes, ils pourraient être capables d'entrer dans l'environnement par les mêmes portes que celles utilisées par les administrateurs légitimes.

Les dispositifs périphériques posent également des défis opérationnels. Ils peuvent être difficiles à patcher rapidement, compliqués à surveiller en profondeur et risqués à mettre hors ligne. Dans de nombreuses organisations, ils sont considérés comme de l'infrastructure plutôt que comme des points de terminaison, ce qui signifie qu'ils peuvent ne pas bénéficier de la même couverture de détection.

Il y a un autre facteur inconfortable : les dispositifs en périphérie relient souvent plusieurs domaines d'identité. Un appareil VPN peut s'authentifier contre Active Directory, LDAP, SAML, des comptes administrateur locaux, RADIUS ou des fournisseurs d'identité cloud. Si un attaquant compromet l'appareil ou ses identifiants administratifs, l'incident résultant peut affecter plus qu'une seule machine. Il peut exposer la configuration, les routes, les politiques, les utilisateurs VPN, les certificats, les réseaux de confiance et parfois les identifiants ou les hachages permettant un mouvement latéral.

Le vol d'identifiants change la chronologie

Lorsque des identifiants sont collectés à grande échelle, le risque ne disparaît pas lorsque la campagne est signalée pour la première fois. Ces identifiants peuvent être vendus, échangés, testés ultérieurement ou utilisés par différents groupes. Les affiliés aux logiciels de rançon n'ont pas besoin d'exploiter la vulnérabilité originale s'ils peuvent acheter un accès fonctionnel.

Cela signifie que la remédiation doit inclure l'invalidation des identifiants et des sessions, pas seulement le correctif.

L'erreur du défenseur est de considérer cela comme un ticket de gestion des vulnérabilités. Le patching est nécessaire, mais les identifiants volés survivent aux correctifs. Les comptes administrateur locaux survivent aux correctifs. Les utilisateurs de backdoor survivent aux correctifs. L'exposition des comptes SAML, LDAP, RADIUS, API et de service peut survivre aux correctifs. Si l'appareil a été accédé, la réponse devrait ressembler à une enquête sur un incident.

Que vérifier en premier

Commencez par les preuves qui permettraient de déterminer si l'appareil a seulement été exposé ou réellement utilisé :

Connexions VPN réussies et échouées par compte, IP source, pays et heure.
Connexions administratives à la console du pare-feu ou du VPN.
Exportations de configuration, modifications de politiques, nouveaux utilisateurs locaux et nouvelles clés API.
Modifications des réseaux de confiance, des serveurs d’authentification, du routage, du NAT ou de la journalisation.
Événements LDAP, RADIUS, SAML et Active Directory qui correspondent aux connexions aux appareils.
Nouvelles sessions d’accès à distance provenant de zones géographiques inhabituelles, ASN, proxies résidentiels ou fournisseurs d’hébergement.
Lacunes dans les journaux suggérant une falsification ou une journalisation uniquement locale.

Si l'appareil n'exporte pas suffisamment de télémétrie vers un SIEM, supposez que l'enquête présente un angle mort. Les journaux de bord doivent être envoyés hors bande, car un attaquant ayant accès à l'appareil pourrait être capable d'effacer les traces locales.

Ce que les défenseurs devraient faire

Les organisations utilisant Fortinet et des plateformes similaires en périphérie devraient adopter une approche de réponse plus large.

Appliquer les correctifs sur les appareils affectés et confirmer l'intégrité du firmware.
Changer les identifiants administratifs et les jetons API.
Révoquer les sessions actives dans la mesure du possible.
Examiner les connexions VPN, les connexions administratives, les modifications de configuration et les nouveaux comptes.
Restreindre les interfaces de gestion aux réseaux de confiance.
Exporter les journaux vers un SIEM séparé afin que les attaquants ne puissent pas effacer les preuves locales.
Surveiller les accès ultérieurs depuis des emplacements inhabituels même après la correction initiale.
Examiner les comptes de service liés à l'appliance, y compris les comptes de liaison LDAP et les intégrations SAML.
Désactiver les portails VPN inutilisés, les méthodes d'authentification héritées et les comptes locaux.
Exiger une authentification multi-facteur résistante au phishing pour les administrateurs et l'accès à distance à haut risque.
Reconstruire ou réimager les appliances lorsque la compromission est probable et que la confiance en l'analyse judiciaire est faible.

La leçon stratégique

Les groupes de ransomwares bénéficient de plus en plus d'un marché d'accès. Un acteur vole des identifiants. Un autre les valide. Un autre les vend. Un affilié de ransomware les utilise. La victime le perçoit comme une seule violation, mais le flux de travail criminel peut impliquer plusieurs transferts.

C'est pourquoi la sécurité périmétrique ne peut plus être considérée comme un contrôle à mettre en place et à oublier. Les systèmes en périphérie nécessitent une gestion des vulnérabilités, une hygiène des identités, une journalisation et une attention à la réponse aux incidents proportionnelles à leur importance.

Conclusion

FortiBleed n'est pas seulement une histoire de Fortinet. C'est une histoire de périmètre et d'identité. Toute organisation utilisant des VPN, des pare-feu, des passerelles web sécurisées, des appareils d'accès à distance ou des systèmes périphériques connectés à l'identité devrait supposer que ces plateformes sont des cibles privilégiées pour la collecte de credentials et la revente d'accès.

Si un identifiant de périphérie fuit, la question n'est pas « avons-nous mis le correctif ? » La question est « qu'est-ce que cet identifiant pouvait atteindre, qu'est-ce qui a changé pendant qu'il était valide, et quel accès a-t-il créé pour plus tard ? »