Aclarando las cosas: afirmaciones exageradas sobre vulnerabilidades, exploits y gravedad

Durante las últimas semanas, el equipo de Huntress ha estado monitoreando las conversaciones recientes sobre supuestas vulnerabilidades de ConnectWise Control y presuntas explotaciones activas.

Hemos estado en contacto tanto con el CISO de ConnectWise y su equipo de seguridad, como con el investigador de seguridad que reportó esto. Si bien ha habido algunos comentarios y artículos de noticias, queremos usar este artículo para compartir nuestra propia perspectiva.

Resumen: Discrepamos respetuosamente con la amenaza y la criticidad presentadas por el investigador de seguridad.

Esta publicación tiene tres propósitos:

  • Dar tranquilidad respecto a las supuestas vulnerabilidades en ConnectWise Control
  • Demostrar esfuerzos adecuados de divulgación responsable y la colaboración entre proveedores
  • Mostrar otras tácticas que resaltan la necesidad de la conciencia humana en materia de seguridad, no solo para los usuarios finales, sino también para los administradores de sistemas y las empresas MSP

Además, compartiremos nuestras propias perspectivas y lo que estamos observando estrictamente en cuanto a ataques de ingeniería social y phishing contra ConnectWise Control.

Tenemos un historial comprobado de exigir divulgación responsable cuando hay algo que podría afectar a la comunidad de MSP en general. Con esto en mente, nos exigimos a nosotros mismos, y a la comunidad en su conjunto, responsabilizar tanto a los investigadores de seguridad como a los proveedores mientras trabajamos para mejorar el panorama de seguridad juntos.

Nuestra cronología

  • T4 2022: Huntress observa un aumento en los intentos de ingeniería social y phishing contra los MSP que usan Control
  • 16 de octubre: ConnectWise recibe información de un investigador de seguridad que sugiere que hay una nueva vulnerabilidad crítica en Control que le da a un adversario ejecución remota de código
  • 17 de octubre: Silent Push ofrece uno de los primeros artículos de asesoría sobre malware que utiliza ConnectWise Control para phishing y acceso remoto.
  • 21 de octubre: ConnectWise publica la versión estable de Control 22.8.10013 con “... validación adicional de los parámetros de URL del instalador del cliente para inhibir ciertos ataques de ingeniería social”
  • 09 de noviembre: Huntress asiste al evento ConnectWise IT Nation Connect
  • Investigadores de Huntress reciben notificación personal de publicaciones en línea que afirman que hay nuevas vulnerabilidades importantes en ConnectWise Control
  • Investigadores de Huntress se comunican con el investigador de seguridad para pedir claridad y entender este supuesto riesgo de seguridad
  • Investigadores de Huntress se reúnen y conversan con el CISO de ConnectWise y su equipo de seguridad. Ambas partes determinan que este reporte no es una vulnerabilidad en Control
  • Huntress le comunica al investigador de seguridad que no parece haber una vulnerabilidad ni una amenaza de explotación. El investigador no quiso proporcionar un video de demostración técnica como prueba de concepto para mostrar el impacto
  • 10 de noviembre: Huntress observa y responde a un hilo de Reddit en r/msp de miembros de la comunidad preocupados por las afirmaciones recientes.
  • 29 de noviembre: 
  • El investigador de seguridad publica su artículo público, “Hijacking Connectwise Control & Screen Connect (v.22.9.10032, MULTIPLE) for Fun and Profit – From DDoS to Multi-OS RCE!”
  • ConnectWise publica un aviso en el que reconoce el reciente aumento en los esquemas de ingeniería social e intentos de phishing que utilizan Control
  • 01 de diciembre:
  • Huntress observa y responde a otro hilo de Reddit en r/msp que alerta a la comunidad sobre intentos continuos de phishing que incluyen ConnectWise Control
  • El reportero Brian Krebs publica una noticia sobre el trabajo del investigador de seguridad.
  • 02 de diciembre: ConnectWise y Huntress se asocian como socios para preparar publicaciones de blog en respuesta a las recientes noticias y artículos que generan más preocupación sobre esta supuesta vulnerabilidad.
  • 05 de diciembre:
  • El investigador de seguridad comparte otro artículo público, “Bypassing Firewall and AV Rules at Scale - Where do old Connectwise Control FQDNs go when they die?”
  • Los investigadores de Huntress determinan un procedimiento distinto que un adversario podría usar en intentos de ingeniería social o phishing contra instancias on-premises de ConnectWise Control.
  • 06 de diciembre: El investigador de seguridad publica un artículo público adicional, “Proof Of Concept: Connectwise Control Screenconnect Signed Executable a ejecución arbitraria de código via ARP Poisoning / DNS Hijacking / Unsanitized Client Parameters or Host Headers with CVE-2020-3147 (Cisco Sx / SMB Series Switches)”
  • 07 de diciembre: Los investigadores de Huntress se reúnen con el CISO de ConnectWise y su equipo de seguridad en un esfuerzo de divulgación responsable para presentar esta técnica de ingeniería social y alinearse sobre la colaboración conjunta del artículo.
  • 14 de diciembre: Huntress publica este artículo de respuesta.

