Es hora de hacer sonar la alarma de Log4Shell. Saryu Nayyar, director general de Gurucul, analiza las medidas que se deberían tomar.
No es mi intención ser alarmista sobre la vulnerabilidad de Log4j (CVE-2021-44228), conocida como Log4Shell, pero esta es bastante mala.
En primer lugar, Log4j es una biblioteca de registro omnipresente que es muy utilizada por millones de ordenadores. En segundo lugar, la directora de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE.UU. (CISA) dice que esta es la vulnerabilidad más grave que ha visto en su carrera de décadas, y muchos expertos en seguridad están de acuerdo. En tercer lugar, los investigadores afirman que los ciberatacantes ya están explotando la vulnerabilidad cientos de veces cada minuto. El hecho es que Log4Shell es relativamente fácil de explotar, por lo que incluso los hackers poco cualificados pueden aprovecharse.
De acuerdo, quizá sea el momento de alarmarse.
Log4j es un software de código abierto de la Apache Software Foundation. Como explica The Conversation, esta biblioteca de registro se utiliza ampliamente para registrar eventos como operaciones rutinarias del sistema y errores, y para comunicar mensajes de diagnóstico relativos a esos eventos. Una función de Log4j permite a los usuarios del software especificar un código personalizado para formatear un mensaje de registro. Esta función también permite a los servidores de terceros enviar código de software que puede realizar todo tipo de acciones -incluidas las maliciosas- en el ordenador objetivo. El resultado de un exploit para el fallo es que un atacante puede controlar un servidor objetivo de forma remota.
Los atacantes se aprovecharon pronto
A las pocas semanas de descubrirse el fallo, a mediados de diciembre, ya se informó de que grupos de países vinculados a Corea del Norte, China, Irán y otros países habían creado conjuntos de herramientas para explotar rápidamente esta vulnerabilidad. Log4Shell también se convirtió en el favorito de las bandas de ransomware y botnet que operan en todo el mundo. El peligro real de este fallo es que hay muchas formas de explotarlo con fines maliciosos.
¿Cuál es la prevalencia de Log4j en los sistemas empresariales? Un análisis realizado por Wiz y Ernst & Young de más de 200 entornos empresariales en la nube con miles de cuentas en la nube demostró que el 93% de esos entornos están en riesgo por la vulnerabilidad.
Los investigadores de Google descubrieron que más del 8 por ciento de todos los paquetes de Maven Central, un gran repositorio de paquetes de Java, tienen al menos una versión afectada por esta vulnerabilidad, una cantidad "enorme" según todos los estándares de impacto en el ecosistema.
Así que, sí, es una presencia bastante amplia de esta vulnerabilidad. En cuanto al impacto global, todavía es demasiado pronto para decirlo. Mucho dependerá de la forma en que las organizaciones respondan a la amenaza.
Todo el mundo debe tomar medidas
Para todos los afectados por esto, existe un imperativo tanto empresarial como moral de tomar medidas inmediatas para mitigar la vulnerabilidad si existe en los sistemas de cara al público. Naturalmente, ninguna empresa quiere que sus sistemas sean vulnerables a un ataque que puede conducir a la corrupción o al robo de datos y a la posibilidad de una grave interrupción de la actividad.
En cuanto al imperativo moral, la Comisión Federal de Comercio señala que las empresas tienen la responsabilidad de tomar medidas "para reducir la probabilidad de daño a los consumidores". Con las secuelas de la brecha de Equifax todavía frescas en la memoria, la FTC advierte que "tiene la intención de utilizar su plena autoridad legal para perseguir a las empresas que no toman medidas razonables para proteger los datos de los consumidores de la exposición como resultado de Log4j, o vulnerabilidades similares conocidas en el futuro." No todas las empresas sirven a los consumidores, por supuesto, pero eso no debería importar a la hora de abordar esta cuestión.
La CISA publicó una lista de "acciones inmediatas" que las organizaciones deben emprender para remediar los riesgos que plantea Log4Shell. La principal acción es comprender el alcance del problema identificando cuáles de sus activos utilizan el software Log4j y luego aplicar un parche adecuado. Detener la hemorragia, por así decirlo.
Después de eso, debe asumir que ya ha sido comprometido, buscar señales de actividad maliciosa dentro de sus sistemas y continuar monitoreando patrones de tráfico o comportamiento extraños que podrían ser indicativos de un ataque en curso.
Es esencial detectar la actividad de las amenazas cuando se explota la vulnerabilidad o cuando los atacantes se insertan con éxito en su entorno. Aquí es donde se pone a prueba la eficacia de sus herramientas de seguridad.
¿Qué eficacia tienen tus herramientas de seguridad?
Las herramientas de seguridad que dependen de la detección tradicional basada en reglas y la concordancia de patrones pueden haber detectado fácilmente algunos de los comandos ejecutados por el malware inyectado en los primeros días de este exploit. Sin embargo, a medida que las variantes de Log4Shell se difunden con mejores tácticas de ejecución, las herramientas tradicionales de gestión de información y eventos de seguridad (SIEM) y de detección y respuesta ampliada (XDR) pueden tener dificultades para identificar los ataques, a menos que los proveedores de herramientas realicen actualizaciones muy frecuentes de la base de reglas. Y eso no es práctico. También será crucial adoptar un enfoque de seguridad por capas que incluya algunos métodos de detección avanzados, como el aprendizaje automático, la inteligencia artificial y el análisis del comportamiento.
Todas las organizaciones deberían tener un plan de mitigación en caso de que algo como esto se repita en el futuro. Ya sea para cerrar la pieza de software ofensiva, o para corregirla inmediatamente y probar el parche antes de que vuelva a la producción, los equipos deben estar preparados para una respuesta proactiva en horas o incluso minutos.
Log4Shell es una llamada de atención para todos. No debemos pulsar el botón de repetición hasta que aparezca la siguiente vulnerabilidad.
Fuente: https://threatpost.com/log4j-vulnerability-pressures-security-world/177721/