Ejemplo: Detecta los exploits de seguridad de Log4Shell

Las vulnerabilidades de seguridad CVE-2021-44228 y CVE-2021-45046 se divulgaron 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 ejecuta las versiones 2.0 a 2.15 de Apache Log4j se vea comprometido y permita que un atacante ejecute un 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, tus servicios podrían verse 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 en busca de intentos existentes de aprovechar 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 de forma correcta y funcionen como se espera mediante el bloqueo de estos intentos de explotación de Log4j 2.
  • Crea una política de alertas para que te notifique cuando se escriba un posible mensaje de explotación en tus registros.

Consulta el Asesoramiento de seguridad de Log4j 2 de Google Cloud para conocer nuestra evaluación actual de productos y servicios de Google Cloud. Para evaluar tu exposición, lee el informe de vulnerabilidad del Instituto Nacional de Estándares y Tecnología (NIST) de CVE-2021-44228.

Detección de Cloud Logging

Los resultados de la consulta de Cloud Logging incluyen solo los registros que ya se almacenaron en buckets de registros y también están 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 excluidos no se incluyen en tus consultas. Recomendamos activar los registros en tu entorno para expandir tu visibilidad en el entorno.

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 en tu servicio que aprovechan la vulnerabilidad de Log4j 2. Si usas Cloud Logging para registrar solicitudes a tu servicio, puedes verificar los campos httpRequest con contenido generado por usuarios a fin de 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 aprovecha esta vulnerabilidad. Por ejemplo, existen muchas formas de usar el escape 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 explotación de vulnerabilidades. Por ejemplo, la siguiente consulta intenta hacer coincidir varias variaciones ofuscadas de la string ${jndi: en los campos 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 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 la consulta a un conjunto de servicios o transmisiones de registros específicos.

Detectar entradas de registro que coincidan no significa que haya habido 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á sondeando para explotar la vulnerabilidad dentro de tu proyecto o carga de trabajo. También 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 ofensivas

Si encuentras resultados coincidentes y si deseas agregar en 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 registros, 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 quitan principales aparecen en el Explorador de registros.

Esto te brinda un desglose del origen de estos análisis de vulnerabilidades de vulnerabilidad de Log4j 2. Algunos de estos pueden ser análisis legítimos de una herramienta de análisis de vulnerabilidades de la aplicación 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 específicas y verifica las técnicas de mitigación

También puedes agregar contenido en las aplicaciones objetivo e identificar si las solicitudes maliciosas realmente llegaron a tus aplicaciones. Si habilitaste técnicas de mitigación con políticas de seguridad de Google Cloud Armor o del control de acceso de Identity-Aware Proxy (IAP), también puedes verificar que funcionen como se espera a partir de la información registrada en los registros del balanceador de cargas HTTP(S).

Primero, para agregar la aplicación de destino al panel Campos de registro, elige uno de los resultados de 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 de campos de registros.

Ahora puedes ver tus aplicaciones o servicios de backend principales a los que se orienta el análisis de vulnerabilidades de Log4j 2. Para determinar si estos intentos de explotación incluso 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 los servicios como IAP o Google Cloud Armor bloquearon correctamente la solicitud. Haz clic en el valor del campo jsonPayload.statusDetails del resultado de la entrada de registro y selecciona Agregar campo al panel de campos de registros.

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

Los servicios de backend más segmentados aparecen en el Explorador de registros

En este ejemplo, IAP bloqueó la mayoría de las solicitudes, que, cuando se habilita en un servicio de backend, verifica la identidad del usuario y usa el contexto antes de permitir el acceso. Esas solicitudes bloqueadas con IAP tienen statusDetails configurado como handled_by_identity_aware_proxy. Además (o como alternativa), si se usa Google Cloud Armor con la política de seguridad correcta vinculada a un servicio de backend, todas las solicitudes bloqueadas por Google Cloud Armor tienen el valor statusDetails configurado como denied_by_security_policy. Si deseas 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 mitigar la vulnerabilidad de Apache Log4j.

Para filtrar las solicitudes permitidas que 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 a fin de ayudar a bloquear estos intentos de explotación.

Crear una alerta basada en registros

Después de diseñar una consulta que encuentra los registros afectados en tu servicio, puedes usar esa consulta para crear una alerta basada en registros que te notificará 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 ante incidentes adecuado.

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 del ataque 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 explotación, crea una política de alertas en una métrica basada en registros:

  1. Crea una métrica basada en registros para contar los casos de posibles strings de explotación en tus registros. Por ejemplo, puedes usar Google Cloud CLI para crear esta métrica:

    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 recibir notificaciones cuando se alcance una cantidad seleccionada de casos. 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?