Webinar sobre Log4Shell: lo que debes saber

Sin importar cuál sea tu función en tecnología, probablemente ya hayas oído hablar de la vulnerabilidad Log4Shell, que afecta a una gran cantidad de aplicaciones Java, o ya te hayas enfrentado a ella. Para compartir la información más reciente sobre esta vulnerabilidad crítica de día cero, hace poco organizamos un webinar para poner a todos al día.

En nuestro webinar Log4Shell: lo que debes saber, Steve Kinman (CISO de campo), Simon Maple (CTO de campo) y Kirill Efimov (líder del equipo de investigación de seguridad) de Snyk hablaron sobre la vulnerabilidad Log4Shell y cómo mitigarla. Aquí tienes un breve resumen de lo que aprenderás en la conversación.

¿Qué es Log4j?

Log4j es una popular biblioteca de código abierto para Java que se usa ampliamente en aplicaciones Java para registrar eventos. Este framework de registro usa el servicio JNDI que ofrece el Java Development Kit (JDK) para obtener información adicional de la aplicación. Así, los datos registrados se enriquecen con más metadatos y los registros resultan más útiles para los desarrolladores. Muchos frameworks populares para aplicaciones Java usan Log4j de forma predeterminada, como Apache Struts 2, Apache Solr y Apache Druid.

El registro de eventos es muy importante. Las aplicaciones Java registran eventos constantemente, sobre todo en torno a excepciones y errores, para que los desarrolladores puedan entender qué está pasando.

La vulnerabilidad Log4Shell

Log4Shell es el nombre que se le dio a una vulnerabilidad crítica y fácil de explotar en la biblioteca Log4j2. La vulnerabilidad (CVE-2021-44228) obtuvo una puntuación CVSS de 10, la más alta posible.

En Log4j se divulgó una vulnerabilidad de día cero crítica, muy extendida y fácil de explotar. Este vector de ataque existe desde hace cinco o seis años. Como es muy fácil de explotar, se están produciendo muchísimos ataques y la situación cambia constantemente.

Cómo funciona el exploit de Log4Shell

JNDI (Java Naming and Directory Interface) es un servicio de directorio similar a LDAP que permite usar un identificador único para obtener código u objetos Java. Es común que las aplicaciones Java hagan solicitudes a los servicios JNDI para obtener fuentes de datos u otra información.

El framework de registro Log4j usa JNDI para obtener variables y otra información con la que enriquece los datos que registra. El problema es que, al registrar eventos, Log4j puede intentar resolver cadenas peligrosas durante la ejecución, incluidas las URL de un servicio JNDI no autorizado.

Esto significa que la vulnerabilidad Log4Shell podría permitir que un actor malicioso envíe una solicitud desde una aplicación Java a su propio servicio JNDI, explotando el servicio de registro, y que ese servicio responda con un objeto o código malicioso. Este ataque de ejecución remota de código (RCE) puede tener consecuencias de gran alcance.

Los principales riesgos de Log4Shell

En el caso de Log4Shell, el riesgo directo es un ataque de ejecución remota de código. Mediante la inyección de código malicioso, un actor de amenazas puede desplegar malware o ransomware, tomar el control de un servidor o una aplicación, exfiltrar datos, afectar la integridad de los datos o la disponibilidad de la aplicación, o deshabilitar otros servicios de seguridad.

Además del riesgo inmediato de que se explote la vulnerabilidad, las aplicaciones Java vulnerables plantean otros problemas. La vulnerabilidad Log4Shell también puede provocar incumplimientos normativos, fallas en los controles de seguridad en la nube, fallas de seguridad en aplicaciones SaaS de terceros e infracciones de las políticas de cumplimiento.

El mayor riesgo es que tu junta directiva o tu CEO te pregunte: «¿Estamos afectados?». Y si no tienes una buena respuesta, eso es un riesgo.

Cómo identificar la vulnerabilidad Log4Shell

Para los equipos de desarrollo Java, mitigar Log4Shell requiere identificar en qué parte del grafo de dependencias se podría estar usando Log4j. Esto puede ser difícil: descubrimos que el 60,8 % de los clientes de Snyk usa Log4j como dependencia transitiva, es decir, el framework de registro está dentro de otra biblioteca de código abierto que utilizan.

Una de las cosas que hace que esta vulnerabilidad sea aún más preocupante para los equipos de seguridad es no saber si están usando Log4j. Si no sabes con qué se creó realmente tu software, quizá no sepas si estás afectado.

Puedes usar Snyk para analizar tus aplicaciones en busca de vulnerabilidades como Log4Shell, incluso si estos problemas de seguridad están en dependencias transitivas. Así puedes proteger tu cadena de suministro de software frente a riesgos de seguridad como Log4Shell. Snyk también creó el comando snyk log4shell para encontrar la vulnerabilidad en tus archivos JAR no administrados y sombreados.

Cómo mitigar el exploit de Log4Shell

Una vez que hayas identificado la versión de Log4j que usas, asegúrate de que sea, como mínimo, la versión 2.17.1. La recomendación inicial, poco después de descubrirse la vulnerabilidad de día cero, fue actualizar a la versión 2.15.0 para corregir Log4Shell, pero esa versión también tiene otros problemas.

Nota del editor: En el momento de grabar el webinar, la actualización recomendada era a la versión 2.16. Desde entonces, se ha actualizado a la versión 2.17.1. Cada día se descubre más sobre esta vulnerabilidad, por lo que te recomendamos consultar con regularidad nuestra página de recursos sobre la vulnerabilidad Log4Shell para obtener la información más reciente.

Si no puedes actualizar la biblioteca de inmediato, tendrás que mitigar la posibilidad de que se explote Log4Shell. Para obtener una guía completa de corrección, consulta nuestra guía rápida de corrección de Log4Shell, que actualizamos continuamente a medida que evoluciona la situación.

Esta vulnerabilidad seguirá presente durante años, y el hecho de que sea de día cero preocupa a toda la industria. Seguirá reapareciendo porque alguien podría volver a ponerla en uso o porque podría estar en una dependencia que desconoces.