Alerte du CERT : vulnérabilités zero-day dans des logiciels Ivanti Connect Secure

• Nouvelle version de l’outil de contrôle d’intégrité externe (ICT) publié par Ivanti le 27 février 2024, plus complet car vérifiant les répertoires auparavant outrepassés.
• Cette version est fortement recommandée, mais génère des Faux Positifs (alertes sur la présence de nouveaux fichiers inoffensifs sur l’équipement).
• Tous les serveurs gérés par OCD ont été analysés avec cet outil.
• CISA a publié un nouveau bulletin d’alerte montrant comment persister sur une machine compromise sans être détecté par l’ICT (en laboratoire).
• Ivanti a infirmé cette découverte, qui n’est selon eux pas possible en conditions réelles.
• Mandiant a publié en 3e blog technique, décrivant l’attaquant baptisé UNC5325, responsable de la 2e vague de compromissions via la 0-day CVE-2024-21893, et ce dès le 19 janvier 2024.
• Des détails (et IOCs) sur les variantes de malware utilisés sont fournis.
• UNC5325 est très probablement lié à UNC5221 (derrière la première vague d’exploitation mi-janvier), mais également avec une confiance moindre à un autre groupe chinois utilisant des 0-days sur ce type de produits : UNC3886.
• Le risque demeure inchangé (élevé i.e. 4 sur 5) : aucune nouvelle vulnérabilité n’étant révélée, mais des attaques opportunistes continuant d’être identifiées par nos équipes.

• Nouveaux correctifs publiés pour des versions des produits Ivanti impactés le 14 février 2024.
• L’ICT interne exclut certains dossiers, offrant ainsi certaines possibilités d’échapper à la détection.
• Plusieurs composants obsolètes trouvés dans la solution.
• Visibilité à distance sur les instances actuellement compromises perdue désormais.
• Orange Cyberdefense a diminué le niveau de risque de cette menace, même si quelques attaques opportunistes sont encore enregistrées.

Recommandations

Ivanti a publié des correctifs pour toutes les versions prises en charge des produits Ivanti concernés. Cela signifie que les équipes peuvent désormais déployer des correctifs pour ces versions qui n’étaient protégées jusqu’alors que par des mesures d’atténuation basées sur un fichier de configuration XML.

Veuillez appliquer ces correctifs, et sinon, laisser la mesure d’atténuation basée sur XML en place.

Veuillez également lire attentivement les instructions de mise à niveau d’Ivanti pour vous assurer que tous les scénarios possibles sont couverts et que l’appareil n’est pas laissé dans un état compromis après le déploiement des correctifs.

Si vous suspectez qu’un appareil Ivanti est compromis, il est préférable de contacter une équipe de réponse à incident pour garantir que l’appareil est correctement analysé et nettoyé. Si tel est le cas, veuillez contacter notre ligne d’assistance en réponse aux incidents. Nous pouvons vous aider à évaluer si votre instance a effectivement été compromise et, si tel est le cas, vous accompagner pour également effectuer une réinitialisation aux paramètres d’usine conformément aux instructions d’Ivanti et appliquer deux fois consécutivement les correctifs pour vous assurer qu’ils ont bien été déployés. Restaurez enfin la configuration de sauvegarde sur l’appareil fraîchement ré-installé.

Attaques

Des attaques opportunistes sont encore observées. Elles tentent principalement de déployer des cryptominers sur des instances vulnérables. De plus, une société de sécurité nommée Eclypsium a publiquement mentionné que l’ICT exclut plusieurs dossiers (peut-être pour éviter les faux positifs), laissant ainsi une possibilité de persistance post-exploitation aux attaquants qui peuvent spécifiquement localiser leurs portes dérobées dans ces répertoires (/data, /etc, /tmp, /var, etc.).

Cependant, le risque associé à la menace pesant sur les solutions Ivanti a été réduit grâce à la disponibilité de correctifs pour toutes les versions de Ivanti Connect Secure, Ivanti Policy Secure et ZTA. Moins de 200 instances piratées (au cours de la semaine se terminant le 17 février) exposent encore publiquement le fichier malveillant « index2.txt » lié à la porte dérobée découverte par le CERT d’Orange Cyberdefense. Cependant, on peut supposer qu’un plus grand nombre d’appareils restent compromis, certains même depuis la première phase d’exploitation de masse qui a débuté à la mi-janvier 2024.

Nous partageons les recherches de notre CERT dans un article de blog dédié à la backdoor « DSLog », à retrouver ici.

Pour en savoir plus sur la backdoor découverte dans DSLog, vous pouvez également télécharger le rapport d’enquête au format PDF.

Ce que nous faisons

Tous les clients des services gérés par Orange Cyberdefense sont protégés, car nos équipes dédiées ont appliqué les recommandations du fournisseur dès le premier jour. Les SOC d’Orange Cyberdefense mènent des enquêtes de manière proactive pour les clients bénéficiant de ce service. Les clients concernés seront informés si un comportement suspect est identifié.

