Las vulnerabilidades de Log4j llegaron para quedarse: ¿está preparado?

La vulnerabilidad generalizada que apareció por primera vez en Apache Log4j en 2021 seguirá siendo explotado, potencialmente incluso de formas peores que las que hemos visto hasta la fecha. El aspecto más preocupante de estas amenazas es que existe una buena posibilidad de que continúen siendo explotadas meses o años en el futuro.

La junta de Revisión de Seguridad Cibernética del Departamento de Seguridad Nacional debutó en 2021 y en 2022 lanzó su informe inaugural de seguridad (PDF). En él, la junta llamó a Log4j una "vulnerabilidad endémica", principalmente porque no hay una "lista de clientes" completa para Log4j, lo que hace que mantenerse al día con las vulnerabilidades sea una tarea casi imposible. Un departamento del Gabinete federal incluso dedicó 33,000 horas a su respuesta Log4j.

Y muchas organizaciones y soluciones de seguridad en el mercado no logran identificar la diferencia entre explotabilidad y vulnerabilidad, lo que deja una oportunidad para que los atacantes lleven a cabo actividades maliciosas.

Explotabilidad vs. Vulnerabilidad

Uno de los problemas clave de la ciberseguridad en la actualidad es comprender la diferencia entre las vulnerabilidades y su gravedad. Cuando se trata de medir la explotabilidad frente a una vulnerabilidad, existe una gran diferencia entre si una amenaza de seguridad es explotable dentro de su negocio o si es simplemente "vulnerable" y no puede obstaculizar el negocio o alcanzar un activo crítico. Los equipos de seguridad pasan demasiado tiempo sin comprender la diferencia entre los dos y solucionan cada vulnerabilidad a medida que se presenta, en lugar de priorizar aquellas que son explotables.

Cada empresa tiene miles de vulnerabilidades y exposiciones comunes (CVE), muchas de las cuales obtienen una puntuación alta en el Sistema de puntuación de vulnerabilidades comunes (CVSS), por lo que es imposible solucionarlas todas. Para combatir esto, la esperanza es que las herramientas de gestión de vulnerabilidades basadas en riesgos (RBVM) facilitar la priorización aclarando qué es explotable.

Sin embargo, los enfoques de priorización de seguridad que combinan puntajes de CVSS con información de amenazas de RBVM no brindan resultados óptimos. Incluso después de filtrar y observar solo lo que se puede explotar en la naturaleza, los equipos de seguridad todavía tienen mucho que manejar porque la lista es larga e inmanejable. Y el hecho de que un CVE no tenga un exploit hoy no significa que no lo tendrá la próxima semana.

En respuesta, las empresas han estado agregando IA de riesgo predictivo, que puede ayudar a los usuarios a comprender si un CVE podría ser explotado en el futuro. Esto todavía no es suficiente y conduce a demasiados problemas para solucionar. Miles de vulnerabilidades seguirán demostrando tener un exploit, pero muchas tendrán otros conjuntos de condiciones que deben cumplirse para realmente explotar el problema.

Por ejemplo, con Log4j, se deben identificar los siguientes parámetros:

• ¿Existe la biblioteca Log4j vulnerable?
• ¿Se carga mediante una aplicación Java en ejecución?
• ¿Está habilitada la búsqueda JNDI?
• ¿Java está escuchando conexiones remotas y hay una conexión para otras máquinas?

Si no se cumplen las condiciones y los parámetros, la vulnerabilidad no es crítica y no debe priorizarse. E incluso si una vulnerabilidad pudiera explotarse en una máquina, ¿y qué? ¿Es esa máquina extremadamente crítica, o tal vez no está conectada a ningún activo crítico o sensible?

También es posible que la máquina no sea importante, pero puede permitir que un atacante continúe hacia activos críticos de manera más sigilosa. En otras palabras, el contexto es clave: ¿esta vulnerabilidad se encuentra en una posible ruta de ataque al activo crítico? ¿Es suficiente cortar una vulnerabilidad en un cuello de botella (una intersección de múltiples rutas de ataque) para evitar que la ruta de ataque alcance un activo crítico?

Los equipos de seguridad odian los procesos de vulnerabilidad y sus soluciones, porque cada vez hay más vulnerabilidades: nadie puede borrar completamente la pizarra. pero si pueden centrarse en lo que puede crear dañar a un activo crítico, pueden comprender mejor por dónde empezar.

Combatir las vulnerabilidades de Log4j

La buena noticia es que la gestión adecuada de vulnerabilidades puede ayudar a reducir y corregir la exposición a ataques centrados en Log4j al identificar dónde existe el riesgo de una posible explotación.

La gestión de vulnerabilidades es un aspecto importante de la ciberseguridad y es necesaria para garantizar la seguridad y la integridad de los sistemas y los datos. Sin embargo, no es un proceso perfecto y las vulnerabilidades aún pueden estar presentes en los sistemas a pesar de los mejores esfuerzos para identificarlas y mitigarlas. Es importante revisar y actualizar periódicamente los procesos y estrategias de gestión de vulnerabilidades para garantizar que sean efectivos y que las vulnerabilidades se aborden de manera oportuna.

El enfoque de la gestión de vulnerabilidades no debe estar solo en las vulnerabilidades en sí mismas, sino también en el riesgo potencial de explotación. Es importante identificar los puntos en los que un atacante puede haber obtenido acceso a la red, así como las rutas que puede tomar para comprometer activos críticos. La forma más eficiente y rentable de mitigar los riesgos de una vulnerabilidad en particular es identificar las conexiones entre las vulnerabilidades, las configuraciones incorrectas y el comportamiento del usuario que podría explotar un atacante, y abordar estos problemas de manera proactiva antes de que se explote la vulnerabilidad. Esto puede ayudar a interrumpir el ataque y evitar daños en el sistema.

También debes hacer lo siguiente:

• Parche: Identifique todos sus productos que son vulnerables a Log4j. Esto se puede hacer manualmente o utilizando escáneres de código abierto. Si se lanza un parche relevante para uno de sus productos vulnerables, parchee el sistema lo antes posible.
• Solución del problema: En las versiones Log4j 2.10.0 y superiores, en la línea Java CMD, establezca lo siguiente: log4j2.formatMsgNoLookups=true
• Bloquear: Si es posible, agregue una regla a su firewall de aplicaciones web para bloquear: “jndi:”

La seguridad perfecta es una hazaña inalcanzable, por lo que no tiene sentido convertir a la perfección en enemigo de lo bueno. En su lugar, concéntrese en priorizar y bloquear posibles rutas de ataque que mejoren continuamente la postura de seguridad. Identificar y ser realista sobre lo que realmente es vulnerable frente a lo que es explotable puede ayudar a hacer esto, ya que permitirá la capacidad de canalizar estratégicamente los recursos hacia las áreas críticas que más importan.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://www.darkreading.com/attacks-breaches/log4j-vulnerabilities-are-here-to-stay-are-you-prepared-