Durante los últimos dias en la red se ha estado hablando bastante sobre la vulnerabilidad de Log4j en la cual se han descubierto diversos vectores de ataque y que ademas se han filtrado diversos exploits funcionales para poder explotar la vulnerabilidad.

La gravedad el asunto radica que este es un marco popular para organizar el registro en aplicaciones Java, que permite la ejecución de código arbitrario cuando se escribe un valor con formato especial en el registro en el formato «{jndi: URL}». El ataque se puede llevar a cabo en aplicaciones Java que registran valores obtenidos de fuentes externas, por ejemplo, al mostrar valores problemáticos en mensajes de error.

Y es que un atacante realiza una solicitud HTTP en un sistema de destino, que genera un registro usando Log4j 2 que usa JNDI para realizar una solicitud en el sitio controlado por el atacante. Luego, la vulnerabilidad hace que el proceso explotado llegue al sitio y ejecute la carga útil. En muchos ataques observados, el parámetro que pertenece al atacante es un sistema de registro de DNS, destinado a registrar una solicitud en el sitio para identificar sistemas vulnerables.

Tal y como ya compartio nuestro compañero Isaac:

Esta vulnerabilidad de Log4j permite explotar una validación de entrada incorrecta a LDAP, permitiendo ejecución remota de código (RCE), y comprometiendo el servidor (confidencialidad, integridad de datos y disponibilidad del sistema). Además, el problema o importancia de esta vulnerabilidad reside en la cantidad de aplicaciones y servidores que la usan, incluyendo software empresarial y servicios en la nube como Apple iCloud, Steam, o videojuegos tan populares como Minecraft: Java Edition, Twitter, Cloudflare, Tencent, ElasticSearch, Redis, Elastic Logstash, y un largo etc.

Hablando sobre el asunto, hace poco la Apache Software Foundation dio a conocer mediante una publicación un resumen de los proyectos que abordan una vulnerabilidad crítica en Log4j 2 que permite que se ejecute código arbitrario en el servidor.

Los siguientes proyectos de Apache se ven afectados: Archiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl y Calcite Avatica. La vulnerabilidad también afectó a los productos de GitHub, incluidos GitHub.com, GitHub Enterprise Cloud y GitHub Enterprise Server.

En los últimos días se ha producido un aumento significativo de la actividad relacionada con la explotación de la vulnerabilidad. Por ejemplo, Check Point registró alrededor de 100 intentos de explotación por minuto en sus servidores ficticios en su punto máximo, y Sophos anunció el descubrimiento de una nueva botnet para la minería de criptomonedas, formada a partir de sistemas con una vulnerabilidad sin parchear en Log4j 2.

En cuanto a la informacion que se ha estado dando a conocer sobre el problema:

• La vulnerabilidad se ha confirmado en muchas imágenes oficiales de Docker, incluidas couchbase, elasticsearch, flink, solr, imágenes de tormenta, etc.
• La vulnerabilidad está presente en el producto MongoDB Atlas Search.
• El problema aparece en una variedad de productos de Cisco, incluidos Cisco Webex Meetings Server, Cisco CX Cloud Agent, Cisco
• Advanced Web Security Reporting, Cisco Firepower Threat Defense (FTD), Cisco Identity Services Engine (ISE), Cisco CloudCenter, Cisco DNA Center, Cisco. BroadWorks, etc.
• El problema está presente en IBM WebSphere Application Server y en los siguientes productos de Red Hat : OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse y AMQ Streams.
• Problema confirmado en Junos Space Network Management Platform, Northstar Controller / Planner, Paragon Insights / Pathfinder / Planner.
• Muchos productos de Oracle , vmWare , Broadcom y Amazon también se ven afectados .

Los proyectos de Apache que no se ven afectados por la vulnerabilidad Log4j 2: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper y CloudStack.

Se recomienda a los usuarios de paquetes problemáticos que instalen urgentemente las actualizaciones publicadas para ellos, actualicen por separado la versión de Log4j 2 o establezcan el parámetro Log4j2.formatMsgNoLookups en verdadero (por ejemplo, agregando la clave «-DLog4j2.formatMsgNoLookup=True» al inicio ).

Para bloquear el sistema es vulnerable al que no hay acceso directo, se sugirió explotar la vacuna Logout4Shell, que, a través de la comisión de un ataque, expone el ajuste de Java «log4j2.formatMsgNoLookups=true», «com.sun.jndi.rmi.object. trustURLCodebase=false » y» com.sun.jndi.cosnaming.object.trustURLCodebase=false «para bloquear más manifestaciones de la vulnerabilidad en sistemas no controlados.