Le graphique ci-dessus montre que le nombre d'hôtes et de services exposés avec Ivanti Connect Secure a suivi une ligne constante qui a oscillé autour de 26 000 hôtes et 27 300 services jusqu'au 31 janvier, date à laquelle la CISA a publié une mise à jour de sa directive d'urgence initiale .
Cependant, lorsque nous avons vérifié à nouveau ces chiffres une semaine plus tard, ils ont grimpé à environ 41 800 hôtes et 46 000 services, soit un doublement du nombre d'hôtes et de services.
Il se passe quelque chose d'inhabituel. Ce pic inattendu éveille les soupçons, car il s'écarte du comportement habituel des hôtes légitimes. Bien que l'internet soit souvent lent à mettre en place des correctifs, il n'augmente généralement pas le nombre d' hôtes affectés après l'annonce d'une importante vulnérabilité de type "zero-day".
En y regardant de plus près, la cause de cette anomalie est devenue évidente : les pots de miel.
Dans le domaine de la sécurité et des réseaux, un pot de miel est généralement un système ou un service stratégiquement conçu pour imiter des cibles réelles. Il s'agit d'attirer les acteurs de la menace pour qu'ils interagissent avec le service et que leurs activités puissent être surveillées.
À l'adresse Censys, nous avons remarqué une catégorie spécifique d'entités trompeuses de type pot de miel qui semblent conçues pour piéger les scanners Internet, comme nous l'avons déjà expliqué dans notre blog sur les " Red Herrings and Honeypots" (pièges à souris et pots de miel ). Ces services tentent d'émuler un grand nombre de produits logiciels différents et légitimes par le biais d'un seul service, ce qui rend la validation plus difficile en inondant les ensembles de données de faux positifs.
Le nombre de nouveaux hôtes Ivanti Connect Secure a été notre premier indice que quelque chose n'allait pas. Presque du jour au lendemain, le nombre total d'hôtes Connect Secure a doublé, ce qui est anormal pour un seul logiciel.
La différence entre le nombre d'hôtes et le nombre de services a été notre deuxième indice qu'il s'agissait probablement de pots de miel. Alors que le nombre d'hôtes et le nombre de services étaient proches au début de la période, le nombre de services a augmenté de manière disproportionnée par rapport au nombre d'hôtes au cours des jours suivants, ce qui indique que les hôtes créent plusieurs services, chacun étant signalé comme exécutant Ivanti Connect Secure. Dans le cadre d'un déploiement moyen de Connect Secure, seuls un ou deux services seront signalés comme exécutant ce logiciel.
Les noms de domaine figurant dans la section "Common Name" (CN) des certificats TLS de chaque service constituent un autre indice plus accablant. Chaque nom de domaine semblait déplacé et, dans certains cas, trop beau pour être vrai ; en d'autres termes, si les domaines étaient réels, il s'agirait de cibles de grande valeur telles que des serveurs de production sur des domaines de premier niveau gouvernementaux.
En combinant les deux derniers indicateurs clés ci-dessus, nous avons pu développer une logique simple permettant de classer ces hôtes comme trompeurs. La nature exacte de cette méthode sera expliquée plus loin dans ce billet.
CensysLe point de vue de l'entreprise sur les serveurs Ivanti Connect Secure actuels
Si l'on exclut les services trompeurs, la tendance est plus proche de ce à quoi nous nous attendions, montrant un déclin progressif des hôtes et des services au fur et à mesure que les organisations commencent à désactiver les instances. Le lundi 19 février, 2024 Censys a observé 24 590 passerelles exposées.
Carte des passerelles sécurisées Ivanti Connect exposées le 19 février 2024 (toutes ne sont pas nécessairement vulnérables)
Combien d'entre eux sont potentiellement vulnérables ?
Le graphique ci-dessous se concentre sur les instances qui montrent des indications d'exécution d'une version potentiellement vulnérable à l'une des 5 vulnérabilités récemment divulguées dans Ivanti Connect Secure (CVE-2023-46805, CVE-2024-21887, CVE-2024-21888, CVE-2024-21893, et CVE-2024-22024).
Le lundi 19 février, Censys a observé 6 000 passerelles Ivanti Connect Secure potentiellement vulnérables. Il est encourageant de constater que ce nombre a diminué de 56,5 % par rapport aux 13 970 instances potentiellement vulnérables observées le 31 janvier.
Les tendances de la figure ci-dessus correspondent également au calendrier des annonces de la CISA - remarquez la forte baisse qui suit la première mise à jour de la directive exécutive (DE) originale publiée le 31 janvier. Il y a un plateau relatif et un petit sursaut jusqu'au 9 février, jour où la CISA a publié sa deuxième mise à jour et fourni des conseils pour "tout déconnecter", après quoi le nombre de services vulnérables a recommencé à diminuer.
Depuis le 19 février, la concentration de ces passerelles vulnérables est particulièrement élevée aux États-Unis et au Japon :
Nombre d'entre eux fonctionnent sur un ensemble de grands réseaux japonais de télécommunications et de fournisseurs d'accès à Internet. L'essentiel de la présence américaine de ces hôtes est concentrée chez Akamai et Expedient, un fournisseur de services dans le nuage. NTT Communications, KDDI et Arteria Networks sont toutes de grandes entreprises japonaises de télécommunications et de réseaux.
La version vulnérable la plus courante d'Ivanti Connect Secure observée par Censys au moment de la rédaction est la 22.3.17. Il est inquiétant de constater que la version 8.3.7, en fin de vie, arrive en deuxième position. Cela suggère que ces cas peuvent être des hôtes anciens qui ont été négligés ou abandonnés.
Fouiller les hébergeurs trompeurs Maintenant que nous connaissons les hôtes réels qui sont exposés et qui exécutent des instances Ivanti Connect Secure potentiellement vulnérables, revenons sur les pots de miel.
Au départ, ces hôtes ont été identifiés comme des hôtes Ivanti Connect Secure sur Censys, étant donné que leurs corps de réponse HTTP contenaient tous les signes révélateurs d'un service Ivanti Connect Secure légitime. En d'autres termes, ce n'est qu'après un examen approfondi que l'on s'aperçoit qu'il s'agit d'une supercherie.
Ci-dessus, nous voyons que le 2 février, le nombre de faux services Ivanti Connect Secure a grimpé à plus de 17 000 hôtes, et c'est l'un des indicateurs clés qui nous donne une idée de l'ampleur de cette tromperie - une observation rare étant donné que cette augmentation s'est produite à peu près au même moment que l'annonce des vulnérabilités.
Se frayer un chemin à travers le bruit Nous avons utilisé trois indicateurs principaux pour déterminer ce qui était légitime et ce qui ne l'était pas.
Le nombre d'hôtes uniques exécutant Ivanti Connect Secure a doublé du jour au lendemain. L'écart entre le nombre d'hôtes et le nombre de services Ivanti Connect Secure (nombre d'hôtes par rapport au nombre de services) ne cesse de se creuser. Éléments de nom commun suspects dans le certificat TLS de chaque service.
Puisque nous avons déjà discuté de l'augmentation du nombre d'installations et de l'écart croissant entre le nombre d'hôtes et de services, examinons plus en détail les noms communs suspects que nous avons trouvés dans les certificats TLS.
dev.appliance.bright-manufacturing.mil
devo-hydro.state-medicine.ua
interne.thermique.première-finance.mil
pilot-vsphere.west-power.ua
private.sslvpn.city-oil.co.il
secret-kace.first-airforce.gov
staging.support.east-power.ca
pilote-sonicwall.south.oil.ca
À gauche, nous voyons quelques exemples de noms communs trouvés dans les certificats TLS de ces hôtes.
Il nous a semblé que ces noms étaient générés sur la base d'une liste prédéfinie de mots-clés. Plus précisément, des mots-clés stratégiquement choisis pour être remarquables dans le seul but d'attirer l'attention d'un attaquant.
Par exemple, nous avons constaté la présence de plusieurs domaines de premier niveau gouvernementaux et fédéraux, tels que ".gov" et ".mil", ainsi que des préfixes tels que "private", "dev" ou "prod" (désignant un système de développement ou de production privé). Tous ces éléments peuvent être considérés comme des cibles de grande valeur.
Une analyse plus approfondie de dizaines de milliers de ces noms communs "uniques" a fait apparaître un schéma dans la disposition de ces noms de domaine apparemment aléatoires. Tout d'abord, nous avons analysé chaque nom en sous-chaînes et noté leur position relative, par exemple, avec pilot-vsphere.west-power.ua:
Valeur Position de la sous-chaîne
pilote 1
vsphere 2
Ouest 3
pouvoir 4
ua TLD
Nous avons constaté que chaque sous-chaîne avait un ensemble prédéfini de valeurs potentielles pour sa position respective dans la chaîne. Vous pouvez observer que dans l'exemple de liste de noms de certificats fourni ci-dessus, le terme "pilote" apparaît exclusivement dans la position la plus à gauche de la chaîne de caractères (position 1). Il en va de même pour le terme "pilote" dans tous les noms communs que nous avons rencontrés.
Les deux diagrammes ci-dessous montrent les modèles que nous avons découverts et les positions respectives des jetons ("P1" à "P4" et le "TLD"). Cela signifie qu'un ensemble différent de mots a été utilisé pour chaque position afin de générer un nom de domaine entièrement qualifié. Que les jetons soient reliés par un point ou un trait d'union, le nombre de positions reste le même.
Vous trouverez ci-dessous un tableau dans lequel nous avons décomposé ces ensembles afin de générer les dix principaux éléments utilisés pour chaque position correspondante et le nombre de fois où nous avons observé chaque élément à cette position.
Position 1 - #Occurences Position 2 - #Occurences Position 3 - #Occurences Position 4 - #Occurences TLD - #Occurences
préprod
37,804
helpdesk
13,923
lumineux
46,555
huile
40,150
ua
66699
test
37,773
transporteur
13,896
Ouest
46,389
pouvoir
40,137
mil
66617
privé
37,621
documents
13,785
suivant
46,048
aéro
40,089
co.il
66610
corps
37,587
échange
13,727
Ville
46,047
banque
39,992
ca
66505
bêta
37,566
confluence
13,701
État
46,003
fabrication
39,941
nous
66470
interne
37,548
comptes
13,696
aujourd'hui
45,948
acier
39,924
gc.ca
66,432
développement
37,349
soutien
13,692
roman
45,946
marine
39,898
com
66,220
recherche
37,342
mfa
13,650
sud
45,934
électrique
39,839
org
65,941
devo
37,319
jira
13,622
à l'est
45,905
sécurité
39,786
Gouv.
65,522
pilote
37,216
l'emballage
13,620
principal
45,885
l'énergie
39,747
N/A
MOYENNE : 37,512.5 MOYENNE : 13,731.2 MOYENNE : 46066.0 MOYENNE : 39,950.3 MOYENNE : 66335.1
Comme nous pouvons le voir, les mots uniques utilisés dans leurs positions respectives ont une distribution assez uniforme, ce qui indique un générateur de nombres aléatoires décent, donnant encore plus de crédit au fait qu'il y avait un haut degré d'automatisation derrière la création et la mise en scène de ces hôtes. Vous trouverez ci-dessous un simple script Python qui imitera la fonctionnalité de base de ces noms de domaine (manifestement) générés par ordinateur.
import random
Importation du temps
p1_toks = ["preprod", "test", "private" "etc..."]
p2_toks = ["helpdesk", "converyor", "docs", "etc..."]
p3_toks = ["bright", "west", "next", "etc..."]
p4_toks = ["oil", "power", "aero", "etc..."]
tld_toks = ["ua", "mil", "co.il", "etc..."]
random.seed(time.time())
p1_tok = p1_toks[int(random.random()) % len(p1_toks)]
p2_tok = p2_toks[int(random.random()) % len(p2_toks)]
p3_tok = p3_toks[int(random.random()) % len(p3_toks)]
p4_tok = p4_toks[int(random.random()) % len(p4_toks)]
tld_tok = tld_toks[int(random.random()) % len(tld_toks)]
print(f"{p1_tok}.{p2_tok}.{p3_tok}-{p4_tok}.{tld_tok}")
De l'un à l'autre Censys a détecté pour la première fois un hôte solitaire utilisant Ivanti Connect Secure le 2 février. En l'espace d'une journée, le nombre d'hôtes est passé à 260 et a rapidement atteint un pic d'environ 17 900 hôtes le 7 février. La capacité à déployer un nombre aussi important d'hôtes en si peu de temps implique l'utilisation de ressources considérables, ce qui indique l'implication d'un acteur bien financé plutôt que d'un amateur.
Censys a commencé à étiqueter activement ces hôtes différemment le 15 février, après quoi leur nombre a légèrement diminué, mais il continue à persister.
Patient zéro Le 2 février 2024, nous avons vu pour la première fois un hôte avec le faux Ivanti Connect Secure fonctionnant avec les caractéristiques décrites dans la section précédente (les noms de domaine générés de manière aléatoire).
IP 52.40.12.180
Port 2096
Système autonome AMAZON-02 (AS16509)
Pays États-Unis
Version Nul (pas de hachage du corps)
Titre HTML Ivanti Connect Secure
Nom commun du certificat staging.siemens.today-oil.ca
Ce service présente quelques aspects intéressants :
Il est hébergé sur un port apparemment aléatoire qui s'écarte du comportement normal - la grande majorité des passerelles Ivanti Connect Secure réelles sont concentrées sur le port 443, comme le montre ce graphique :
L'hôte se trouve dans AMAZON-02, l'un des réseaux AWS les plus importants. C'est également là que les pots de miel étaient concentrés la dernière fois que nous avons écrit à leur sujet .
Le nom commun du certificat suscite quelques soupçons. À première vue, il s'agit d'un certificat légitime, mais si l'on y regarde de plus près, le nom commun est une combinaison inhabituelle de mots pour le domaine racine et les sous-domaines.
En isolant les hôtes qui suivent ce modèle de dénomination de certificat, voici comment la répartition des hôtes de pots de miel sur les réseaux a évolué au fil du temps :
Étant donné que la majorité de ces services sont hébergés sur AWS, il est difficile d'identifier un propriétaire spécifique. Néanmoins, un petit sous-ensemble d'hôtes était situé dans les systèmes autonomes `Ningxia West Cloud` et `BJ-GUANGHUAN`, qui servent de fournisseurs de transit d'AWS en Chine. Ce seul fait suggère l'implication d'une organisation ayant des liens avec la Chine, puisque le titulaire du compte devrait avoir une licence commerciale officiellement enregistrée en Chine pour créer des hôtes dans ces systèmes autonomes spécifiques adjacents à AWS.
Il y a d'autres signes assez évidents qui indiquent qu'il s'agit d'un faux :
1. Tendances du nombre d'hôtes en miroir dans ~10 pays :
La figure ci-dessous montre l'évolution de la géolocalisation IP de ces hôtes :
Remarquez qu'il semble y avoir environ 10 pays qui ont tous des tendances remarquablement similaires en ce qui concerne le nombre d'hôtes. Ce schéma suggère que ces hôtes ont été systématiquement déployés et surveillés dans chaque pays, probablement à l'aide d'un script.
2. Titre HTML uniforme, pas de versions
Tous ont exactement le même titre HTML : "Ivanti Connect Secure", et aucune version n'a pu être extraite d'aucune d'entre elles. Ces caractéristiques communes renforcent notre suspicion d'un comportement "généré par un script".
3. Augmentation rapide du nombre de ports par hôte
Au fil du temps, le nombre moyen de ports sur chaque hôte équipé d'Ivanti Connect Secure a quadruplé, passant de 1 à 4, comme le montre la figure ci-dessous. Il est peu probable qu'un hôte légitime moyen fasse fonctionner la passerelle VPN sur 4 ports distincts simultanément, ou qu'il augmente le nombre de ports au fur et à mesure que des vulnérabilités majeures sont découvertes.
4. Rotation fréquente des certificats
Nous avons voulu savoir si ces hôtes mettaient régulièrement à jour leurs certificats ou modifiaient leurs noms. Bien que les motivations pour une rotation fréquente des certificats varient, dans le contexte des hôtes trompeurs, une hypothèse plausible est qu'ils le feraient pour ajouter un aspect dynamique qui rendrait plus difficile la distinction entre les vrais et les faux systèmes, ce qui permettrait d'échapper plus longtemps à la détection.
Le graphique ci-dessous illustre la distribution du nombre de certificats uniques observés sur un seul port pendant toute la période analysée (du 31 janvier au 19 février).
Nom commun distinct 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Nombre de services 16323 22465 23965 22935 19744 15552 10575 6547 3959 2007 797 347 152 42 25 8 6
Sur une période de 20 jours, Censys a enregistré une moyenne de 4 certificats uniques présentés sur un seul port, avec trois services spécifiques affichant jusqu'à 17 certificats différents. Ce taux de renouvellement n'est pas habituel et suggère que quelque chose d'inhabituel se passe ici. Encore une fois, en l'absence de preuves plus définitives, il s'agit simplement d'une intuition, mais elle s'inscrit dans la lignée de nos autres observations.
Ce modèle spécifique d'hôtes de pots de miel n'est pas exclusif à Ivanti Connect Secure. Nous avons remarqué des hôtes similaires qui semblent utiliser des logiciels liés à d'autres annonces récentes de vulnérabilités. Il est difficile à ce stade d'identifier les responsables, mais les preuves s'accumulent qu'ils agissent délibérément. Nous resterons attentifs à l'évolution de la situation. 🔎
Que peut-on faire ? Remédiation aux vulnérabilités d'Ivanti Connect Secure 