Ejemplo: Detecta vulnerabilidades de seguridad de Log4Shell

Se divulgaron las vulnerabilidades de seguridad CVE-2021-44228 y CVE-2021-45046 en las versiones 2.0 a 2.15 de la biblioteca Apache Log4j. La utilidad Apache Log4j es un componente de uso general para registrar solicitudes. Esta vulnerabilidad, también llamada Log4Shell, puede permitir que un sistema que ejecute Apache Log4j desde la versión 2.0 hasta la 2.15 se vea comprometido y permita que un atacante ejecute código arbitrario.

Esta vulnerabilidad no afecta a Cloud Logging ni a los agentes que proporciona para recopilar registros de aplicaciones de terceros, pero si usas Log4j 2, es posible que tus servicios se vean afectados.

Puedes usar Cloud Logging para identificar posibles ataques. Este documento se describe cómo hacer lo siguiente:

  • Consulta tus registros con el Explorador de registros para detectar intentos de explotación existentes la vulnerabilidad de Log4j 2.
  • Confirma que tus técnicas de mitigación habilitadas, como las políticas de seguridad de Google Cloud Armor y el control de acceso de Identity-Aware Proxy, estén configuradas correctamente y funcionen como se espera bloqueando estos intentos de exploits de Log4j 2.
  • Crea una política de alertas para que te notifique cuando un posible exploit se escribe en tus registros.

Consulta Log4j 2 Security Advisory de Google Cloud para nuestro evaluación actual de productos y servicios de Google Cloud. Para evaluar tu exposición, lee el informe de vulnerabilidades del Instituto Nacional de Estándares y Tecnología (NIST) sobre CVE-2021-44228.

Detección de Cloud Logging

Los resultados de la consulta de Cloud Logging incluyen solo los registros que ya se que se almacenan en buckets de registros y se encuentran límites de retención. Aunque la mayoría de los servicios de Google Cloud tienen registros los registros que se inhabilitaron o excluidos no incluidos en tus consultas. Te recomendamos que actives los registros en todo el entorno para expandir tu visibilidad en él.

Si usas un balanceador de cargas HTTP(S), debes tener habilitado el registro para que los registros de solicitudes estén disponibles en Cloud Logging. Del mismo modo, si tienes servidores web como Apache o NGINX que se ejecutan en una VM pero no instalaste el agente de operaciones ni el agente de Logging, no se podrá acceder a esos registros en Cloud Logging.

Puedes usar el Explorador de registros para detectar posibles ataques y aprovecha la vulnerabilidad de Log4j 2. Si usas Cloud Logging para registrar solicitudes a tu servicio, puedes verificar los campos httpRequest con contenido generado por el usuario para detectar posibles exploits.

