Zero Day en la omnipresente herramienta Apache Log4j bajo ataque activo - Calendae | Informática, Electrónica, CMS, Ciberseguridad

Zero Day en la omnipresente herramienta Apache Log4j bajo ataque activo

Hola y mil gracias por leerme. En el teclado Eduardo Arroyo y en el día de hoy te voy a hablar sobre Zero Day en la omnipresente herramienta Apache Log4j bajo ataque activo

Zero Day en la omnipresente herramienta Apache Log4j bajo ataque activo

La vulnerabilidad de Log4Shell amenaza críticamente a cualquiera que use el popular marco Apache Struts de código abierto y podría conducir a una «mini crisis de Internet pronto».

Una falla atroz y fácilmente explotada se explota en la naturaleza en la omnipresente biblioteca de registros de Java Apache Log4j que permite la ejecución de código remoto no autenticado (RCE) y la captura completa del servidor.

El viernes por la mañana temprano, el Equipo de Respuesta a Emergencias Cibernéticas (CERT) del Grupo Deutsche Telekom tuiteó que estaba viendo ataques en sus honeypots desde la red Tor cuando los actores de amenazas intentaron explotar la nueva vulnerabilidad de día cero, que se rastrea como «Log4Shell» por MoonSec y cómo CVE-2021-44228.

🚨⚠️Nueva vulnerabilidad # 0-day rastreada bajo «Log4Shell» y CVE-2021-44228 descubierta en Apache Log4j 🌶️‼ ️ Estamos observando ataques a nuestra infraestructura honeypot desde la red TOR. Encuentre instrucciones de mitigación aquí: https://t.co/tUKJSn8RPF pic.twitter.com/WkAn911rZX

– Deutsche Telekom CERT (@DTCERT) 10 de diciembre de 2021

lo mismo para CERT Nueva Zelanda y personas que han iniciado sesión en Twitter para advertir que también están viendo exploits en la naturaleza.

Este problema provocará una mini caída de Internet, dijeron los expertos, ya que Log4j está integrado en varios marcos populares, incluidos Apache Struts2, Apache Solr, Apache Druid y Apache Flink. Esto expone una asombrosa cantidad de aplicaciones de terceros que también pueden ser vulnerables al mismo tipo de exploit de alta gravedad que las que se encuentran en Minecraft, así como a servicios en la nube como Steam y Apple iCloud.

Incluso si se corrigió rápidamente, llevará algún tiempo llegar allí, dada la medida en que la biblioteca de grabaciones se construye en sentido descendente. «Espere un colapso de Mini Internet pronto», dijo el especialista en seguridad británico Kevin Beaumont, quien tuiteó que la solución «debe fluir en sentido descendente a Apache Struts2, Solr, distribuciones de Linux, proveedores, dispositivos, etc.»

Puntaje CVSS máximo de 10

El descubrimiento del error se ha atribuido a Chen Zhaojun de Alibaba. Fue galardonado con el puntuación máxima de CVSS de 10, dado lo relativamente fácil que es explotar, la capacidad de los atacantes para tomar el control de los servidores objetivo y la ubicuidad de Log4j.

La reacción de Internet: «Umm, ay».

«Esta vulnerabilidad log4j (CVE-2021-44228) es extremadamente grave», tuiteó el experto en seguridad Marcus Hutchins. «Millones de aplicaciones usan Log4j para el registro y todo lo que el atacante tiene que hacer es que la aplicación registre una cadena especial».

Según el informe del jueves de LunaSec, los servicios en la nube, incluidos Steam, Apple iCloud y aplicaciones como Minecraft, ya se habían encontrado vulnerables, pero a partir del viernes por la tarde ET, los informes de otras aplicaciones afectadas se estaban extendiendo.

Solo un ejemplo de la escala masiva del error: el viernes por la mañana, Rob Joyce, director de ciberseguridad de la Agencia de Seguridad Nacional / (NSA), tuiteó que incluso la NSA Ghidra – un conjunto de herramientas de ingeniería inversa desarrolladas por la Dirección de Investigación de la NSA – incluye la biblioteca buggy log4j.

“La vulnerabilidad log4j es una amenaza significativa para la explotación debido a la inclusión generalizada en los marcos de software, incluida la GHIDRA de la NSA. Este es un caso de estudio sobre por qué los conceptos de la lista de materiales de software (SBOM) son tan importantes para comprender la exposición ”. —Rob Joyce, director de seguridad cibernética de la NSA

Visto por primera vez en sitios de Minecraft

