Incidente de seguridad con la librería de logging log4j de Java.
Se ha detectado un problema de seguridad grave en una librería de logging de Java ampliamente usada por proyectos de código abierto de extensa adopción como Jenkins, ElasticSearch o Apache Solr. Esta vulnerabilidad, con CVE CVE-2021-44228, implica un riesgo de seguridad de 9 en la escala de alcance y afectación del cálculo de CVSS, lo cual la convierte en una vulnerabilidad crítica. Esta vulnerabilidad permite al atacante, de forma trivial, ejecutar código remoto en una aplicación que utilice esta librería para la generación de logs.
Existe la posibilidad de desactivar la función que permite esta vulnerabilidad (JNDI) con variables de entorno en algunas versiones de la librería, pero la solución permanente a este problema consiste en actualizar a la versión de log4j 2.17.0.
Alcance
Esta vulnerabilidad tiene un alcance muy extendido a través de muchas aplicaciones utilizadas el stack técnico de muchas empresas modernas. Entre ellas podemos contar los productos de Elastic. Si bien varias de sus productos hacen uso de versiones vulnerables de Log4j, de acuerdo al desarrollador algunos de sus ellos, como por ejemplo Elasticsearch, no son vulnerables debido al uso que hacen de Java Security Manager.
La lista completa, en proceso de actualización, puede verse en el github de CISA. Esta lista se irá actualizando según van apareciendo nuevas afectaciones.
Mitigación y threat hunting
Es posible mitigar esta vulnerabilidad desactivando la función de JNDI que hace posible esta vulnerabilidad desactivándola con una variable de entorno para las aplicaciones que la utilizan, o eliminando la librería del archivo de Java que la contiene directamente para que sea imposible de explotar. Estos son parches puntuales, y la solución definitiva en el roadmap debería consistir en actualizar la versión de la librería utilizada a log4j 2.17.0.
Se pueden investigar indicadores de compromiso y comprobar la posible existencia de esta librería sin parchear en el sistema con una herramienta de escaneo que se ha desarrollado que recoge indicadores de compromiso frecuentes, y como último paso escanea la existencia de esta librería de log4j en el sistema donde se lance. También pueden ser de utilidad escaners de rootkits como rkhunder o chkrootkit para intentar determinar si el sistema ha sido comprometido.
En cualquier caso, si hubiera sospecha de que el sistema ha sido comprometido, y dado que una vez un atacante tiene acceso al sistema no es posible comprobar con total seguridad si ha dejado un backdoor, desde Geko Cloud aconsejamos destruir y recrear la máquina afectada.
Actualización 1: 2021-12-14
Se ha descubierto que el fix publicado por Apache en log4j 2.16.0 era incompleto en algunas configuraciones no estándar, y que aún permitía explotar la vulnerabilidad de ejecución de código remota en la librería. Se recomienda actualizar a la versión 2.17.0 a la mayor brevedad posible para evitar esta vulnerabilidad.
