Les failles de sécurité CVE-2021-44228 et CVE-2021-45046 ont été divulguées dans les versions 2.0 à 2.15 de la bibliothèque Apache Log4j. L'utilitaire Apache Log4j est un composant couramment utilisé pour journaliser les requêtes. Cette faille, également appelée Log4Shell, peut permettre à un pirate informatique de compromettre un système exécutant les versions 2.0 à 2.15 d'Apache Log4j et d'y exécuter du code arbitraire.
Cette faille n'affecte pas Cloud Logging ou ses agents de collecte de journaux d'applications tierces. Toutefois, si vous utilisez Log4j 2, vos services peuvent être affectés.
Vous pouvez utiliser Cloud Logging pour identifier les attaques possibles. Cette page explique comment effectuer les opérations suivantes :
- Interroger vos journaux à l'aide de l'explorateur de journaux pour essayer d'exploiter la faille Log4j 2.
- Vérifiez que les techniques d'atténuation activées, telles que les stratégies de sécurité Google Cloud Armor et le contrôle des accès Identity-Aware Proxy, sont correctement configurées et fonctionnent comme prévu en bloquant ces tentatives d'exploitation de Log4j 2.
- Créez une règle d'alerte pour vous avertir lorsqu'un message d'exploitation potentiel est écrit dans vos journaux.
Consultez l'avis de sécurité Log4j 2 concernant Google Cloud pour connaître notre évaluation de sécurité actuelle des produits et services Google Cloud. Vous pouvez évaluer votre exposition en lisant le rapport de faille du NIST (National Institute of Standards and Technology) CVE-2021-44228.
Détection Cloud Logging
Les résultats de requête Cloud Logging n'incluent que les journaux qui ont déjà été stockés dans des buckets de journaux et qui sont également dans les limites de conservation spécifiées par l'utilisateur. Bien que les journaux soient activés par défaut pour la plupart des services Google Cloud, ceux qui ont été désactivés ou exclus ne sont pas inclus dans les requêtes. Nous vous recommandons d'activer les journaux dans votre environnement pour améliorer votre visibilité sur l'environnement.
Si vous utilisez un équilibreur de charge HTTP(S), la journalisation doit être activée pour que les journaux de requêtes soient disponibles dans Cloud Logging. De même, si vous disposez de serveurs Web tels qu'Apache ou NGINX s'exécutant sur une VM, mais que vous n'avez pas installé l'agent Ops ou l'agent Logging, ces journaux ne seront pas accessibles dans Cloud Logging.
Interroger vos journaux
Vous pouvez utiliser l'explorateur de journaux pour détecter les attaques potentielles sur votre service qui exploitent la faille Log4j 2. Si vous utilisez Cloud Logging pour enregistrer les requêtes dans votre service, vous pouvez vérifier les champs httpRequest contenant du contenu généré par l'utilisateur pour identifier les failles potentielles.
Les valeurs des champs httpRequest peuvent contenir des jetons de chaîne de type ${jndi:ldap://, mais il existe de nombreuses façons d'exploiter cette faille.
Par exemple, il existe de nombreuses façons d'utiliser l'échappement ou Unicode pour éviter la détection.
Les chaînes suivantes présentent des exemples courants d'opérations d'exploitation de failles, mais il ne s'agit pas d'une liste exhaustive des variantes :
${jndi:
$%7Bjndi:
%24%7Bjndi:
${jNdI:ldAp
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}:
${${lower:j}${lower:n}${lower:d}i:
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}:
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}
Vous pouvez créer des requêtes dans l'explorateur de journaux afin de détecter certaines des chaînes d'exploitation possibles. Par exemple, la requête suivante tente de faire correspondre différentes variantes masquées de la chaîne ${jndi: dans les champs httpRequest des journaux de requêtes de l'équilibreur de charge HTTP(S). Notez que les expressions régulières utilisées dans la requête ne détectent pas toutes les variantes et peuvent entraîner des faux positifs :
resource.type="http_load_balancer"
httpRequest.requestUrl=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR
httpRequest.userAgent=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR
httpRequest.referer=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)"
Vous pouvez utiliser la requête précédente pour analyser les journaux de requêtes dans d'autres services en modifiant la valeur de resource.type.
La requête précédente peut prendre beaucoup de temps lorsque vous analysez un grand volume de journaux. Pour accélérer vos requêtes, vous pouvez utiliser des champs indexés tels que resource.type, resource.labels ou logName pour limiter votre requête à un ensemble de services ou de flux de journaux spécifiques.
La détection d'entrées de journal correspondantes ne signifie pas que la sécurité a été compromise. Si quelque chose est détecté, nous vous recommandons de suivre le processus de gestion des incidents de votre organisation. Une correspondance peut indiquer qu'un utilisateur cherche à exploiter la faille dans votre projet ou votre charge de travail. Il peut également s'agir d'un faux positif si votre application utilise des modèles tels que ${jndi: dans les champs de requête HTTP. Examinez vos journaux pour vous assurer que ce modèle de comportement est bien différent du comportement normal d'une application.
Affinez la requête afin qu'elle soit adaptée à votre environnement.
Rechercher les adresses IP à l'origine du problème
Si vous trouvez des correspondances et que vous souhaitez agréger les adresses IP distantes envoyant de telles requêtes, ajoutez le champ remoteIp au volet Champs de journal de l'explorateur de journaux. Pour ajouter le champ remoteIp, cliquez sur la valeur du champ dans une entrée de journal correspondante, puis sélectionnez Ajouter le champ aux champs de journaux, comme illustré dans la capture d'écran suivante:
Vous pouvez désormais voir les principales adresses IP distantes envoyant des requêtes correspondantes dans le volet Champs de journal:
Vous obtenez ainsi une répartition de l'origine de ces analyses d'exploitation de failles Log4j 2. Certaines de ces analyses peuvent être légitimes et provenir d'un outil d'analyse des failles d'application que vous avez peut-être configuré, comme Web Security Scanner. Si vous utilisez Web Security Scanner depuis Security Command Center, notez les plages d'adresses IP statiques utilisées par Web Security Scanner.
Rechercher les applications ciblées et vérifier les techniques d'atténuation
Vous pouvez également agréger les applications ciblées et identifier si des requêtes malveillantes ont réellement atteint vos applications. Si vous avez activé des techniques d'atténuation à l'aide de stratégies de sécurité de Google Cloud Armor ou de contrôle des accès par Identity-Aware Proxy (IAP), vous pouvez également vérifier qu'elles fonctionnent comme prévu à partir des informations consignées dans les journaux de l'équilibreur de charge HTTP(S).
Pour ajouter l'application ciblée au volet Champs du journal, commencez par choisir l'un des résultats des entrée de journal, développez resource.labels, cliquez sur la valeur du champ resource.labels.backend_service_name, puis sélectionnez Ajouter un champ au volet des champs de journal.
Vous pouvez désormais voir vos principales applications ou services backend ciblés par des analyses d'exploitation Log4j 2. Pour déterminer si ces tentatives d'exploitation ont même atteint votre service de backend, utilisez le champ jsonPayload.statusDetails renseigné par l'équilibreur de charge HTTP(S) pour savoir si la requête a été mise en proxy vers le backend ou si elle a été bloquée par des services tels que IAP ou Google Cloud Armor. Cliquez sur la valeur du champ jsonPayload.statusDetails dans le résultat de l'entrée de journal, puis sélectionnez Ajouter un champ au volet des champs de journaux.
Vous pouvez désormais voir un récapitulatif de la façon dont les requêtes ont été gérées dans le volet Champs de journal:
Dans cet exemple, la majorité des requêtes ont été bloquées par IAP, qui, lorsqu'il est activé sur un service de backend, vérifie l'identité et le contexte d'utilisation de l'utilisateur avant d'autoriser l'accès. Pour ces requêtes bloquées par l'IAP, statusDetails est défini sur handled_by_identity_aware_proxy. En outre (ou à la place), si vous utilisez Google Cloud Armor avec la stratégie de sécurité appropriée associée à un service de backend, toutes les requêtes bloquées par Google Cloud Armor ont statusDetails défini sur denied_by_security_policy.
Pour savoir comment appliquer la nouvelle règle WAF cve-canary préconfigurée à vos stratégies de sécurité Google Cloud Armor, consultez la page Règle WAF de Google Cloud Armor pour limiter les failles Apache Log4j.
Pour filtrer les requêtes autorisées qui atteignent réellement un service de backend, sélectionnez response_sent_by_backend sous statusDetails dans le volet Champs du journal. Envisagez d'activer l'API IAP pour ces services de backend et/ou d'appliquer une stratégie de sécurité Google Cloud Armor avec la règle WAF cve-canary préconfigurée pour bloquer ces tentatives d'exploitation.
Créer une alerte basée sur les journaux
Une fois que vous avez conçu une requête qui recherche les journaux concernés dans votre service, vous pouvez l'utiliser pour créer une alerte basée sur les journaux afin d'être averti lorsque de nouvelles entrées de journal correspondent à la requête. Cette alerte peut être transmise au centre d'opérations de sécurité (SOC) ou à l'équipe de gestion des incidents, le cas échéant.
Pour en savoir plus sur la création d'une alerte basée sur les journaux, consultez la page Créer une alerte basée sur les journaux (explorateur de journaux). Lorsque vous créez l'alerte, veillez à utiliser votre requête correspondant à la chaîne d'exploitation plutôt que la requête spécifiée dans l'exemple.
Créer une règle d'alerte pour une métrique basée sur les journaux
Pour surveiller les points de terminaison ou services qui consignent les tentatives d'exploitation possibles, créez une règle d'alerte associée à une métrique basée sur les journaux :
Créez une métrique basée sur les journaux pour compter les occurrences de chaînes d'exploitation possibles dans vos journaux. Par exemple, vous pouvez utiliser la Google Cloud CLI pour créer une telle métrique:
gcloud logging metrics create log4j_exploits \ --description="Detect log4j exploits" \ --log-filter='httpRequest.requestUrl=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.userAgent=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.referer=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)"'Pour en savoir plus sur la création de métriques basées sur les journaux, consultez la page Configurer les métriques de compteur.
Créez une règle d'alerte pour être informé lorsqu'un nombre sélectionné d'occurrences est atteint. Pour plus d'informations sur la configuration d'une règle d'alerte, consultez la page Créer une règle d'alerte associée à une métrique de compteur.
Étape suivante
Consultez ce document pour savoir si de nouvelles informations sont disponibles.
Pour plus d'informations sur la faille Log4j 2 et vos services Google Cloud, consultez les ressources suivantes :