Les vulnérabilités de Log4j sont là pour rester — Êtes-vous prêt ?

La vulnérabilité généralisée qui est apparue pour la première fois dans Apache Log4j en 2021 continuera d'être exploité, potentiellement même de manière pire que ce que nous avons vu jusqu'à présent. L'aspect le plus inquiétant de ces menaces est qu'il y a de fortes chances qu'elles continuent d'être exploitées des mois ou des années dans le futur.

Le comité d'examen de la cybersécurité du ministère de la Sécurité intérieure a fait ses débuts en 2021 et, en 2022, a publié son premier rapport de sécurité (PDF). Dans ce document, le conseil a qualifié Log4j de "vulnérabilité endémique", principalement parce qu'il n'y a pas de "liste de clients" complète pour Log4j, ce qui rend le suivi des vulnérabilités une tâche presque impossible. Un département du Cabinet fédéral a même passé 33,000 4 heures sur sa réponse LogXNUMXj.

Et de nombreuses organisations et solutions de sécurité sur le marché ne parviennent pas à identifier la différence entre l'exploitabilité et la vulnérabilité, ce qui laisse aux attaquants la possibilité de mener des activités malveillantes.

Exploitabilité vs Vulnérabilité

L'un des principaux enjeux de la cybersécurité aujourd'hui est de comprendre la différence entre les vulnérabilités et leur gravité. Lorsqu'il s'agit de mesurer l'exploitabilité par rapport à une vulnérabilité, il existe une grande différence entre le fait qu'une menace de sécurité est exploitable au sein de votre entreprise ou si elle est simplement « vulnérable » et ne peut pas entraver l'activité ou atteindre un actif critique. Les équipes de sécurité passent trop de temps à ne pas comprendre la différence entre les deux et corrigent chaque vulnérabilité au fur et à mesure, au lieu de prioriser celles qui sont exploitables.

Chaque entreprise a des milliers de vulnérabilités et d'expositions communes (CVE), dont beaucoup obtiennent un score élevé sur le Common Vulnerability Scoring System (CVSS), il est donc impossible de toutes les corriger. Pour lutter contre cela, l'espoir est que les outils de gestion des vulnérabilités basés sur les risques (RBVM) faciliter la priorisation en clarifiant ce qui est exploitable.

Cependant, les approches de hiérarchisation de la sécurité qui combinent les scores CVSS avec les informations sur les menaces RBVM ne fournissent pas de résultats optimaux. Même après avoir filtré et examiné uniquement ce qui est exploitable dans la nature, les équipes de sécurité ont encore trop à gérer car la liste est longue et ingérable. Et ce n'est pas parce qu'un CVE n'a pas d'exploit aujourd'hui qu'il n'en aura pas la semaine prochaine.

En réponse, les entreprises ont ajouté une IA prédictive des risques, qui peut aider les utilisateurs à comprendre si un CVE pourrait être exploité à l'avenir. Cela ne suffit toujours pas et entraîne trop de problèmes à résoudre. Des milliers de vulnérabilités montreront toujours un exploit, mais beaucoup auront d'autres ensembles de conditions qui doivent être remplies pour exploiter réellement le problème.

Par exemple, avec Log4j, les paramètres suivants doivent être identifiés :

• La bibliothèque vulnérable Log4j existe-t-elle ?
• Est-il chargé par une application Java en cours d'exécution ?
• La recherche JNDI est-elle activée ?
• Java écoute-t-il les connexions distantes et existe-t-il une connexion pour d'autres machines ?

Si les conditions et les paramètres ne sont pas remplis, la vulnérabilité n'est pas critique et ne doit pas être priorisée. Et même si une vulnérabilité pouvait être exploitable sur une machine, et alors ? Cette machine est-elle extrêmement critique, ou peut-être n'est-elle connectée à aucun actif critique ou sensible ?

Il est également possible que la machine ne soit pas importante, mais qu'elle puisse permettre à un attaquant de continuer vers des actifs critiques de manière plus furtive. En d'autres termes, le contexte est essentiel : cette vulnérabilité est-elle une voie d'attaque potentielle vers l'actif critique ? Suffit-il de couper une vulnérabilité à un point d'étranglement (une intersection de plusieurs chemins d'attaque) pour empêcher le chemin d'attaque d'atteindre un actif critique ?

Les équipes de sécurité détestent les processus de vulnérabilité et leurs solutions, car il y a de plus en plus de vulnérabilités - personne ne peut jamais effacer complètement l'ardoise. Mais s'ils peuvent concentrez-vous sur ce qui peut créer des dommages à un actif critique, ils peuvent mieux comprendre par où commencer.

Combattre les vulnérabilités de Log4j

La bonne nouvelle est qu'une bonne gestion des vulnérabilités peut aider à réduire et à corriger l'exposition aux attaques centrées sur Log4j en identifiant où se trouve le risque d'exploitation potentielle.

La gestion des vulnérabilités est un aspect important de la cybersécurité et est nécessaire pour assurer la sécurité et l'intégrité des systèmes et des données. Cependant, ce n'est pas un processus parfait et des vulnérabilités peuvent toujours être présentes dans les systèmes malgré tous les efforts déployés pour les identifier et les atténuer. Il est important d'examiner et de mettre à jour régulièrement les processus et stratégies de gestion des vulnérabilités pour s'assurer qu'ils sont efficaces et que les vulnérabilités sont traitées en temps opportun.

La gestion des vulnérabilités ne doit pas seulement se concentrer sur les vulnérabilités elles-mêmes, mais également sur le risque potentiel d'exploitation. Il est important d'identifier les points où un attaquant peut avoir accédé au réseau, ainsi que les chemins qu'il peut emprunter pour compromettre les actifs critiques. Le moyen le plus efficace et le plus rentable d'atténuer les risques d'une vulnérabilité particulière est d'identifier les liens entre les vulnérabilités, les erreurs de configuration et le comportement des utilisateurs qui pourraient être exploités par un attaquant, et de résoudre ces problèmes de manière proactive avant que la vulnérabilité ne soit exploitée. Cela peut aider à perturber l'attaque et à éviter d'endommager le système.

Vous devez également procéder comme suit :

• Patch: Identifiez tous vos produits vulnérables à Log4j. Cela peut être fait manuellement ou en utilisant des scanners open source. Si un correctif pertinent est publié pour l'un de vos produits vulnérables, corrigez le système dès que possible.
• Solution: Sur les versions 4 et supérieures de Log2.10.0j, dans la ligne Java CMD, définissez ce qui suit : log4j2.formatMsgNoLookups=true
• Bloc: Si possible, ajoutez une règle au pare-feu de votre application Web pour bloquer : "jndi :"

La sécurité parfaite est un exploit irréalisable, il est donc inutile de faire de la perfection l'ennemie du bien. Au lieu de cela, concentrez-vous sur la hiérarchisation et le verrouillage des chemins d'attaque potentiels qui améliorent en permanence la sécurité. Identifier et être réaliste quant à ce qui est réellement vulnérable par rapport à ce qui est exploitable peut aider à le faire, car cela permettra de canaliser stratégiquement les ressources vers les domaines critiques qui comptent le plus.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
• La source: https://www.darkreading.com/attacks-breaches/log4j-vulnerabilities-are-here-to-stay-are-you-prepared-