Log4Shell

Log4Shell ( CVE-2021-44228 ) es una vulnerabilidad reportada en noviembre de 2021 en Log4j , un popular marco de registro de Java , que implica la ejecución de código arbitrario y se explota como una vulnerabilidad de día cero . ^{[ 2 ] [ 3 ]} La vulnerabilidad había existido sin ser detectada 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. ^{[ 4 ]}

Antes de que se publicara 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 se utilizó inicialmente para rastrear el problema en línea. ^{[ 2 ] [ 1 ] [ 5 ] [ 6 ] [ 7 ]} Apache le otorgó a Log4Shell una calificación de gravedad CVSS de 10, la puntuación más alta disponible. ^{[ 8 ]} El exploit era sencillo de ejecutar y se estima que tenía el potencial de afectar a cientos de millones de dispositivos. ^{[ 7 ] [ 9 ]}

La vulnerabilidad aprovecha Log4j permitiendo solicitudes a servidores LDAP y JNDI arbitrarios, ^{[ 2 ] [ 10 ] [ 11 ]} permitiendo a los atacantes ejecutar código Java arbitrario en un servidor u otra computadora, o filtrar información confidencial. ^{[ 6 ]} El equipo de seguridad de Apache ha publicado una lista de proyectos de software afectados . ^{[ 12 ]} Los servicios comerciales afectados incluyen Amazon Web Services , ^{[ 13 ]} Cloudflare , iCloud , ^{[ 14 ]} Minecraft: Java Edition , ^{[ 15 ]} Steam , Tencent QQ y muchos otros. ^{[ 10 ] [ 16 ] [ 17 ]} Según Wiz y EY , la vulnerabilidad afectó al 93% de los entornos de nube empresariales. ^{[ 18 ]}

La revelación de la vulnerabilidad provocó fuertes reacciones entre los expertos en ciberseguridad. La empresa de ciberseguridad Tenable afirmó que la explotación era "la mayor y más crítica vulnerabilidad jamás vista" ^{[ 19 ],} Ars Technica la calificó como "posiblemente la vulnerabilidad más grave jamás vista" ^{[ 20 ]} y The Washington Post señaló que las descripciones de los profesionales de la seguridad "rozan lo apocalíptico" ^{[ 9 ] .}

Log4j es un marco de registro de código abierto que permite a los desarrolladores de software registrar datos dentro de sus aplicaciones, e incluso incluir la entrada del usuario. ^{[ 21 ]} Se utiliza ampliamente en aplicaciones Java, especialmente en software empresarial. ^{[ 6 ]} Escrito originalmente en 2001 por Ceki Gülcü, ahora forma parte de Apache Logging Services, un proyecto de la Apache Software Foundation . ^{[ 22 ]} Tom Kellermann, miembro de la Comisión de Ciberseguridad del Presidente Obama , describió Apache como "uno de los pilares fundamentales de un puente que facilita la conexión entre los mundos de las aplicaciones y los entornos informáticos". ^{[ 23 ]}

La Interfaz de Nombres y Directorios 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 utilizar varias interfaces de directorio, cada una de las cuales proporciona un esquema diferente para la búsqueda de archivos. Entre estas interfaces se encuentra el Protocolo Ligero de Acceso a Directorios (LDAP), un protocolo no específico de Java ^{[ 24 ]} que recupera los datos del objeto como una URL desde un servidor apropiado, ya sea local o en cualquier lugar de Internet. ^{[ 25 ]}