Nuestra validación

En IT Nation Connect, el 9 de noviembre, el equipo de Huntress estaba en nuestro stand conversando con partners en el piso del evento, cuando un miembro de la comunidad se acercó a hablar con nosotros diciendo que acababan de comprometerlo “a través de ConnectWise Control”.

Al escuchar esto, uno de nuestros compañeros de equipo recordó una publicación reciente en LinkedIn que sugería que se divulgaría públicamente información sobre una nueva vulnerabilidad de ConnectWise Control que se estaba explotando activamente. Nuestro CEO y un pequeño grupo de investigadores de Huntress salieron corriendo del stand, se apresuraron al rincón tranquilo más cercano, sacaron sus laptops y empezaron a investigar. Nos contactamos con el investigador que publicó esto, programamos una llamada telefónica y creamos un canal interno de Slack para comunicarnos con el resto de nuestro equipo.

image3

Nos pusimos manos a la obra revisando nuestros informes de incidentes anteriores y rastreando actividad relacionada con ConnectWise Control.

Durante los últimos meses, nuestros analistas del SOC han estado observando y notificando a los partners sobre ataques relacionados con ConnectWise Control. Sin embargo, estos no implicaban DDoS, secuestro, envenenamiento, inyección, botnets, ataques de amplificación, ataques de canal lateral, ejecución remota de código ni ninguna de las otras amenazas de gravedad crítica planteadas en el artículo del investigador.

image5

La amenaza más frecuente contra ConnectWise Control que tanto Huntress como la comunidad han observado y compartido es la ingeniería social y los intentos de phishing. Son muy comunes en estafas y trampas que buscan que la víctima llame a un número telefónico, donde el atacante responderá haciéndose pasar por una mesa de ayuda o línea de soporte de empresas como BestBuy o GeekSquad, e incentivará al usuario final a descargar y ejecutar un cliente legítimo de Control.

Huntress reportó 14 casos de ataques relacionados con ConnectWise Control, cifra que aumentó a 85 en noviembre. Desde principios de diciembre, hemos reportado más de 60 casos de estas instalaciones “fraudulentas” de Control.

image2
image1
image6

En este frente, Huntress tiene conocimiento de varios dominios y direcciones IP incluidos en intentos de phishing relacionados con ConnectWise Control. Esta lista se incluye al final de este artículo y está disponible en este enlace directo a gist.

Según entendemos, y de acuerdo con la evaluación de ConnectWise, sí hubo un truco peculiar incluido en el informe inicial del investigador de seguridad. Antes del lanzamiento de Control 22.8, los parámetros de URL h (nombre del servidor) y p (puerto) incluidos al descargar un cliente de Control podían manipularse para dirigir la conexión a otro endpoint.

Demostración en video: solicitud de una URL con parámetros modificados para apuntar a otro servidor de ConnectWise Control

