Ejemplo: Detecta exploits 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. En este documento, se describe cómo hacer lo siguiente:

  • Consulta tus registros con el Explorador de registros para detectar intentos existentes de explotar 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 se escriba un posible mensaje de exploit en tus registros.

Revisa el Aviso de seguridad de Log4j 2 de Google Cloud para conocer nuestra evaluación actual de los 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 las consultas de Cloud Logging solo incluyen los registros que ya se almacenaron en buckets de registros y que también se encuentran dentro de los límites de retención especificados por el usuario. Si bien la mayoría de los servicios de Google Cloud tienen registros habilitados de forma predeterminada, los registros que se inhabilitaron o excluyeron no se incluyen 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 ejecutándose en una VM, pero no instalaste el Agente de operaciones ni el Agente de registro, no podrás acceder a esos registros en Cloud Logging.

Puedes usar el Explorador de registros para detectar posibles ataques a tu servicio que aprovechen 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 de los campos httpRequest pueden tener tokens de cadena como ${jndi:ldap://, pero hay muchas variaciones en la forma en que se aprovecha 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 busquen algunas de las posibles cadenas de exploits. Por ejemplo, la siguiente consulta intenta hacer coincidir varias variaciones ofuscadas de la cadena ${jndi: en los campos httpRequest de 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 si cambias el valor de resource.type.

La consulta anterior puede tardar mucho tiempo en completarse cuando analizas un gran volumen de registros. Para que tus consultas se ejecuten más rápido, puedes usar campos indexados, como resource.type, resource.labels o logName, para limitar tu consulta a un conjunto de servicios o flujos de registro específicos.

Detectar entradas de registro que coincidan no significa que se produjo una vulneración exitosa. Si se detecta algo, te recomendamos que sigas 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, podría 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.

Buscar direcciones IP infractoras

Si encuentras resultados coincidentes y deseas agregar las direcciones IP remotas que envían esas solicitudes, agrega el campo remoteIp al panel Campos de registro en el 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 el campo "remoteIp" al panel "Campos de registro" para determinar las 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 direcciones IP que se quitaron aparecen en el
Explorador de registros.

Esto te brinda un desglose del origen de estos análisis de exploits de vulnerabilidad de Log4j 2. Algunos de ellos pueden ser análisis legítimos de una herramienta de análisis de vulnerabilidades de aplicaciones 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 exploits llegaron a tu servicio de backend, usa el campo jsonPayload.statusDetails propagado por el balanceador de cargas de HTTP(S) para saber si la solicitud se asignó a un proxy al backend o si se bloqueó correctamente con 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 atacados aparecen en el 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 por IAP tienen statusDetails configurado como handled_by_identity_aware_proxy. Además (o como alternativa), si usas Google Cloud Armor con la política de seguridad correcta adjunta a un servicio de backend, todas las solicitudes bloqueadas por Google Cloud Armor tienen statusDetails establecido 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 la 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 exploits.

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.

Si deseas obtener información para 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

Para supervisar qué extremos o servicios registran posibles intentos de exploits, crea una política de alertas en una métrica basada en registros:

  1. Crea una métrica basada en registros para contar las ocurrencias de posibles cadenas de exploits 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 cómo crear métricas basadas en registros, consulta Configura métricas de contador.

  2. Crea una política de alertas para que te notifique cuando se alcance una cantidad seleccionada de ocurrencias. 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?