• Deux nouvelles vulnérabilités, CVE-2024-21888 et CVE-2024-21893, ont été divulguées en plus des vulnérabilités précédemment divulguées.
• Ivanti a publié des correctifs le 31 janvier 2024 pour un nombre limité de versions des produits concernés. Ils corrigent les 4 vulnérabilités connues.
• De nouvelles mesures d’atténuation basées sur XML ont été publiées pour corriger les 2 nouvelles vulnérabilités connues également.
• Ivanti a publié un nouvel outil de vérification d’intégrité externe (ICT)  qui peut être utilisé pour détecter les appareils Ivanti compromis.
• L’exploitation active et en masse des vulnérabilités se poursuit.
• Orange Cyberdefense a déjà contacté des clients dont les produits Ivanti concernés sont gérés ou co-gérés par Orange Cyberdefense afin d’appliquer des corrections ou des mesures d’atténuation sur les appareils.
• Au 31 janvier 2024, les analyses d’Orange Cyberdefense montrent que sur les 24 986 appareils Ivanti exposés sur Internet :
  • 20 674 appareils ont appliqué des mesures d’atténuation basées sur XML
  • 3 254 appareils sont vulnérables,
  • 451 ont appliqué des mesures d’atténuation basées sur XML, mais peuvent avoir été compromis avant que les mesures d’atténuation n’aient été appliquées,
  • 684 ont été compromis sans doute possible,
  • et 680 appareils ont divulgué des données sensibles via le logo/login.gif.

• La CISA ordonne aux agences fédérales de déconnecter tous les appareils Ivanti concernés et de les nettoyer avant de les réinstaller.
• La vulnérabilité Ivanti Server-Side Request Forgery, CVE-2024-21893, est utilisée pour créer une porte dérobée jusqu’alors inconnue et intéressante.
• L’accès à cette porte dérobée est contrôlé via un mécanisme de base par « clé API ».
• L’attaquant effectue une injection de commandes avec des privilèges élevés.
• Orange Cyberdefense continue de surveiller, d’enquêter sur et de signaler les activités associées à l’exploitation des vulnérabilités Ivanti récemment révélées.
• Un nouveau correctif est disponible pour une vulnérabilité récemment divulguée, CVE-2024-22024, pour des versions spécifiques des passerelles Ivanti Connect Secure, Ivanti Policy Secure et ZTA.
• Les mesures d’atténuation basées sur XML existantes protègent contre l’exploitation de CVE-2024-22024.
• La vulnérabilité n’est liée à aucun acteur malveillant connu ou à aucune activité d’exploitation actuelle.

Recommandations

Veuillez appliquer le correctif, car il corrige la dernière vulnérabilité révélée, CVE-2024-22024, et les quatre vulnérabilités précédemment divulguées.

Selon Ivanti, les mesures d’atténuation basées sur XML existantes (mitigation.release.20240126.5.xml) protègent déjà contre l’exploitation de CVE-2024-22024. 

Selon Ivanti, une réinitialisation aux paramètres d’usine n’est pas nécessaire pour corriger CVE-2024-22024 si elle a déjà été effectuée précédemment. De plus, 2 opérations de réinitialisation aux paramètres d’usine consécutives, comme nous l’avons mentionné, sont inutiles. Mais une double application des mises à niveau du 31 janvier reste recommandée.

Une investigation supplémentaire peut être effectuée à l’aide des IOCs réseau/hôte (disponibles pour nos clients MTD et MTI via le Datalake d’Orange Cyberdefense), des règles de détection ou encore une analyse des comportements suspects directement dans les journaux ou sur l’appareil. Faites également attention à la façon dont les appareils sont configurés, car ils peuvent être en mode actif-passif et/ou impliquer un groupe d’appareils et peuvent nécessiter certaines étapes pour garantir une enquête approfondie. Nous pouvons vous aider à évaluer si votre instance a effectivement été compromise et, si tel est le cas, veuillez contacter notre ligne d’assistance de réponse aux incidents.

Actions supplémentaires recommandées (mises à jour le 8 février 2024)

La CISA a exhorté les agences fédérales à déconnecter et à réinitialiser aux paramètres d’usine tous leurs appareils [source]. Ivanti et Mandiant recommandent désormais 2 mises à niveau consécutives [source] pour éviter une éventuelle restauration future qui remettrait l’appareil dans son état « compromis » précédent. Cela garantit que les instances sont effectivement propres. Ce processus de résolution extrême peut sembler superflu, mais à défaut de donner la priorité aux correctifs, vous pouvez au moins appliquer la mesure d’atténuation plus tôt que la réinitialisation aux paramètres d’usine plus tard. Une réinitialisation aux paramètres d’usine avec des correctifs complets est recommandée lorsqu’un appareil a été compromis ou si votre organisation est ciblée spécifiquement par l’acteur malveillant chinois derrière ces vulnérabilités.

Il est fortement recommandé de suivre le processus d’Ivanti et d’appliquer soit la nouvelle mesure d’atténuation basée sur XML, soit idéalement les correctifs publiés le 31 janvier 2024 [source]. Les correctifs sont actuellement limités à quelques versions. Ainsi, s’il manque un correctif pour votre version, appliquez la mesure d’atténuation basée sur XML et vérifiez régulièrement si la version spécifique a reçu un correctif.

Il n’est pas garanti que les analyses avec l’outil de vérification d’intégrité (ICT) d’Ivanti révèlent toutes les compromissions. Elles peuvent passer à côté d’éventuels dangers, mais restent la source de détection la plus efficace. Si :

