En seguridad informática, la divulgación responsable es un modelo de divulgación de vulnerabilidad en el que un problema se divulga públicamente solo después de un período de tiempo que permite a la parte afectada solucionar el problema en un tiempo razonable. Para la mayoría de los errores que no se están explotando activamente, este período suele durar entre 90 y 120 días. Después de este período de gracia, los detalles de los hallazgos se publican para educar a las masas sobre los riesgos que implica si los afectados deciden no aplicar el parche.
Investigadores de seguridad de Bishop Fox descubrieron ocho vulnerabilidades en ConnectWise Control que iban de gravedad baja a alta, con una considerada crítica por la empresa de seguridad. Hoy termina el embargo para estas vulnerabilidades y se contactó a Huntress para:
- Validar la investigación (excelente) de Bishop Fox
- Confirmar si los problemas fueron parchados
- Y opinar sobre el impacto en la comunidad
Esperamos sinceramente que disfrutes este resumen sin exageraciones y no dudes en publicar tus preguntas en r/MSP o conversar con nosotros en el Slack de MSP Geek.
Hemos actualizado cada sección de este blog con información adicional que obtuvimos de conversaciones con Bishop Fox y con el equipo de ConnectWise Control. Además, ConnectWise publicó una matriz resumen de los análisis y su propia respuesta.
Nota administrativa: el flujo de este blog sigue el orden de los hallazgos de Bishop Fox y no está clasificado por prioridad o gravedad. Este blog también es un trabajo en progreso que seguiremos actualizando a medida que completemos nuestra investigación.
Secuencias de comandos en sitios cruzados (XSS) en el modificador de apariencia
Estado: Mitigado parcialmente
ID de CVE: CVE-2019-16512
Resumen de Bishop Fox: La aplicación ConnectWise Control se ve afectada por una vulnerabilidad de secuencias de comandos en sitios cruzados almacenada en el modificador de apariencia. La vulnerabilidad permitía a cualquier cliente malicioso ejecutar JavaScript arbitrario en los navegadores de los visitantes.
Como se demuestra arriba, este error funciona exactamente como lo describió el equipo de Bishop Fox. Para quienes no lo notaron, esta vulnerabilidad de XSS almacenada abusa de una función legítima dentro de Control que permite a los MSP/departamentos de TI personalizar la apariencia de su producto. Como te imaginarás, eliminar por completo esta capacidad sería bastante controvertido para ConnectWise, así que creemos que han optado por aceptar el riesgo.
Esto simplemente significa que los hackers podrían registrarse para pruebas de Control y potencialmente servir JavaScript malicioso desde un dominio *.screenconnect.com. En teoría, esto podría ser un componente básico para otras cadenas de ataque. Sin embargo, entendemos la decisión de ConnectWise. Dicho esto, ConnectWise podría considerar un enfoque intermedio que deshabilite la función de modificador de apariencia en las pruebas. Esto elevaría el nivel de esfuerzo requerido para los hackers y los obligaría a comprometer las cuentas de los usuarios para realizar este ataque de XSS.
En general esta no es una buena situación, pero no vale la pena perder el sueño por ella.
Actualización 25/1/2020: Después de discutir los hallazgos de Bishop Fox con ConnectWise, confirmaron nuestras suposiciones de que este comportamiento es intencional. Sugerimos que sería mejor no permitir etiquetas de script HTML, pero ese filtrado se ha intentado sin éxito muchas veces. Según las declaraciones más recientes de ConnectWise sobre el tema, están eliminando la función de personalización de apariencia de las pruebas, lo cual ayuda mucho a mitigar el uso malicioso de esta función. Creemos que es un gran acuerdo.
Configuración incorrecta de Cross-Origin Resource Sharing (CORS)
Estado: Mitigado
ID de CVE: CVE-2019-16517
Resumen de Bishop Fox: Tanto el cloud de ConnectWise Control como las instancias de los clientes se vieron afectados por una configuración incorrecta de CORS, que reflejaba el Origin proporcionado por las solicitudes entrantes. Esto permitía que JavaScript ejecutándose en cualquier dominio interactuara con las API del cloud de Control y del servidor Control del cliente, y realizara acciones administrativas, como firmar identificadores de sesión, sin que la víctima lo supiera.
Según nuestro análisis, parece que el equipo de ConnectWise mitigó el problema exacto de CORS y CSRF en SetAccountAttributes que se destacó en el informe de Bishop Fox. 🎉
Sin embargo, notamos que otros endpoints, como GetMessages, no logran rechazar orígenes externos, como se demuestra en el video con https://himom.com.
La configuración de CORS en Control parece implementarse endpoint por endpoint, lo cual se parece un poco a jugar al topo (es difícil cubrirlos todos y mantenerse al día con los cambios). Endpoints como GetMessages parecen “reflejar” cualquier Origin especificado, lo que abre la puerta a otras acciones indeseables.
Estamos de acuerdo con la evaluación de Bishop Fox de que se trata de un riesgo de seguridad “alto”.
Actualización 25/1/2020: Después de hablar sobre esta vulnerabilidad con el equipo de ConnectWise Control, confirmaron que tienen una lista de aceptados limitada de endpoints que permiten cualquier origen para CORS. Después de recibir el informe de Bishop Fox, ConnectWise eliminó el endpoint SetAccountAttributes de la lista de aceptados. También nos informaron que GetScripts y GetMessages están diseñados para ser endpoints públicos, por lo que permiten solicitudes entre orígenes. Según esta información, parece que ConnectWise Control está usando CORS correctamente para defenderse de JavaScript malicioso.
Falsificación de solicitudes entre sitios (CSRF)
Estado: Mitigado
ID de CVE: CVE-2019-16513
Resumen de Bishop Fox: El cloud de ConnectWise Control y las instancias de usuario no implementan protección CSRF. Si un usuario con Adobe Flash o una versión desactualizada de Chrome o Chromium visitaba un sitio web de terceros mientras estaba autenticado en la aplicación Control, un script que se ejecutara en el sitio web malicioso podría modificar la cuenta de Control del usuario enviando solicitudes a la API, sin que la víctima usuaria de Control lo supiera.
Como se demuestra en este video, el PoC en JavaScript de Bishop Fox para desactivar las alertas por correo de "actividad sospechosa de la cuenta" de Control ya no funciona. Esto parece ser resultado directo de los esfuerzos de ConnectWise por aplicar CORS en el endpoint SetAccountAttributes. Sin embargo, este video también muestra cómo todavía es posible falsificar una solicitud desde un sitio web externo a través del endpoint GetScripts.
Para dar una protección integral en todo Control, definitivamente deberían usarse tokens de prevención de CSRF. Coincidimos de nuevo con la recomendación del equipo de Bishop Fox:
Actualización del 25/1/2020: la seguridad funciona mejor cuando hay múltiples mitigaciones que trabajan juntas para prevenir ataques. El término del sector para describir esto es defensa en profundidad. Sin tokens CSRF, un simple error que hizo que la lista de aceptados de CORS fuera demasiado permisiva significó que atacantes de cualquier dominio podían desactivar la configuración de seguridad de una cuenta de ConnectWise Control. Recomendamos a ConnectWise implementar tokens CSRF para todos los endpoints que modifican datos, con el fin de reforzar aún más la seguridad. Ellos estuvieron de acuerdo y declararon:
ConnectWise reconoce los tokens de prevención de CSRF como la mejor práctica del sector contra este tipo de ataque y está planificando activamente su implementación.
Los endpoints GetScripts y GetMessages técnicamente no son vulnerables a CSRF ya que no modifican ningún dato. Esto concuerda con la intención de que sean endpoints públicos.
Divulgación de información de identificación personal (PII)
Estado: Mitigada
ID de CVE: no asignado
Resumen de Bishop Fox: el servicio en la cloud de ConnectWise Control se ve afectado por una vulnerabilidad de divulgación de información que permite a un atacante no autenticado revelar el correo electrónico del administrador y el código postal de una instancia de Control de cualquier cliente arbitrario.
Esta vulnerabilidad era especialmente interesante porque podría haber dado a los hackers un tesoro de datos de posicionamiento previo y selección de objetivos contra los MSP. Nuestro equipo incluso comentó esta idea durante el episodio de diciembre de Tradecraft Tuesday. Por suerte, el equipo de ConnectWise eliminó los correos electrónicos y códigos postales de los socios de las solicitudes devueltas.
Dicho esto, todavía es plausible que los hackers pudieran forzar por fuerza bruta el instanceId de seis caracteres para determinar IDs válidos. También podrían correlacionar estos datos con el currentLicenseCount devuelto para elaborar una lista priorizada de instancias objetivo. Si ConnectWise planea usar estos IDs únicos para buscar datos confidenciales, sugeriríamos que aumenten la complejidad de los IDs.
Divulgación de información por enumeración de usuarios
Estado: Mitigado
ID de CVE: CVE-2019-16516
Resumen de Bishop Fox: ConnectWise Control es vulnerable a una vulnerabilidad de enumeración de usuarios, que permite a un atacante no autenticado determinar con certeza si existe una cuenta para un nombre de usuario dado.
Como se demuestra en el video anterior, hemos validado que Control ya no devuelve el encabezado X-Login-Result, lo que evita que los atacantes identifiquen nombres de usuario válidos. Este problema de seguridad se abordó públicamente en las notas de la versión de Control 2019.5. ¡Buen trabajo, ConnectWise!
Ejecución remota de código por extensión maliciosa
Estado: Mitigado
ID de CVE: CVE-2019-16514
Resumen de Bishop Fox: El servidor de ConnectWise Control es vulnerable a una vulnerabilidad de ejecución remota de código. Los usuarios administrativos podían subir un archivo ZIP de extensión sin firmar que contenía código ejecutable, el cual el servidor luego ejecutaba.
Dado el tiempo limitado antes de que esto se divulgara públicamente, todavía no hemos validado este hallazgo. Vuelve a revisar para ver más actualizaciones.
Actualización del 25/1/2020: Si bien no pudimos validar esto nosotros mismos (las pruebas de ConnectWise Control no permiten subir extensiones personalizadas), lo conversamos con el equipo de Control y confirmaron que subir extensiones arbitrarias es intencional. También destacaron que su postura de seguridad es tratar cada instancia de cliente como tratarían cualquier otra máquina en internet (potencialmente maliciosa). También confirmaron que, aunque una extensión subida con una firma inválida quedaría deshabilitada, era posible ejecutar la extensión deshabilitada tal como documentó Bishop Fox. Esto se ha corregido posteriormente.
Encabezados de seguridad faltantes
Estado: Sin mitigar
ID de CVE: CVE-2019-16515
Resumen de Bishop Fox: La aplicación ConnectWise Control no implementa encabezados de seguridad HTTP modernos, lo cual es una oportunidad perdida para implementar funciones de seguridad opcionales en los navegadores.
Este es un hallazgo menos interesante y de bajo impacto. Sí, actualmente no está mitigado y probablemente actualizaremos esta sección al final.
Actualización del 25/1/2020: El equipo de ConnectWise Control está trabajando en implementar algunos de estos encabezados y esperamos que los tengan desplegados en las próximas semanas.
Alcance inseguro de cookies
Estado: Mitigado
ID de CVE: No asignado
Resumen de Bishop Fox: La cookie de autenticación de ConnectWise Control, CloudAuth, tiene alcance en el dominio padre, .screenconnect.com. Cuando un usuario visita una instancia de Control propiedad de un cliente SaaS malicioso, el token de autenticación CloudAuth del usuario se enviaría a la instancia SaaS del usuario malicioso.
Este es un hallazgo menos interesante y de bajo impacto. Sí, actualmente no está mitigado y probablemente actualizaremos esta sección al final.
Actualización 25/1/2020: Después de hablar esto con el equipo de ConnectWise Control, nos informaron que consideraban que este hallazgo era en realidad una amenaza más significativa que el riesgo de seguridad bajo asignado por Bishop Fox. El equipo corrigió esta vulnerabilidad el 2/10/2019. En lugar de usar una sola cookie CloudAuth, esta cookie se dividió en dos cookies separadas; CloudInstanceAuth y CloudSiteAuth, cada una correctamente delimitada para reducir la posibilidad de uso indebido. Esto parece una solución sólida.