Los valores en los campos httpRequest pueden tener tokens de cadena como ${jndi:ldap://, pero hay muchas variaciones en la forma en que se explota esta vulnerabilidad. Por ejemplo, hay muchas formas de usar la evasión o Unicode para evitar la detección. En las siguientes cadenas, se muestran algunos ejemplos comunes que indican intentos de explotación contra tu sistema, pero este no es un conjunto exhaustivo de 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:-:}

Puedes crear consultas en el Explorador de registros que analicen de las posibles cadenas de explotación. Por ejemplo, la siguiente consulta intenta hacer coincidir varias variantes ofuscadas de la cadena ${jndi: en httpRequest en los registros de solicitudes del balanceador de cargas HTTP(S). Ten en cuenta que las expresiones regulares que se usan en la consulta no detectan todas las variaciones y pueden generar falsos positivos:

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)"

Puedes usar la consulta anterior para analizar los registros de solicitudes en otros servicios. cambiando el valor de resource.type.

Es posible que la consulta anterior tarde mucho tiempo en completarse cuando la estás analizando un gran volumen de registros. Para que tus consultas se ejecuten más rápido, puedes usa campos indexados, como resource.type, resource.labels o logName para limitar tu búsqueda a un conjunto de servicios ni transmisiones de registro.

Detectar entradas de registro que coincidan no significa que se produjo una vulneración exitosa. Si se detecta algo, te recomendamos que sigas en el proceso de respuesta ante incidentes de tu organización. Una coincidencia podría indicar que alguien está probando explotar la vulnerabilidad dentro de tu proyecto o carga de trabajo. O bien, puede ser un falso positivo si tu aplicación usa patrones como ${jndi: en los campos de solicitud HTTP. Revisa tus registros para asegurarte de que este patrón no sea parte del comportamiento normal de la aplicación. Define mejor la consulta para que tenga sentido en tu entorno.

Busca direcciones IP infractoras

Si encuentras resultados coincidentes y quieres agregar datos en la IP remota direcciones que envían esas solicitudes y, luego, agrega el campo remoteIp al el panel Campos de registro del Explorador de registros Para agregar el campo remoteIp, haz clic en el valor del campo en una entrada de registro coincidente y selecciona Agregar campo al panel de campos de registro, como se muestra en la siguiente captura de pantalla:

Agrega "remoteIp" al campo “Campos de registro” para determinar la IP
direcciones IP que envían la mayor cantidad de solicitudes coincidentes.

Ahora puedes ver las principales direcciones IP remotas que envían solicitudes coincidentes En el panel Campos de registro:

Las principales direcciones IP que se quitarán
el Explorador de registros.

Esto te da un desglose de dónde estos análisis de vulnerabilidades de Log4j 2 de dónde provienen los datos. Algunos de estos pueden ser análisis legítimos de una aplicación Herramienta de análisis de vulnerabilidades que hayas configurado, como Web Security Scanner. Si usas Web Security Scanner desde Security Command Center, toma nota de los rangos de direcciones IP estáticas que usa Web Security Scanner.

Busca aplicaciones segmentadas y verifica las técnicas de mitigación

También te recomendamos que agregues las aplicaciones objetivo y que identifiques si las solicitudes maliciosas llegaron a tus aplicaciones. Si habilitaste técnicas de mitigación con políticas de seguridad de Google Cloud Armor o el control de acceso de Identity-Aware Proxy (IAP), también puedes verificar que funcionen según lo esperado a partir de la información registrada en los registros del balanceador de cargas de HTTP(S).

Primero, para agregar la aplicación objetivo al panel Campos de registro, elige uno de los resultados de la entrada de registro, expande resource.labels, haz clic en el valor del campo resource.labels.backend_service_name y, luego, selecciona Agregar campo al panel Campos de registro.

Ahora puedes ver cuáles son tus aplicaciones o servicios de backend principales a los que se dirigen los análisis de exploits de Log4j 2. Para determinar si estos intentos de explotación llegaron a tu servicio de backend, usa el campo jsonPayload.statusDetails propagado por el balanceador de cargas HTTP(S) para saber si la solicitud se envió al backend o si la bloqueó correctamente servicios como IAP o Google Cloud Armor. Haz clic en el valor del campo jsonPayload.statusDetails del resultado de la entrada de registro y selecciona Agregar campo al panel Campos de registro.

Ahora puedes ver un desglose de cómo se controlaron las solicitudes en el panel Campos de registro:

Los servicios de backend más orientados aparecen en la
Explorador de registros

En este ejemplo, la mayoría de las solicitudes se bloquearon con IAP, que, cuando se habilita en un servicio de backend, verifica la identidad del usuario y el contexto de uso antes de permitir el acceso. Esas solicitudes bloqueadas con IAP tienen statusDetails establecer como handled_by_identity_aware_proxy. Además (o alternativamente), si usando Google Cloud Armor con la política de seguridad correcta vinculada a un servicio de backend todas las solicitudes bloqueadas de Google Cloud Armor tienen el elemento statusDetails configurado como denied_by_security_policy. Para obtener detalles sobre cómo aplicar la nueva regla de WAF cve-canary preconfigurada a tus políticas de seguridad de Google Cloud Armor, consulta Regla de WAF de Google Cloud Armor para ayudar a mitigar la vulnerabilidad de Apache Log4j.

Para filtrar las solicitudes permitidas que realmente llegan a un servicio de backend, selecciona response_sent_by_backend en statusDetails en el panel Campos de registro. Considera habilitar IAP para estos servicios de backend o aplicar una política de seguridad de Google Cloud Armor con la regla de WAF cve-canary preconfigurada para ayudar a bloquear estos intentos de explotación.

Crear una alerta basada en registros

Después de diseñar una consulta que encuentre registros afectados en tu servicio, puedes usarla para crear una alerta basada en registros que te notifique cuando nuevas entradas de registro coincidan con la consulta. Esta alerta se puede reenviar al centro de operaciones de seguridad (SOC) de tu organización o al equipo de respuesta a incidentes correspondiente.

Para obtener información sobre cómo crear una alerta basada en registros, consulta Crea una alerta basada en registros. (Explorador de registros). Cuando crees la alerta, asegúrate de usar tu consulta para la cadena de exploits en lugar de la consulta especificada en el ejemplo.

Crea una política de alertas para una métrica basada en registros

Supervisar qué endpoints o servicios están registrando posibles ataques intentos, crea una política de alertas en una métrica basada en registros:

  1. Crear una métrica basada en registros para contar los casos de posibles y exploit cadenas en tus registros. Por ejemplo, puedes usar Google Cloud CLI para crear una métrica de este tipo:

    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)"'
    

    Para obtener más información sobre la creación de métricas basadas en registros, consulta Configura métricas de contador.

  2. Crea una política de alertas para que te notifique cuando un número seleccionado de se alcanza la cantidad de repeticiones. Para obtener información sobre cómo configurar una política de alertas, consulta Crea una política de alertas en una métrica de contador.

¿Qué sigue?