Résumé :
- Cisco Talos a identifié trois jours zéro dans deux produits de pare-feu Cisco dans le cadre d'une enquête sur une campagne plus large d'acteurs de la menace appelée "ArcaneDoor" qui a ciblé des dispositifs de réseaux périmétriques appartenant à des gouvernements dans le monde entier, avec une exploitation remontant à janvier 2024.
- Les vulnérabilités de type "zero day" identifiées sont les suivantes : CVE-2024-20353, CVE-2024-20359 et CVE-2024-20358. Seules les vulnérabilités CVE-2024-20353 et CVE-2024-20359 ont été exploitées dans le cadre de la campagne ArcaneDoor.
- Bien que le vecteur d'accès initial utilisé pour cette campagne soit encore inconnu, Cisco a publié des mises à jour logicielles et a fourni des étapes permettant aux clients de vérifier l'intégrité de leurs dispositifs de pare-feu Cisco dans leur avis de réponse à l'événement.
- Lorsque nous avons examiné les adresses IP contrôlées par des acteurs et fournies par Talos dans les données Censys et que nous les avons recoupées avec d'autres indicateurs de certificats, nous avons découvert des données convaincantes suggérant l'implication potentielle d'un acteur basé en Chine, notamment des liens avec plusieurs grands réseaux chinois et la présence d'un logiciel anti-censure développé par des Chinois. Il est difficile de tirer des conclusions définitives à ce stade.
Au fur et à mesure que l'enquête sur ArcaneDoor se poursuit, d'autres données sur les victimes de ces attaques devraient apparaître. Dans l'intervalle, veuillez consulter notre avis de réponse rapide pour obtenir des informations complètes sur l'ampleur des appareils Cisco ASA exposés et des conseils sur la remédiation.
Comprendre la campagne ArcaneDoor
Le 24 avril, Cisco Talos a publié un rapport faisant la lumière sur une campagne menée par un acteur de menace parrainé par un État jusqu'alors inconnu, connu sous le nom de "UAT4356". Cette campagne, baptisée "ArcaneDoor", visait les dispositifs de réseaux périmétriques appartenant aux gouvernements et provenant de divers fournisseurs, dans le cadre d'un effort mondial.
L'enquête de Talos a révélé que l'infrastructure de l'acteur a été établie entre novembre et décembre 2023, l'activité initiale ayant été détectée pour la première fois au début du mois de janvier 2024. Bien que le vecteur d'accès initial utilisé dans cette campagne reste inconnu, Talos a découvert trois vulnérabilités zero-day affectant les logiciels Cisco Adaptive Security Appliance (ASA) et Cisco Firepower Threat Defense (FTD) qui ont été exploitées dans le cadre de la chaîne d'attaque : CVE-2024-20353, CVE-2024-20359 et CVE-2024-20358.
Analyse de l'infrastructure des acteurs de la menace de l'UAT4356
Dans son excellente enquête sur ArcaneDoor en collaboration avec d'autres organisations, Talos a partagé quelques indicateurs intéressants au sein de l'infrastructure de l'attaquant exploitée par UAT4356 dans cette campagne.
Examen des indicateurs de certificats associés :
Indicateurs de certificat et de logiciel de l'UAT4356(Source)
Talos a identifié un modèle spécifique dans les noms de l'émetteur et du sujet des certificats SSL :
Modèle de certificat :
:issuer = O=ocserv,CN=ocserv VPN
:selfsigned = true
:serial = 0000000000000000000000000000000000000002
:subject = O=ocserv,CN=ocserv VPN
:version = v3
"Ocserv" est associé à OpenConnect VPN Server, un client VPN open-source couramment utilisé pour se connecter à des VPN tels que Cisco ASA. Il est plausible qu'OpenConnect ait été utilisé par l'acteur de la menace pour se connecter initialement aux périphériques réseau ciblés et réaliser cette chaîne d'exploitation.
En date du 29 avril 2024, seuls 5 hôtes étaient en ligne et présentaient ce certificat sur Censys:
services : (tls.certificate.parsed.issuer_dn : "O=ocserv,CN=ocserv VPN" et tls.certificate.parsed.subject_dn : "O=ocserv,CN=ocserv VPN")
Hôtes présentant des certificats associés à "ocserv" dans Censys le 29 avril 2024
Le fait qu'il y ait si peu d'hôtes présentant ce certificat peut signifier plusieurs choses, mais c'est néanmoins significatif. Lorsqu'un pivot Censys ne donne qu'une poignée de résultats, chaque hôte revêt une plus grande importance - cela signifie que vous êtes tombé sur quelque chose de particulier dans une enquête.
Sur cette capture d'écran, vous remarquerez que certains de ces hôtes semblent également utiliser le logiciel ou le système d'exploitation ASA, ce qui correspond aux observations de Talos. Voici les identifiants CPE uniques associés à l'ASA sur ces hôtes :
cpe:2.3:h:cisco:adaptive_security_appliance:*:*:*:*:*:*:*:*
cpe:2.3:o:cisco:adaptive_security_appliance_software:*:*:*:*:*:*:*:*
Nous avons déterminé que ces hôtes exécutaient ASA sur la base de divers indicateurs, notamment la présence d'un en-tête de réponse HTTP Set-Cookie contenant la chaîne de caractères suivante webvpncontextune caractéristique associée à l'ASA.
Cela soulève la question suivante : pourquoi ces hôtes semblent-ils utiliser Cisco ASA, l'un des logiciels qu'ils ont tenté d'exploiter ? Ce logiciel est-il impliqué d'une manière ou d'une autre dans les méthodes utilisées pour réaliser l'exploit, ou s'agit-il d'une tentative d'obscurcissement de leur infrastructure ?
Un autre indice notable est la répartition de ces hôtes entre différents systèmes autonomes.
Réseaux hébergeant des IP affichant des indicateurs de certificat "ocserv
| Système autonome |
Nombre d'hôtes |
| TENCENT-NET-AP Shenzhen Tencent Computer Systems Company Limited (45090) |
2 |
| AS-CHOOPA (20473) |
1 |
| CHINANET-BACKBONE No.31,Jin-rong Street (4134) |
1 |
| TENCENT-NET-AP-CN Tencent Building, Kejizhongyi Avenue (132203) |
1 |
Quatre des cinq hôtes sont basés en Chine. "TENCENT-NET-AP" est associé à Tencent, un conglomérat multinational chinois dont le siège se trouve à Shenzhen, tandis que "CHINANET-BACKBONE" est géré par ChinaNet, une importante société de télécommunications chinoise. Des réseaux tels que Tencent et ChinaNet ont une portée et des ressources étendues, et il serait donc logique qu'ils soient choisis comme infrastructure pour une opération mondiale sophistiquée comme celle-ci.
Enquête sur les IP contrôlés par des acteurs :
Examinons maintenant la liste des 22 adresses IP potentiellement contrôlées par des acteurs, fournie par Talos, et connectons-les à Censys. L'analyse de l'infrastructure de l'attaquant s'avère plus avantageuse que celle de l'infrastructure partagée, car il est plus facile d'isoler les caractéristiques distinctives propres au comportement de l'acteur de la menace.
Le lundi 29 avril 2024, 11 des 22 hôtes initialement fournis par Talos restaient en ligne dans les analyses Censys , ce qui indique une activité continue au sein de l'infrastructure identifiée.
Voyons d'abord dans quels réseaux ces hôtes sont concentrés :
- GHOST: fournisseur de services en nuage basé au Luxembourg et associé à G-Core Labs S.A.
- AS-CHOOPA: Un réseau connu pour ses services de réseau à haute performance, également connu sous le nom de Vultr
- ACCELERATED-IT: Fournisseur d'internet accéléré ou à haut débit.
- AKAMAI-LINODE: Infrastructure informatique en nuage d'Akamai.
- ASNET: Une entité au nom générique, apparemment détenue par "Baxet Group Inc.".
- LIMESTONENETWORKS: Un fournisseur d'hébergement basé à Dallas, Texas.
- LES INDUSTRIES DE L'ÉTOILE: Un système autonome russe qui fonctionnerait comme un fournisseur d'hébergement à l'épreuve des balles
- TSRDC-AS-AP Truxgo S. R.L. de C.V: géant des télécommunications basé au Mexique.
Lorsque nous générons un rapport sur les noms communs des émetteurs des certificats de ces hôtes, nous obtenons des résultats intéressants :
Si bon nombre de ces certificats semblent familiers, certains le sont moins au premier abord.
En premier lieu : WIN-16HD0VMNND5. Après quelques recherches, il semble qu'il s'agisse d'un certificat RDP auto-généré - ce qui est corroboré par le fait que lorsque nous recherchons des hôtes avec des certificats similaires dans Censys (services.tls.certificates.leaf_data.subject_dn : "CN=WIN-*"), ils se trouvent principalement sur des services RDP.
lke155316-227342-104695750000-ca@1707338035: Ce nom semble généré par une machine et correspond à un modèle observé dans les certificats d'hôtes LINODE d'Akamai(services.tls.certificates.leaf_data.subject_dn : "CN=lke*").
Parmi ces certificats, un nom commun se distingue par son originalité : Gozargah. Au départ, ce terme ne nous était pas familier.
De plus, les deux services qui le présentent sont tous deux sur cet hôte : 212.193.2[.]48 basé dans un réseau appelé ASNET, et tous deux apparaissent comme des services "UNKNOWN" dans nos données sur les ports TCP 3630 et 3631, ce qui signifie qu'ils ne correspondent à aucune spécification de protocole que nous connaissons.
La recherche de "Gozargah" dans un moteur de recherche web nous amène à cette organisation GitHub : https://github.com/Gozargah.
Leur repo épinglé s'appelle "Marzban"(https://github.com/Gozargah/Marzban), décrit comme "Unified GUI Censorship Resistant Solution Powered by Xray" (solution unifiée d'interface graphique résistante à la censure développée par Xray).
Qu'est-ce que "Xray" ?
Il s'agit de ce projet open source : https://github.com/XTLS/Xray-core qui semble avoir été développé par une communauté appelée "Project X" qui existe depuis 2020 : https://xtls.github.io/. Sa description est la suivante : "Xray, pénètre tout. Egalement le meilleur v2ray-core, avec support XTLS. Configuration entièrement compatible".
La majeure partie de la page GitHub du projet X est rédigée en chinois.
XTLS, ou Extended Transport Layer Security, est une extension de TLS 1.3 qui utilise des techniques cryptographiques plus avancées, obscurcit sa signature de protocole (ce qui la rend plus difficile à identifier) et permet de dissimuler l'accès à un point d'extrémité VPN. Il est logique qu'il soit utilisé dans les outils de lutte contre la censure, puisqu'il est le plus souvent utilisé pour contourner les pare-feux. Étant donné qu'il a été mis au point par des développeurs chinois, il est évident qu'il a été créé dans le but de contourner The Great Firewall (le grand pare-feu), ou le pare-feu national géré par le gouvernement chinois.
Lorsque nous examinons les autres hôtes portant le nom commun de certificat "Gozargah", nous constatons qu'environ 4 800 adresses IP visibles sur Censys présentent ce certificat(services.tls.certificates.leaf_data.issuer.common_name="Gozargah"). Il est intéressant de noter que les ports 3630 et 3631 ne figurent pas dans la liste des 20 premiers ports communs - il semble que les TCP 62050 et 62051 soient plus populaires pour ce service. Il n'y a que 2 autres hôtes avec ce nom commun de certificat qui ont les mêmes ports 3630 et 3631 ouverts.
C'est intéressant, mais cela l'est encore plus lorsque l'on examine l'un des hôtes présentant un certificat avec un issuer_dn "ocserv" signalé comme indicateur par Talos : https://search.censys.io/hosts/54.179.113.92.
Sur le port TCP 8888, cet hôte exécute un service HTTP avec un titre HTML : "Trojan Panel"
Il semble que cela soit lié à ce projet GitHub appelé "trojanpanel", qui possède également un site web rédigé en grande partie en chinois :
Il se décrit comme un "panneau de gestion web multi-utilisateurs prenant en charge Xray/Trojan-Go/Hysteria/NaiveProxy".
Cela fait deux mentions de cet outil "Xray" lié à des services fonctionnant sur cette infrastructure.
Résumons les preuves que nous avons recueillies jusqu'à présent: en croisant les IP contrôlées par les acteurs et d'autres indicateurs de certificats identifiés par Talos avec les données de Censys , nous avons découvert que (a) certains de ces hôtes exécutaient des services associés à des logiciels anti-censure probablement destinés à contourner le Grand Firewall, et (b) qu'un nombre important de ces hôtes sont basés dans des réseaux chinois de premier plan.
Que signifie tout cela ?
Les indices les plus probants quant à l'identité de l'auteur potentiel de cette campagne proviennent de l'analyse des adresses IP contrôlées par les acteurs sur le site Censys, ainsi que de l'analyse d'autres hôtes présentant les indicateurs de certificat signalés par Talos.
Les résultats de cette enquête préliminaire montrent quelques indications qu'il pourrait s'agir de l'œuvre d'un acteur basé en Chine. Il est possible que nous constations une activité continue et/ou des changements au niveau de ces hôtes dans nos données au cours des prochains jours.
Pour déterminer si les cyberattaques sont commanditées par des États, il faut adopter une approche globale. Si l'analyse des réseaux hébergeant l'infrastructure de l'acteur de la menace est une pièce du puzzle, d'autres facteurs doivent être pris en compte, tels que les méthodes d'attaque, les victimes et le contexte géopolitique. La nature obscure de l'identité de cet acteur de la menace, combinée au fait que le vecteur d'accès initial utilisé dans cette campagne est encore inconnu, est une raison de continuer à surveiller la situation.
Il est probable que l'enquête se poursuive au fur et à mesure que nous obtenons plus de détails sur les cibles de ces attaques. En attendant, veuillez vous référer à notre avis de réponse rapide pour plus de détails sur l'étendue des appareils Cisco ASA exposés et les conseils de remédiation.
