CERTFR-2021-ALE-022
Vulnerability from certfr_alerte

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.

Cette vulnérabilité 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.

Des preuves de concept ont déjà été publiées. Cette vulnérabilité fait désormais l'objet d'une exploitation active.

Détection

Le CERT-FR recommande de réaliser une analyse approfondie des journaux réseau. Les motifs suivants permettent d'identifier une tentative d'exploitation de cette vulnérabilité lorsqu'ils sont utilisés dans les URLs ou certaines en-têtes HTTP comme *user-agent* : > > > > > > > \${jndi: > > > > > > > > \$%7Bjndi:     (prend en compte un obscurcissement simple) > > > > > > > > Cependant, les attaquants peuvent utiliser des moyens d’obscurcissement pour contourner les motifs de détection précédents. Les motifs suivants permettent de prendre en compte certaines méthodes d'obscurcissement mais peuvent provoquer des faux positifs :

\${\${

\${::-

%24%7B%3A%3A-

\${env:

\${date:

\${lower:

\${upper:

hostName}

}\${

\${                   (génère beaucoup de faux positifs, mais très exhaustif)

  Afin de déterminer si une tentative d'exploitation a réussi, et dans le cas où vous disposeriez de journaux contenant des requêtes DNS, il est recommandé de les corréler aux résultats des motifs précédemment énoncés. En effet, si l’exécution d'une requête de type *\${jndi:xxx://nom.domaine.com}* a fonctionné, une résolution DNS sera alors effectuée pour résoudre le nom de domaine externe *nom*.*domaine.com*. L'émission d'une requête DNS peut également faire l'objet d'une trace dans les journaux du serveur applicatif. Ainsi, il peut être utile de chercher le motif *com.sun.jndi.dns.DnsContext@* dans ces journaux. Note : une résolution de domaine externe ne signifie pas qu'une exécution de code a réussi mais permet de confirmer que l'application est vulnérable. Il sera donc nécessaire de poursuivre l'analyse des journaux pour détecter une compromission. En complément des informations ci-dessus, une requête de type *\${jndi:dns://serveur_dns/enregistrement_TXT}* est également utilisable par l'attaquant pour tester la présence de la vulnérabilité. Il est également intéressant de rechercher les motifs suivants dans les fichiers journaux des applications :
  • le motif com.sun.jndi.ldap.LdapCtx@ (et non pas com.sun.jndi.dns.DnsContext@ comme indiqué précédemment) apparaîtra lorsqu'une injection LDAP est utilisée pour récupérer du contenu qui ne serait pas un objet java au standard rfc2713 : il peut s'agir d'un scan de détection ou d'une tentative erronée d'un attaquant
  • l'injection sera enregistrée dans les journaux telle qu'elle a été soumise par l'attaquant si le serveur LDAP n'est pas joignable ou si l'objet qu'il souhaitait télécharger n'est pas trouvé sur le serveur LDAP : il est donc possible de trouver des tentatives d'injection sous une forme obscurcie dans les journaux, les motifs précédemment listés peuvent donc être utilisés pour identifier toutes les tentatives
  • une erreur contenant le motif "Reference Class Name:" suivi d'un nom de classe puis des lignes commençant par "Type:" et "Content:" peut apparaître dans les journaux si l'injection LDAP fonctionne mais que la classe contenant la charge utile ne peut pas être récupérée sur le serveur LDAP visé
  • il peut être intéressant de chercher des injections en DNS et LDAP basées sur la classe JavaLookup tels que \${java:hw}, \${java:vm} et \${java:os}. Ces dernières sont utilisées par les attaquants pour obtenir des informations sur la machine ciblée.*
    *

[Mise à jour du 07 janvier 2022] Le CERT-FR propose au téléchargement un ensemble de règles de détection basées sur la syntaxe utilisée par l'outil suricata. Ces règles peuvent être mises en œuvre, après adaptation, sur un équipement de détection réseau ou un pare-feu applicatif. Un guide de mise en œuvre est également proposé.

  • le guide est disponible ici.
  • les règles sont disponibles ici.
### Précisions sur les CVE-2021-45046 et CVE-2021-45105 La version 2.15.0 recommandée jusqu'à présent est affectée par une autre vulnérabilité, désignée par l'identifiant CVE-2021-45046 \[4\]. Cette vulnérabilité permet à un attaquant non authentifié d'effectuer un déni de service. Par ailleurs, des chercheurs ont mis en évidence la possibilité d'exfiltrer des données dans certaines configurations non détaillées. Par ailleurs, les versions 2.16.0 et 2.12.2 sont affectées par une nouvelle vulnérabilité, désignée par l'identifiant CVE-2021-45105 \[5\], qui permet de provoquer un déni de service à distance. ### Précisions sur la CVE-2021-44832 La version 2.17.0 recommandée jusqu'à présent est affectée par une vulnérabilité, désignée par l'identifiant CVE-2021-44832 \[6\]. Cette vulnérabilité permet à un attaquant, autorisé à modifier le fichier de configuration Log4J, d'effectuer une exécution de code à distance. La complexité de l'attaque étant élevée, le CERT-FR continue de recommander la mise à jour des composants Log4j à la version 2.17.0 pour java 8 et 2.12.3 pour java7. Par ailleurs, il est fortement recommandé de rester attentif aux nouvelles vulnérabilités Log4j qui pourraient être identifiées à l'avenir ainsi qu'aux correctifs proposés par Apache. ### Précisions sur les modes d'attaque Il convient également de noter que des techniques permettent d'exploiter la vulnérabilité localement sans recourir à un serveur tiers malveillant. L'attaquant peut injecter un code malveillant dans la requête initiale s'il a suffisamment d'informations sur l'application vulnérable qu'il cible. Cette attaque requiert donc une première phase de reconnaissance et de collecte de données. Cette phase est possible tant que n'ont pas été appliqués : d'une part, un filtrage réseau adéquat et d'autre part, le correctif ou, à défaut, les mesures de contournement. Il est donc important de disposer des journaux de ces environnements pour rechercher des éventuelles traces d'exfiltration de données. Les moyens de détection précédemment peuvent être utilisés à cette fin.   Pour rappel : une application utilisant une version non vulnérable de log4j peut transmettre des données à une autre application qui utilise une version vulnérable de cette bibliothèque. L’attaquant pourra exploiter la vulnérabilité dans la seconde application en soumettant une donnée malveillante via la première. Par conséquent, le CERT-FR recommande de ne pas limiter l'identification de la vulnérabilité aux seules applications exposées sur Internet, mais également aux applications internes. L'utilisation d'outils tels que ceux listés ci-dessous facilitera leur identification.

Contournement provisoire

La version 1 de log4j a été initialement déclarée vulnérable cependant la vulnérabilité n'existe que si le composant JMS Appender est configuré pour prendre en compte JNDI. Il s'agit donc d'une configuration très spécifique [1][3].

Il est recommandé d'utiliser une version à jour de l'environnement d'exécution Java (les versions 8u191 et ultérieures apportent des restrictions pour les appels JNDI basés sur LDAP et RMI), cependant les codes d'exploitation les plus récents sont en mesure de contourner ces protections pour continuer d'exploiter la vulnérabilité.

La mise en place de filtres au niveau de vos pare-feux applicatifs pour bloquer les tentatives d'exploitation de cette vulnérabilité peut constituer une première mesure d'urgence mais elle reste insuffisante : les attaquants utilisent différentes techniques d'obscurcissement des données injectées pour contourner ces filtres.

Les contournements proposés initialement ne permettent plus de se prémunir contre certaines formes d'exploitation. Face à la possibilité que d'autres exploitations soient encore découvertes y compris pour la version 2.15.0, le CERT-FR recommande d'utiliser les versions les plus à jour de la bibliothèque.

En cas d'impossibilité de migration, il reste possible de supprimer la classe Java vulnérable. Cette opération impose de tester le fonctionnement de l'application afin d'identifier les impacts de la modification sur son fonctionnement.

Cette suppression peut par exemple être effectuée avec la commande suivante : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Outillage

- Des outils de recherche de la bibliothèque Log4j sont proposés par le **CERT/CC** (non qualifiés par le CERT-FR) : - Le site du **NCSC-NL** recense également des outils, qui n'ont pas été qualifiés par le NCSC-NL ni par le CERT-FR : - La **CISA** a publié un scanner basé sur des outils issus de la communauté open-source :

Solution

Il est fortement recommandé aux utilisateurs d'applications ou de logiciels sur étagère basés sur la technologie Java/J2EE :

  • de conserver les journaux a minima depuis le 1er décembre 2021 à des fins d'analyse ultérieure ;
  • de préparer sans délai des mesures de préservation en cas d'incident majeur, notamment par la mise hors ligne de sauvegardes à jour ;
  • de filtrer et de journaliser les flux sortants des serveurs pour les limiter aux seuls flux autorisés vers des services de confiance ;
  • de prendre contact avec le développeur ou l'éditeur pour vérifier s'ils sont exposés à cette vulnérabilité et si un correctif est disponible.

Il est fortement recommandé aux développeurs/éditeurs :

  • d'inventorier les solutions affectées par les vulnérabilités ;
  • d'informer les utilisateurs et clients de leurs statuts et des actions en cours ;
  • de corriger les solutions en utilisant à minima la version 2.17.0 pour java 8 ou la version 2.12.3 pour java 7 et idéalement la version 2.17.1 pour java 8 ou la version 2.12.4 pour java 7 ;
  • de fournir une nouvelle version de leurs solutions dans les plus brefs délais.

Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).


La mise à jour d’un produit ou d’un logiciel est une opération délicate qui doit être menée avec prudence. Il est notamment recommandé d’effectuer des tests autant que possible. Des dispositions doivent également être prises pour garantir la continuité de service en cas de difficultés lors de l’application des mises à jour comme des correctifs ou des changements de version.

Impacted products
Vendor Product Description
Apache N/A Apache Log4j versions 2.0 à 2.14.1
Apache N/A Apache Log4j versions 1.x (versions obsolètes) sous réserve d'une configuration particulière, cf. ci-dessous
Apache N/A Apache Log4j version 2.15.0
Apache N/A Les produits utilisant une version vulnérable de Apache Log4j : les CERT nationaux européens tiennent à jour une liste complète des produits et de leur statut vis-à-vis de la vulnérabilité [2]
Apache N/A Apache Log4j versions 2.16.0 et 2.12.2 (java 7)

Show details on source website


{
  "$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
  "affected_systems": [
    {
      "description": "Apache Log4j versions 2.0 \u00e0 2.14.1",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "Apache",
          "scada": false
        }
      }
    },
    {
      "description": "Apache Log4j versions 1.x (versions obsol\u00e8tes) sous r\u00e9serve d\u0027une configuration particuli\u00e8re, cf. ci-dessous",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "Apache",
          "scada": false
        }
      }
    },
    {
      "description": "Apache Log4j version 2.15.0",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "Apache",
          "scada": false
        }
      }
    },
    {
      "description": "Les produits utilisant une version vuln\u00e9rable de Apache Log4j : les CERT nationaux europ\u00e9ens tiennent \u00e0 jour une liste compl\u00e8te des produits et de leur statut vis-\u00e0-vis de la vuln\u00e9rabilit\u00e9 [2]",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "Apache",
          "scada": false
        }
      }
    },
    {
      "description": "Apache Log4j versions 2.16.0 et 2.12.2 (java 7)",
      "product": {
        "name": "N/A",
        "vendor": {
          "name": "Apache",
          "scada": false
        }
      }
    }
  ],
  "affected_systems_content": "",
  "closed_at": "2022-05-04",
  "content": "## Contournement provisoire\n\nLa version 1 de log4j a \u00e9t\u00e9 initialement d\u00e9clar\u00e9e vuln\u00e9rable cependant\nla vuln\u00e9rabilit\u00e9 n\u0027existe que si le composant *JMS Appender* est\nconfigur\u00e9 pour prendre en compte *JNDI*. Il s\u0027agit donc d\u0027une\nconfiguration tr\u00e8s sp\u00e9cifique \\[1\\]\\[3\\].\n\nIl est recommand\u00e9 d\u0027utiliser une version \u00e0 jour de l\u0027environnement\nd\u0027ex\u00e9cution Java (les versions 8u191 et ult\u00e9rieures apportent des\nrestrictions pour les appels JNDI bas\u00e9s sur LDAP et RMI), cependant les\ncodes d\u0027exploitation les plus r\u00e9cents sont en mesure de contourner ces\nprotections pour continuer d\u0027exploiter la vuln\u00e9rabilit\u00e9.\n\n\u003cspan class=\"mx_MTextBody mx_EventTile_content\"\u003e\u003cspan\nclass=\"mx_EventTile_body\" dir=\"auto\"\u003eLa mise en place de filtres au\nniveau de vos pare-feux applicatifs pour bloquer les tentatives\nd\u0027exploitation de cette vuln\u00e9rabilit\u00e9 peut constituer une premi\u00e8re\nmesure d\u0027urgence mais elle reste insuffisante : les attaquants utilisent\ndiff\u00e9rentes techniques d\u0027obscurcissement des donn\u00e9es inject\u00e9es pour\ncontourner ces filtres. \u003c/span\u003e\u003c/span\u003e\n\n**Les contournements propos\u00e9s initialement ne permettent plus de se\npr\u00e9munir contre certaines formes d\u0027exploitation. Face \u00e0 la possibilit\u00e9\nque d\u0027autres exploitations soient encore d\u00e9couvertes y compris pour la\nversion 2.15.0, le CERT-FR recommande d\u0027utiliser les versions les plus \u00e0\njour de la biblioth\u00e8que.**\n\nEn cas d\u0027impossibilit\u00e9 de migration, il reste possible de **supprimer la\nclasse Java vuln\u00e9rable**. Cette op\u00e9ration impose de tester le\nfonctionnement de l\u0027application afin d\u0027identifier les impacts de la\nmodification sur son fonctionnement.\n\nCette suppression peut par exemple \u00eatre effectu\u00e9e avec la commande\nsuivante : *zip -q -d log4j-core-\\*.jar\norg/apache/logging/log4j/core/lookup/JndiLookup.class*\n\n### Outillage\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n-   Des outils de recherche de la biblioth\u00e8que Log4j sont propos\u00e9s par\n    le **CERT/CC** (non qualifi\u00e9s par le CERT-FR) :\n    \u003chttps://github.com/CERTCC/CVE-2021-44228_scanner\u003e\n-   Le site du **NCSC-NL** recense \u00e9galement des outils, qui n\u0027ont pas\n    \u00e9t\u00e9 qualifi\u00e9s par le NCSC-NL ni par le CERT-FR :\n    \u003chttps://github.com/NCSC-NL/log4shell/tree/main/scanning\u003e\n-   La **CISA** a publi\u00e9 un scanner bas\u00e9 sur des outils issus de la\n    communaut\u00e9 open-source : \u003chttps://github.com/cisagov/log4j-scanner\u003e\n\n\u003c/div\u003e\n\n\u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003c/div\u003e\n\n## Solution\n\nIl est fortement recommand\u00e9 \u003cu\u003eaux utilisateurs\u003c/u\u003e d\u0027applications ou de\nlogiciels sur \u00e9tag\u00e8re bas\u00e9s sur la technologie Java/J2EE :\n\n-   de conserver les journaux a minima depuis le 1er d\u00e9cembre 2021 \u00e0 des\n    fins d\u0027analyse ult\u00e9rieure ;\n-   de pr\u00e9parer sans d\u00e9lai des mesures de pr\u00e9servation en cas d\u0027incident\n    majeur, notamment par la mise hors ligne de sauvegardes \u00e0 jour ;\n-   de filtrer et de journaliser les flux sortants des serveurs pour les\n    limiter aux seuls flux autoris\u00e9s vers des services de confiance ;\n-   de prendre contact avec le d\u00e9veloppeur ou l\u0027\u00e9diteur pour v\u00e9rifier\n    s\u0027ils sont expos\u00e9s \u00e0 cette vuln\u00e9rabilit\u00e9 et si un correctif est\n    disponible.\n\nIl est fortement recommand\u00e9 aux \u003cu\u003ed\u00e9veloppeurs/\u00e9diteurs\u003c/u\u003e :\n\n-   d\u0027inventorier les solutions affect\u00e9es par les vuln\u00e9rabilit\u00e9s ;\n-   d\u0027informer les utilisateurs et clients de leurs statuts et des\n    actions en cours ;\n-   de corriger les solutions en utilisant **\u00e0 minima la version 2.17.0\n    pour java 8** ou **la version 2.12.3 pour java 7** et **id\u00e9alement\n    la version 2.17.1 pour java 8** ou **la version 2.12.4 pour java 7**\n    ;\n-   de fournir une nouvelle version de leurs solutions dans les plus\n    brefs d\u00e9lais.\n\n\u00a0\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des\ncorrectifs (cf. section Documentation).\n\n\u00a0\n\n------------------------------------------------------------------------\n\nLa mise \u00e0 jour d\u2019un produit ou d\u2019un logiciel est une op\u00e9ration d\u00e9licate\nqui doit \u00eatre men\u00e9e avec prudence. Il est notamment recommand\u00e9\nd\u2019effectuer des tests autant que possible. Des dispositions doivent\n\u00e9galement \u00eatre prises pour garantir la continuit\u00e9 de service en cas de\ndifficult\u00e9s lors de l\u2019application des mises \u00e0 jour comme des correctifs\nou des changements de version.\n\n",
  "cves": [
    {
      "name": "CVE-2021-4104",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-4104"
    },
    {
      "name": "CVE-2021-44832",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-44832"
    },
    {
      "name": "CVE-2021-45105",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-45105"
    },
    {
      "name": "CVE-2021-45046",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-45046"
    },
    {
      "name": "CVE-2021-44228",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-44228"
    }
  ],
  "initial_release_date": "2021-12-10T00:00:00",
  "last_revision_date": "2022-05-04T00:00:00",
  "links": [
    {
      "title": "[6] R\u00e9f\u00e9rence CVE CVE-2021-44832",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-44832"
    },
    {
      "title": "[1]",
      "url": "https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126"
    },
    {
      "title": "[5] R\u00e9f\u00e9rence CVE CVE-2021-45105",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-45105"
    },
    {
      "title": "R\u00e9f\u00e9rence CVE CVE-2021-44228",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-44228"
    },
    {
      "title": "[4] R\u00e9f\u00e9rence CVE CVE-2021-45046",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-45046"
    },
    {
      "title": "[2] liste des produits et de leurs statuts vis-\u00e0-vis de la vuln\u00e9rabilit\u00e9",
      "url": "https://github.com/NCSC-NL/log4shell/tree/main/software"
    },
    {
      "title": "Bulletin de s\u00e9curit\u00e9 Apache du 09 d\u00e9cembre 2021",
      "url": "https://logging.apache.org/log4j/2.x/security.html"
    },
    {
      "title": "[3] R\u00e9f\u00e9rence CVE CVE-2021-4104",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-4104"
    }
  ],
  "reference": "CERTFR-2021-ALE-022",
  "revisions": [
    {
      "description": "Version initiale",
      "revision_date": "2021-12-10T00:00:00.000000"
    },
    {
      "description": "Compl\u00e9ment concernant les versions vuln\u00e9rables",
      "revision_date": "2021-12-12T00:00:00.000000"
    },
    {
      "description": "compl\u00e9ment concernant la jre",
      "revision_date": "2021-12-12T00:00:00.000000"
    },
    {
      "description": "ajout d\u0027aide \u00e0 la d\u00e9tection, note sur l\u0027utilisation des pare-feux applicatifs, compl\u00e9ment sur les solutions.",
      "revision_date": "2021-12-14T00:00:00.000000"
    },
    {
      "description": "Ajout de r\u00e9f\u00e9rence vers les outils de d\u00e9tection et note importante sur les m\u00e9thodes d\u0027attaque ainsi que les derni\u00e8res versions de log4j",
      "revision_date": "2021-12-15T00:00:00.000000"
    },
    {
      "description": "Evolution de la section solution",
      "revision_date": "2021-12-16T00:00:00.000000"
    },
    {
      "description": "prise en compte de la CVE-2021-45105 et ajout d\u0027\u00e9l\u00e9ments d\u0027aide \u00e0 la d\u00e9tection",
      "revision_date": "2021-12-20T00:00:00.000000"
    },
    {
      "description": "correction motif de d\u00e9tection, compl\u00e9ment outillage, note sur la possibilit\u00e9 d\u0027exploiter la vuln\u00e9rabilit\u00e9 sur une application interne",
      "revision_date": "2021-12-22T00:00:00.000000"
    },
    {
      "description": "Prise en compte de la CVE-2021-44832",
      "revision_date": "2022-01-05T00:00:00.000000"
    },
    {
      "description": "correction date 05 janvier 2022, ajout du fichier signatures",
      "revision_date": "2022-01-07T00:00:00.000000"
    },
    {
      "description": "Cl\u00f4ture de l\u0027alerte. Cela ne signifie pas la fin d\u0027une menace. Seule l\u0027application de la mise \u00e0 jour permet de vous pr\u00e9munir contre l\u0027exploitation de la vuln\u00e9rabilit\u00e9 correspondante.",
      "revision_date": "2022-05-04T00:00:00.000000"
    }
  ],
  "risks": [
    {
      "description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
    }
  ],
  "summary": "Une vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 d\u00e9couverte dans la biblioth\u00e8que de\njournalisation Apache log4j. Cette biblioth\u00e8que est tr\u00e8s souvent\nutilis\u00e9e dans les projets de d\u00e9veloppement d\u0027application Java/J2EE ainsi\nque par les \u00e9diteurs de solutions logicielles sur \u00e9tag\u00e8re bas\u00e9es sur\nJava/J2EE.\n\nCette vuln\u00e9rabilit\u00e9 permet \u00e0 un attaquant de provoquer une ex\u00e9cution de\ncode arbitraire \u00e0 distance s\u0027il a la capacit\u00e9 de soumettre une donn\u00e9e \u00e0\nune application qui utilise la biblioth\u00e8que log4j pour journaliser\nl\u0027\u00e9v\u00e8nement. Cette attaque peut \u00eatre r\u00e9alis\u00e9e sans \u00eatre authentifi\u00e9, par\nexemple en tirant parti d\u0027une page d\u0027authentification qui journalise les\nerreurs d\u0027authentification.\n\nDes preuves de concept ont d\u00e9j\u00e0 \u00e9t\u00e9 publi\u00e9es. Cette vuln\u00e9rabilit\u00e9 fait\nd\u00e9sormais l\u0027objet d\u0027une exploitation active.\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003c/div\u003e\n\n\u003c/div\u003e\n\n\u003c/div\u003e\n\n### D\u00e9tection\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\nLe CERT-FR recommande de r\u00e9aliser une analyse approfondie des journaux\nr\u00e9seau. Les motifs suivants permettent d\u0027identifier une tentative\nd\u0027exploitation de cette vuln\u00e9rabilit\u00e9 lorsqu\u0027ils sont utilis\u00e9s dans les\nURLs ou certaines en-t\u00eates HTTP comme *user-agent* :\n\n\u003c/div\u003e\n\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \\${jndi:\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \\$%7Bjndi:\u00a0\u00a0\u00a0\u00a0 (prend en compte un obscurcissement simple)\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\nCependant, les attaquants peuvent utiliser des moyens d\u2019obscurcissement\npour contourner les motifs de d\u00e9tection pr\u00e9c\u00e9dents. Les motifs suivants\npermettent de prendre en compte certaines m\u00e9thodes d\u0027obscurcissement\nmais \u003cstrong\u003epeuvent provoquer des faux positifs :  \n\u003c/strong\u003e\n\n\u003c/div\u003e\n\n\u003c/div\u003e\n\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \\${\\${\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003cspan class=\"mx_MTextBody mx_EventTile_content\"\u003e\u003cspan\n\u003e class=\"mx_EventTile_body\" dir=\"auto\"\u003e\\${::-\u003c/span\u003e\u003c/span\u003e\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003cspan class=\"mx_MTextBody mx_EventTile_content\"\u003e\u003cspan\n\u003e class=\"mx_EventTile_body\" dir=\"auto\"\u003e%24%7B%3A%3A-\u003c/span\u003e\u003c/span\u003e\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003cspan class=\"mx_MTextBody mx_EventTile_content\"\u003e\u003cspan\n\u003e class=\"mx_EventTile_body\" dir=\"auto\"\u003e\\${env:\u003c/span\u003e\u003c/span\u003e\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003cspan class=\"mx_MTextBody mx_EventTile_content\"\u003e\u003cspan\n\u003e class=\"mx_EventTile_body\" dir=\"auto\"\u003e\\${date:\u003c/span\u003e\u003c/span\u003e\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003cspan class=\"mx_MTextBody mx_EventTile_content\"\u003e\u003cspan\n\u003e class=\"mx_EventTile_body\" dir=\"auto\"\u003e\\${lower:\u003c/span\u003e\u003c/span\u003e\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003cspan class=\"mx_MTextBody mx_EventTile_content\"\u003e\u003cspan\n\u003e class=\"mx_EventTile_body\" dir=\"auto\"\u003e\\${upper:\u003c/span\u003e\u003c/span\u003e\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003cspan class=\"mx_MTextBody mx_EventTile_content\"\u003e\u003cspan\n\u003e class=\"mx_EventTile_body\" dir=\"auto\"\u003ehostName}\u003c/span\u003e\u003c/span\u003e\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \u003cspan class=\"mx_MTextBody mx_EventTile_content\"\u003e\u003cspan\n\u003e class=\"mx_EventTile_body\" dir=\"auto\"\u003e}\\${\u003c/span\u003e\u003c/span\u003e\n\u003e\n\u003e \u003c/div\u003e\n\u003e\n\u003e \u003cdiv markdown=\"1\"\u003e\n\u003e\n\u003e \\${\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 (g\u00e9n\u00e8re beaucoup de faux positifs, mais tr\u00e8s\n\u003e exhaustif)\n\u003e\n\u003e \u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cspan style=\"color: #ff0000;\" darkreader-inline-color=\"\"\u003e\u003cstrong\u003e\u00a0\u003c/strong\u003e\u003c/span\u003e\n\n\u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\nAfin de d\u00e9terminer si une tentative d\u0027exploitation a r\u00e9ussi, et dans le\ncas o\u00f9 vous disposeriez de journaux contenant des requ\u00eates DNS, il est\nrecommand\u00e9 de les corr\u00e9ler aux r\u00e9sultats des motifs pr\u00e9c\u00e9demment\n\u00e9nonc\u00e9s. En effet, si l\u2019ex\u00e9cution d\u0027une requ\u00eate de type\n*\\${jndi:xxx://nom.domaine.com}* a fonctionn\u00e9, une r\u00e9solution DNS sera\nalors effectu\u00e9e pour r\u00e9soudre le nom de domaine externe\n*nom*.*domaine.com*. L\u0027\u00e9mission d\u0027une requ\u00eate DNS peut \u00e9galement faire\nl\u0027objet d\u0027une trace dans les journaux du serveur applicatif. Ainsi, il\npeut \u00eatre utile de chercher le motif *com.sun.jndi.dns.DnsContext@* dans\nces journaux.\n\n\u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\nNote : une r\u00e9solution de domaine externe ne signifie pas qu\u0027une\nex\u00e9cution de code a r\u00e9ussi mais permet de \u003cstrong\u003econfirmer que l\u0027application\nest vuln\u00e9rable\u003c/strong\u003e. Il sera donc n\u00e9cessaire de poursuivre l\u0027analyse des\njournaux pour d\u00e9tecter une compromission.\n\n\u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\nEn compl\u00e9ment des informations ci-dessus, une requ\u00eate de type\n*\\${jndi:dns://serveur_dns/enregistrement_TXT}* est \u00e9galement utilisable\npar l\u0027attaquant pour tester la pr\u00e9sence de la vuln\u00e9rabilit\u00e9.\n\n\u003c/div\u003e\n\n\u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003c/div\u003e\n\n\u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\nIl est \u00e9galement int\u00e9ressant de rechercher les motifs suivants dans les\nfichiers journaux des applications :\n\n\u003c/div\u003e\n\n-   le motif\u00a0*\u003cspan class=\"mx_MTextBody mx_EventTile_content\"\u003e\u003cspan\n    class=\"mx_EventTile_body markdown-body\"\n    dir=\"auto\"\u003ecom.sun.jndi.ldap.LdapCtx@\u003c/span\u003e\u003c/span\u003e* (et non pas\n    *com.sun.jndi.dns.DnsContext@* comme indiqu\u00e9 pr\u00e9c\u00e9demment)\n    appara\u00eetra lorsqu\u0027une injection LDAP est utilis\u00e9e pour r\u00e9cup\u00e9rer du\n    contenu qui ne serait pas un objet java au standard rfc2713 : il\n    peut s\u0027agir d\u0027un scan de d\u00e9tection ou d\u0027une tentative erron\u00e9e d\u0027un\n    attaquant\n-   l\u0027injection sera enregistr\u00e9e dans les journaux telle qu\u0027elle a \u00e9t\u00e9\n    soumise par l\u0027attaquant si le serveur LDAP n\u0027est pas joignable ou si\n    l\u0027objet qu\u0027il souhaitait t\u00e9l\u00e9charger n\u0027est pas trouv\u00e9 sur le serveur\n    LDAP : il est donc possible de trouver des tentatives d\u0027injection\n    sous une forme obscurcie dans les journaux, les motifs pr\u00e9c\u00e9demment\n    list\u00e9s peuvent donc \u00eatre utilis\u00e9s pour identifier toutes les\n    tentatives\n-   une erreur contenant le motif \"Reference Class Name:\" suivi d\u0027un nom\n    de classe puis des lignes commen\u00e7ant par \"*Type:*\" et \"*Content:*\"\n    peut appara\u00eetre dans les journaux si l\u0027injection LDAP fonctionne\n    mais que la classe contenant la charge utile ne peut pas \u00eatre\n    r\u00e9cup\u00e9r\u00e9e sur le serveur LDAP vis\u00e9\n-   il peut \u00eatre int\u00e9ressant de chercher des injections en DNS et LDAP\n    bas\u00e9es sur la classe *JavaLookup* tels que *\\${java:hw}*,\n    *\\${java:vm}* et *\\${java:os}*. Ces derni\u00e8res sont utilis\u00e9es par les\n    attaquants pour obtenir des informations sur la machine cibl\u00e9e.*  \n    *\n\n\u003cspan style=\"color: #ff0000;\"\u003e\u003cstrong\u003e\\[Mise \u00e0 jour du 07 janvier\n2022\\]\u003c/strong\u003e\u003c/span\u003e Le CERT-FR propose au t\u00e9l\u00e9chargement un ensemble de\nr\u00e8gles de d\u00e9tection bas\u00e9es sur la syntaxe utilis\u00e9e par l\u0027outil suricata.\nCes r\u00e8gles peuvent \u00eatre mises en \u0153uvre, apr\u00e8s adaptation, sur un\n\u00e9quipement de d\u00e9tection r\u00e9seau ou un pare-feu applicatif. Un guide de\nmise en \u0153uvre est \u00e9galement propos\u00e9.\n\n-   le guide est disponible \u003cspan style=\"color: #ff0000;\"\u003e\u003ca\n    href=\"/uploads/ANSSI_Detection_log4j_NP_TLP_WHITE_v1.0.6.pdf\"\n    style=\"color: #ff0000;\"\u003eici\u003c/a\u003e\u003c/span\u003e.\n-   les r\u00e8gles sont disponibles\n    [ici](/uploads/anssi_cve_2021_44228_and_jndi_export_v3.txt).\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n### Pr\u00e9cisions sur les CVE-2021-45046 et CVE-2021-45105\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\nLa version 2.15.0 recommand\u00e9e jusqu\u0027\u00e0 pr\u00e9sent est affect\u00e9e par une autre\nvuln\u00e9rabilit\u00e9, d\u00e9sign\u00e9e par l\u0027identifiant CVE-2021-45046 \\[4\\]. Cette\nvuln\u00e9rabilit\u00e9 permet \u00e0 un attaquant non authentifi\u00e9 d\u0027effectuer un d\u00e9ni\nde service. Par ailleurs, des chercheurs ont mis en \u00e9vidence la\npossibilit\u00e9 d\u0027exfiltrer des donn\u00e9es dans certaines configurations non\nd\u00e9taill\u00e9es.\n\n\u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\nPar ailleurs, les versions 2.16.0 et 2.12.2 sont affect\u00e9es par une\nnouvelle vuln\u00e9rabilit\u00e9, d\u00e9sign\u00e9e par l\u0027identifiant CVE-2021-45105 \\[5\\],\nqui permet de provoquer un d\u00e9ni de service \u00e0 distance.\n\n\u003c/div\u003e\n\n### Pr\u00e9cisions sur la CVE-2021-44832\n\nLa version 2.17.0 recommand\u00e9e jusqu\u0027\u00e0 pr\u00e9sent est affect\u00e9e par une\nvuln\u00e9rabilit\u00e9, d\u00e9sign\u00e9e par l\u0027identifiant CVE-2021-44832 \\[6\\]. Cette\nvuln\u00e9rabilit\u00e9 permet \u00e0 un attaquant, autoris\u00e9 \u00e0 modifier le fichier de\nconfiguration Log4J, d\u0027effectuer une ex\u00e9cution de code \u00e0 distance. La\ncomplexit\u00e9 de l\u0027attaque \u00e9tant \u00e9lev\u00e9e, le CERT-FR continue de recommander\nla mise \u00e0 jour des composants Log4j \u00e0 la version 2.17.0 pour java 8 et\n2.12.3 pour java7. Par ailleurs, il est fortement recommand\u00e9 de rester\nattentif aux nouvelles vuln\u00e9rabilit\u00e9s Log4j qui pourraient \u00eatre\nidentifi\u00e9es \u00e0 l\u0027avenir ainsi qu\u0027aux correctifs propos\u00e9s par Apache.\n\n### Pr\u00e9cisions sur les modes d\u0027attaque\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\nIl convient \u00e9galement de noter que des techniques permettent d\u0027exploiter\nla vuln\u00e9rabilit\u00e9 localement sans recourir \u00e0 un serveur tiers\nmalveillant. L\u0027attaquant peut injecter un code malveillant dans la\nrequ\u00eate initiale s\u0027il a suffisamment d\u0027informations sur l\u0027application\nvuln\u00e9rable qu\u0027il cible. Cette attaque requiert donc une premi\u00e8re phase\nde reconnaissance et de collecte de donn\u00e9es. Cette phase est possible\ntant que n\u0027ont pas \u00e9t\u00e9 appliqu\u00e9s : d\u0027une part, un filtrage r\u00e9seau\nad\u00e9quat et d\u0027autre part, le correctif ou, \u00e0 d\u00e9faut, les mesures de\ncontournement. Il est donc important de disposer des journaux de ces\nenvironnements pour rechercher des \u00e9ventuelles traces d\u0027exfiltration de\ndonn\u00e9es. Les moyens de d\u00e9tection pr\u00e9c\u00e9demment peuvent \u00eatre utilis\u00e9s \u00e0\ncette fin.\n\n\u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cspan style=\"color: #ff0000;\" darkreader-inline-color=\"\"\u003e\u003cstrong\u003e\u00a0\u003c/strong\u003e\u003c/span\u003e\n\n\u003c/div\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\n\u003cdiv markdown=\"1\"\u003e\n\nPour rappel : une application utilisant une version non vuln\u00e9rable de\nlog4j peut transmettre des donn\u00e9es \u00e0 une autre application qui utilise\nune version vuln\u00e9rable de cette biblioth\u00e8que. L\u2019attaquant pourra\nexploiter la vuln\u00e9rabilit\u00e9 dans la seconde application en soumettant une\ndonn\u00e9e malveillante via la premi\u00e8re. Par cons\u00e9quent, le CERT-FR\nrecommande de ne pas limiter l\u0027identification de la vuln\u00e9rabilit\u00e9 aux\nseules applications expos\u00e9es sur Internet, mais \u00e9galement aux\napplications internes. L\u0027utilisation d\u0027outils tels que ceux list\u00e9s\nci-dessous facilitera leur identification.\n\n\u003c/div\u003e\n\n\u003c/div\u003e\n\n\u003c/div\u003e\n\n\u003c/div\u003e\n\n\u003c/div\u003e\n\n\u003c/div\u003e\n",
  "title": "[MaJ] Vuln\u00e9rabilit\u00e9 dans Apache Log4j",
  "vendor_advisories": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…