Log4j: Vulnerabilidad en Java y cómo Afrontarlo

Blog

El pasado diciembre, el experto en ciberseguridad de Alibaba, Chen Zhaojun, descubrió una vulnerabilidad crítica en la biblioteca Java Log4j, que se utiliza en cientos de miles de aplicaciones en todo el mundo. La vulnerabilidad permite acceder de forma remota al servidor donde se almacena la aplicación y ejecutar código arbitrario en él.

Junto con los expertos, descubrimos por qué la biblioteca es tan popular, cuál es la vulnerabilidad y cómo se puede solucionar.

Concepto de vulnerabilidad Log4j
Concepto de vulnerabilidad Log4j

Qué es Log4j y por qué es tan popular

Log4j forma parte del proyecto Apache Logging. Se trata de una biblioteca de registro que ayuda a analizar el flujo de ejecución de instrucciones en un entorno de producción o de prueba. Puede etiquetar todas las llamadas con instrucciones textuales, lo que facilita el aislamiento de los problemas.

La biblioteca es utilizada por cientos de miles de programas, juegos, servidores en la nube y aplicaciones empresariales, incluidos los de Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla y Twitter. En general, los usuarios de Log4j pueden describirse como empresas muy grandes que, por una u otra razón, no utilizan las versiones actuales de Java. La mayoría de las veces se trata del segmento empresarial, en el que cualquier actualización del lenguaje, del framework o de la biblioteca supone un gran problema.

En el segmento empresarial, las aplicaciones más populares son las desarrolladas en tecnología JavaEE/JakartaEE y con Spring. En el ecosistema de Spring, el framework Boot, que utiliza LogBack como librería de registro por defecto, ha ganado recientemente especial popularidad. Para las empresas que utilizan Spring Boot (sin incluir la conexión Log4j2 personalizada), la vulnerabilidad no está amenazada.

Cuál es el peligro

Concepto de fallo de seguridad en biblioteca Java Log4j
Concepto de fallo de seguridad en biblioteca Java Log4j

El papel de Apache Log4j

Miles de aplicaciones están vinculadas a Apache Log4j, hasta Steam, Minecraft, Blender, LinkedIn, VMware, etc. El hecho de que la biblioteca se haya descargado desde GitHub más de 400.000 veces habla por sí mismo.

CVE-2021-44228 (o Log4Shell) es una vulnerabilidad de ejecución remota de código y sólo está presente en las versiones 2.0-beta9 a 2.14.1 de Log4j.

Tipo de vulnerabilidadEjecución remota de código (RCE)
El nivel de riesgoCrítica
La puntuación en la escala de CVSS10.0
Las versiones vulnerablesDe 2.0-beta9 hasta 2.14.1

Log4Shell utiliza JNDI (Java Naming and Directory Interface) para conectarse al servidor. Se trata de una API que proporciona un mecanismo uniforme para que un programa Java se comunique con varios servicios de nombres y directorios. Conociendo el nombre JNDI de un servidor LDAP, base de datos o agente de mensajería, es posible acceder a ellos mediante una operación de búsqueda.

Otra vulnerabilidad se refiere a la seguridad de las cadenas o strings. A menudo, las variables se exponen no sólo en el archivo de configuración, un importante vínculo con la biblioteca de registro, sino también en las strings. En el caso de las strings inseguras, la biblioteca escanea los mensajes del usuario y, si ve código fuente en ellos, lo ejecuta. Los investigadores de SecurityLab describen casos en los que Log4Shell se ha utilizado para minar criptomonedas o para realizar ataques DDoS.

Programas Bug bounty para evitar vulnerabilidades

Los cazadores de recompensas de errores (bug bounty hunters) inmediatamente presentaron miles de informes de vulnerabilidad relacionados con el fallo de Apache Log4j, que sigue causando conmoción en el ecosistema mundial del software.

El modelo de recompensas por errores (o bugs) está demostrando ser una parte vital de una defensa en capas durante la crisis, sostienen algunas empresas como ExpressVPN, que recientemente anunció su programa bug bounty.

Anuncio del programa Bug Bounty de ExpressVPN
Anuncio del programa Bug Bounty de ExpressVPN

Después del grave acontecimiento, algunos programas de bug bounty han introducido bonos o recompensas especiales específicamente para las vulnerabilidades de log4j después de que su investigación interna haya terminado. Hacerlo permite validar de forma cruzada las correcciones implementadas y garantiza que no se deje ningún punto débil.

Detección de Log4j

El equipo de BI.ZONE ha desarrollado y publicado en GitHub su propio escáner basado en la regla YARA (Log4j_Detector). Analiza la memoria de los procesos Java en busca de firmas de Log4j. Está escaneando desde dentro y no desde fuera, es decir, no viene de la red, sino directamente del host.

La salida es una lista de hosts que tienen aplicaciones que ejecutan Log4j, y puede comprobar la versión de la biblioteca.

También hay otras herramientas gratuitas disponibles en Internet que pueden probar si la aplicación web es vulnerable. Una de estas herramientas es https://log4shell.huntress.com/ que es de código abierto y se puede encontrar en GitHub

Resultados de la vulnerabilidad de Log4Shell con Huntress
Resultados de la vulnerabilidad de Log4Shell con Huntress

Y si es vulnerable, puedes hacer algo al respecto con los consejos del siguiente párrafo. No te eximirá de tener que instalar parches, pero reducirá el riesgo de explotar con éxito Log4Shell.

Qué hacer con la vulnerabilidad

El mejor consejo que se puede dar en esta situación es actualizar Log4j a la versión 2.15 o Java a la versión 11. Si la actualización es un problema, hay varias soluciones alternativas:

  • Si la aplicación utiliza Log4j y se ejecuta mediante el comando java -d, puede establecer el parámetro de propiedad del sistema en true: java -Dlog4j2.formatMsgNoLookups=true.
  • Otra opción es extraer la configuración actual de las variables de entorno (LOG4J_FORMAT_MSG_NO_LOOKUPS=true). En el segundo caso, no es necesario establecer ninguna opción adicional, se extraerá automáticamente del entorno.

Aquí se describen algunas soluciones más complicadas.

Conclusiones

La mayoría de las vulnerabilidades se producen en versiones antiguas de lenguajes, bibliotecas y frameworks, por lo que hay que tener cuidado de actualizarlos regularmente. Para las grandes empresas es un lujo inasequible, pero las aplicaciones seguras y libres de vulnerabilidades requieren actualizaciones periódicas.

Una buena idea realizar periódicamente (cada tres o seis meses) auditorías de seguridad en los sistemas que están en producción. Es igualmente importante seguir las recomendaciones contenidas en los informes de seguridad. Esto ayuda a identificar los problemas comunes y a tratar los cambios urgentes (aunque con algunas limitaciones).

Sobre el Autor:

Hey hola! Yo soy Alex Walton y tengo el placer de compartir conocimientos hacía ti sobre el tema de Programación en Java, desde cero, Online y Gratis.

Deja una Respuesta

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.