Ne paniquez pas : Log4Shell – Blogs performants

Comme beaucoup d'entre vous, nous avons passé notre week-end et le début de cette semaine à trier les risques posés par CVE-2021-44228 (alias Log4Shell).
Comme nous l'avons vérifié et en corrigeant nos systèmes internes, nos produits et nos systèmes clients, certains collègues et moi avons fait quelques observations que nous voulions partager.
Tout d'abord, cependant. Si vous êtes préoccupé par les risques posés par cette vulnérabilité log4j, nous vous recommandons de vous assurer que vous avez corrigé les produits du fournisseur conformément aux instructions du fournisseur et de vous assurer que tous vos systèmes sont mis à jour pour utiliser log4j 2.16.0 ou une version plus récente. En outre, voici quelques autres ressources provenant de sources et de partenaires de confiance que nous trouvons utiles :
Quelques autres notes techniques…
- log4j 2.15.0 semble être pour la plupart sûr, mais il existe plusieurs situations où ce correctif est incomplet car décrit dans CVE-2021-45046nous vous recommandons d'utiliser 2.16.0 dans la mesure du possible. Il s'agit d'une situation dynamique, et cela peut à nouveau changer à mesure que des tests plus approfondis continuent d'être effectués.
- log4j 1.2.x a une vulnérabilité similaire mais plus limitée et aucun correctif ne sera disponible car cette version de log4j a dépassé la fin de vie . Le score CVSS 3.0 pour CVE-2021-4104 est toujours en attente, mais nous nous attendons à ce que le niveau de risque soit inférieur compte tenu des chemins de code limités qui semblent être affectés, mais il existe encore une certaine incertitude ici. Plus d'informations devraient être disponibles bientôt, mais le TL;DR est que vous devriez être d'accord si vous n'utilisez pas JMSAppenders, mais cela peut encore évoluer.
- N'oubliez pas que log4j peut ne pas être une dépendance directe de votre code, il peut être une dépendance d'une dépendance ou plus bas dans l'arbre des dépendances. Il est important d'utiliser votre outil de gestion des dépendances (c'est-à-dire Maven, Gradle, etc.) pour rechercher dans l'arborescence complète des références à log4j.
- La vulnérabilité elle-même est assez simple et incroyablement facile à exploiter. Il utilise la magie des recherches JNDI, une fonctionnalité de Java qui vous permet d'interagir de manière transparente avec une variété de services d'annuaire et de nommage. Dans ce cas, l'exploit utilise LDAP (Lightweight Directory Access Protocol) et une petite astuce pour obtenir la recherche JNDI pour extraire ce qu'il pense être un objet d'un serveur LDAP via une redirection vers un point de terminaison https mais c'est vraiment du code qui sera exécuté sur le serveur vulnérable. Le risque ici est que n'importe quel endroit dans une application pour lequel un utilisateur peut transmettre une entrée textuelle et que le texte est enregistré tel quel, sera susceptible de recevoir un code arbitraire qui lui sera transmis et exécuté dans cette entrée de texte.
Passons maintenant à la partie intéressante. Alors que nous en discutions en interne, nous avons réalisé quelques points sur le risque posé par la vulnérabilité log4shell : . " Il y a deux manières principales que cette pensée est imparfaite. Premièrement, empêcher parfaitement un acteur malveillant d'accéder à votre réseau est impossible. Non seulement les pare-feu ne sont pas parfaits, mais l'ingénierie sociale et les employés en colère peuvent les contourner complètement. Deuxièmement, ce type de vulnérabilité peut être exploité en cascadant une chaîne incriminée d'un système à l'autre via des appels de service le long de la chaîne jusqu'à ce qu'il en trouve une qui soit vulnérable.
Si vous avez besoin d'aide pour résoudre les problèmes ou pour concevoir une stratégie d'optimisation réponse la prochaine fois (car il y aura certainement une prochaine fois), en tant que partenaire et conseiller de confiance, nous sommes prêts, disposés et capables de vous aider.
N'oubliez pas votre serviette.
Source link