¿La vulnerabilidad de Log4J abre vulnerabilidades en una red interna segura que de otro modo no estarían presentes?
¿Existe un escenario de “aplicación interna segura” en el que el software es más vulnerable debido a versiones anteriores de Log4J más que si no las tuviera?
He detallado algunas notas sobre esta pregunta a continuación.
Estoy trabajando para mitigar los riesgos de la reciente vulnerabilidad de Log4J. Conozco enfoques que implican eliminar todos los rastros de las antiguas versiones de Log4J de todas las computadoras, servidores, escritorios remotos, todo en la organización, considerando que la organización está “en riesgo” hasta que se realice esta acción. Sin embargo, también me pregunto si gasto tan grande de esfuerzo generalizado es proporcional [editar 22-dic-21 12:15 – disculpas: para aclarar lo que intento entender con “proporcional” es si obtendremos mejores resultados enfocando mucho esfuerzo en algunas implementaciones de código de Log4J con menos esfuerzo en otras, considerando que puede haber otras vulnerabilidades no relacionadas con Log4J que podamos abordar durante esta carga de trabajo organizativa].
Tengo una comprensión básica de la vulnerabilidad, por ejemplo, a partir de https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/, donde un actor malintencionado envía un mensaje HTTP que contiene un comando JNDI, que luego se ejecuta cuando el programa intenta escribir en el registro la próxima vez. Los riesgos en este caso parecen obvios para aplicaciones públicas y me hacen pensar en ataques de Inyección de SQL bien comprendidos (se me viene a la mente el clásico
Pero una solución “generalizada” busca mitigar los riesgos para software como:
– aplicaciones web Java internas que están protegidas del mundo exterior (tanto entrante como saliente) mediante técnicas como cortafuegos y DMZ.
– programas de lote Java internos que esperaría que sean inmunes a manipulación durante su ejecución.
– escritorios virtuales Citrix que pueden funcionar en modo de administrador, dependiendo del usuario, pero que esperaría que sean totalmente inaccesibles desde el mundo exterior.
La única justificación que he escuchado hasta ahora para una solución “generalizada” es que un actor malintencionado podría infiltrarse en la red y hacer que se ejecute la vulnerabilidad de Log4J, pero en ese escenario parece que un actor malintencionado que se infiltre en una red podría simplemente ejecutar malware ellos mismos sin necesidad de buscar programas que utilicen versiones anteriores de Log4J.
davy.ai
Basándose en los detalles proporcionados, no está claro si existe un escenario de “aplicación interna segura” donde el software sea más vulnerable debido a versiones anteriores de Log4J que si no las tuviera. Si bien algunos riesgos asociados con la vulnerabilidad de Log4J son obvios, como aquellos para aplicaciones de cara al público o aquellos vulnerables a ataques de inyección de SQL, los riesgos para las aplicaciones internas protegidas por firewalls, DMZ y restricciones administrativas son menos claros. La justificación para una solución “generalizada” también es incierta, ya que es posible que un actor malicioso tenga otras formas más fáciles de ejecutar malware dentro de una red en lugar de enfocarse en programas que utilizan versiones anteriores de Log4J. Por lo tanto, sería necesario realizar un análisis y evaluación adicionales de las aplicaciones internas específicas y sus riesgos de seguridad para determinar la mejor acción a tomar.