Table des matières[Cacher][Montrer]
Log4Shell, une vulnérabilité Internet, a récemment affecté des millions de machines. Log4j, un logiciel obscur mais presque omniprésent, en est la cause.
Log4j est utilisé pour enregistrer toutes les actions qui se produisent en coulisses dans une variété de systèmes informatiques.
Il est basé sur une bibliothèque de journalisation open source utilisée par les entreprises et même les organisations gouvernementales dans la plupart des applications.
Étant l'une des pires failles de cybersécurité jamais découvertes, il est essentiel de protéger vos systèmes de cette vulnérabilité. Mais comment?
Explorons en détail la vulnérabilité Log4j et toutes les solutions possibles pour y remédier.
Qu'est-ce que Log4j ?
Log4j est un open-source cadre de journalisation qui permet aux développeurs de logiciels d'enregistrer différentes données dans leurs applications. C'est un composant du projet Apache Logging Services, qui est exécuté par le Apache Software Foundation.
Des centaines de sites Web et d'applications utilisent Log4j pour effectuer des opérations critiques telles que la journalisation des données pour le débogage et d'autres utilisations.
Lorsque vous saisissez ou cliquez sur un lien en ligne médiocre et que vous recevez un avis d'erreur 404, il s'agit d'un exemple fréquent de Log4j au travail. Le serveur Web qui exécute le domaine du lien Web auquel vous avez tenté d'accéder vous informe qu'aucune page Web de ce type n'existe. Il enregistre également l'événement dans Log4j pour les administrateurs système du serveur.
Dans tous les programmes logiciels, des signaux de diagnostic similaires sont utilisés. Dans le jeu en ligne Minecraft, par exemple, le serveur utilise Log4j pour enregistrer des activités telles que la RAM totale utilisée et les instructions utilisateur envoyées à la console.
Comment la vulnérabilité se produit-elle ?
Les recherches sont une nouvelle fonctionnalité introduite dans Log4j 2.0, qui aide à incorporer des informations supplémentaires dans les entrées de journal. L'une de ces recherches est la recherche JNDI (Java Naming and Directory Interface), qui est une API Java permettant de communiquer avec un service d'annuaire.
Grâce à cette approche, les ID utilisateur internes peuvent être mappés sur des noms d'utilisateur réels. Cette requête expose la vulnérabilité RCE nouvellement découverte, car l'un des types de données fournis par le serveur LDAP est un URI pointant vers une classe Java, qui est ensuite chargée en mémoire et exécutée par l'instance Log4j.
En raison d'une faiblesse dans la validation des entrées de la bibliothèque Log4j, il est possible d'injecter un serveur LDAP arbitraire à partir d'une source non fiable. Étant donné que les développeurs supposent que les données envoyées aux journaux seront traitées comme du texte brut, aucune validation d'entrée supplémentaire n'est entreprise et une entrée utilisateur dangereuse entre dans les journaux.
Une instruction de journal peut ressembler à ceci :
Un utilisateur malveillant insèrerait désormais une recherche JNDI faisant référence à un serveur LDAP non autorisé dans un paramètre d'URL. La recherche JNDI serait la suivante :
La bibliothèque Log4j communique ensuite avec ce serveur LDAP sur attacker.com pour obtenir des informations sur le répertoire, y compris les valeurs de Java Factory et Java Codebase.
Ces deux valeurs incluent la classe Java de l'attaquant, qui est ensuite chargée en mémoire et exécutée par l'instance Log4j, complétant l'exécution du code.
Quelles sont les personnes à risque ?
La vulnérabilité Log4j est incroyablement large, affectant les applications métier, les appareils embarqués et leurs sous-systèmes. Les applications concernées incluent Cisco Webex, Minecraft et FileZilla FTP.
Cependant, ce n'est en aucun cas une liste complète. La faille a même un impact sur la mission chopper Ingenuity Mars 2020, qui utilise Apache Log4j pour l'enregistrement des événements.
La communauté de la sécurité a compilé un liste des systèmes vulnérables. Il est crucial de noter que ces listes sont mises à jour en permanence, donc si un certain programme ou système n'est pas présenté, ne présumez pas qu'il n'est pas affecté.
L'exposition à cette vulnérabilité est tout à fait probable, et même si un pile technologique n'applique pas Java, les responsables de la sécurité doivent s'attendre à ce que les systèmes fournisseurs critiques, les fournisseurs SaaS, les fournisseurs d'hébergement cloud et les fournisseurs de serveurs Web le fassent.
Comment vérifier la vulnérabilité Log4j ?
La première étape consiste à déterminer si une agression a déjà eu lieu. Vous pouvez le faire en vérifiant les journaux système pour les fragments de charge utile RCE.
Si une recherche de termes tels que "jndi", "ldap" ou "$ ::" donne des journaux, les chercheurs en sécurité devraient explorer davantage pour voir s'il s'agissait d'une attaque légitime ou simplement d'une prise d'empreintes digitales.
De nombreux assauts dans la nature ont été découverts qui n'ont livré aucune charge utile nocive. Néanmoins, elles ont été réalisées par des experts en sécurité pour déterminer combien d'applications étaient vulnérables à cette attaque.
L'étape suivante consiste à utiliser la bibliothèque Log4j pour identifier tous les projets. Si des versions entre 2.0-beta9 et 2.14.1 sont utilisées, le projet peut être sensible.
Étant donné la difficulté à déterminer où cette vulnérabilité existe, il peut être préférable de présumer que le projet est susceptible et que la mise à jour de la bibliothèque est la meilleure ligne de conduite pour éliminer le danger d'exécution de code.
Le projet n'est pas vulnérable si la version utilisée est inférieure à 2.0-beta 9, bien que la bibliothèque Log4j doive encore être mise à niveau car les versions de la gamme 1.x sont anciennes et ne reçoivent plus de mises à jour.
Si un projet sensible est découvert, il est conseillé de le vérifier pour voir si des informations enregistrées à l'aide de Log4j contiennent des informations que l'utilisateur peut modifier. Les URL, les paramètres de requête, les en-têtes et les cookies sont des exemples de ces données. Si l'un d'entre eux est enregistré, le projet est en danger.
Cette connaissance peut vous aider à approfondir les journaux système et à déterminer si votre application Web a déjà été attaquée.
Il existe des outils en ligne gratuits qui peuvent détecter si une application Web est vulnérable. L'un de ces programmes est Log4Shell chasseresse. Il est open-source et disponible sur GitHub.
Si une zone de code vulnérable dans l'application en ligne est découverte, la charge utile fournie par l'outil décrit peut être utilisée pour l'injecter dans l'application Web. L'outil de test révélerait les connexions établies entre votre application Web et son serveur LDAP si la vulnérabilité était exploitée.
Solutions pour corriger la vulnérabilité Log4j
La première étape consiste à mettre à jour Log4j, ce que vous pouvez faire en utilisant les gestionnaires de packages normaux ou en le téléchargeant directement à partir de ce page.
Il est également possible de diminuer l'exploitabilité de la vulnérabilité en définissant la variable d'environnement FORMAT MSG NO LOOKUPS sur true. Cette contre-mesure n'est cependant applicable qu'aux versions de Log4j supérieures ou égales à 2.10.
Considérons maintenant les options alternatives.
1. Solutions de contournement pour Log4j version 2.17.0
Il est certainement fortement conseillé d'utiliser Log4j version 2.15.0 pour se protéger contre Log4Shell, cependant, si cela n'est pas possible, d'autres solutions sont disponibles.
Versions 2.7.0 et ultérieures de Log4j : Il est possible de se protéger contre toute attaque en modifiant le format des événements à journaliser en utilisant la syntaxe percent m nolookups pour les données fournies par l'utilisateur. Cette mise à jour nécessite la modification du fichier de configuration Log4j pour générer une nouvelle version du programme. Par conséquent, avant de déployer cette nouvelle version, les étapes de validation technique et fonctionnelle doivent être répétées.
Log4j versions 2.10.0 et ultérieures : Il est également possible de se prémunir contre toute attaque en mettant le paramètre de configuration log4j2.formatMsgNoLookups à true, par exemple, lors du démarrage de la machine virtuelle Java avec l'option -Dlog4j2. formatMsgNoLookups = true, Une autre option consiste à supprimer la classe JndiLookup de l'argument classpath, ce qui supprimera le vecteur d'attaque principal (les chercheurs n'excluent pas la possibilité d'un autre vecteur d'attaque).
Amazon Web Services fournit un hotpatch qui « doit être utilisé à vos risques et périls ». D'autres « techniques », comme Logout4Shell, qui « utilise cette vulnérabilité contre elle-même », ont été publiées. L'expert en sécurité s'interroge sur la légalité de cette décision, qui consiste à "pirater une machine pour la réparer".
2. Le problème a été résolu dans Log4j v2.17.0.
Pour les versions supérieures à 2.10 : Log4j2.formatMsgNoLookups doit être défini sur true.
Pour les versions 2.0 à 2.10.0 : exécutez la commande suivante pour supprimer la classe LDAP de Log4j.
Log4j2.formatMsgNoLookups doit être défini sur true dans les paramètres système.
Atténuation dans JVM
L'atténuation avec les paramètres JVM n'est plus une option. D'autres méthodes d'atténuation continuent de donner de bons résultats. Mettez à niveau vers Log4j version 2.17.0 si possible. Un guide de migration est disponible pour Log4j v1.
Si une mise à jour n'est pas possible, assurez-vous que les composants côté client et côté serveur ont la propriété système -Dlog4j2.formatMsgNoLookups = true définie.
Veuillez noter que Log4j v1 a atteint sa fin de vie (EOL) et ne recevra plus de corrections de bogues. D'autres vecteurs RCE sont également sensibles à Log4j v1. Par conséquent, nous vous invitons à effectuer une mise à niveau vers Log4j 2.17.0 dès que possible.
3. Mesures d'atténuation
Les exploits actuels ne peuvent pas fonctionner même si Log4j est sensible dans certains cas, par exemple si la machine hôte exécute une version Java supérieure à 6u212, 7u202, 8u192 ou 11.0.2.
Cela est dû à une meilleure protection du chargement de classe à distance Java Naming and Directory Interface (JNDI) dans les versions actuelles, qui est nécessaire pour que l'attaque fonctionne.
De plus, avec les versions de Log4j supérieures à 2.10, le problème peut être évité en définissant la valeur système formatMsgNoLookups sur true, en fournissant l'argument JVM -Dlog4j2.formatMsgNoLookups = true, ou en supprimant la classe JndiLookup du classpath.
En attendant, jusqu'à ce que les instances vulnérables soient corrigées, la vulnérabilité peut être corrigée à l'aide des techniques ci-dessous :
- Définissez la propriété système log4j2.formatMsgNoLookups sur true pour >=2.10.
- Définissez l'option d'environnement LOG4J FORMAT MSG NO LOOKUPS sur true pour >=2.10.
- Supprimez JndiLookup.class du chemin de classe pour 2.0-beta9 à 2.10.0 : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Une bonne pratique recommandée consiste à limiter le trafic de sortie vers Internet aux seuls ports appropriés.
Bien que la plupart des attaques sur le terrain soient livrées via HTTP, la vulnérabilité peut être exploitée via n'importe quel protocole qui enregistre les données d'entrée de l'utilisateur à l'aide de Log4j.
Cependant, la mise à jour vers log4j 2.17.0 est le meilleur remède car quelqu'un peut découvrir une approche supplémentaire du problème. De plus, de nombreux éditeurs et fabricants ont annoncé des améliorations de leurs services ou applications.
4. Correctif de vulnérabilité Log4Shell
Log4j est omniprésent, surtout maintenant que la vulnérabilité est exploitée. Pour résumer, il vous suffit d'inclure les caractères suivants dans les journaux inspectés par Log4j.
Et cela téléchargera et exécutera le fichier Java situé à la fin de l'URL. C'est aussi simple que dramatique.
Comme vous le savez, il est essentiel de mettre à niveau log4j vers la version >= 2.17.0 pour remédier à cette vulnérabilité Log4Shell (CVE-2021-44228).
Si ce n'est pas possible :
Pour les applications qui utilisent les versions 4 et ultérieures de la bibliothèque Log2.10.0j, il est également possible de se protéger contre toute attaque en définissant le paramètre de configuration log4j2.formatMsgNoLookups sur true, par exemple lors du démarrage de la machine virtuelle Java avec -Dlog4j2.formatMsgNoLookups = true option.
Une autre option consiste à supprimer la classe JndiLookup de l'argument classpath, ce qui supprimera le vecteur d'attaque principal (les chercheurs n'excluent pas l'existence d'un autre vecteur d'attaque).
Notes
Les organisations qui hésitent ou ne veulent pas apporter d'ajustements aux systèmes sensibles (ou qui le font mais souhaitent installer des protections supplémentaires) doivent réfléchir à :
- Assurez-vous que tout le trafic est acheminé via un iSensor/WAF/IPS. Cela peut empêcher l'agresseur d'accéder au système.
- Limitation de la quantité de trafic pouvant atteindre le système sensible Si le système n'a pas besoin d'être connecté à Internet, limitez l'accès aux seuls IPS et plages essentiels et fiables.
- Réduction du trafic sortant autorisé de l'hébergeur. Étant donné que cette attaque fonctionne en se connectant à un serveur malveillant, toutes les adresses IP et tous les ports superflus doivent être bloqués sur un pare-feu.
- Si le service n'est plus requis, il doit être désactivé jusqu'à ce qu'un correctif soit prêt.
Conclusion
Les failles de Log4j ont choqué notre communauté et nous ont rappelé à tous à quel point nous dépendons des logiciels open source.
Log4j est unique. Ce n'est ni un système d'exploitation, ni un navigateur, ni un logiciel. C'est plutôt ce que les programmeurs appellent une bibliothèque, un package ou un module de code. Cela ne sert qu'à un seul but, c'est-à-dire garder une trace de ce qui se passe sur un serveur.
Les personnes qui écrivent du code préfèrent se concentrer sur ce qui rend leur logiciel distinctif. Ils ne sont pas intéressés à réinventer la roue. En conséquence, ils s'appuient sur une pléthore de bibliothèques de code existantes, telles que Log4j.
Le module Log4j est dérivé d'Apache, le logiciel de serveur Web le plus utilisé. C'est pourquoi il peut être découvert sur des millions de serveurs. Par conséquent, augmentant les menaces de sécurité.
J'espère que les solutions ci-dessus vous aideront à protéger vos appareils.
Restez à l'écoute de HashDork pour plus d'informations utiles sur le monde de la technologie.
Soyez sympa! Laissez un commentaire