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 la journalisation 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 vos techniques d'atténuation activées, comme les règles de sécurité 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 CloudVous pouvez évaluer votre exposition en lisant le rapport de faille du NIST (National Institute of Standards and Technology) CVE-2021-44228.
Détection de la journalisation
Les résultats de requête 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 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 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 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 incriminées
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 au volet "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 des sources de ces analyses d'exploitation des failles Log4j 2. Il peut s'agir d'analyses légitimes provenant 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 des 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é Cloud Armor ou du 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).
Tout d'abord, pour ajouter l'application ciblée au volet Champs du journal, sélectionnez l'un des résultats d'entrée de journal, développez resource.labels, cliquez sur la valeur du champ resource.labels.backend_service_name, puis sélectionnez Ajouter le champ au volet Champs du journal.
Vous pouvez désormais identifier les principales applications ou services de backend ciblés par les 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é transmise au backend ou bloquée avec succès par des services tels qu'IAP ou 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 journal.
Vous pouvez désormais voir comment les requêtes ont été traité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é de l'utilisateur et le contexte d'utilisation avant d'autoriser l'accès. Pour ces requêtes bloquées par IAP, statusDetails est défini sur handled_by_identity_aware_proxy. De plus (ou à la place), si vous utilisez Cloud Armor avec la règle de sécurité appropriée associée à un service de backend, toutes les requêtes bloquées par 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é Cloud Armor, consultez Règle WAF de Google Cloud Armor pour limiter les failles Apache Log4j.
Pour filtrer toutes 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 IAP pour ces services de backend et d'appliquer une stratégie de sécurité Cloud Armor avec la règle WAF cve-canary préconfigurée pour bloquer ces tentatives d'exploitation.
Créer une règle d'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 règle d'alerte basée sur les journaux afin d'être averti lorsque de nouvelles entrées de journal correspondent à la requête. Les incidents créés par la règle d'alerte peuvent être transmis 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 règle d'alerte basée sur les journaux, consultez Créer une règle d'alerte basée sur les journaux (explorateur de journaux). Lorsque vous créez la règle d'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 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 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 en savoir plus sur la faille Log4j 2 et vos servicesGoogle Cloud , consultez les ressources suivantes :