La vulnerabilidad de Apache Log4J: cuestionario y consejos de VRM

Apache Log4j 2, una biblioteca de registro basada en Java, se vio afectada por una vulnerabilidad de día cero el 9 de diciembre de 2021. La vulnerabilidad, conocida como Log4Shell e identificada por el Instituto Nacional de Estándares y Tecnología (NIST) como CVE-2021-44228, permite a los ciberdelincuentes tomar el control de sistemas y servidores vulnerables.

Muchas aplicaciones web, plataformas en la nube de código abierto y proveedores de servicios utilizan Log4j. Este uso generalizado podría exponer la superficie de ataque interna de su organización y el ecosistema de terceros a la vulnerabilidad Log4Shell. Para proteger los sistemas y datos críticos de forma eficaz, su organización debe evaluar el uso interno de Log4j y el uso de la biblioteca de registros por parte de su proveedor.

Siga leyendo para descubrir 11 preguntas que su equipo de gestión de riesgos de proveedores puede utilizar para determinar cómo los proveedores utilizan Log4j en su cadena de suministro de terceros y cómo esto podría afectar a la postura de seguridad de su organización.

Obtenga más información sobre UpGuard Vendor Risk: la solución de gestión de riesgos de proveedores #1 del mundo>

Resumen de la vulnerabilidad Log4Shell

En diciembre de 2021, los investigadores de seguridad anunciaron una falla de seguridad crítica en el marco Apache Log4j, que permitía a los piratas informáticos malintencionados comprometer sistemas vulnerables a través de una sola inyección de código.

Durante los primeros días de impacto, los investigadores de seguridad identificaron aproximadamente 10 millones de intentos de explotación de Log4Shell cada hora. Varias industrias son vulnerables a Log4Shell porque muchos productos y software digital, incluidas las aplicaciones de Microsoft e IOS, utilizan Java.

El sector minorista fue el más afectado por la vulnerabilidad de Log4Shell, pero otros sectores, como la tecnología, los servicios financieros, la fabricación y la sanidad, también se vieron afectados.

Aplicación de parches a la vulnerabilidad de Log4J

Apache comenzó a desarrollar un parche para Log4Shell rápidamente después de darse cuenta de la vulnerabilidad en diciembre de 2021. Sin embargo, Log4j sigue presentando importantes riesgos de seguridad, dado su uso generalizado.

Cualquier versión de Log4j 2 anterior a la 2.17.1 es vulnerable a la vulnerabilidad Log4Shell. Para protegerse eficazmente contra esta vulnerabilidad, las organizaciones deben abordar cualquier versión vulnerable de Log4j 2 en uso en su infraestructura interna y ecosistemas de terceros.

Los equipos de seguridad pueden seguir el siguiente protocolo para abordar la vulnerabilidad:

Actualización a la última versión de Log4j 2
Ejecución de análisis de vulnerabilidades con un escáner
Actualizar las propiedades del sistema Java
Desactivar JNDI
Enviar un cuestionario de Apache Log4j a los proveedores
Emplear la autenticación multifactor

Lectura recomendada: Log4Shell: la vulnerabilidad de Log4J claramente explicada

Vulnerabilidades relacionadas de Log4J

Mientras Apache trabajaba para resolver la vulnerabilidad de Log4Shell, los investigadores y los actores de amenazas descubrieron fallas adicionales en varias versiones de Log4j. El NIST ha identificado estos defectos con los siguientes códigos:

CVE-2021-45046: Permite a los ciberdelincuentes enviar búsquedas JNDI maliciosas, presentes en Log4j 2.15 y versiones anteriores

CVE-2021-45105: Permite a los ciberdelincuentes desplegar ataques de denegación de servicio a través de mensajes maliciosos, presentes en Log4j 2.16 y versiones anteriores

CVE-2021-44832: Una vulnerabilidad de ejecución remota de código (RCE) que permite a los hackers explotar sistemas con código arbitrario si tienen permisos elevados, presente en Log4j 2.17 y versiones anteriores

11 preguntas sobre Apache Log4J para hacer a sus proveedores

Los cuestionarios de seguridad son una de las formas más eficaces en que una organización puede evaluar la postura de seguridad de sus proveedores externos. Su organización puede utilizar las siguientes 11 preguntas para crear un cuestionario de seguridad para identificar cualquier versión obsoleta de Log4j en todo su ecosistema de proveedores.

Descubra la sólida biblioteca de cuestionarios de seguridad de UpGuard>

1. ¿Su organización ejecuta alguna versión de Log4j 2?

Sí
No
[Abrir campo de texto para comentarios del proveedor]

2. ¿Su organización se ha actualizado a Log4j 2.17.1 como recomiendan Apache Software Foundation y CISA?

Sí, la organización ha actualizado a Log4j 2.17.1
No, la organización no puede actualizar a Log4j 2.17.1 (explique a continuación)
La organización aún no ha actualizado a Log4j 2.17.1
[Abrir campo de texto para comentarios del proveedor]

3. En caso negativo, ¿qué versión de Log4j 2 ejecuta actualmente su organización?

La organización utiliza una versión de Log4j 2 entre 2.7 y 2.14.1 (pase a la pregunta 3)
La organización utiliza una versión de Log4j 2 entre 2.0-beta9 y 2.10.0 (pase a la pregunta 4)
La organización utiliza Log4j 2.17.1