• votre appareil a reçu une mesure d’atténuation dès le début (vers le 11 janvier 2024)
• aucune analyse d’ICT historique ni analyse d’ICT externe ad hoc n’a révélé de signes de compromission,
• et aucun autre comportement suspect, c’est-à-dire dans les IOCs, les journaux ou les alertes des solutions de sécurité dans le reste de l’infrastructure.

alors, l’appareil n’est probablement pas compromis. Néanmoins, il est recommandé de continuer à rechercher des signes de compromission, en analysant régulièrement l’appareil avec l’ICT interne/externe et en utilisant les derniers IOCs disponibles.

Un instantané du système et un extrait de la mémoire et des données de journal pertinentes sont recommandés avant d’exécuter l’analyse externe avec l’ICT, car ce dernier redémarre l’appareil [source]. Pensez à activer la journalisation avancée, car cela pourrait améliorer la détection. Cette journalisation de niveau débogage (y compris les requêtes non authentifiées) n’est pas activée par défaut en raison de problèmes de performances potentiels.

Un plan de réponse aux incidents doit être activé si un appareil compromis est identifié. Ce plan peut comprendre :

• isoler l’appareil des autres systèmes
• lancer un audit des comptes privilégiés récemment créés ou modifiés
• révoquer les informations d’identification, y compris les certificats ou les mots de passe éventuellement exposés
• surveiller les tentatives d’authentification suspectes
• enquêter sur et trouver des anomalies dans les services ou les appareils précédemment connectés à l’appareil Ivanti

Une enquête supplémentaire peut être effectuée à l’aide des IOCs réseau/hôte ci-dessous (ou la liste complète disponible uniquement pour nos clients MTD/MTI via le Datalake d’Orange Cyberdefense), des règles de détection ou encore une analyse des comportements suspects directement dans les journaux ou sur l’appareil.

Faites également attention à la façon dont les appareils Ivanti sont configurés, car ils peuvent être en mode actif-passif et/ou impliquer un groupe d’appareils et peuvent nécessiter certaines étapes pour garantir une enquête approfondie. Nous pouvons vous aider à évaluer si votre instance a effectivement été compromise et, si tel est le cas, veuillez contacter notre ligne d’assistance de réponse aux incidents.

Ivanti a publié des détails et des correctifs corrigeant une nouvelle vulnérabilité de haute gravité [source] présente dans Connect Secure (et Policy Secure), suivie sous le nom de CVE-2024-22024 (lien [source] pour nos clients). Un attaquant distant pourrait l’exploiter en envoyant un fichier XML spécialement conçu pour accéder à des ressources spécifiques sans authentification SAML. 

Watchtowr Labs [source] a publié des informations détaillées expliquant les points de terminaison vulnérables (en particulier : « /dana-na/auth/saml-sso.cgi »), sans fournir directement une preuve de concept entièrement fonctionnelle pour les pirates de bas niveau. Des attaquants de niveau avancé pourraient néanmoins exploiter ces informations pour réussir à pirater des appareils non corrigés. De plus, Watchtowr a expliqué que le problème vient d’une régression introduite par Ivanti le 31 janvier, lors de la correction des 4 vulnérabilités précédentes dont nous avons déjà parlé. Nous ne pensons donc pas que cette vulnérabilité soit exploitée activement pour le moment, mais elle peut également être chaînée avec l’un des bugs d’injection de commandes existant dans le produit. Un correctif est donc disponible pour toutes les versions prises en charge. Il inclut (si besoin) les correctifs des 4 vulnérabilités évoquées précédemment.

Un module Metasploit [source] qui enchaîne le précédent contournement d’authentification SAML 0-day (CVE-2024-21893) avec l’injection de commande (CVE-2024-21887) est désormais accessible au public, ce qui facilite davantage le lancement par des pirates peu qualifiés d’attaques automatisées contre des appareils non protégés (qui n’ont reçu aucune mesure d’atténuation ou correctif).

Statistiques et porte dérobéee dans DSLog

Le nombre d’instances vulnérables diminue, comme le montre ShadowServer [source]. De plus, le nombre d’instances compromises et intégrant une porte dérobée dans DSlog.pm ne cesse de diminuer selon nos analyses quotidiennes : moins de 500 appareils sont encore accessibles à distance aujourd’hui. Nous avons averti de manière proactive nos clients identifiés dans cette liste.

Nous avons également fourni des détails techniques sur cette porte dérobée dans un rapport public disponible ici [source]. Comme nous l’avons déjà indiqué, nous avons indirectement détecté ces compromissions : c’est-à-dire passivement, avec de simples requêtes GET non authentifiées adressées aux fichiers illégitimes créés par la porte dérobée et situés à l’adresse : « /root/home/webserver/htdocs/dana-na/imgs/index2[.]txt ».

Vulnérabilités

