Environ 17 projets Apache sont concernés par la vulnérabilité Log4j 2

log4j

Au cours des derniers jours sur le net on a beaucoup parlé de la vulnérabilité de Log4j dans lequel divers vecteurs d'attaque ont été découverts et divers exploits fonctionnels ont également été filtrés afin d'exploiter la vulnérabilité.

Le sérieux de la question est qu'il s'agit d'un cadre populaire pour l'organisation du registre dans les applications Java., qui permet l'exécution de code arbitraire lorsqu'une valeur spécialement formatée est écrite dans le registre au format « {jndi : URL} ». L'attaque peut être menée sur des applications Java qui enregistrent des valeurs obtenues à partir de sources externes, par exemple en affichant des valeurs problématiques dans des messages d'erreur.

Et est-ce un attaquant effectue une requête HTTP sur un système cible, ce qui génère un journal à l'aide de Log4j 2 Qui utilise JNDI pour faire une demande au site contrôlé par l'attaquant. La vulnérabilité amène alors le processus exploité à arriver sur le site et à exécuter la charge utile. Dans de nombreuses attaques observées, le paramètre qui appartient à l'attaquant est un système d'enregistrement DNS, destiné à enregistrer une requête sur le site pour identifier les systèmes vulnérables.

Comme notre collègue Isaac l'a déjà partagé :

Cette vulnérabilité de Log4j permet d'exploiter une validation d'entrée incorrecte vers LDAP, permettant exécution de code à distance (RCE), et compromettant le serveur (confidentialité, intégrité des données et disponibilité du système). De plus, le problème ou l'importance de cette vulnérabilité réside dans le nombre d'applications et de serveurs qui l'utilisent, y compris les logiciels d'entreprise et les services cloud tels qu'Apple iCloud, Steam, ou les jeux vidéo populaires tels que Minecraft : Java Edition, Twitter, Cloudflare, Tencent, ElasticSearch, Redis, Elastic Logstash, etc.

S'exprimant sur le sujet, récemment l'Apache Software Foundation a publié par une publication un résumé des projets qui corrigent une vulnérabilité critique dans Log4j 2 qui permet à du code arbitraire de s'exécuter sur le serveur.

Les projets Apache suivants sont concernés : Archiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl et Calcite Avatica. La vulnérabilité a également affecté les produits GitHub, notamment GitHub.com, GitHub Enterprise Cloud et GitHub Enterprise Server.

Ces derniers jours, il y a eu une augmentation significative de l'activité liée à l'exploitation de la vulnérabilité. Par exemple, Check Point a enregistré environ 100 tentatives d'exploit par minute sur ses serveurs fictifs en son apogée, et Sophos a annoncé la découverte d'un nouveau botnet de minage de crypto-monnaie, formé à partir de systèmes avec une vulnérabilité non corrigée dans Log4j 2.

Concernant les informations publiées sur le problème :

  • La vulnérabilité a été confirmée dans de nombreuses images Docker officielles, notamment couchbase, elasticsearch, flink, solr, images de tempête, etc.
  • La vulnérabilité est présente dans le produit MongoDB Atlas Search.
  • Le problème apparaît dans une variété de produits Cisco, y compris Cisco Webex Meetings Server, Cisco CX Cloud Agent, Cisco
  • Rapports de sécurité Web avancés, Cisco Firepower Threat Defense (FTD), Cisco Identity Services Engine (ISE), Cisco CloudCenter, Cisco DNA Center, Cisco. BroadWorks, etc.
  • Le problème est présent dans IBM WebSphere Application Server et dans les produits Red Hat suivants : OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse et AMQ Streams.
  • Problème confirmé dans Junos Space Network Management Platform, Northstar Controller / Planner, Paragon Insights / Pathfinder / Planner.
  • De nombreux produits d'Oracle, vmWare, Broadcom et Amazon sont également concernés.

Projets Apache qui ne sont pas affectés par la vulnérabilité Log4j 2: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper et CloudStack.

Il est conseillé aux utilisateurs de packages problématiques d'installer d'urgence les mises à jour publiées pour eux, mettez à jour séparément la version de Log4j 2 ou définissez le paramètre Log4j2.formatMsgNoLookups sur true (par exemple, en ajoutant la clé "-DLog4j2.formatMsgNoLookup = True" au démarrage).

Pour verrouiller le système vulnérable auquel il n'y a pas d'accès direct, il a été suggéré d'exploiter le vaccin Logout4Shell, qui, via la commission d'une attaque, expose le paramètre Java "log4j2.formatMsgNoLookups = true", "com.sun.jndi .rmi.objet. trustURLCodebase = false "et" com.sun.jndi.cosnaming.object.trustURLCodebase = false "pour bloquer d'autres manifestations de la vulnérabilité sur les systèmes non contrôlés.


Le contenu de l'article adhère à nos principes de éthique éditoriale. Pour signaler une erreur, cliquez sur c'est par ici !.

Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.