Bulletin de sécurité : "Log4Shell" vulnérabilité de Apache Log4j2 (CVE-2021-44228 & CVE-2021-45046)
[Obsolete - Voir ci-dessous] Une vulnérabilité critique a été découverte la semaine dernière dans la bibliothèque Apache Log4j2. Elle a un impact sur un large éventail de logiciels dans l'écosystème Java. Cet article résume l'impact sur Scalingo et donne quelques conseils sur la façon dont vous devriez agir si vous utilisez une application Java.
[Mise à jour 17/12/2021] Comme vous le savez probablement, plusieurs vulnérabilités critiques (CVE-2021-44228 et CVE-2021-45046) ont été découvertes la semaine dernière dans la bibliothèque Apache Log4j2. Elles ont un impact sur un large éventail de logiciels dans l'écosystème Java.
[Mise à jour 20/12/2021] Une vulnérabilité moins critique du nom de CVE-2021-45105 a été découverte. Il est maintenant conseiller d'upgrader vers Log4j2 2.17. Nous vous informons ici dans le but de mettre à jour les informations de cet article. Sachez cependant que comme nos services ne sont plus impactés nous allons arrêter le travail de notre équipe incident sur ce sujet. Nous continuons bien sûr à monitorer nos services. De votre coté vous pouvez vous rendre sur https://logging.apache.org/log4j/2.x/security.html pour connaître les dernières mises à jours.
[Mise à jour du 29/12/2021] CVE-2021-44832 a été signalé. Veuillez lire les informations disponibles et appliquer les correctifs à votre discrétion.
Cet article résume l'impact sur Scalingo et donne quelques conseils sur la façon dont vous devriez agir si vous utilisez une application Java. Nous faisons de notre mieux pour mettre à jour cet article de manière journalière dans la mesure des découvertes et de nos connaissances. Dernière Mise à jour 29/12/2021 12:00
Que s'est-il passé ?
La semaine dernière, une vulnérabilité critique CVE-2021-44228 a été découverte dans la library Apache Log4j2.
Si vous voulez bien comprendre le problème, la fondation Apache a publié cette documentation sur le sujet.
Les versions de Log4j2 comprises entre 2.0-beta9 et 2.14.1 sont concernées. La première version patchée est la 2.15.0 et une solution de contournement est disponible pour les versions précédentes (voir ci-dessous).
[Mise à jour 20/12/2021] Comme annoncé par CVE-2021-45105 la mise à jour vers une version Log4j2 ≥ 2.17.0 (for Java 8 users) or Log4j2 2.12.3 (for Java 7 users) est obligatoire pour résoudre la vulnérabilité.
[Mise à jour du 29/12/2021] Comme CVE-2021-44832 a été signalé, vous souhaiterez peut-être passer à Log4j2 ≥ 2.17.1 (pour les utilisateurs de Java 8) ou Log4j2 ≥ 2.12.4 (pour les utilisateurs de Java 7) ou Log4j2 ≥ 2.3.2 (pour les utilisateurs de Java 6) pour corriger la vulnérabilité.
Impact sur Scalingo et ce que nous faisons pour y remédier
Services internes
Chez Scalingo, nous n'utilisons pas beaucoup d'applications basées sur Java. Néanmoins l'outil open-source Metabase est utilisé pour faire quelques analyses.
À la date de l'incident, notre instance Metabase était potentiellement affectée par la vulnérabilité, mais étant donné qu'elle fonctionnait avec un JRE (Java Runtime Engine) à jour qui atténuait le problème, il n'était pas possible de l'exploiter.
Nous n'avons pas attendu pour faire une analyse approfondie et avons déjà appliqué un correctif ce week-end.
Nous avons également analysé les logs de l'application Metabase et le routeur interne et n'avons trouvé aucune trace d'une tentative d'exploitation avant la correction de l'application.
Pour information : nous voyons maintenant ce qui semble être des tentatives d'intrusion automatisées utilisant l'exploit sur notre infrastructure mais grâce à l'application qui est à jour, elles ne fonctionnent pas.
[Mise à jour 17/12/2021] Nous avons patché à nouveau nos services internes pour la CVE-2021-45046
[Mise à jour 20/12/2021] Pas d'impact sur Scalingo
[Mise à jour 29/12/2021] Pas d'impact sur Scalingo
Elasticsearch en tant que service
Chez Scalingo, nous proposons Elasticsearch à nos clients en tant qu'addon de base de données, et il était prioritaire de s'assurer que les données de nos clients étaient sécurisées. La communication officielle d'Elasticsearch indique qu'en raison de l'utilisation de la fonctionnalité Java Security Manager, l'impact de la CVE n'est pas aussi élevé que celui d'autres outils, mais qu'il existe néanmoins un risque.
Deux couches de protection sont configurées par défaut chez Scalingo pour atténuer davantage ce problème :
- Les instances Elasticsearch ne sont jamais directement accessibles aux utilisateurs et aux applications. En effet, chaque déploiement est effectué à l'intérieur d'un réseau privé dont le seul point d'entrée pour les clients est une passerelle HAProxy gérant l'authentification. Cela signifie que seules les demandes authentifiées sont transmises aux instances Elasticsearch elles-mêmes. (Si votre mot de passe est accessible à un attaquant, il a déjà accès à vos données).
- Par défaut, nos bases de données ne sont pas accessibles sur Internet, ce qui réduit la surface d'attaque, car les entités automatisées qui tentent d'exploiter le CVE ne trouveront aucune instance Elasticsearch qui n'a pas été explicitement exposée publiquement.
Compte tenu de ces mesures, l'impact du CVE devient plus faible sur nos déploiements d'Elasticsearch.
La sécurité étant une accumulation de couches, la version 6.8.21 d'Elasticsearch publiée en réaction au CVE a été mise à disposition. Vous pouvez mettre à jour votre instance Elasticsearch vers cette nouvelle version sur Scalingo immédiatement en utilisant le tableau de bord de gestion de votre addon de base de données.
[Mise à jour 17/12/2021] Elasticsearch n'a pas besoin d'une nouvelle mise à jour pour la CVE-2021-45046 selon cette annonce de sécurité.
[Mise à jour 20/12/2021] Elasticsearch n'a pas besoin de nouvelles mises à jour CVE-2021-45105 comme indiqué dans leur Security Announcement
Déploiement par des tiers via le "one-click-deploy".
Notre fonctionnalité "one-click-deploy" est un moyen rapide de déployer du code tiers en tant qu'applications Scalingo.
Pour ce faire, les projets ont leurs propres dépôts GitHub et peuvent être proposés par n'importe qui, sans aucun soutien de Scalingo.
Néanmoins, il existe quelques projets "one-click-deploy" que nous hébergeons historiquement ou utilisons en interne. Nous les avons mis à jour et vous devez déclencher un nouveau déploiement.
Metabase [Mise à jour 17/12/2021] vous devez à nouveau déclencher un déploiement pour mettre à jour vers la 0.41.5) [Mise à jour 20/12/2021] Metabase is not vulnerable to CVE-2021-45105
Sonarqube [Mise à jour 17/12/2021] vous devez à nouveau déclencher un déploiement pour mettre à jour vers 8.9.5 ou 9.2.3). Faites attention à ne pas avoir défini la variable SONARQUBE_VERSION (ou à lui donner une valeur supérieure à 8.9.5 ou 9.2.3). [Mise à jour 20/12/2021] Sonarqube semble être vulnerable à CVE-2021-45105 pour le moment il n'y a pas de solutions. Lorsqu'une solution sera proposée, merci de déployer à nouveau. Toutes les infos de Sonarqube ici.
Logstash [Mise à jour du 17/12/2021] non affecté par CVE-2021-45046, mais assurez-vous d'avoir au moins la version 6.8.21 ou 7.16.1)
[Mise à jour 20/12/2021] Logstash n'a pas besoin d'une nouvelle mise à jour pour CVE-2021-45105 comme l'indique leSecurity Announcement
- *[Update 20/12/2021] Kibana n'a pas besoin d'une nouvelle mise à jour pour CVE-2021-45105 comme l'indique le Security Announcement
À noter : Vous DEVEZ déclencher un nouveau déploiement pour obtenir la dernière version corrigée, en suivant les instructions du fichier README.
Si vous utilisez une application tierce "one-click-deploy", veuillez contacter le responsable original pour vérifier si une version mise à jour a été déployée.
[Mise à jour 17/12/2021] Buildpacks tiers
Si vous utilisez Datadog dans votre application via notre support multi-buildpack votre application est vulnérable et vous devez déclencher un déploiement, soit via le tableau de bord, soit via la CLI.
AVERTISSEMENT : Si vous avez épinglé votre version avec la variable d'environnement DD_AGENT_VERSION, vous devez vous assurer que cette variable doit est ≥ 6.32.3 (ou 7.32.3)
Source: https://www.datadoghq.com/log4j-vulnerability/
[Mise à jour 20/12/2021] Merci de vous référer à cet article de Datadog sur l'impact de CVE-2021-45105
Autres applications Java
Ce paragraphe est là pour vous aider sur la base de notre expérience si vous hébergez une application Java (sur Scalingo ou ailleurs).
Vous pouvez également trouver une liste des logiciels vulnérables à Log4Shell ici.
Quel est le risque ?
Un attaquant qui fabrique la bonne chaîne de caractères peut exécuter n'importe quel code dans le contexte de votre application, ce qui peut entraîner des problèmes potentiels :
- Confidentialité : exfiltration d'informations de votre application (et indirectement de votre base de données).
- Disponibilité : perturbation de la fonctionnalité de votre application
- Intégrité : insertion de données malformées ou incorrectes dans votre base de données.
Comment savoir si votre application est impactée ?
Première question à laquelle vous devez répondre : "Votre application utilise-t-elle le language de programmation Java ?"
Si la réponse est NON, vous êtes en sécurité.
Deuxième question : "Si vous utilisez Java, votre application ou une de ses dépendances utilise-t-elle Log4j2 <= 2.14.1 ?" [Mise à jour 17/12/2021] Les versions inférieurs à 2.16.0 sont potentiellement vulnérables.* [Mise à jour 20/12/2021] Les versions avant 2.17.0 peuvent être vulnerables. [Mise à jour 29/12/2021] Les versions avant 2.17.1 peuvent être vulnerables.
Si la réponse est NON, vous êtes en sécurité. Mais il semble que ce type de réponse soit terriblement difficile à répondre en raison des montagnes de dépendances que les applications Java utilisent.
Corrections possibles
Vous avez plusieurs changements rapides que vous pouvez mettre en pratique.
Option 1 : Mettre à jour la dépendance Log4j2
- Vous contrôlez le code de votre application, utilisez votre système de build (Maven, Gradle, ...) pour mettre à jour Log4j2 à la dernière version
-
[Mise à jour 17/12/2021]Les utilisateurs de Java 8 (ou version ultérieure) doivent passer à la version 2.16.0.Les utilisateurs de Java 7 doivent passer à la version 2.12.2.
-
[Mise à jour 20/12/2021]Les utilisateurs Java 8 (ou version ultérieure) doivent upgrader vers la version 2.17.0.Les utilisateurs Java 7 doivent upgrader vers la version 2.12.3.
- [Mise à jour 29/12/2021]
- Les utilisateurs de Java 8 (ou version ultérieure) doivent passer à la version 2.17.1
- Les utilisateurs de Java 7 doivent passer à la version 2.12.4
- Les utilisateurs de Java 6 doivent passer à la version 2.3.2
-
- Vous ne contrôlez pas le code source, mettez à jour le software. Exemple pour Metabase :
scalingo --app my-app deploy <https://github.com/Scalingo/metabase-scalingo/archive/refs/heads/master.tar.gz>
Option 2 : Si vous ne pouvez pas mettre à jour Log4j, vous pouvez définir cette variable d'environnement
LOG4J_FORMAT_MSG_NO_LOOKUPS=true pour patcher la vulnérabilité.
Cela peut être fait via notre dashboard ou en utilisant cette commande scalingo -a my-app env-set LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Veuillez noter que cela ne fonctionne que pour log4j2 > 2.10 et non pour les versions antérieures.
[Mise à jour 17/12/2021] Cette correction peut être contournée dans des configurations extrêmement rares, mais reste une première réponse valable.
[Mise à jour 17/12/2021] Option 3 : Si vous êtes vraiment bloqué et ne pouvez pas faire de mise à jour, mais que vous souhaitez éliminer la possibilité de faire des recherches JNDI, vous pouvez utiliser la Méthode 2 donnée par JFrog qui élimine la classe problématique de l'environnement.
Un moyen simple d'implémenter cela sur Scalingo consiste à utiliser un script de profil.
Conclusion
Scalingo a patché tous les services internes affectés par la vulnérabilité. Aucune violation de données n'a été possible ni détectée.
Le produit Scalingo impacté est ElasticSearch, la vulnérabilité n'est pas exploitable. Vous pouvez le mettre à jour pour plus de sécurité en utilisant le tableau de bord de la base de données.
Pour toute autre application Java hébergée sur Scalingo, veuillez la mettre à jour ou vous assurer que vous utilisez déjà une version corrigée de Log4j2.
Si vous êtes un client de Scalingo, vous pouvez également vous adresser à notre support en cas de doute ou de question. Notre équipe vous répondra et fera de son mieux pour répondre à vos questions.