Jeudi soir, nous pensions être face au début d’une nouvelle exploitation massive. Il s’agissait cependant de faux positifs générés par les contrôles de l’ICT interne, exécutés par défaut toutes les deux heures. Ces vérifications détectaient les nouveaux fichiers du package chargé sur l’appareil lors de sa mise à niveau. Néanmoins, l’exploitation active par des attaquants opportunistes a commencé le 2 février 2024, juste après que Rapid7 [source] et AssetNote [source] ont révélé publiquement comment la vulnérabilité SAML 0-day (CVE-2024-21893) fonctionnait, en publiant une preuve de concept (PoC) fonctionnelle que n’importe qui pouvait utiliser. Le CERT d’Orange Cyberdefense a identifié les attaques quelques heures seulement après cette publication. On a trouvé, par exemple, une activité impliquant des variantes de botnet basées sur Mirai qui étaient déposées sur des instances compromises par des acteurs malveillants opportunistes.

La vulnérabilité SAML 0-day est liée à une bibliothèque open source tierce, la dépendance « xmltooling », maintenue par Shibboleth [source]. Ce composant était en effet vulnérable à une faille SSRF corrigée en juin 2023 et suivie sous le nom de CVE-2023-36661 (pour nos clients : Vulnerability Intelligence Watch).

Les points de terminaison vulnérables, qui transmettent au « saml-server » un XML spécialement forgé, peuvent inclure :

• /dana-ws/saml.ws,
• /dana-ws/saml20.ws,
• /dana-ws/samlecp.ws,
• /dana-na/auth/saml-sso.cgi
• /dana-na/auth/saml-logout.cgi
• /dana-na/auth/saml-consumer.cgi
• Etc.

Lorsqu’elle est traitée par xmltooling à l’aide de la fonction « XMLToolingFIPS.XMLObject.Signature », la requête mal formée donnera à l’attaquant distant non authentifié un accès à la machine. L’exploit peut être enchaîné avec la première injection de commande 0-day (CVE-2024-21887) directement depuis l’appareil (c’est-à-dire via « 127.0.0.1/api/v1/license/keys-status ») pour contourner la mesure d’atténuation initiale via XML.

Actifs compromis

Depuis le début de cette crise, le CERT d’Orange Cyberdefense tente d’identifier les instances vulnérables ou compromises, en utilisant les différences dans les réponses lors de la requête auprès de certains fichiers ou points de terminaison (c’est-à-dire la réponse 403 « empty » [source], le webshell GIFTEDVISITOR, le faux fichier logo/login.gif, etc.). Après avoir analysé une instance compromise par rapport à une instance propre, le CERT a découvert qu’une backdoor a été créée pour les journaux de traitement de module légitimes (DSlog.pm) et que les données non sensibles concernant l’appareil avaient été transférées dans un fichier .txt nouvellement créé. Le CERT a identifié les actifs affichant ce comportement et a trouvé plusieurs instances potentiellement infectées à l’aide de cette porte dérobée.

Pour rappel, la technique d’analyse originale « 403 - Forbidden: empty response » décrite ci-dessus, qui a été utilisée pour évaluer si la mesure d’atténuation basée sur XML initiale était appliquée ou non, ne doit plus être utilisée puisque les correctifs sont disponibles. Les instances déjà mises à niveau n’ont plus besoin de la mesure d’atténuation basée sur XML et ne sont pas vues comme vulnérables.

Un chercheur sur X (ex-Twitter) a expliqué une autre technique [source] pour vérifier à distance si une instance a été détournée en utilisant la vulnérabilité SAML 0-day avec la réponse d’une autre requête. Le CERT d’Orange Cyberdefense n’a pas pu confirmer que cette technique fonctionnait comme décrit.

CISA

Le grand nombre de tentatives d’exploitation ciblant la dernière vulnérabilité SAML exige que les organisations concernées réagissent rapidement. La CISA, agence gouvernementale américaine de cybersécurité, demande à toutes les agences fédérales de débrancher les appareils d’ici le vendredi 2 février 2024 pour réduire l’exposition potentielle [source]. Dans le cadre de cette demande, les appareils ne peuvent être remis en ligne qu’après l’application du correctif.

Ivanti

La nouvelle mesure d’atténuation basée sur XML fournie par Ivanti peut être appliquée à toutes les versions du produit et les correctifs corrigent simplement les problèmes de sécurité et n’incluent aucune nouvelle fonctionnalité. Un autre correctif pour une nouvelle branche (numérotée 22.5R2.2) a été publié le 1er février 2024. Le dernier ICT externe mis à jour n’inclut pas d’IOCs ni de nouvelles techniques de détection, mais permet aux utilisateurs de vérifier une instance, même exécutée sur les dernières versions (c’est-à-dire corrigées).

Mandiant

La filiale de Google a publié par la suite un article de blog technique sur les souches de malware utilisées par le principal acteur malveillant d’origine. Le fournisseur de réponse aux incidents a confirmé avoir détecté une activité post-exploitation très ciblée. Mandiant n’a nommé aucune des victimes ni leurs pays ou secteurs. L’acteur malveillant a réussi dans certains cas à compromettre les appareils, puis à les rétablir dans un état propre, pour échapper à la détection, y compris lors de l’analyse par l’ICT externe. Les attaquants ont falsifié les fichiers de l’ICT interne pour l’empêcher de fonctionner. Mandiant a partagé certains identifiants d’événement pour détecter de telles modifications dans les journaux. De plus, Mandiant a également partagé d’autres identifiants liés à l’effacement des journaux système effectué par ce groupe d’attaquants.

