Existe una vulnerabilidad (CVE-2021-44228) en ciertas versiones de la biblioteca Log4j. Un ciberdelincuente malintencionado podría aprovechar esta vulnerabilidad para ejecutar código arbitrario.

Los ciberdelincuentes maliciosos están escaneando activamente las redes para explotar Log4Shell, CVE-2021-45046 y CVE-2021-45105 en sistemas vulnerables

Se ha tomado como referencia la guía de CISA, una guía que detalla los pasos que los proveedores y las organizaciones con TI y / o activos en la nube deben tomar para reducir el riesgo que representan estas vulnerabilidades.

Estos pasos incluyen:

1. Identificar los activos afectados por Log4Shell y otras vulnerabilidades relacionadas con Log4j,
2. Actualizar los activos de Log4j y los productos afectados a la última versión tan pronto como los parches estén disponibles y permanezcan alertas a las actualizaciones de software del proveedor, y
3. Iniciar procedimientos de búsqueda y respuesta a incidentes para detectar una posible explotación de Log4Shell.

Log4Shell

Log4Shell , publicada el 10 de diciembre de 2021, es una vulnerabilidad de ejecución remota de código (RCE) que afecta a la librería Log4j de Apache, versiones 2.0-beta9 a 2.14.1.

La vulnerabilidad existe en la acción que realiza la Interfaz de directorio y nombres de Java (JNDI) para resolver las variables. Las versiones afectadas de Log4j contienen funciones JNDI, como la sustitución de búsqueda de mensajes, que no protegen contra el Protocolo ligero de acceso a directorios (LDAP) controlado por adversarios, el Sistema de nombres de dominio (DNS) y otros puntos finales relacionados con JNDI.

Un ciberdelincuente puede explotar Log4Shell enviando una solicitud especialmente diseñada a un sistema vulnerable que hace que ese sistema ejecute código arbitrario. La solicitud permite al atacante tomar el control total del sistema. El ciberdelincuente puede entonces robar información, lanzar ransomware o realizar otra actividad maliciosa.

CVE ‑ 2021‑45046

Publicado el 13 de diciembre de 2021, permite que un atacante remoto cause RCE, una condición de denegación de servicio (DoS) u otros efectos en ciertas configuraciones no predeterminadas. Esta vulnerabilidad afecta a todas las versiones de Log4j desde 2.0-beta9 hasta 2.12.1 y 2.13.0 hasta 2.15.0. En respuesta, Apache lanzó Log4j versión 2.16.0 (Java 8).

CVE ‑ 2021‑45105

Publicado el 16 de diciembre de 2021, permite que un atacante remoto cause una condición de DoS u otros efectos en ciertas configuraciones no predeterminadas. Según Apache, cuando la configuración de registro utiliza un diseño de patrón no predeterminado con una búsqueda de contexto (por ejemplo, $$ {ctx: loginId}), los atacantes con control sobre los datos de entrada del mapa de contexto de subprocesos (MDC) pueden crear datos de entrada maliciosos que contiene una búsqueda recursiva, lo que da como resultado un StackOverflowError que terminará el proceso. En respuesta, Apache lanzó Log4j versión 2.17.0 (Java 8).

Impacto

Log4Shell y CVE-2021-45046, calificados como vulnerabilidades críticas por Apache, son graves porque Java se usa ampliamente en las plataformas de TI y OT, son fáciles de explotar y la aplicación de mitigaciones requiere muchos recursos. Log4Shell es especialmente crítico porque permite a los actores malintencionados ejecutar código de forma remota en redes vulnerables y tomar el control total de los sistemas.

Según los informes públicos, la explotación de Log4Shell comenzó el 1 de diciembre de 2021 o alrededor de esa fecha, y una vulnerabilidad de prueba de concepto está disponible públicamente para esta vulnerabilidad.

El FBI ha observado intentos de explotación y escaneo generalizado de la vulnerabilidad Log4j para obtener acceso a las redes para implementar malware de criptominería y botnet. El FBI evalúa que esta vulnerabilidad puede ser explotada por atacantes avanzados con una intensión de delinquir buscan adoptar técnicas de ofuscación cada vez más sofisticadas.

Se evalúa que es probable que la explotación de estas vulnerabilidades, especialmente Log4Shell, aumente y continúe durante un tiempo. Dada la gravedad de las vulnerabilidades y el probable aumento de la explotación, se está exigiendo encarecidamente a todas las organizaciones a aplicar las recomendaciones de la sección Mitigaciones para identificar, mitigar y actualizar los activos afectados.

Recomendaciones

Organizaciones

1. Identifique los activos vulnerables en su entorno.

Saber dónde existen Log4j y otros productos afectados en su entorno es clave para proteger sus redes.

A. Revise el inventario de todos los activos que utilizan la biblioteca de Java Log4j . 

Según los informes públicos, los usuarios están parcheando y mitigando los activos que comprometen para mantener el control de los activos. 

1. Suponga que todas las versiones de Java y Log4j son vulnerables e inclúyalas en el inventario.
2. Asegúrese de que el inventario incluya todos los activos, incluidos los activos de la nube, independientemente de la función, el sistema operativo o la marca. Asegúrese de que el inventario incluya la siguiente información sobre cada activo:
   
   
   1. Versiones de software.
   2. Cuando se actualizó por última vez y quién lo hizo.
   3. Cuentas de usuario en el activo con su nivel de privilegio
   4. Ubicación del activo en la topología de su institución.

B. Identifique los activos inventariados que probablemente sean vulnerables.

1. Utilice  CVE-2021-44228_scanner de CERT / CC para identificar los activos vulnerables a Log4Shell.

Los recursos adicionales para detectar instancias vulnerables de Log4j se identifican a continuación. 

Nota: debido a la urgencia de compartir esta información, aún no han validado este contenido.

• Para identificar las aplicaciones de servidor que pueden verse afectadas por Log4Shell y CVE-2021-45046, consulte TrendMicro: Log4J Vulnerability Tester .
• Para obtener una lista de hashes que ayuden a determinar si una aplicación Java está ejecutando una versión vulnerable de Log4j, consulte:
  
  
  • Página de GitHub de Rob Fuller: CVE-2021-44228-Log4Shell-Hashes , y
  • La página de GitHub del Grupo NCC: Cyber-Defense / Intelligence / CVE-2021-44228 / .
• Para que PowerShell detecte instancias vulnerables, consulte:
  
  
  • Página de GitHub de Nathan Kula: PowerShellSnippets / Invoke-Log4ShellScan.ps1 , y
  • Página de Will Dormann en GitHub: checkjndi.ps1 .
• Para obtener orientación sobre el uso de Canary Token para probar la devolución de llamada, consulte el hilo de Twitter de Thinkst Canary sobre el uso de Canary Tokens .
• Para obtener orientación sobre el uso de Burpsuite Pro para escanear, consulte:
  
  
  • Página de GitHub de Silent Signal: burp-log4shell , y
  • Página de GitHub de PortSwigger: active-scan-plus-plus .
• Para obtener orientación sobre el uso de Nmap Scripting Engine (NSE) de NetMap, consulte la página de GitHub de Divertor : nse-log4shell .
• Consulte la página de GitHub de Florian Roth, Fenrir 0.9.0 – Lanzamiento de Log4Shell , para obtener orientación sobre el uso de la herramienta Fenrir de Roth para detectar instancias vulnerables.

2. Mitigar los activos vulnerables conocidos y sospechosos en su entorno.

A. Trate los activos vulnerables conocidos y sospechosos como comprometidos. Estos activos deben aislarse hasta que se mitiguen y verifiquen. El método de aislamiento que debe utilizar depende de la criticidad del activo. Los posibles métodos de aislamiento incluyen:

• Eliminar físicamente el activo de la red (por ejemplo, desenchufar el cable de red);
• Mover el activo a una “VLAN de jail” con mayor supervisión y seguridad;
• Bloqueo en la capa de red (un conmutador o algún otro dispositivo);
• Implementar un firewall (incluido el firewall de aplicaciones web) con un estricto control de puertos y registro; o
• Restringir la comunicación del activo, especialmente a Internet y al resto de la red empresarial.

B. Parche Log4j y otros productos afectados a la última versión

• Consulte la página web Apache Log4j Security Vulnerabilities (al 22 de diciembre de 2021, la última versión de Log4j es 2.17.0 para Java 8 y 2.12.3 para Java 7). Nota : parchear o actualizar Java no es suficiente, debe actualizar la propia biblioteca Log4j.

Nota : si su organización no puede identificar y parchear instancias vulnerables de Log4j de inmediato, aplique las soluciones alternativas adecuadas. 

Se han recomendado el uso de mitigaciones proporcionadas por el proveedor cuando estén disponibles. Debido a la situación en rápida evolución, estas soluciones no deben considerarse arreglos permanentes y las organizaciones deben aplicar el parche apropiado tan pronto como esté disponible.

Las mitigaciones adicionales se identifican a continuación; sin embargo, las organizaciones deben usar estas mitigaciones bajo su propio riesgo, ya que pueden ser incompletas, temporales o causar efectos dañinos, como inestabilidad de la aplicación, una condición de DoS o evasión de registros.

• Elimina Jndilookup.class de la ruta de clases [ 1 ]
• Asegúrese de que las versiones anteriores que no pueden actualizarse o que esperan ser actualizadas estén configuradas de modo que la configuración de la biblioteca “log4j2.formatMsgNoLookups” esté establecida en TRUE. Nota : esta mitigación es una respuesta rápida para las configuraciones vulnerables identificadas inicialmente junto con la implementación del parche.
• Elimine o cambie el nombre de Jndilookup.class. Nota : la eliminación de JndiManager hará que JndiContextSelector y JMSAppender dejen de funcionar)
• Aplicar un parche en caliente.
  
  
  • NCC Group: log4j-jndi-be-gone: una mitigación simple para CVE-2021-44228
  • Amazon AWS:
    
    
    • Página de GitHub: hotpatch-for-apache-log4j2
    • Blog: Hotpatch para Apache Log4j

C. Mantener un inventario de los activos vulnerables conocidos y sospechosos y lo que se hace con ellos durante este proceso . 

Es importante realizar un seguimiento de la aplicación de parches porque los actores cibernéticos malintencionados pueden poner en peligro un activo y luego parchearlo para proteger sus operaciones. Las instituciones deben mantener un registro meticuloso de los activos vulnerables que han parcheado para identificar si un actor de amenazas puede haber parcheado un activo.

D. Verifique que la mitigación haya funcionado, si es posible.

1. Escanee el activo parcheado / mitigado con las herramientas y métodos enumerados en el paso 1.A. Utilice más de un método para verificar que la mitigación se haya aplicado correctamente.
2. Supervise el activo de cerca.
3. Permanezca alerta a los cambios de los proveedores del software en el activo.

3. Iniciar procedimientos de búsqueda y respuesta a incidentes. Dada la explotación generalizada de esta vulnerabilidad, se alientan a todas las instituciones a asumir que sus activos que utilizan Log4j pueden haber sido comprometidos e iniciar procedimientos de búsqueda.

A. Busque señales de explotación y compromiso.

1. Trate los activos que utilizan Log4j como sospechosos y lleve a cabo una investigación forense rigurosa de esos activos.
2. Inspeccione y supervise las cuentas de su empresa que existan o se conecten a activos que usan Log4j.
3. Inspeccione los cambios realizados en las configuraciones desde el 1 de diciembre de 2021 y verifique que fueran previstos, especialmente en los activos que usan Log4j.

Los recursos adicionales para detectar una posible explotación o compromiso se identifican a continuación. 

• Blog de Cisco Talos: Aviso sobre amenazas: vulnerabilidad crítica de Apache Log4j explotada en la naturaleza
• Página de GitHub de Curated Intelligence: Log4Shell-IOCs ( Nota : Curated Intelligence señala que “los IOC compartidos por estos feeds son de confianza baja a media, por lo que [Curated Intelligence] recomendamos encarecidamente no agregarlos a una lista de bloqueo”).
• EmergingThreat.net: firmas para ayudar con la detección de la actividad CVE-2021-44228
• Páginas de GitHub de Florian Roth:
  
  
  • Detección de explotación de Log4j RCE
  • Signature-base / yara / expl_log4j_cve_2021_44228.yar
  • detector-log4shell
• Blog de Huntress: Vulnerabilidad crítica de RCE: log4j – CVE-2021-44228
• Blog de Mandiant: Ahora eres serial, ahora no lo haces – Búsqueda sistemática de exploits de deserialización
• Página de Microsoft Azure GitHub: Azure-Sentinel / Detections / MultipleDataSources / Log4J_IPIOC_Dec112021.yaml
• Grupo NCC: Log4Shell: Reconocimiento y detección de redes posteriores a la explotación
• Páginas de Sigma GitHub:
  
  
  • sigma / rules / web / web_cve_2021_44228_log4j.yml
  • sigma / rules / web / web_cve_2021_44228_log4j_fields.yml

B. Si se detecta un compromiso, las organizaciones deben

1. Iniciar procedimientos de respuesta a incidentes. 
2. Considere informar los compromisos de inmediato a las autoridades de ciberseguridad correspondientes. Se alienta a las organizaciones a ser lo más minuciosas posible al incluir información como direcciones IP / dominios utilizados para explotar su infraestructura, aplicaciones / servidores explotados, información de contacto de los administradores y las fechas de inicio y finalización del ataque.

4. Evaluar y aplicar otras mitigaciones.

R. Permanezca alerta a los cambios de los proveedores para el software en el activo y aplique inmediatamente actualizaciones a los activos cuando un proveedor le notifique que su producto tiene un parche para esta vulnerabilidad. 

B. Continuar monitoreando de cerca los activos de Log4J . Utilice continuamente firmas e indicadores de compromiso que puedan indicar explotación.

1. Consulte los recursos de explotación y detección enumerados en el paso 3.A. (4).
2. Tenga en cuenta que hay muchas formas de ocultar la cadena de explotación. No dependa de un método de detección para que funcione todo el tiempo.

C. Continúe monitoreando la página web Apache Log4j Security Vulnerabilities para obtener nuevas actualizaciones . Nota : como esta es una situación en evolución y se están descubriendo nuevas vulnerabilidades en Log4J, las organizaciones deben asegurarse de que su Apache Log4j esté actualizado. Identifique el software que utiliza su empresa y manténgase al tanto de las actualizaciones, ya que pueden ser reemplazadas por otras actualizaciones y correcciones.

D. Bloquear el tráfico de red saliente específico del Protocolo de control de transmisión (TCP) y del Protocolo de datagramas de usuario (UDP) .

1. LDAP saliente : para la mayoría de las redes, LDAP se usa internamente, pero es raro que las solicitudes LDAP se enruten fuera de una red. Las organizaciones deben bloquear LDAP saliente o utilizar una lista de permisos para LDAP saliente a buenos destinos conocidos. Nota : esto puede ser difícil de detectar en ciertos puertos sin un firewall que filtre la capa de aplicación.
2. Invocación de método remoto (RMI) : para la mayoría de las redes, RMI no se utiliza o se utiliza para fuentes internas. Las organizaciones deben bloquear la RMI saliente o utilizar una lista de permisos para la RMI saliente a buenos destinos conocidos.
3. DNS saliente : las organizaciones que utilizan la resolución de DNS empresarial pueden bloquear el DNS saliente de fuentes distintas de los resolutores de DNS identificados. Como mínimo, el bloqueo del DNS saliente directo de los servidores de aplicaciones web configurados para utilizar la resolución de DNS empresarial mitigará los riesgos para esos sistemas.

palabra clave: 59044d3dae4805080e30b30d1c801498

59044d3dae4805080e30b30d1c801491=cualiz