Los expertos en seguridad de TI comentan sobre la brecha de seguridad log4j para la cual BSI ha declarado el nivel de advertencia roja. Expertos de Barracuda Networks, Radar Cyber Security y ForeNova brindan una evaluación de la situación.
Jonathan Tanner, investigador sénior de seguridad en Barracuda Networks
Jonathan Tanner, investigador sénior de seguridad de Barracuda Networks: "Debido a que esta vulnerabilidad permite la ejecución remota de código, los riesgos son bastante altos" (Imagen: Barracuda Networks).
¿Cómo pueden las empresas identificar esta vulnerabilidad en su tecnología y cuáles son los riesgos si no se soluciona?
“Primero se debe verificar si se usa una versión de log4j anterior a la 2.15.0, también en las dependencias. Tanto Maven como Gradle, ambas herramientas de gestión de compilación basadas en Java, brindan la capacidad de imprimir todo el árbol de dependencias de un proyecto. De esta forma se puede determinar si se está utilizando o no una versión vulnerable de log4j. Incluso con la versión 2.15.0 o posterior, asegúrese de que la propiedad del sistema formatMsgNoLookups no esté establecida en 'true'.
La única razón por la que esta versión no es vulnerable es que ha establecido el valor predeterminado de verdadero a falso. En algunas versiones de log4j, esta propiedad se puede establecer fácilmente en false de forma manual para mitigar la vulnerabilidad. Si la aplicación no requiere LDAP como parte de su uso legítimo, también es posible bloquear todo el tráfico LDAP con un firewall o un filtro de aplicaciones web para evitar que se alcance el código remoto en caso de que se aproveche la vulnerabilidad.
Sin embargo, estos solo verifican si log4j puede explotar esta vulnerabilidad RCE o no. Si un sistema es realmente vulnerable a un ataque o no, es un asunto mucho más complicado sin una sola prueba como las vulnerabilidades como las que tenía HeartBleed. Para aprovechar esta vulnerabilidad, un atacante necesitaría realizar un ataque de inyección de registros. Encontrarlos es un proceso mucho más complejo, pero básicamente cualquier lugar donde se registre la entrada de un usuario (o de un atacante potencial) puede ser vulnerable a este ataque.
Por lo tanto, para probar un RCE real, habría que intentar encontrar una forma de realizar una solicitud LDAP JNDI dentro de los registros del propio contexto del usuario (por ejemplo, a través del sitio web o la API si la aplicación potencialmente afectada es una aplicación web). Dado que esta vulnerabilidad permite la ejecución remota de código, los riesgos son bastante altos. Un atacante podría potencialmente penetrar en la red e intentar acceder a recursos y datos importantes desde allí”.
¿Qué papel desempeñó el código abierto en esta vulnerabilidad y cuáles son las principales consideraciones de seguridad para las organizaciones que utilizan herramientas como log4j?
“Debido a que log4j es una biblioteca de código abierto muy popular, la cantidad de aplicaciones vulnerables fue ciertamente mayor. En general, cualquier software puede ser vulnerable a los ataques, y el software de código abierto popular a menudo tiene un gran ecosistema que busca y soluciona las amenazas de seguridad. Aunque el software de código abierto ocupa la mayoría de los titulares cuando se encuentran vulnerabilidades importantes, eso no significa que sea proporcionalmente menos seguro (de hecho, probablemente sea mucho más seguro que el código propietario o las bibliotecas menos populares). La distribución generalizada solo aumenta la probabilidad de que se encuentren vulnerabilidades, no necesariamente la probabilidad de que existan.
Al buscar bibliotecas de código abierto, las empresas deben elegir proyectos grandes, de buena reputación y bien mantenidos como log4j por las razones anteriores. Por supuesto, aún puede haber vulnerabilidades, pero es más probable que la comunidad encuentre y parchee esas vulnerabilidades, y también verifique que el código esté libre de errores que podrían causar vulnerabilidades en primer lugar, que en proyectos más pequeños.
Incluso para aquellos cuyas aplicaciones no son vulnerables a CVE-2021-44228, o que no usan log4j para iniciar sesión, esta vulnerabilidad es definitivamente una llamada de atención de que la inyección de registros es un método potencial que los atacantes podrían usar. Vale la pena verificar que todas las entradas de los usuarios que se registran estén correctamente desinfectadas en cada aplicación, sin importar qué sistema de registro o incluso qué lenguaje de programación se use. Si bien otras formas de inyección son mucho más comunes y son el foco de interés, la inyección de registros sigue siendo una forma de ataque de inyección y, por lo tanto, se encuentra dentro de las 10 vulnerabilidades principales de OWASP”.
¿Cómo pueden las empresas identificar esta vulnerabilidad en su tecnología y cuáles son los riesgos si no se soluciona?
“Primero debe verificar si se usa una versión de log4j anterior a la 2.15.0, también en las dependencias. Tanto Maven como Gradle, ambas herramientas de gestión de compilación basadas en Java, brindan la capacidad de imprimir todo el árbol de dependencias de un proyecto. De esta forma se puede determinar si se está utilizando o no una versión vulnerable de log4j. Incluso con la versión 2.15.0 o posterior, asegúrese de que la propiedad del sistema formatMsgNoLookups no esté establecida en 'true'. La única razón por la que esta versión no es vulnerable es que ha establecido el valor predeterminado de verdadero a falso.
En algunas versiones de log4j, esta propiedad se puede establecer fácilmente en false de forma manual para mitigar la vulnerabilidad. Si la aplicación no requiere LDAP como parte de su uso legítimo, también es posible bloquear todo el tráfico LDAP con un firewall o un filtro de aplicaciones web para evitar que se alcance el código remoto en caso de que se aproveche la vulnerabilidad. Sin embargo, estos solo verifican si log4j puede explotar esta vulnerabilidad RCE o no. Si un sistema es realmente vulnerable a un ataque o no, es un asunto mucho más complicado sin una sola prueba como las vulnerabilidades como las que tenía HeartBleed.
Para aprovechar esta vulnerabilidad, un atacante necesitaría realizar un ataque de inyección de registros. Encontrarlos es un proceso mucho más complejo, pero básicamente cualquier lugar donde se registre la entrada de un usuario (o de un atacante potencial) puede ser vulnerable a este ataque. Por lo tanto, para probar un RCE real, habría que intentar encontrar una forma de realizar una solicitud LDAP JNDI dentro de los registros del propio contexto del usuario (por ejemplo, a través del sitio web o la API si la aplicación potencialmente afectada es una aplicación web).
Dado que esta vulnerabilidad permite la ejecución remota de código, los riesgos en caso de una vulnerabilidad son bastante altos. Un atacante podría potencialmente penetrar en la red e intentar acceder a recursos y datos importantes desde allí”.
Más en Barracuda.com
Lothar Haensler, director de operaciones de Radar Cyber Security
Lothar Hänsler, COO de Radar Cyber Security: "La vulnerabilidad es relativamente fácil de explotar, los ataques se pueden ocultar fácilmente" (Imagen: Radar Cyber Security).
lo que pasó de todos modos
“El fin de semana pasado, se descubrió una vulnerabilidad en el módulo log4j2 de Apache.org y rápidamente se le asignó una puntuación CVSS de 10, el nivel de criticidad más alto. Autoridades como la Oficina Federal para la Seguridad de la Información (BSI, por sus siglas en inglés) elevaron rápidamente su evaluación de riesgos, que inicialmente era naranja, a rojo”.
¿Qué hace que esta vulnerabilidad sea tan especial?
“Las vulnerabilidades son relativamente fáciles de explotar, los ataques pueden oscurecerse fácilmente (ofuscación). Además, las medidas defensivas no son fáciles de implementar. Una de las razones de esto es que todas las estrategias de mitigación pueden tener riesgos y efectos secundarios en las aplicaciones afectadas por la vulnerabilidad. Sin embargo, las evaluaciones en los grupos de expertos son muy dinámicas, por lo que también hay diferentes perspectivas sobre las estrategias de mitigación”.
¿Qué ha hecho exactamente Radar Cyber Security?
"Durante el fin de semana, primero analizamos la situación de los datos con una respuesta al incidente, estimamos el impacto, utilizamos varias fuentes de información de plataformas internacionales como los Equipos de Respuesta a Emergencias Informáticas (CERT) y diseñamos una estrategia para enfrentar esta amenaza. Finalmente, el lunes por la mañana, enviamos un aviso de seguridad a todos nuestros clientes. Nuestro Centro de Defensa Cibernética (CDC) se ha configurado en modo de alerta alta.
Ahora presta especial atención a la ocurrencia de la vulnerabilidad en el módulo log4j2, sin descuidar la postura de seguridad general. Hemos actualizado los módulos de detección para verificar y reportar exploits de esta vulnerabilidad a nuestros clientes. Esto abarca desde la gestión de vulnerabilidades hasta los servicios SIEM clásicos y las herramientas de análisis de red individuales. Al mismo tiempo, comenzamos un análisis de nuestros propios sistemas. Después del primer escaneo en un primer cliente, se identificaron dos incidentes críticos en muy poco tiempo. Otros servicios especiales analizan si los clientes se ven afectados específicamente por esta vulnerabilidad. En casos extremos, es posible que sea necesario apagar los sistemas”.
Más en RadarCS.com
Paul Smith, director de servicios profesionales de ForeNova
Paul Smit, Director de Servicios Profesionales de ForeNova: "La vulnerabilidad de día cero en log4j es extremadamente peligrosa porque puede explotarse directamente sin recargar explícitamente el código malicioso" (Imagen: ForeNova).
“La vulnerabilidad de día cero en la biblioteca Java log4j ampliamente utilizada es extremadamente peligrosa porque la vulnerabilidad se puede explotar directamente sin recargar explícitamente el código malicioso. Sin embargo, si esto sucederá de inmediato o no, solo se puede ver cuando es demasiado tarde. Un punto final puede verse comprometido, pero aún no a la vista de los piratas informáticos. En este momento, se está volviendo evidente la necesidad de que las pequeñas y medianas empresas piensen en la detección y respuesta de red y la detección y respuesta de punto final juntas como una estrategia de defensa integral. EDR ve si el malware se ha instalado y organiza la defensa en el endpoint.
Ver el pasado con NDR
Con NDR, también puede ver en los datos de registro retrospectivamente a qué sistemas los piratas informáticos intentaron acceder desde el exterior. NDR también ve el tráfico típico resultante de dicho intento de acceso, como la comunicación con los servidores C2C, el escaneo de puertos y el tráfico específico. NDR también permite el bloqueo y segmentación de redes o la cuarentena de sistemas, una medida que debe tomarse en caso de duda. Una solución NDR como NovaComand también analiza los datos de telemetría de los puntos finales. NovaCommand ha lanzado un parche y ha actualizado las reglas para detectar este tipo de ataques. NovaCommand también activa otras soluciones de terceros para bloquear y segmentar los sistemas y secciones de red afectados”.
Más en ForeNova.com
Artículos relacionados con el tema