Étiquette : Log4Shell

La vulnérabilité Log4j, exploitée dans VMware Horizon pour le déploiement de ransomware

On 24/02/2022

Un groupe de pirates proche du gouvernement iranien utilise la vulnérabilité Log4j pour infecter des serveurs VMware Horizon obsolètes.

Comme le rapportent les chercheurs Amitai Ben Shushan Ehrlich et Yair Rigevsky de la société de sécurité SentinelOne, le groupe cybercriminel appelé « TunnelVison » exploite activement la vulnérabilité Java Log4j (CVE-2021-44228) pour l’exécution de code à distance. Ils peuvent ainsi prendre le contrôle des serveurs affectés et lancer des commandes PowerShell pour activer des portes dérobées, créer des utilisateurs, obtenir des informations et effectuer des mouvements latéraux. VMware utilise généralement Apache Tomcat pour le déploiement d’applications Web Java.

Au cours de l’activité détectée, l’utilisation d’un dépôt Github connu sous le nom de « VmwareHorizon » et de l’utilisateur « protections20 » a été observée.

Il est recommandé de mettre à jour les dernières versions pour éviter ce type d’incident.

Plus d’information:
https://kb.vmware.com/s/article/87073
https://thehackernews.com/2022/02/iranian-hackers-targeting-vmware.html

Guide d’atténuation de Log4j publié par le ministère américain de la Sécurité intérieure

de jabot

On 30/12/2021

dans CVE, Sécurité

L’Agence pour la cybersécurité et les infrastructures (CISA) du ministère américain de la sécurité intérieure a publié des recommandations sur la manière de remédier à la vulnérabilité désormais répandue d’Apache Log4j.

Tout d’abord, les vendeurs doivent identifier, atténuer et mettre à niveau les produits utilisant Log4j vers la dernière version de la bibliothèque.

Deuxièmement, toutes les organisations doivent prendre immédiatement les mesures suivantes :

Identifiez toutes les ressources accessibles via Internet qui permettent la saisie par l’utilisateur et utilisent la bibliothèque Log4j quelque part dans leur infrastructure.
Identifiez tous les actifs qui utilisent Log4j.
Mettez à jour ou isolez les actifs affectés. Une fois identifiée, l’organisation doit rechercher des indicateurs de compromission et des schémas habituels d’activités post-exploitation. Supposons que l’actif a été compromis.
Surveillez les schémas de trafic inhabituels. Par exemple, le trafic sortant lié aux protocoles JNDI, LDAP/RMI, DNS ou DMZ.

Flux d’actions pour identifier les installations vulnérables. Source : https://www.cisa.gov

Une fois le risque maîtrisé, les utilisateurs ou organisations concernés doivent, dans la mesure du possible, mettre à niveau la bibliothèque vers la dernière version disponible. Si une mise à niveau n’est pas possible, les contre-mesures suivantes sont recommandées :

Désactiver les logiciels qui utilisent la bibliothèque. Cela pourrait limiter la visibilité d’autres problèmes opérationnels, car ĺa bibliothèque est chargée de prendre les journaux.
Bloquer les recherches JNDI. Il s’agit d’une option efficace, mais qui peut nécessiter des travaux de développement et une perte de fonctionnalité.
Arrêter temporairement les infrastructures touchées. Cela réduirait la probabilité d’une attaque.
Créez un réseau isolé pour séparer les infrastructures touchées du reste du réseau de l’entité.
Déployer un WAF pour protéger les infrastructures concernées. Bien qu’elle ne soit pas une solution complète, elle peut contribuer à réduire le nombre de menaces.
Appliquez des micro-patchs. Il existe des solutions qui ne font pas partie de la mise à jour officielle mais qui peuvent contribuer à atténuer les risques dans certains cas spécifiques.

Pour rester à jour, la CISA a créé un dépôt Github où elle publiera les mises à jour de ce protocole : https://github.com/cisagov/log4j-affected-db.

Plus d’information :
https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

La Chine punit le géant technologique Alibaba pour « une différence de priorités »

de jabot

On 25/12/2021

dans CVE, Sécurité

La Chine a sanctionné le géant technologique Alibaba, plus précisément sa filiale de cloud computing, en suspendant pour six mois l’accord de collaboration qu’il avait mis en place pour échanger des informations sur la cybersécurité et les données dans le cloud.

La sanction a été catégorique et retentissante de la part du gouvernement chinois, car l’entreprise a signalé la vulnérabilité populaire et désormais bien connue de Log4Shell.

Et il semble que le gouvernement chinois n’ait pas pris ce fait à la légère ou avec joie, car il ne semble pas être d’accord avec la priorité de savoir qui doit être tenu pour responsable en premier, et il a sévèrement puni le géant technologique.

Avec cette sanction, le gouvernement chinois veut faire comprendre à toutes les entreprises technologiques du pays quelle priorité elles doivent accorder au signalement d’une vulnérabilité.

Chen Zhaojun, un technicien de l’équipe de sécurité d’Alibaba Cloud, est à l’origine de la découverte de la vulnérabilité (Log4Shell), à laquelle a été attribuée une note de 10/10 sur le CVSS (Common Vulnerability Scoring System), une norme permettant de mesurer la gravité des vulnérabilités.

Zhaojun, suivant la procédure habituelle des communautés de cybersécurité et des développeurs de logiciels libres, a offert une réponse rapide. La Fondation Apache a publié un correctif à peine 24 heures plus tard, mais les dégâts ont été catastrophiques, comme nous l’avons lu partout ces dernières semaines, qui ont affecté des milliers d’entreprises et d’institutions.

Il y a quelques mois, le gouvernement avait adopté une nouvelle réglementation sur la divulgation des vulnérabilités, exigeant que tout logiciel ou fournisseur de télécommunications concerné divulgue d’abord ses vulnérabilités aux autorités gouvernementales.

En septembre, Pékin a officiellement et publiquement indiqué les plates-formes sur lesquelles ces incidents doivent être signalés, afin de protéger les infrastructures technologiques chinoises contre tout acteur malveillant, ou du moins c’est la raison officielle invoquée par le gouvernement chinois.