Les nouvelles souches de malware attribuées à l’acteur malveillant (UNC5221) sont ainsi détaillées :

• un nouveau webshell Perl appelé BUSHWALK, intégré dans un fichier légitime (querymanifest.cgi) qui permet des actions de lecture et d’écriture
• une variante LIGHTWIRE trouvée dans un autre fichier légitime : « compcheckresult.cgi ». Mandiant recommande de rechercher cette requête GET - « /dana-na/auth/url_default/compcheckresult.cgi?comp=comp&compid=%3Cobfuscated%C2%A0command%3E » - dans les journaux Web, l’espace non alloué et les images mémoire
• une autre variante de WIREFIRE, baptisée CHAINLINE, trouvée dans un nouveau fichier « health.py » recevant une requête via le point de terminaison : « /api/v1/cav/client/health »
• L’attaquant accède au webshell FRAMESTING (dans le fichier category.py [détails]) via des requêtes adressées à « /api/v1/cav/client/categories »
• plusieurs variantes du voleur d’informations d’identification WARPWIRE ont également été trouvées par les experts.

Le code de la souche ZIPLINE a été détaillé par Mandiant et l’utilisation d’outils open source comme Impacket, Iodine, CrackMapExec ou Enum4Linux, est identifiée. Comme indiqué dans les mises à jour précédentes, une archive .tar se faisant passer pour un fichier CSS de 10 caractères générés aléatoirement dans le répertoire « /home/webserver/htdocs/dana-na/css/ » a été utilisée pour stocker les informations volées (vidage de la configuration et du cache). Comme nous le savions déjà, des données volées ont dans certains cas été ajoutées au fichier légitime « logo.gif » ou « login.gif », dans le même but.

• Deux nouvelles vulnérabilités 0-day ont été annoncées par Ivanti dans le cadre de l’enquête sur l’attaque, CVE-2024-21888 et CVE-2024-21893. CVE-2024-21888 permet à un attaquant de procéder à une élévation de privilèges interne (locale) et ne modifie pas le niveau de menace. CVE-2024-21893 a plus d’impact et constitue une falsification de requête côté serveur dans le composant SAML pour contourner l’authentification. La faille est activement exploitée par l’acteur malveillant chinois dans le cadre d’attaques ciblées contre un nombre limité de clients. 
• L’exploitation des 2 vulnérabilités existantes se poursuit, même si le nombre d’appareils vulnérables exposés sur Internet a considérablement diminué au fil du temps : quelques centaines, voire quelques milliers seulement, restant aujourd’hui en ligne. Cependant, le 25 janvier 2024, nous avons confirmé qu’au moins 500 instances exposaient des données sensibles en ligne via le « faux » fichier logo.gif créé par l’acteur malveillant.

Le 18 janvier 2024, Volexity a parlé pour la première fois d’une souche de malware basée sur Rust pour Linux qui a été exploitée par l’acteur malveillant, sans fournir plus de détails à l’époque. Un chercheur a publié quelques jours plus tard un certain nombre d’IOCs à ce sujet, puis des informations complémentaires sur cette nouvelle souche qu’il appelle « KrustyLoader »2 (car codée en Rust). Le chercheur a partagé un script de déchiffrage permettant de récupérer les URL utilisées par le chargeur pour créer une porte dérobée Sliver, un outil avancé de post-exploitation que notre service « Managed Threat Intell-detect » suit de manière proactive depuis longtemps.

• Au cours des multiples missions de notre CSIRT, nous avons identifié que les appareils compromis avec le framework Metasploit impliquent souvent la présence d’artefacts spécifiques dans le dossier « /imgs/Ivanti.zip/ ». De plus, nous pensons que les contrôles effectués avec l’ICT (même externe) peuvent dans certains cas ne pas identifier un appareil compromis. Ivanti l’a déjà mentionné précédemment et l’agence gouvernementale américaine CISA a déclaré le 30 janvier 2024 que les attaquants avaient réussi à contourner les résultats de l’ICT externe pour échapper à la détection.
• Les points de terminaison vulnérables initiaux sont bien connus, de nombreux fournisseurs de sécurité ajoutant des signatures pour les requêtes adressées à ces points de terminaison (par exemple Cloudflare, Snort/Suricata, etc.). Picus en a énuméré plusieurs au bas de son article. Les fournisseurs de SIEM tels que Splunk ont également fourni des exemples de requêtes pour rechercher les demandes suspectes. Cependant, certains points de terminaison liés au chemin vulnérable « /api/v1/totp/user-backup-code/.. » ne sont pas bien documentés par le fournisseur et nos experts ont découvert que le produit n’enregistre pas correctement certaines des requêtes effectuées vers ce point de terminaison. Les tentatives d’exploitation par des attaquants avant l’application de la mesure d’atténuation basée sur XML peuvent avoir laissé peu de preuves dans les journaux et une enquête plus avancée peut s’avérer nécessaire.
• Ivanti a publié des correctifs corrigeant CVE-2023-46805, CVE-2024-21887, CVE-2024-21888 et CVE-2024-21893, dans les versions du produit ICS suivantes :
  • 9.1R14.4,
  • 9.1R17.2,
  • 9.1R18.3,
  • 22.4R2.2,
  • 22.5R1.1.