Esto significa que la URL incluida en un correo de phishing podría apuntar a una dirección confiable, como un servidor de ConnectWise Control que el usuario final reconoce como propio de su empresa u organización, pero el cliente descargado lo dirigiría a un servidor de Control completamente distinto.

  • Supongamos que tu organización realmente usa msp123.screenconnect.com para Control
  • Un usuario final podría recibir un correo con un enlace al genuino msp123.screenconnect.com
  • Los parámetros de la URL se modifican para apuntar hacia attacker789.screenconnect.com
  • El actor de amenazas aún necesita controlar attacker789.screenconnect.com para aceptar la solicitud.
  • (El actor de amenazas bien podría haber realizado typo-squatting y usado su propio
    msp-123.screenconnect.com, con un guion agregado, en el señuelo de phishing original)

Esta debilidad podría ayudar en algunas tácticas de ingeniería social y phishing, pero no se clasificaría como un exploit. El adversario aún necesitaría tener su propio servidor de ConnectWise Control bajo su control para recibir y responder correctamente a la solicitud de conexión… lo cual no ofrece ninguna ventaja respecto de lo que ya tenían al inicio. Ambas partes todavía deben aceptar y reconocer la solicitud de manera voluntaria.

Demostración en video: invocando el cliente de ConnectWise Control apuntado hacia otro servidor de Control e iniciando el control remoto

Las versiones 22.8 y posteriores de ConnectWise Control resuelven el problema de los parámetros arbitrarios h y p, y todas las instancias en la nube se actualizaron para remediar esto, incluidas todas las versiones de prueba gratuitas disponibles del software.

image4

Cuando un miembro de la comunidad, un investigador de seguridad o cualquier otra persona nos plantea inquietudes de seguridad como esta, hacemos nuestro propio análisis interno, pero también coordinamos con otros proveedores para validar nuestros hallazgos. En vivo, en el rincón trasero de IT Nation Connect, hablamos cara a cara con el CISO de ConnectWise y con miembros del equipo de seguridad para ver el panorama completo y determinar qué riesgo representa esto para el panorama de seguridad en general. Es vital que los proveedores colaboren en problemas de seguridad y hagan que nuestra industria sea mejor en conjunto.

Nuestra evaluación

Es importante señalar que incluso generar un nuevo cliente apuntado a un servidor de Control diferente sigue siendo solo iniciar una conexión hacia otro servidor de Control. Esto no es ejecución arbitraria de código desde un binario firmado, y no permite que un adversario ejecute comandos o controle el objetivo sin que el usuario sea engañado mediante una táctica de ingeniería social.

En una llamada con el investigador el 9 de noviembre, Huntress llegó a la conclusión de que, en última instancia, esta no es una técnica novedosa y no representa una nueva amenaza para las organizaciones. Dicho esto, creemos que la decisión de ConnectWise de expresar esto como un simple aviso y notificación fue la acción correcta.

Demostración en video: se invoca el agente de ConnectWise Control, apuntando hacia el listener de netcat de un atacante,
mostrando la conexión TCP y los paquetes, pero sin ejecución arbitraria de código.

En las semanas posteriores a IT Nation Connect, el investigador expresó en LinkedIn que vendrían más detalles y que pronto publicaría su entrada de blog pública.

El 29 de noviembre, su publicación pública estuvo disponible y posteriormente llamó la atención de algunos reporteros y periodistas. Los investigadores de Huntress hablaron más con esta persona y le preguntaron si podía compartir una demostración en video para mostrar con mayor claridad la gravedad e impacto alegados, pero no estuvo dispuesto a producir una.

Las publicaciones posteriores del blog compartidas por el investigador de seguridad intentan plantear esto como un riesgo relacionado con nombres de dominio y la confianza de certificados. Además, las publicaciones sugieren que este supuesto ataque podría combinarse con otros posibles CVEs y vulnerabilidades antiguas, así como con dispositivos que podrían estar presentes dentro de una red interna.

Nuestra reserva con este planteamiento es que no se trata de un exploit dirigido estrictamente a ConnectWise Control; el problema central sigue dependiendo de la ingeniería social, y la supuesta amenaza continua se basa en hipótesis sobre si acaso dispositivos vulnerables podrían estar presentes incluso dentro de un entorno objetivo.

La amenaza central que representa ConnectWise Control sigue siendo la ingeniería social y el phishing, algo que también podría lograrse con cualquier otro software de control remoto disponible públicamente, como TeamViewer, AnyDesk u otros.

El investigador de seguridad afirma repetidamente que esto no requiere ingeniería social, pero nosotros (junto con otros miembros de la comunidad) sostenemos que sí la requiere.

El 1 de diciembre, después de que Brian Krebs informara sobre esto en su propia nota periodística, tanto nosotros en Huntress como ConnectWise teníamos una preocupación creciente de que esto generara más miedo, incertidumbre y duda dentro de la comunidad. Aun así, con mente abierta y dispuestos a entender mejor la situación y dar sentido a las afirmaciones planteadas, volvimos a hablar con el investigador.

Un efecto secundario de generar un nuevo cliente de Control fue la creación de un nuevo ejecutable con un certificado legítimo firmado por ConnectWise. Esto llevó al investigador de seguridad a afirmar que se trataba de un ataque indetectable, capaz de evadir el antivirus y los controles de seguridad de endpoint, logrando ejecución remota de código. Sin embargo, de nuevo, este binario sigue siendo un agente puro de ConnectWise Control que solo intenta conectarse a un servidor de ConnectWise Control.

Pedimos más aclaraciones y nuevamente preguntamos si podían ofrecer una demostración técnica en video para mostrar el proceso y lograr el efecto deseado, pero el investigador se volvió a negar.

Dicho esto, durante nuestra comunicación el investigador de seguridad sí notó otra rareza en el comportamiento de ConnectWise Control. Nuestro equipo en Huntress siguió este hilo un poco más y tomó un camino distinto, derivado de las afirmaciones del investigador de seguridad pero no exactamente lo que planteó en sus múltiples artículos.

Nuestra exploración adicional

Además de las diferentes versiones previas y posteriores a la actualización de ConnectWise Control, también debemos considerar las distintas variantes de implementación: ya sea una instalación on-premises del servidor o una instancia en la nube (accesible en pruebas gratuitas).

El investigador de seguridad incluyó capturas de pantalla de un truco interesante al solicitar un nuevo binario de cliente desde un servidor de Control: suministrar tu propio encabezado HTTP Host modificado. Como se ve en sus capturas de pantalla, su ejecutable descargado intentaría conectarse al endpoint deseado, pero fallaría al descargar o recuperar datos nuevos.

Demostración en video: modificando el encabezado HTTP Host para descargar un instalador firmado de ConnectWise Control,
apuntando a un endpoint arbitrario para instalar el software.

Este ejecutable parecía estar intentando instalar por completo el software requerido para la conexión de ConnectWise Control, obtenido una vez más desde el servidor.

Lo que no vimos probado en el informe del investigador de seguridad fue preparar un endpoint para proporcionar los datos que el nuevo binario de cliente esperaba recibir. Dado que podíamos controlar este encabezado Host en la solicitud, es posible generar un binario que descargue e instale una aplicación proporcionada desde cualquier ubicación.

Demostración en video: inspeccionando el instalador firmado de ConnectWise Control descargado mediante el encabezado Host modificado,
observando cómo se contacta con la ubicación proporcionada para instalar y ejecutar cualquier código arbitrario.

Si pudiéramos preparar un endpoint para servir los mismos archivos de aplicación que la descarga esperaría, se instalaría y ejecutaría nuestro propio código proporcionado. ¡Eso en realidad podría convertirse en ejecución arbitraria de código bajo un binario firmado de ConnectWise!

Para validar esto, revisamos los registros de errores cuando el procedimiento de descarga del cliente fallaba, y pudimos ver que intentaba contactar la ubicación proporcionada en el encabezado Host y descargar un archivo .application.

Demostración en video: instalador firmado de ConnectWise Control, modificado mediante manipulación del encabezado HTTP Host para descargar e instalar un software distinto a ConnectWise Control: en este caso, un stub para la aplicación Calculadora de Windows.

Este archivo .application es una aplicación ClickOnce, que es un componente y función nativa de los sistemas operativos Windows (con .NET frameworks versión 2.0 o posterior) que instala y luego ejecuta automáticamente un programa alojado en un sitio web en línea con un solo clic.

Cabe señalar que la aplicación ClickOnce podría ser cualquier código C# que quisiéramos. Generar la aplicación de calculadora es una buena prueba de muestra, pero esto podría ser igual de fácilmente cualquier payload malicioso: iniciar una conexión de shell inverso, invocar cualquier otro malware, o cualquier actividad nefasta que se quiera (aún bajo el control de antivirus y otros controles de seguridad de endpoints).

Demostración en video: instalador firmado de ConnectWise Control preparado para iniciar una conexión de shell inverso hacia el atacante.

El ejecutable descargado desde el servidor de Control sigue siendo, en efecto, un ejecutable firmado de ConnectWise. Pero con esta técnica, logramos que el programa descargue e instale otra cosa que no es ConnectWise Control.

Vale la pena mencionar que, si bien el programa inicial será un ejecutable legítimo firmado, la aplicación ClickOnce creada mostrará diálogos de confirmación que indican que la aplicación instalada puede no estar firmada. Ejecutar el binario de cliente descargado es un proceso, pero la nueva aplicación ClickOnce instalada se generará como su propio proceso nuevo.

Dado que este ejecutable sí solicita la aprobación de esta nueva instalación, esta técnica una vez más requiere interacción del usuario y, en definitiva, ingeniería social. Esto podría lograr la tarea de ejecutar código verdaderamente arbitrario bajo un binario firmado de ConnectWise, pero la técnica central sigue dependiendo del engaño humano.

Además, este esfuerzo de modificar el encabezado HTTP Host elimina el único truco redentor del esquema de parámetros de URL h y p. Como esto depende de un encabezado HTTP, la entrega ya no puede ser un simple enlace de texto incluido en un correo electrónico. Es cierto que un atacante podría (1) realizar algunas técnicas de secuencias de comandos en sitios cruzados para forzar al navegador del usuario final a solicitar la URL, (2) preparar otro código HTML y JavaScript para forzar una descarga oculta del binario, o (3) alojar o adjuntar el binario descargado al correo electrónico.

Huelga decir que todas esas condiciones agregan más complejidad y dependencias a esta técnica, y puede que no valga la pena para un adversario, en primer lugar. La necesidad de ingeniería social en cualquiera de estos escenarios de ataque reduce considerablemente el riesgo y la gravedad; todo sigue dependiendo de engañar a la víctima, y la mejor defensa es la concientización y la capacitación en seguridad.

Finalmente, tras profundizar más en esto a partir de las afirmaciones del investigador de seguridad y ejecutar más que solo la funcionalidad normal de ScreenConnect bajo el binario firmado, continuamos comunicándonos y colaborando con ConnectWise.

Nuestra colaboración

Cuando compartimos esta técnica personalizada de ClickOnce con ConnectWise, agradecieron que les llamáramos la atención sobre esto. Nuestras conversaciones en conjunto aclararon nuestra propia comprensión de la superficie de ataque y reforzaron la importancia de la concientización y la capacitación en seguridad, no solo para los usuarios finales, sino también para los administradores de sistemas.

  • ConnectWise lanzó las versiones de Control 22.8.10013 y 22.9.10032 para mitigar la manipulación de URL reportada por el investigador de seguridad.
  • En todas las instancias en la nube y en las instalaciones on-premises posteriores a la actualización, los esquemas y estafas de ingeniería social siguen siendo muy posibles, pero ya no es posible la redirección del servidor mediante parámetros.
  • Aparte de la información del investigador de seguridad, después de la actualización, la manipulación del encabezado HTTP Host y el escenario personalizado de ClickOnce que describimos arriba:
  • solo es posible contra instalaciones on-premises de ConnectWise Control.
  • no es posible en instancias en la nube, ya que el encabezado HTTP Host se usa para el proxy

Los miembros del equipo de ConnectWise explicaron que, simplemente por la naturaleza del software de soporte remoto (especialmente ofrecido tanto en entornos en la nube como on-premises), siempre existe un riesgo potencial de estafas de ingeniería social. La confianza y la certificación de los binarios ejecutables son un punto de discusión interesante.

El binario cliente de ConnectWise Control que se descarga no está firmado por el servidor on-premises, ya que esa aplicación de servidor ciertamente no debería distribuirse con los permisos de firma oficiales. Según entendemos, cierta información de configuración puede incluirse después de firmar el ejecutable sin corromper la firma. Esta información de configuración adjunta le indica al cliente que descargue la aplicación ClickOnce real desde cualquier ubicación externa. Incluso si la instancia on-premises está protegida, es técnicamente posible tomar cualquier ejecutable del cliente de Control y modificar la configuración para que se conecte y descargue una aplicación potencialmente maliciosa sin invalidar la firma del código.

Esto es un "mal necesario" al ofrecer la aplicación de escritorio remoto en los métodos de libre acceso y disponibilidad que manejan. Firmar ejecutables mientras se mantiene la capacidad de alojarlos desde organizaciones individuales plantea un problema peculiar y difícil de resolver.

Dicho esto, la técnica de manipulación del encabezado Host es ineficaz en instancias en la nube, porque el servicio frontend no es el verdadero servidor de retransmisión de ConnectWise Control. El encabezado HTTP Host se usa dentro del proxy interno para enrutar correctamente hacia la instancia en la nube correspondiente a la implementación del usuario.

Esto significa que manipular el encabezado Host en la nube no permitirá llegar a un endpoint adecuado ni siquiera para descargar el binario del cliente.

Demostración en video: solicitar un instalador de ConnectWise Control con encabezados Host modificados falla contra las instancias en la nube.

En el caso de las instalaciones on-premises, es crucial que los administradores del sistema sigan los procedimientos de instalación adecuados y el manual, otras guías de fortalecimiento y la lista de verificación de seguridad de ConnectWise Control. proporcionada.

Según la documentación, se recomienda a los usuarios con instalaciones on-premises configurar sus parámetros WebServerAddressableUrl y RelayAddressableUrl para evitar la técnica de proxy que demostramos arriba (o definir un destino alternativo específico que se deba usar).

ConnectWise nos comentó que está trabajando con su equipo de educación para agregar esta recomendación a la guía de mejores prácticas para los socios de Control.

Reflexiones finales

Para ser claros, esta respuesta no busca señalar culpables ni confrontar a ninguna de las partes involucradas. Esperamos ofrecer nuestra propia perspectiva, pero seguimos abiertos a nueva información o aclaraciones que nos ayuden a educarnos a nosotros también.

Entre palabras rimbombantes, saltos lógicos de fe, hipótesis inciertas y un componente central que aún no presenta nada nuevo ni novedoso, discrepamos respetuosamente con la gravedad propuesta en el informe del investigador de seguridad.

Otros miembros de la comunidad se han sumado a la conversación para entender y aclarar mejor estos problemas, pero hay un mensaje y un tema recurrente: todos debemos ser responsables al dar la voz de alarma.

Sin evidencia demostrada ni pruebas tangibles, las afirmaciones audaces y la jerga técnica solo generan pánico en la gente. Miles de MSP usan herramientas como ConnectWise Control, y cuando alguien grita que viene el lobo sin razón, perjudica a toda nuestra industria.

Necesitamos abordar el miedo infundado y la palabrería que son tan comunes. Necesitamos colaborar con otros y resolver problemas, no empeorarlos. Sigamos trabajando juntos para mejorar el panorama de la seguridad.

Dominios e IP asociados a phishing

Loading Gist...

También te podría interesar