En la configuración predeterminada, al registrar una cadena, Log4j 2 realiza una sustitución de cadena en expresiones de la forma ${prefix:name}. ^{[ 25 ]} Por ejemplo, Text: ${java:version}podría convertirse en Text: Java version 1.7.0_67. ^{[ 26 ]} Entre las expresiones reconocidas está ${jndi:<lookup>}; al especificar que la búsqueda sea a través de LDAP, se puede consultar una URL arbitraria y cargarla como datos de 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. ^{[ 25 ]} 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 se sustituirán y se enviarán al servidor del atacante. ^{[ 27 ] [ 28 ]} 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). ^{[ 29 ] [ 30 ]}

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 medidas de mitigación incluyeron el bloqueo de cualquier solicitud que contuviera contenido potencialmente malicioso, como ${jndi. ^{[ 31 ]} 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úscula en la letra j. ^{[ 32 ]} Incluso si una entrada, como un nombre, no se registra inmediatamente, puede registrarse posteriormente durante el procesamiento interno y ejecutarse su contenido. ^{[ 25 ]}

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. ^{[ 33 ] [ 34 ] [ 35 ]} La corrección incluyó 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. ^{[ 36 ] [ 37 ]} 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 , registrada como CVE-2021-44832 y corregida en la versión 2.17.1. ^{[ 38 ] [ 39 ]} Para versiones anteriores, org.apache.logging.log4j.core.lookup.JndiLookupes necesario eliminar la clase del classpath para mitigar ambas vulnerabilidades. ^{[ 8 ] [ 36 ]} Una solución recomendada inicialmente para versiones anteriores fue establecer la propiedad del sistema log4j2.formatMsgNoLookupsen true, pero este cambio no impide la explotación de CVE-2021-45046 y posteriormente se descubrió que no deshabilitaba las búsquedas de mensajes en ciertos casos. ^{[ 8 ] [ 36 ]}

Las versiones más recientes del Entorno de Ejecución de Java (JRE) también mitigan esta vulnerabilidad al bloquear la carga de código remoto de forma predeterminada, aunque aún existen otros vectores de ataque en ciertas aplicaciones. ^{[ 2 ] [ 27 ] [ 40 ] [ 41 ]} Se han publicado varios métodos y herramientas que ayudan a detectar versiones vulnerables de Log4j utilizadas en paquetes Java compilados. ^{[ 42 ]}

Cuando no ha sido posible aplicar versiones actualizadas, debido a una variedad de limitaciones como la falta de recursos o soluciones administradas por terceros, filtrar el tráfico de red saliente de implementaciones vulnerables ha sido el recurso principal para muchos. ^{[ 43 ]} El enfoque es recomendado por NCC Group ^{[ 44 ]} y el Centro Nacional de Ciberseguridad (Reino Unido) , ^{[ 45 ]} y es un ejemplo de una medida de defensa en profundidad . La efectividad de dicho filtrado se evidencia ^{[ 46 ]} mediante experimentos de laboratorio realizados con cortafuegos capaces de interceptar el tráfico de salida con varias versiones total o parcialmente vulnerables de la propia biblioteca y el JRE .

La vulnerabilidad permite a los hackers obtener el control de dispositivos vulnerables que utilizan Java. ^{[ 7 ]} Algunos hackers emplean la vulnerabilidad para usar 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 . ^{[ 7 ] [ 9 ] [ 47 ]} En los días posteriores a la divulgación de la vulnerabilidad, Check Point observó millones de ataques iniciados por hackers, y algunos investigadores observaron una tasa de más de cien ataques por minuto que finalmente resultaron en intentos de ataque a más del 40 % de las redes empresariales a nivel internacional. ^{[ 7 ] [ 23 ]}

Según Matthew Prince , CEO de Cloudflare , la evidencia de explotación o escaneo del exploit se remonta al 1 de diciembre, nueve días antes de que se divulgara públicamente. ^{[ 48 ]} Según la empresa de ciberseguridad GreyNoise, varias direcciones IP estaban rastreando sitios web para verificar servidores que tuvieran la vulnerabilidad. ^{[ 49 ]} Varias botnets comenzaron a escanear la vulnerabilidad, incluyendo la botnet Muhstik el 10 de diciembre, así como Mirai y Tsunami. ^{[ 7 ] [ 48 ] [ 50 ]} Se observó que el grupo de ransomware Conti estaba utilizando la vulnerabilidad el 17 de diciembre. ^{[ 9 ]}

Según Check Point, algunos grupos patrocinados por el Estado en China e Irán también utilizaron la vulnerabilidad, pero se desconoce si Israel, Rusia o Estados Unidos la utilizaron antes de que se revelara. ^{[ 9 ] [ 19 ]} Check Point afirmó que el 15 de diciembre de 2021, hackers respaldados por Irán intentaron infiltrarse en las redes de empresas e instituciones gubernamentales israelíes. ^{[ 9 ]}

A fecha de 14 de diciembre de 2021  ,Casi la mitad de todas las redes corporativas a nivel mundial fueron sometidas a sondeos activos, y se produjeron más de 60 variantes del exploit en 24 horas. ^{[ 65 ]} Check Point Software Technologies describió la situación como una "verdadera ciberpandemia" y caracterizó el potencial de daño como "incalculable". ^{[ 66 ]} Varios avisos iniciales exageraron la cantidad de paquetes vulnerables, lo que generó falsos positivos. En particular, el paquete "log4j-api" fue marcado como vulnerable, mientras que, en realidad, una investigación posterior demostró que solo el paquete principal "log4j-core" era vulnerable. Esto fue confirmado tanto en el hilo original del problema ^{[ 67 ]} como por investigadores de seguridad externos. ^{[ 68 ]}

La revista tecnológica Wired escribió que, a pesar del revuelo previo en torno a múltiples vulnerabilidades, "la vulnerabilidad Log4j  ... cumple con las expectativas por diversas razones". ^{[ 19 ]} La revista explica que la omnipresencia de Log4j, la dificultad de detección de la vulnerabilidad por parte de los posibles objetivos y la facilidad para transmitir código a las víctimas crearon una "combinación de gravedad, simplicidad y omnipresencia que tiene a la comunidad de seguridad muy preocupada". ^{[ 19 ]} Wired también describió las etapas en las que los hackers utilizan Log4Shell: primero, los grupos de criptominería utilizan la vulnerabilidad; luego, los intermediarios de datos venden una "puerta de entrada" a los ciberdelincuentes, quienes finalmente participan en ataques de ransomware, espionaje y destrucción de datos. ^{[ 19 ]}

Amit Yoran , director ejecutivo de Tenable y director fundador del Equipo de Preparación para Emergencias Informáticas de los Estados Unidos , declaró: "[Log4Shell] es, con diferencia, la vulnerabilidad más grande y crítica que jamás haya existido", señalando que los ataques sofisticados comenzaron poco después del fallo, y añadió: "También estamos viendo que ya se está utilizando 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 intentar cobrar un rescate, un comportamiento bastante inusual". ^{[ 19 ]} Sean Gallagher, investigador sénior de amenazas de Sophos , dijo: "Sinceramente, la mayor amenaza aquí es que la gente ya ha obtenido acceso y simplemente lo está aprovechando, e incluso si se soluciona el problema, alguien ya está en la red  ... Va a estar presente mientras exista Internet". ^{[ 19 ]}

Según un informe de Bloomberg News , parte del enojo se dirigió a los desarrolladores de Apache por no haber corregido la vulnerabilidad después de que se hicieran advertencias sobre exploits de amplias clases de software, incluido Log4j, en una conferencia de ciberseguridad de 2016. ^{[ 69 ]}

• Sitio web de Log4j
• Descripción general de Log4Shell en GitHub por parte de NCSC-NL
• Página de vulnerabilidades y exposiciones comunes
• Página de la Base de Datos Nacional de Vulnerabilidades
• Proyectos afectados por cve-2021-44228, por el equipo de seguridad de Apache.