La version ZTA 22.6R1.3 d’Ivanti a également reçu un correctif pour les 4 vulnérabilités.

Ivanti recommande d’effectuer une réinitialisation aux paramètres d’usine des appareils avant d’appliquer les correctifs, quelques heures étant nécessaires pour chaque opération. Nous vous encourageons néanmoins à appliquer le correctif sur les appareils dès que ceux pour vos versions sont publiés, même s’ils sont plus complexes que l’application de la mesure d’atténuation basée sur XML. 

Si vous ne pouvez pas appliquer le correctif, Ivanti a également sorti un nouveau fichier XML d’atténuation (mitigation.release.20240126.5.xml) pour se protéger contre les deux vulnérabilités 0-day supplémentaires publiées aujourd’hui. Lorsqu’elle est disponible (NDLR : le lien de téléchargement ne fonctionne pas à 14h, heure de Paris), nous encourageons vivement les utilisateurs à déployer au moins cette nouvelle protection jusqu’à ce que les appareils puissent recevoir le correctif. Cette solution de contournement mise à jour bloque la vulnérabilité d’authentification SAML (CVE-2024-21893) :

« La nouvelle mesure d’atténuation bloquera toutes les communications et authentifications SAML. Cela aura un impact limité sur les fonctionnalités des clients qui utilisent LDAP pour l’authentification », a déclaré Ivanti.

En plus du nouveau XML, Ivanti a publié une nouvelle version de son ICT externe :

• ICT-V22622  Ivanti Connect Secure Generic Integrity Checker Software 22.xR2
• ICT-V22611  Ivanti Connect Secure Generic Integrity Checker Software 22.xR1
• CT-V91183  Ivanti Connect Secure Generic Integrity Checker Software 9.x

Tout actif exposé sur Internet qui n’a pas encore appliqué l’une des mesures d’atténuation doit être considéré comme probablement piraté. Cela fait écho au dernier article de blog de la CISA qui recommande aux défenseurs de continuer à rechercher des signes de compromission dans tous les cas.

• AssetNote a de nouveau expliqué comment exploiter les vulnérabilités Ivanti. Les chercheurs ont confirmé que certaines anciennes versions, telles que 9.1R11.4, pourraient ne pas être directement compromises à l’aide du PoC accessible au public, mais ont présenté comment l’utiliser en utilisant d’autres points de terminaison vulnérables. Ils ont également détaillé comment nous (et d’autres équipes de sécurité) vérifions à distance depuis plus d’une semaine si un appareil est vulnérable.
• Déchiffrement du disque : afin d’enquêter de manière approfondie sur d’éventuelles compromissions, il est possible de récupérer des artefacts sur les disques des machines exécutant le produit Ivanti. Malheureusement, certains disques basés sur LILO sont chiffrés par le logiciel de chiffrement loop-AES, utilisé pour chiffrer des partitions ou des fichiers sur un système Linux. Les intervenants sur l’incident chez Northwave ont fourni un script Python disponible sur GitHub avec le processus détaillé pour déchiffrer les disques. Certaines des clés de chiffrement déjà trouvées sont actuellement partagées en privé au sein de la communauté des CERT afin d’accélérer les analyses forensiques.
• Exposition de données sensibles : dans nos missions de réponse aux incidents, nous avons pu confirmer les affirmations de Volexity selon lesquelles UTA0178 aurait volé des données et les aurait intégrées dans un fichier GIF accessible à distance nommé « logo.gif ». Cette tactique pose des risques de sécurité supplémentaires pour ces appareils compromis, car une quantité massive d’informations critiques (mots de passe, configurations, clés secrètes, certificats, etc.) sont ainsi exposées publiquement, toute personne connaissant le chemin spécifique à rechercher pouvant récupérer ces informations librement. Pire encore, certains appareils précédemment compromis semblent désormais avoir bénéficié d’une mesure d’atténuation (c’est-à-dire exécutant la solution de contournement XML), mais exposent toujours ces fichiers.
• Instances compromises :
  • Censys a identifié 412 actifs toujours compromis par le module de collecte d’informations d’identification (lastauthserverused.js), mais il ne s’agit que d’une partie des appareils piratés, car des centaines d’autres sont également touchés avec le webshell GIFTEDVISITOR.
  • HarfangLab a expliqué comment le nombre de webshells a diminué (parce que les propriétaires d’appareils les ont nettoyés ou les ont mis hors ligne), mais que le nombre de compromissions dans lastauthserverused.js continue de croître et a maintenant dépassé celui des webshells.
  • De plus, Quointell a identifié une variante du webshell exploité par UTA1078 (également nommé UNC5221) afin d’échapper à certaines détections utilisant actuellement la règle publique Yara de Mandiant. Le nouveau webshell est déposé sur un nouveau chemin : ../api/resources/category.py (au lieu de /visits.py.).
  • L’exploitation automatisée va encore augmenter depuis la sortie d’un module Metasploit le 20 janvier 2024.

• Avertissement de correction : comme nous l’avons déjà mentionné, Ivanti a mis à jour sa base de connaissances le 20 janvier 2024. L’éditeur conseille aux clients de ne pas appliquer de configurations de sauvegarde potentiellement compromise aux nouvelles instances ayant déjà bénéficié de la mesure d’atténuation basée sur XML.
• Tous les IOCs liés à l’infrastructure C2 des attaquants distants ont été ajoutés à notre plateforme de CTI Datalake. Nous avons lancé plusieurs missions pour des clients de multiples secteurs et pouvons vous aider à dissiper tout doute quant à savoir si votre appareil est compromis ou non. Nous continuons également d’essayer d’identifier régulièrement les appareils vulnérables, ayant bénéficié d’une mesure d’atténuation ou compromis et exposés en ligne.

• Différents acteurs malveillants ciblent désormais les appareils vulnérables à l’aide des preuves de concept (PoC) publiques et déploient des cryptominers.
• UTA0178 tente d’échapper à la détection en altérant l’ICT interne, compromettant à nouveau certains appareils.
• Les clients sont invités à utiliser uniquement l’ICT externe fourni par Ivanti et, si l’ICT est exécuté périodiquement, à vérifier les journaux de l’outil pour s’assurer qu’aucune compromission n’a été détectée précédemment de façon temporaire.
• Aucun équipement géré par OCD n’est affecté, mais les missions de notre CSIRT ont commencé pour des instances non gérées. La notification préventive des clients vulnérables ou victimes est toujours en cours.

Présentation générale

Une société d’investigation appelée Volexity a découvert pour la première fois deux vulnérabilités 0-day, CVE-2023-46805 et CVE-2024-21887, dans les produits Ivanti Connect Secure (ICS) début décembre 2023. Ces vulnérabilités ont été exploitées pour insérer des webshells que Volexity a nommés GLASSTOKEN. Volexity a également attribué le nom UTA0178 à l’acteur malveillant inconnu qui, selon lui, aurait des liens avec le gouvernement chinois. 

Le niveau de sophistication et de furtivité des acteurs malveillants est élevé et, au départ, on pensait que l’activité détectée pourrait être liée à une campagne d’espionnage ciblée, en raison du nombre initialement faible d’instances ICS impactées. Plus tard, le nombre d’équipements touchés a augmenté, ce qui a réduit la probabilité que nous soyons confrontés à une attaque ciblée. UTA0178 n’a pas encore été associé à d’autres groupes de pirates informatiques chinois existants. Volexity a également annoncé qu’un autre acteur malveillant, suivi sous le nom d’UTA0188, cible également les failles d’ICS.

Suite au rapport de Volexity, Mandiant a également partagé des détails techniques sur le malware associé aux récentes attaques attribuées à l’acteur malveillant UTA0178 (suivies sous le nom UNC5221 par Mandiant). L’activité post-exploitation implique l’utilisation de plusieurs malwares spécifiques baptisés ZIPLINE, THINSPOOL, LIGHTWIRE, WARPWIRE et WIREFIRE.

Le 10 janvier 2024, Ivanti a reconnu ces deux vulnérabilités 0-day en publiant un avis désignant les produits concernés. Ces vulnérabilités impactent toutes les versions des passerelles Ivanti Connect Secure (une solution VPN anciennement connue sous le nom de Pulse Connect Secure), Policy Secure et, dans une certaine mesure, Neurons for ZTA. 

Les deux vulnérabilités ont été chaînées pour permettre une exécution de code à distance (RCE) non authentifiée. CVE-2023-46805 est une vulnérabilité de contournement d’authentification, tandis que CVE-2024-21887 est une faille de sécurité par injection de commandes. Combinées, elles fournissent aux attaquants un accès non authentifié au serveur, leur permettant de prendre la main sur le réseau puis de se déplacer latéralement, dans ce cas en utilisant des protocoles tels que RDP, SMB et SSH.

Malheureusement, les détails relatifs aux vulnérabilités sont devenus publics grâce aux travaux publiés par Watchtower Labs et Rapid7. Watchtower Labs a publié un article de blog annonçant avoir réussi à reproduire les failles. Ses experts ont expliqué avoir pu le faire en identifiant les points de terminaison bloqués par Ivanti dans sa solution de contournement (c’est-à-dire le fichier de la mesure d’atténuation basée sur XML), car les différences sont visibles dans les réponses des instances vulnérables et ayant bénéficié de la mesure d’atténuation. Rapid7 a ensuite divulgué des détails relatifs à CVE-2023-46805, permettant ainsi à d’autres de créer des exploits pour cette faille. 

Naturellement, nous nous attendons à une augmentation du nombre de tentatives d’exploitation, car plusieurs milliers d’appareils ne sont toujours pas corrigés. À peu près au même moment, GreyNoise a signalé avoir détecté une augmentation des tentatives d’exploitation liées aux deux vulnérabilités d’ICS. À son tour, Volexity a indiqué que les attaquants installent actuellement des malwares qui facilitent le cryptominage (XMRIG) et d’autres types de charges utiles. 

Au 17 janvier 2023, plus de 4 000 hôtes ICS n’avaient toujours pas bénéficié de la mesure d’atténuation fournie par Ivanti. À peu près à la même date, Volexity a estimé qu’environ 2 100 appareils VPN Ivanti Connect Secure avaient été compromis par l’implant GIFTEDVISITOR attribué à UTA0178. 

Annexes