4. Si su organización utiliza una versión de Log4j2 entre la 2.7 y la 2.14.1, ¿se han implementado los siguientes esfuerzos de mitigación?

a) La propiedad del sistema, log4j2.formatMsgNoLookups, o la variable de entorno, LOG4J_FORMAT_MSG_NO_LOOKUPS, se han establecido en true

b) Todos los patrones de PatternLayout se han modificado a %m{nolookups} en lugar de solo %m

La organización ha implementado medidas de precaución a)
La organización ha implementado la precaución b)
La organización ha implementado las precauciones a) y b)
[Abrir campo de texto para comentarios del proveedor]

5. Si su organización utiliza una versión de Log4j2 entre 2.0-beta9 y 2.10.0, ¿se han implementado los siguientes esfuerzos de mitigación?

a) La propiedad del sistema, log4j2.formatMsgNoLookups, o la variable de entorno, LOG4J_FORMAT_MSG_NO_LOOKUPS, se han establecido en true

b) La clase JndiLookup se ha retirado de la ruta: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

La organización ha implementado medidas de precaución a)
La organización ha implementado la precaución b)
La organización ha implementado las precauciones a) y b)
[Abrir campo de texto para comentarios del proveedor]

6. ¿Su organización utilizó el repositorio GitHub de CISA para identificar los activos vulnerables a Log4Shell?

Sí
No
[Abrir campo de texto para comentarios del proveedor]

7. ¿Ha identificado su organización algún indicador de compromiso (IOC) como resultado de la vulnerabilidad de Log4Shell?

Sí (enumere a continuación)
No
[Abrir campo de texto para comentarios del proveedor]

8. ¿Cómo afectó la vulnerabilidad de Log4Shell a su organización?

La vulnerabilidad no afectó a la organización y no estuvimos expuestos a ningún ataque cibernético ni a problemas de seguridad derivados de la vulnerabilidad
La vulnerabilidad afectó moderadamente a la organización, pero no se vieron afectados los sistemas, la infraestructura, los servicios o los datos críticos (explique a continuación)
La vulnerabilidad afectó directamente a los sistemas, la infraestructura, los servicios y/o los datos críticos de la organización (explique a continuación)
[Abrir campo de texto para comentarios del proveedor]

9. ¿Su organización tiene un plan de respuesta a incidentes para responder a las amenazas cibernéticas?

Sí, la organización cuenta con un plan de respuesta a incidentes
La organización está en el proceso de finalizar un plan de respuesta a incidentes específico
No, la organización no cuenta con un plan de respuesta a incidentes
[Abrir campo de texto para comentarios del proveedor]

10. ¿Con qué frecuencia su organización implementa evaluaciones de riesgos en profundidad para evaluar las vulnerabilidades de seguridad internas?

Anualmente
Cada seis meses
Según sea necesario, o no tengamos una cadencia programada para las evaluaciones de riesgos
[Abrir campo de texto para comentarios del proveedor]

11. ¿Quién es el punto de contacto de su organización para responder preguntas y consultas adicionales?

Nombre:
Título:
Correo electrónico:
Teléfono:
[Abrir campo de texto para comentarios del proveedor]

Cómo remediar los riesgos de los proveedores

Si su organización implementa un cuestionario de seguridad de Apache Log4j y descubre que un proveedor está ejecutando una versión vulnerable de Log4j 2, debe corregir el riesgo de inmediato. Su organización debe priorizar los esfuerzos de corrección en función de la criticidad del proveedor si hay varios proveedores expuestos.

En función del nivel de concienciación sobre seguridad del proveedor, es posible que la organización tenga que trabajar junto con el equipo de seguridad del proveedor para implementar las actualizaciones y los protocolos de corrección necesarios.

El equipo puede seguir el siguiente flujo de trabajo de corrección al identificar un proveedor expuesto:

Comunícate con el punto de contacto identificado y solicita la corrección
Sugerir procedimientos de mitigación, como la eliminación de búsquedas JNDI, la actualización a la última versión de Log4j, el uso del repositorio GitHub de CISA para inventariar a los proveedores y otros recomendados por Apache y CISA
Comunicar las expectativas, los plazos y las consecuencias de los avisos en caso de errores de corrección
Enviar un nuevo cuestionario de seguridad para comprobar que el riesgo se ha corregido

Lectura recomendada: Elegir un software automatizado de remediación de riesgos de proveedores en 2024

UpGuard es una empresa de ciberseguridad dedicada a ayudar a los equipos de seguridad a proteger sus superficies de ataque internas y de terceros. Los dos productos de UpGuard, Vendor Risk y BreachSight, permiten a las organizaciones mejorar su higiene cibernética, evaluar la postura de seguridad de los proveedores individuales e implementar protocolos sólidos de gestión de riesgos de proveedores y de gestión de riesgos cibernéticos.

Las capacidades de escaneo y evaluación de vulnerabilidades de UpGuard permiten a las organizaciones identificar varias vulnerabilidades que podrían afectar su postura de seguridad y provocar ataques cibernéticos como malware o ransomware.

UpGuard Vendor Risk e BreachSight incluyen las siguientes características: