Log4Shell: Cómo se está explotando y cómo mitigar los daños.

Acompáñanos este miércoles 15 de diciembre a las 11:00 a. m. (hora del este) para obtener información actualizada sobre la evolución de la situación con Log4Shell. Tras la sesión informativa, habrá una sesión de preguntas frecuentes en directo. Haz clic aquí para registrarte.

CVE-2021-44228 is a critical vulnerability affecting Log4j, a widely used, open-source logging library written in Java. The vulnerability in Log4j will parse a specially crafted log message insecurely, causing it to execute remote code with the full privileges of the main program. The exploit has been dubbed Log4Shell.

On December 9, 2021, Chen Zhaojun of the Alibaba Cloud Security Team discovered and released sample code for a major remote code execution vulnerability in Apache's Log4j technology. In a now-deleted social media post, Zhaojun shared a proof of concept (POC) for the Log4j vulnerability. Initially, the vulnerability was thought to be limited to Minecraft, where it was used by trolls to take over the game’s servers, but it was quickly discovered that it was more broadly applicable.

Una instancia Log4j vulnerable interpretará el mensaje de registro especialmente creado como un registro legítimo e intentará acceder y desserializar contenido, como un recurso sitio web o código ejecutable. Por ejemplo, la vulnerabilidad podría permitir a un atacante iniciar tráfico del Protocolo de Acceso a Directorios Ligero (LDAP) a un nodo controlado por el atacante desde la Interfaz de Nombres y Directorios de Java (JNDI). El nodo controlado por el atacante responderá con un archivo de clase Java malicioso que luego comienza a ejecutar en el servidor víctima.

Actividad de amenazas

Recorded Future observó comportamientos de escaneo y explotación que comenzaron a las pocas horas de la revelación de la vulnerabilidad, casi todos procedentes de Tor. GreyNoise y Bad Packets observaron tráfico similar. Imperva informó de 1,4 millones de intentos de escanear la vulnerabilidad. Cloudflare y Cisco Talos informaron de intentos de escaneo de Log4Shell dos semanas antes de la divulgación pública, lo que sugiere que el exploit ya estaba en circulación antes de la divulgación pública.

Algunas compañías ofrecieron sus servicios para monitorizar y publicar direcciones IP etiquetadas que parecen estar escaneando la vulnerabilidad Log4j. Otras organizaciones, como Cloudflare, declararon abiertamente que el potencial de daño es tan grande que están introduciendo medidas proactivas de mitigación, incluso para organizaciones que no pagan. Personas del colectivo Curated Intel recopilaron una lista de indicadores de compromiso de Log4Shell.

Microsoft declaró que la gran mayoría de la actividad observada es escaneo masivo a servidores de huellas dactilares, aunque también presenciaron actividades de "explotación y post-explotación". Investigadores en redes sociales también informaron de explotación maliciosa. El investigador de BlackBerry, Greg Linares, informa presenciar ataques dirigidos específicamente a instalaciones SIEM, concretamente a Splunk. Splunk declaró que las funciones de Data Fabric Search (DFS) y Splunk Analytics for Hadoop (Hunk) se ven afectadas y proporcionó orientación sobre cómo eliminar Log4j de Splunk. Un autor anónimo creó un repositorio en GitHub para rastrear a los fabricantes afectados.

Los actores de amenazas de la dark sitio web en foros XSS y Exploit hablaron sobre el exploit de Log4Shell y compartieron enlaces a código POC. Algunos actores maliciosos mencionaron que GitHub parecía estar eliminando estos repositorios POC, pero muchos fueron bifurcados, y varios pueden encontrar abiertamente y están enlazados repetidamente. Parte del tráfico puede ser menor debido a la extrema facilidad para explotar Log4Shell. The Record informa que la mayoría de los ataques actualmente provienen de minería de criptomonedas y botnets, incluyendo Mirai, Muhstik y Kinsing. Microsoft informó de ver Log4Shell empleado para desplegar sitio web shells y Cobalt Strike.

Cabe destacar que algunos defensores están publicando públicamente detecciones y pruebas empleando servicios de detección de fugas DNS, muchos de ellos publicando capturas de pantalla del servicio DNSlog. Aconsejamos precaución al emplear cualquier servicio anónimo para probar tu infraestructura, especialmente porque DNSLog aún no reveló quién tiene acceso a sus registros, lo que podría ser útil para un atacante para enumerar hosts vulnerables.

Previsión

La vulnerabilidad Log4Shell resulta útil tanto para el acceso inicial como para el movimiento lateral, ya que tanto los servicios externos como los internos pueden emplear la biblioteca de registro Log4j. La primera actividad detectada por Recorded Future en relación con esta vulnerabilidad identificó a delincuentes que la estaban explotando activamente; la explotación activa continúa. El investigador de BlackBerry, Greg Linares, predice la probabilidad de que aparezca una versión que permita la propagación de virus en los próximos días, y según se informa, algunos grupos están trabajando activamente en dichas versiones.

Cómo se ve afectado el Recorded Future

La seguridad de la infraestructura de Recorded Future y los datos de los clientes que poseemos es de suma importancia. Recorded Future no emplea la biblioteca Log4j en ninguno de nuestros códigos propietarios, y actualmente no tenemos pruebas de que esta vulnerabilidad fue explotada en nuestros sistemas. En la medida en que Log4j es empleado por proveedores que suministran Recorded Future, implementamos mitigaciones para abordar cualquier vulnerabilidad conocida. Mientras validamos estas mitigaciones, los equipos de operaciones de Recorded Future monitorizan y despliegan continuamente cualquier cambio necesario en respuesta a riesgos emergentes.

Procedimiento para probar y mitigar Log4j

Los usuarios pueden buscar tráfico que intente explotar el software buscando las cadenas '{jndi:', '${', o largas cadenas del User-Agent en los registros del servidor web. El CERT neerlandés (Centro Nacional de Ciberseguridad) ha publicado un repositorio en GitHub, que incluye una lista regular de detección:

${(${(.?:|.?:.?:-)('|"|)*(?1)}*|[jndi:lapsrm]('|"|)}*){9,11}

La detección basada en firma probablemente sea insuficiente por sí sola, y ya se observó ofuscación. Los clientes también pueden emplear el tráfico hacia direcciones de devolución de llamada conocidas como punto de partida para investigar cualquier host que acceda a Internet vulnerable a Log4Shell. Aunque el tráfico hacia estas direcciones no indica un compromiso, muestran que un host respondió a un paquete Log4Shell. Recomendamos inspeccionar el tráfico saliente LDAP, HTTP y RMI (un protocolo Java personalizado que normalmente se usa en el puerto 1099) como punto de partida para triar los hosts que se conectan a Internet y que puedan ser explotados.

Existen diferentes medidas de mitigación disponibles según la versión implementada. Los defensores pueden modificar los archivos de configuración de registro estableciendo 'formatMsgNoLookups=true' para evitar que se realicen búsquedas de registro. Las versiones anteriores (2.10.0 y anteriores) incluyen '%m {nolookups}' en los archivos de configuración en lugar de "%m" para evitar que el servidor busque datos agregados a los registros. Estas son las correcciones que se proporcionan automáticamente en la versión 2.16.0 de Log4j. Tenable también recomienda eliminar las clases JdniLookup y JdniManager del archivo Log4j-core.jar.

Figure 1: Pasos de un ataque log4j JNDI y mitigaciones sugeridas (Fuente: Swiss CERT)

Se publicaron varios CERTs gubernamentales, compañías de seguridad y blogs con orientación para ayudar a los defensores. El CERT suizo publicó la guía mostrada en la Figura 1 anterior para mostrar diversas medidas de mitigación para defender contra Log4Shell.

Revisa la versión afectada. Las versiones afectadas de Log4j son de la 2.0 a la 2.14.1. Si tienes la versión afectada, comprueba la versión actual de Java. Log4j-2.16.0 requiere Java 8.
Si tienes Java 8, actualiza a la 2.16.0.
Aísla los sistemas afectados en una "VLAN vulnerable". También deberías revisar las reglas del firewall entre los hosts afectados y el resto de tu compañía.
Monitoriza los patrones de tráfico saliente. Un ejemplo sería un sistema DMZ que inicia conexiones salientes.
Busca cambios de configuración no autorizados en todos los sistemas. (Crédito por los pasos 3-5 al instructor de SANS Mick Douglas)