Certains journaux associés pouvant faire l’objet d’une enquête seraient potentiellement les suivants :

msg="WEB31809 : L’accès à /api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark est bloqué en raison d’un correctif (Patch 2).

Pour vérifier si le XML a été appliqué, vous pouvez par exemple effectuer une requête auprès de l’un des points de terminaison situés ici :

• /api/v1/configuration/users/user-roles/user-role/rest-userrole-1/web/web-bookmarks/bookmark
• /api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark

Cette API REST a été introduite dans la version 8.3R3 de Pulse Secure et existe dans la documentation de toutes les versions 9.xRx.

Un script Nmap peut faciliter cette vérification pour vous. La réponse comprendra dans les deux cas un « 403 Forbidden », mais le contenu de la réponse contiendra :

• une page vide pour une instance vulnérable.
• un contenu HTML complet incluant « L’accès au site Web est bloqué par votre administrateur. […] » dans le cas où le correctif XML a été appliqué.

Analyse des malwares

• Mandiant a apporté plus de détails sur le webshell GLASSTOKEN mentionné dans l’article de Volexity. Suivi sous le nom de LIGHTWIRE par Mandiant, ce malware est intégré dans un fichier Connect Secure légitime (un script CGI) et permet à l’acteur malveillant d’intercepter des requêtes spécifiques et de les interpréter comme du code Perl. Il est important de noter que ce LIGHTWIRE intercepte uniquement les requêtes adressées à « compcheckresult.cgi » qui contiennent les paramètres « comp=comp » et « compid ».
• THINSPOOL fait office de script Perl pour déposer les webshells LIGHTWIRE dans un fichier Ivanti Connect Secure légitime. Cela permet à l’acteur malveillant de persister sur les appareils compromis et de manipuler les fichiers ou processus Ivanti Connect Secure de manière à éviter d’être détecté. Cependant, selon les observations de Mandiant, cette tentative a échoué, car elle a été détectée par l’outil de vérification d’intégrité (ICT) d’Ivanti.
• WIREFIRE est le webshell Python qui fonctionne comme un cheval de Troie pour un composant spécifique de l’appareil Connect Secure (le fichier visits.py mentionné précédemment). Ce webshell peut également télécharger des fichiers et exécuter des commandes arbitraires sur l’appareil compromis. De plus, il décode, déchiffre et décompresse toutes les données brutes existantes après un en-tête GIF (Graphics Interchange Format) pour s’exécuter en tant que sous-processus. WIREFIRE utilise sans aucun doute cet en-tête pour masquer ou transporter des données malveillantes.
• WARPWIRE est l’outil de collecte d’informations d’identification écrit en Javascript et intégré dans un fichier Connect Secure légitime, également brièvement mentionné par Volexity. Son objectif principal est de collecter des informations d’identification, notamment des noms d’utilisateur et des mots de passe en texte brut. Une fois collectées, ces informations sont codées en Base64 et soumises à un serveur de commande et de contrôle à l’aide de requêtes HTTP GET.
• ZIPLINE est le seul malware nouvellement détaillé, et plus précisément une backdoor passive ELF qui détourne la fonction accept() de libsecure.so afin d’intercepter le trafic réseau et de prendre le contrôle de la connexion entrante discrètement, sans éveiller les soupçons. Une fois cette action réalisée, le malware effectue diverses actions malveillantes, telles que la collecte d’informations, le téléchargement de fichiers, la configuration de serveurs proxy et de serveurs de tunneling. Mais aucun hachage d’échantillon pour cette souche n’a été fourni par Mandiant.

Quelques indicateurs de compromission

Emplacement du fichier malveillant :

• /home/perl/DSLogConfig[.]pm
• /home/etc/sql/dsserver/sessionserver[.]pl
• /home/etc/sql/dsserver/sessionserver[.]sh
• /home/webserver/htdocs/dana-na/auth/compcheckresult[.]cgi
• /home/webserver/htdocs/dana-na/auth/lastauthserverused[.]js
• /tmp/rév
• /tmp/s[.]py
• /tmp/s[.]jar
• /tmp/b
• /tmp/tuer

Nom de l’hôte :

• gpoaccess[.]com
• webb-institute[.]com
• symantke[.]com

IP :

• 206.189.208[.]156
• 75.145.243[.]85
• 47.207.9[.]89
• 98.160.48[.]170
• 173.220.106[.]166
• 73.128.178[.]221
• 50.243.177[.]161
• 50.213.208[.]89
• 64.24.179[.]210
• 75.145.224[.]109
• 50.215.39[.]49
• 71.127.149[.]194
• 173.53.43[.]7

Hachage MD5 :

• 3d97f55a03ceb4f71671aa2ecf5b24e9 (compcheckresult[.]cgi)
• 677c1aa6e2503b56fe13e1568a814754 (sessionserver[.]sh)
• d0c7a334a4d9dcd3c6335ae13bee59ea (lastauthserverused[.]js)
• 6de651357a15efd01db4e658249d4981 (visits[.]py)

Si vous souhaitez couvrir les risques et atténuer la menace, en détection ou en chasse, accédez à l’intégralité de nos IOCs depuis notre plateforme SaaS Datalake (incluse dans le service Managed Threat Intelligence).