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