La falla apareció por primera vez en sitios dirigidos a usuarios del juego favorito del mundo, Minecraft, el jueves. Los sitios según se informa advirtió que los atacantes podrían dejar caer código malicioso en servidores o clientes que ejecutan la versión Java de Minecraft manipulando los mensajes de registro, incluido el texto escrito en los mensajes de chat.

Según CERT Austria, la falla de seguridad de día cero se puede aprovechar simplemente registrando una cadena especial. Los investigadores le dijeron a Ars Technica que Log4Shell es un error de deserialización de Java que se deriva de que la biblioteca realiza solicitudes de red a través de Java Naming and Directory Interface (JNDI) a un servidor LDAP y ejecuta cualquier código de retorno. Según se informa, se activa dentro de los mensajes de registro utilizando la sintaxis $ .

«JNDI activa una búsqueda en un servidor controlado por un atacante y ejecuta el código de retorno», según el aviso de CERT Austria, publicado el viernes, que descubrió que el código para un exploit de prueba de concepto (PoC) era publicado en GitHub.

Versiones afectadas

El jueves, MoonSec Explicó que cualquiera que use Apache Struts, el popular marco de código abierto para desarrollar aplicaciones web en el lenguaje de programación Java, probablemente sea vulnerable. La compañía de seguridad dijo que hemos visto vulnerabilidades similares previamente explotadas en brechas como la violación masiva de Equifax de 2017.

La empresa de seguridad dijo que las versiones afectadas son 2.0

Agregó que las versiones de JDK por encima de 6u211, 7u201, 8u191 y 11.0.1 no se ven afectadas por el vector de ataque LDAP, ya que en esas versiones «com.sun.jndi.ldap.object.trustURLCodebase se establece en un JNDI falso, lo que significa que no se puede cargar un base de código remota usando LDAP. «

Pero hay «otros vectores de ataque que apuntan a esta vulnerabilidad que puede provocar RCE», continuó LunaSec. «Dependiendo del código presente en el servidor, un atacante podría explotar este código existente para ejecutar una carga útil», indicando una publicación de Veracode sobre un ataque dirigido a la clase org.apache.naming.factory.BeanFactory presente en los servidores Apache Tomcat.

La versión 2.15.0 se lanzó el viernes. log4j-core.jar está disponible en Maven Central aquí, con notas de la versión son disponible aquí y los anuncios de seguridad log4j de Apache disponible aquí.

LunaSec afirmó que «dado lo ubicua que es esta biblioteca, el impacto del exploit (control total del servidor) y lo fácil que es explotar, el impacto de esta vulnerabilidad es bastante severo».

Las organizaciones pueden averiguar si se ven afectadas examinando los archivos de registro de los servicios que utilizan las versiones afectadas de Log4j. Si contienen cadenas controladas por el usuario (CERT-NZ usa el ejemplo de “Jndi: ldap”), podrían estar interesados.

Para mitigar las vulnerabilidades, los usuarios deben establecer log4j2.formatMsgNoLookups en verdadero agregando: ”- Dlog4j2.formatMsgNoLookups = True” al comando JVM para iniciar la aplicación.

Para evitar que la biblioteca sea explotada, se recomienda urgentemente que las versiones de Log4j sean actualizado para log4j-2.15.0-rc1.

«Si cree que puede verse afectado por CVE-2021-44228, Randori alienta a todas las organizaciones a adoptar una mentalidad de presunta violación y revisar los registros de las aplicaciones afectadas para detectar actividades inusuales», los investigadores de ciberseguridad de Randori escrito en una publicación de blog.

Mitigación temporal

Para aquellos que no pueden actualizar de inmediato, LunaSec señaló discusión sobre HackerNews con respecto a una estrategia de mitigación disponible en la versión 2.10.0 y posterior que se publicó en las primeras horas de la mañana del viernes.

Esta estrategia ya no es necesaria con la versión 2.15.0, lo que la convierte en el comportamiento predeterminado.

Para las versiones anteriores a 2.10.0 que no se pueden actualizar, se han sugerido estas opciones de mitigación:

  • Edite el diseño de cada plantilla de registro para que diga% m nolookups en lugar de% m en sus archivos de configuración de registro (aquí están los detalles de Apache), o,
  • Reemplace una implementación vacía o no vulnerable de la clase org.apache.logging.log4j.core.lookup.JndiLookup, para que su cargador de clases use su reemplazo en lugar de la versión vulnerable de la clase. Consulte la documentación sobre la carga de aplicaciones o clases de pila para comprender este comportamiento.

.

Deberías compartir en en tu Twitter y Facebook para que tus colegas lo vean

??? ? ? ???

Comparte

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *