La vulnerabilidad Log4j y su impacto en la seguridad de la cadena de suministro de software
13 de diciembre de 2021
0 minutos de lecturaNota 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 que identificó que la versión 2.17.0 era vulnerable a la ejecución remota de código, registrada como CVE-2021-44832. Recomendamos actualizar a la versión más reciente, que actualmente es la 2.17.1. Lee más aquí.
Nota del editor (18 de diciembre de 2021 a las 6:55 p. m. GMT): La situación de Log4j cambia rápidamente y actualizamos nuestros blogs a medida que hay nueva información disponible. Se recomienda actualizar a la versión 2.17.1 o posterior. Esta versión incluye correcciones de seguridad para dos vulnerabilidades de ejecución remota de código, corregidas en 2.15.0 (CVE-2021-44228) y 2.16.0 (CVE-2021-45046), así como la vulnerabilidad DoS más reciente, corregida en la versión 2.17.1 (CVE-2021-45105). Lee más aquí.
A estas alturas, ya conoces —y probablemente estés trabajando para corregir— la vulnerabilidad conocida como Log4Shell e identificada como CVE-2021-44228. Se trata de la vulnerabilidad que investigadores de seguridad divulgaron el viernes (10 de diciembre de 2021) en el framework de registro Log4j de Apache.
En este artículo, exploraremos algunos datos clave sobre Log4j y las medidas que puedes tomar para protegerte a ti y a tu empresa:
Log4j es una vulnerabilidad crítica que requiere acción urgente
Responder rápidamente a problemas críticos como Log4j es clave para el negocio
Log4j es una vulnerabilidad crítica que requiere acción urgente
No podemos enfatizar lo suficiente la importancia de esta vulnerabilidad de Log4j. Es una vulnerabilidad crítica de seguridad con una puntuación CVSS de 10 (la más alta posible) que permite a los atacantes ejecutar código de forma remota en cualquier entorno vulnerable. Es un asunto grave que requiere una corrección urgente.
Lee las secciones siguientes para saber qué medidas inmediatas debes tomar según las versiones de Log4j que usas actualmente en tus aplicaciones.
Uso Log4j v1, ¿qué debo hacer?
En este caso, el riesgo es mucho menor que el de la vulnerabilidad que afecta a la versión 2.x. Sin embargo, en circunstancias muy específicas, Log4j v1 permite búsquedas, similares a las que hemos visto que afectan a log4j2, que no protegen contra LDAP ni otros endpoints resueltos mediante JNDI. Se sabe que estos vectores de ataque (y posiblemente otros) pueden provocar ataques de ejecución remota de código (RCE). Si usas una versión de Log4j v1 con JMSAppender habilitado, podrías ser vulnerable. Es importante tener en cuenta que JMSAppender está deshabilitado de forma predeterminada, por lo que es poco probable que esté habilitado en la mayoría de las instancias de Log4j v1 usadas en aplicaciones.
Esta es una actualización crítica y reciente que se implementó hace muy poco (13 de diciembre de 2021, alrededor de las 5 p. m. UTC). Snyk la registra con el identificador de vulnerabilidad SNYK-JAVA-LOG4J-2316893.
Por eso, recomendamos que, si es posible, actualices a la versión v2 más reciente de Log4j, que incluye la corrección para la vulnerabilidad reciente. Consulta el documento oficial de Apache sobre la migración desde Log4j v1. Si no puedes actualizar, considera deshabilitar JMSAppender o bloquear cualquier entrada del usuario para que no llegue a su configuración.
Uso Log4j v2, ¿qué debo hacer?
Si usas Log4j versión 2.x, debes actualizar a la versión más reciente de Log4j v2 (actualmente, la 2.16.0), que corrige la vulnerabilidad.
Uso Log4j v1 o v2, pero no puedo actualizar rápidamente. ¿Hay alguna solución temporal inmediata?
Si no puedes actualizar en el futuro inmediato, lee nuestro artículo sobre Log4j, donde explicamos cómo corregir la vulnerabilidad mediante la configuración de propiedades del sistema y parámetros de Java.
Log4j se usa ampliamente y tendrá un enorme impacto
El registro de datos es una práctica común
Al crear aplicaciones, los desarrolladores casi siempre registran datos para obtener información útil para la depuración, el análisis y las auditorías. Además de servir para las tareas cotidianas de desarrollo, los registros también son una exigencia de muchos equipos de seguridad, ya que proporcionan pistas de auditoría que pueden usarse para rastrear y correlacionar posibles actividades sospechosas.
El registro de datos es una práctica de desarrollo esencial
El hecho de que el registro de datos sea tan generalizado y de que la vulnerabilidad de Log4j pueda activarse al registrar entradas del usuario aumenta considerablemente la gravedad del ataque y amplía los posibles vectores de ataque. Por ejemplo, en redes sociales se ha observado públicamente que los usuarios empezaron a usar cargas de explotación de Log4j como direcciones de correo electrónico y nombres de usuario en formularios web.
Aunque no conoceremos el impacto total de la vulnerabilidad de Log4j por un tiempo, desde su publicación ya se han registrado informes de cientos de intentos de explotarla en entornos reales, tanto por parte de atacantes que parecen actuar de forma oportunista como de botnets más sofisticadas.
La biblioteca de código abierto Log4j se usa ampliamente
Como puedes imaginar por la popularidad de esta vulnerabilidad, Log4j se usa ampliamente en proveedores, proyectos de código abierto, frameworks y proyectos de fundaciones importantes.
Además de los millones de aplicaciones Java que usan Log4j, muchos proyectos propios de Apache Software Foundation también utilizan Log4j, como Apache Solr, Apache Struts2, Apache Kafka, Apache Druid, Apache Flink, Apache Swift y otros.
También se usa ampliamente en muchos otros proyectos populares, como Redis, Elasticsearch, Spring Framework, Netty y más.
Incluso se descubrió que la herramienta de ingeniería inversa de la Agencia de Seguridad Nacional (NSA), Ghidra, que se publicó como proyecto de código abierto, era vulnerable a este problema de seguridad de Log4j.
Los proveedores en general también se han visto muy afectados por esta vulnerabilidad. Entre ellos se encuentran los propios servicios de AWS, como AWS CloudHSM y Amazon OpenSearch, y posiblemente otros productos de servicios. También afecta a productos de RedHat, como Red Hat JBoss Fuse 7, Red Hat CodeReady Studio 12, Red Hat OpenShift Logging y más. Como puedes imaginar, muchos otros proveedores, como VMware, Cisco y otros, también se han visto muy afectados.
Descubrimos que la base de usuarios de Snyk también se ha visto considerablemente afectada. Cerca de un tercio de los clientes de Snyk se ven afectados por la vulnerabilidad de Log4j, lo que representa decenas de miles de vulnerabilidades que detectamos en los proyectos importados o supervisados por Snyk.
La crisis de código abierto de terceros en torno a la biblioteca Java Log4j refuerza aún más la necesidad de llevar un seguimiento de la lista de materiales de software (SBOM) en toda la organización e integrar una herramienta de análisis de composición de software que permita a los equipos de desarrollo y seguridad responder rápidamente.
Log4j tiene un impacto considerable en la seguridad de la cadena de suministro y será difícil de corregir
Al aprovechar los datos de los proyectos importados, supervisados y analizados por Snyk, pudimos obtener información detallada sobre los patrones de uso de la biblioteca Log4j en los proyectos.
Hasta la fecha, descubrimos que el 60 % de los proyectos Java que supervisamos en Snyk y que usan la biblioteca Log4j la utilizan como dependencia indirecta. Las dependencias indirectas son aquellas que un proyecto usa de manera indirecta (es decir, una de las dependencias de tu proyecto usa Log4j, lo que te hace vulnerable aunque no uses Log4j directamente). Esto significa que una búsqueda sencilla para determinar si usas una versión vulnerable de Log4j no necesariamente encontrará todas las apariciones de la biblioteca en tus proyectos. Necesitarás una herramienta de análisis de composición de software (SCA), como Snyk, que pueda recorrer un grafo de dependencias profundamente anidado y correlacionar versiones con una base de datos de vulnerabilidades para determinar los riesgos de seguridad de la cadena de suministro.
De hecho, en el informe State of Open Source Security de 2020 de Snyk, descubrimos (¡y confirmamos!) que la mayoría de las vulnerabilidades se originan en dependencias indirectas en los ecosistemas de Java, Ruby y JavaScript:
Esta es una de las muchas razones por las que, como desarrollador, debes usar herramientas de seguridad como Snyk para identificar vulnerabilidades en tus proyectos (como log4j): no basta con saber si usas una dependencia vulnerable; también debes saber de forma recursiva si tus dependencias son vulnerables.
Todo esto significa que corregir la nueva vulnerabilidad de Log4j será complicado, ya que habrá que actualizar muchas bibliotecas de código abierto para solucionar el problema y evitar que los proyectos que dependen de ellas sigan siendo vulnerables. Y eso llevará tiempo.
La vulnerabilidad de Log4j representa una amenaza global e inminente. Al igual que la pandemia de COVID-19 nos afectó y exigió que las organizaciones de salud y las empresas de investigación médica de todo el mundo colaboraran y trabajaran juntas, vemos que una colaboración similar está en marcha y es fundamental para abordar el riesgo general que supone la vulnerabilidad de Log4j y ofrecer una solución integral para la comunidad.
Es fundamental priorizar la corrección de seguridad de Log4j entre las tareas pendientes de seguridad ya acumuladas
Para muchos, la vulnerabilidad de Log4j es otro problema de seguridad urgente que debe atenderse entre una lista ya acumulada de deuda de seguridad.
Con el aumento de las vulnerabilidades de seguridad en los ecosistemas de lenguajes, las configuraciones incorrectas, los componentes de código abierto de los sistemas operativos y otros problemas de seguridad de las aplicaciones, ¿cómo saben los equipos de seguridad por dónde empezar? ¿Cuál es la vulnerabilidad más importante y urgente que deben atender si ya tienen poco personal?
La priorización no solo es clave para que los equipos de seguridad trabajen de manera eficaz, sino que también es una herramienta importante para reducir el riesgo general del negocio. Para ser eficaces, los equipos de seguridad necesitan comprender el riesgo de las vulnerabilidades, no solo en un proyecto, sino con una visión integral de toda la organización.
Para que los desarrolladores y los equipos de seguridad puedan responder rápidamente y evaluar los riesgos desde una perspectiva organizacional general, incorporamos los puntajes de prioridad a Snyk.
Mientras que las prácticas de seguridad tradicionales se han basado en el factor CVSS de una vulnerabilidad, que en gran medida carecía de contexto, el puntaje de prioridad de Snyk considera información contextual sobre la vulnerabilidad, como el nivel de madurez de la explotación, las tendencias en redes sociales, la gravedad asignada por CVE, si hay una corrección disponible y si se divulgó recientemente.
Nuestro puntaje de prioridad va de 0, el valor más bajo, a 1000, el más alto posible, y representa las vulnerabilidades de seguridad más urgentes que una empresa debe atender. La vulnerabilidad de seguridad de Log4j es el ejemplo perfecto de cómo nuestro puntaje de prioridad permite a los equipos priorizar correctamente la corrección. A continuación se muestra una imagen del panel de Snyk que muestra cómo, en algunos casos, la CVE específica de Log4j obtuvo el puntaje máximo posible de 1000 entre las miles de vulnerabilidades que una organización debe gestionar en cientos de proyectos de distintos ecosistemas y lenguajes:
Guy Podjarny (fundador y presidente de Snyk) desarrolló aún más este concepto y explicó la diferencia entre lo importante y lo urgente, y cómo se aplica a la priorización de la seguridad. De hecho, ampliamos este concepto al desarrollo de aplicaciones nativas de la nube para que los equipos tengan más información gracias a la priorización contextual en sus implementaciones de Kubernetes.
Responder rápidamente a problemas críticos como Log4j es clave para el negocio
La vulnerabilidad Log4j obligó a los equipos de respuesta a incidentes a identificar las causas raíz y comenzar a analizar (y corregir) su inventario de aplicaciones Java implementadas.
No cabe duda de que los equipos de respuesta a incidentes debían responder rápidamente a vulnerabilidades críticas como Log4j, pero esta carga también recae en los desarrolladores y los equipos de seguridad de aplicaciones, responsables de la seguridad de sus aplicaciones.
El ADN de Snyk se centra en una seguridad que prioriza a los desarrolladores y es fácil de usar para ellos. Ayudar a los desarrolladores y equipos de seguridad a encontrar y corregir vulnerabilidades de seguridad con la mayor rapidez y facilidad posible no es solo uno de nuestros principales objetivos: es lo que nos define.
En medio del caos de seguridad que generó la vulnerabilidad Log4j, nos alegró y nos sentimos honrados de ver que otras personas tuvieron éxito con Snyk al corregir la vulnerabilidad:
No se trata solo de corregir vulnerabilidades de forma proactiva y automática para los desarrolladores, sino también de poder tener en cuenta los problemas de seguridad en todos tus repositorios de código fuente, incluidos esos proyectos heredados antiguos y olvidados:
Próximos pasos para corregir Log4Shell
Hay luz al final de este túnel: ¡solo tienes que dar algunos pasos para acercarte!
Snyk puede ayudarte de distintas maneras: desde comprender el nivel de exposición de tus diferentes aplicaciones y hacer pruebas desde las primeras etapas y durante todo el SDLC, hasta activar pull requests de corrección automatizados para corregir rápidamente las vulnerabilidades identificadas.
Te recomendamos leer cómo encontrar y corregir Log4Shell rápidamente con Snyk para obtener consejos prácticos sobre cómo corregir con rapidez las vulnerabilidades relacionadas con Log4j en tus proyectos. Si aún no lo hiciste, regístrate en Snyk: ¡es gratis!
Como los acontecimientos siguen desarrollándose, siempre es buena idea mantenerse al tanto de las noticias. Seguiremos publicando actualizaciones en nuestro newsletter y en este blog, ¡así que mantente al tanto!
Y para terminar con una nota más ligera, al menos esta vulnerabilidad crítica nos ha sacado algunas risas conocidas. Nos viene a la mente la historieta de XKCD “Little Bobby Tables” (con algunas modificaciones nuevas, tal como se compartió originalmente en redes sociales):
