[12/12/2021] Los atacantes están explotando activamente una vulnerabilidad crítica en Apache Log4j, una biblioteca de registro que se utiliza potencialmente en millones de aplicaciones basadas en Java, incluidas las basadas en la web. Las organizaciones deberían revisar inmediatamente si sus aplicaciones, especialmente las de acceso público, utilizan la biblioteca y deberían implementar mitigaciones lo antes posible.
El 9 de diciembre se publicó una prueba de concepto de la vulnerabilidad, ahora rastreada como CVE-2021-44228, mientras los desarrolladores de Apache Log4j seguían trabajando en la publicación de una versión parcheada. Los ataques comenzaron poco después, lo que convirtió la falla en un problema de día cero (sin parche) en el momento de su explotación. Desde entonces, Apache ha publicado la versión 2.15.0 de Log4j, que incluye una corrección.
El exploit Log4Shell
La vulnerabilidad puede conducir a la ejecución remota de código en los servidores subyacentes que ejecutan las aplicaciones vulnerables y la explotación del problema no requiere autenticación. La falla está calificada con la máxima gravedad de 10 en la escala CVSS.
"Un atacante que pueda controlar los mensajes de registro o los parámetros de los mensajes de registro, puede ejecutar código arbitrario cargado desde los servidores LDAP cuando la sustitución de la búsqueda de mensajes está habilitada", dijeron los desarrolladores en su aviso. "A partir de log4j 2.15.0, este comportamiento se ha deshabilitado por defecto".
En general, esto significa que, si un usuario puede generar una solicitud que incluya una entrada específicamente diseñada, y esa solicitud se registra a través de Log4j, la vulnerabilidad podría ser explotada. Dado que la mayoría de las aplicaciones están diseñadas para aceptar entradas del usuario de diversas maneras, la explotación es trivial.
Los desarrolladores atribuyen a Chen Zhaojun, del equipo de seguridad en la nube de Alibaba, la notificación original del problema en noviembre. Según los comentarios de los desarrolladores en el rastreador de errores, la publicación de una versión parcheada podría haberse retrasado porque los investigadores encontraron una forma de eludir la solución propuesta inicialmente, por lo que requirió trabajo y revisión adicionales.
Impacto duradero
La vulnerabilidad no solo afecta a las aplicaciones y servicios basados en Java que utilizan directamente la biblioteca, sino también a muchos otros componentes y marcos de desarrollo populares de Java que dependen de ella, como, según se informa, Apache Struts2, Apache Solr, Apache Druid, Apache Flink, ElasticSearch, Apache Kafka y muchos otros.
La comunidad todavía está trabajando para evaluar la superficie de ataque, pero es probable que sea enorme debido al complejo ecosistema de dependencias. Algunos de los componentes afectados son extremadamente populares y son utilizados por millones de aplicaciones y servicios empresariales.
Se ha informado de que los servicios de Apple, Amazon, Twitter, Cloudflare, Steam, Tencent y Baidu, entre otros, son vulnerables. Cloudflare creó reglas de detección en su firewall de aplicaciones web para bloquear los intentos de explotación y publicó un aviso. El investigador Florian Roth también publicó las reglas de detección de YARA.
"Espero que haya una larga cola aquí", señaló Chris Wysopal, CTO de la firma de seguridad de aplicaciones Veracode, en un seminario web sobre la falla. "Puede que haya aplicaciones de las que tenga buena visibilidad y que encuentre con bastante rapidez, pero es un reto encontrar todas sus aplicaciones Java".
"El otro reto es, por supuesto, las aplicaciones de los proveedores que están escritas en Java. Ya vimos esto con Heartbleed hace muchos años -que en cierto modo puso en marcha todo el riesgo de terceros- que muchas aplicaciones de proveedores estaban escritas con la biblioteca SSL abierta y había que esperar a que el proveedor la parchease. Y lo mismo podría ocurrir aquí. Muchos dispositivos y muchos paquetes de software utilizan Java, así que me imagino que la gente preguntará a sus proveedores cuándo van a ser parcheados".
Es probable que las empresas estén ocupadas durante meses persiguiendo y parcheando las aplicaciones vulnerables a este problema, lo que pone de manifiesto la importancia de que los proveedores implementen listas de materiales de software. Por desgracia, no parchear a tiempo las fallas explotadas de forma activa puede dar lugar a importantes infracciones. La gran brecha del 2017 de Equifax fue el resultado de no parchear una vulnerabilidad Struts2 activamente explotada durante dos meses en una aplicación de cara al público.
Los atacantes ya están explorando Internet en busca de aplicaciones y servicios que puedan ser vulnerables a CVE-2021-44228, y el servicio de monitorización de tráfico GreyNoise informa de que el número de intentos de explotación está aumentando.
Mitigaciones
Hay algunos casos en los que los exploits actuales podrían no funcionar, aunque Log4j sea vulnerable; por ejemplo, si el sistema anfitrión utiliza una versión de Java superior a la 6u212, 7u202, 8u192 o 11.0.2. Esto se debe a que estas versiones añadieron una protección mejorada para la carga de clases remotas JNDI (Java Naming and Directory Interface), que es necesaria para que el exploit funcione.
Además, en las versiones de log4j superiores a la 2.10, el problema puede mitigarse estableciendo la propiedad del sistema formatMsgNoLookups en true, estableciendo el parámetro de la JVM -Dlog4j2.formatMsgNoLookups=true o eliminando la clase JndiLookup del classpath.
Sin embargo, la mejor solución es actualizar a log4j 2.15.0 porque alguien podría encontrar una ruta alternativa para llegar al código vulnerable que no dependa de JNDI. Si eso sucede, las mitigaciones propuestas que dependen de la limitación de JNDI serían ineficaces.
Basado en el artículo de Lucian Constantin (CSO) y editado por CIO Perú