ACTUALIZACIÓN 27/2/23: Como recientemente detectó Fox-IT y luego reportó SecurityWeek, una vulnerabilidad crítica descubierta el año pasado en el software R1Soft Server Backup Manager de ConnectWise ya se ha visto explotada activamente para implementar puertas traseras en cientos de servidores mediante CVE-2022-36537. El siguiente artículo se publicó originalmente a fines de octubre por los investigadores sénior de seguridad John Hammond y Caleb Stewart, detallando las formas en que esta vulnerabilidad podría explotarse, y se ha confirmado que los actores de amenazas ya están utilizando este método.
La educación y la difusión comunitaria son fundamentales para generar conciencia sobre estas situaciones y evitar daños, al ofrecer perspectivas expertas basadas en datos para la remediación. Es tanto un privilegio como una responsabilidad trabajar como socio del ecosistema de seguridad más amplio para detener a los hackers y mitigar los riesgos para organizaciones de todo el mundo. Huntress seguirá compartiendo ampliamente los hallazgos de sus expertos internos, tanto del equipo del SOC como del equipo de Investigación y Desarrollo, para que la comunidad se beneficie.
Huntress ha validado un informe inicial sobre una omisión de autenticación y una filtración de archivos confidenciales presente en el framework de Java “ZK”, utilizado dentro del software ConnectWise R1Soft Server Backup Manager SE. Esta publicación detalla la gravedad de este hallazgo en la cadena de suministro, enfatiza la necesidad inmediata de aplicar el parche y resalta la importancia de una colaboración estrecha con los proveedores dentro de las comunidades de SMB/MSP.
El siguiente video muestra el exploit de prueba de concepto (POC) de Huntress utilizado para los pasos mencionados: 1) omitir la autenticación, 2) subir un controlador de base de datos JDBC con puerta trasera para lograr ejecución de código, y 3) usar la API REST para activar comandos a los agentes registrados y finalmente enviar el ransomware Lockbit 3.0 recientemente filtrado a todos los endpoints posteriores.
Descubrimiento inicial
Markus Wulftange de Code White GmbH originalmente descubrió una vulnerabilidad en la biblioteca ZK y, tras una divulgación responsable, ayudó a impulsar el lanzamiento parchado de la versión 9.7.2 de ZK en mayo de 2022. Esta vulnerabilidad de omisión de autenticación fue denominada CVE-2022-36537.
Un colega de Markus, Florian Hauser (@frycos), vio que la biblioteca ZK estaba incluida en el software ConnectWise R1Soft Server Backup Manager e intentó notificar a ConnectWise en julio de 2022. Sin respuesta tras los 90 días del estándar de divulgación, @frycos mostró capturas de pantalla de cómo replicar el problema en Twitter. Días después, la publicación fue eliminada; ConnectWise pide amablemente a los investigadores que usen el formulario de divulgación ubicado en la página de inicio de su Trust Center.
Investigación de Huntress
A partir de este tuit, Huntress reprodujo el problema y amplió el exploit de prueba de concepto, aprovechando la vulnerabilidad inicial para filtrar archivos de claves privadas del servidor, licencias de software, archivos de configuración del sistema y, finalmente, lograr ejecución remota de código (RCE) como superusuario del sistema, además de manipular R1Soft para distribuir ejecución arbitraria de código hacia todos los endpoints registrados.
Hemos trabajado de cerca con ConnectWise para informarles de estos problemas y ya han publicado un parche para el software Server Backup Manager SE. Huntress ha validado su parche y confirma que es efectivo para detener nuestro propio exploit de prueba de concepto (POC).
Impacto potencial
Nuestro equipo pudo demostrar el impacto y la gravedad de este problema al ejecutar nuestro exploit POC para:
- Omitir la autenticación
- Subir un controlador de base de datos JDBC con puerta trasera para lograr ejecución de código
- Usar la API REST para activar comandos a los agentes registrados y finalmente distribuir el ransomware Lockbit 3.0 recientemente filtrado a todos los endpoints posteriores
Nuestra investigación identificó más de 5.000 instancias expuestas de server manager backup mediante Shodan, todas con el potencial de ser explotadas por actores de amenazas, junto con sus hosts registrados. Considerando que Server Backup Manager SE es utilizado predominantemente por proveedores de hosting y de servicios administrados que se especializan en servicios de TI tercerizados para muchas empresas, esta vulnerabilidad tiene el potencial de afectar a muchas más de 5.000 SMB.
Al momento de escribir esto, no se ha encontrado evidencia de explotación activa detectada por Huntress o ConnectWise.
Hemos estado trabajando de cerca con el equipo de ConnectWise durante este proceso; sus equipos han sido receptivos y colaborativos, y merecen reconocimiento por tomar las medidas adecuadas a medida que hemos interactuado con ellos.
Esta vulnerabilidad sirve como otro recordatorio de la importancia de que los proveedores y los miembros de la comunidad trabajen juntos para responder a los problemas de seguridad, y de actuar rápidamente antes de que los actores maliciosos aprovechen exploits conocidos.
Nuestros hallazgos
Los investigadores de seguridad de Huntress John Hammond y Caleb Stewart realizaron el trabajo para recrear la prueba de concepto y explorar su impacto. Pudimos obtener una prueba gratuita de R1Soft Server Backup Manager y probarla localmente dentro de nuestro propio entorno de laboratorio.
Las capturas de pantalla que @frycos compartió en línea mostraban diferentes solicitudes y respuestas HTTP presentes en Burpsuite, lo cual no era tan revelador como un escrito completo y una explicación detallada. Tuvimos que hacer algo de experimentación y prueba y error para lograr por completo la omisión de autenticación, y en pocas horas habíamos recreado con éxito el POC.
Con esta omisión de autenticación, quedó claro a partir de la divulgación de la vulnerabilidad ascendente de ZK que podíamos acceder a archivos internos sensibles del servidor como /WEB-INF/web.xml y zk.xml. Si bien esto fue un logro, no era un exploit convertido en arma, y teníamos curiosidad por saber si se podía causar más daño.
A partir de la vulnerabilidad inicial, aparentemente podíamos aprovechar el reenvío interno para realizar múltiples solicitudes HTTP POST, pero solo solicitudes POST. Esto limitaba el acceso que teníamos como usuario autenticado, pero aun así pudimos encadenar algunos trucos creativos.
Cabe destacar que ZK es un framework particular, así que las solicitudes HTTP “tradicionales” que uno pensaría usar en un ataque clásico de secuencias de comandos en sitios cruzados no funcionarían. ZK procesa todo del lado del servidor, obteniendo eventos cada vez que haces clic en un botón o widget individual, y cada vez que editas un campo de entrada. Cada elemento de cada página tiene asignado un identificador único, y todas las acciones relacionadas con él se envían al servidor de forma secuencial.
Esto significaba que un exploit más sólido necesitaría cierta guía manual, simulando cada acción con otra solicitud y, en cierto modo, “saltando” de un identificador de widget o página a otro.
Tras una noche de pruebas, logramos un primitivo funcional para explorar libremente la aplicación R1Soft, aprovechando la vulnerabilidad de omisión de autenticación. Luego buscamos qué más podíamos usar para llevar esto más lejos y desarrollar aún más esta prueba de concepto.
En este punto, nos alejamos de la vulnerabilidad de ZK en sí y empezamos a aprovechar funciones y funcionalidades de la propia aplicación R1Soft. ZK abrió la puerta con la omisión de autenticación, pero ahora, como usuario administrador, teníamos el mismo poder y privilegios que cualquier administrador del sistema que gestionara su solución de respaldo con R1Soft específicamente.
Exploramos un sinfín de posibilidades, descompilando clases de Java y revisando el código, probando distintas rutas o cadenas de ataque. Al final, tuvimos más éxito con la simple función de agregar tu propio controlador de base de datos.
Server Backup Manager SE permite al administrador proporcionar su propio controlador de base de datos Java Database Connectivity (JDBC). El archivo JAR proporcionado se sube al directorio temporal del servidor y luego se agrega a la ruta de clases para invocarlo. Con algunos trucos, esto podría aprovecharse para lograr ejecución de código.
Hicimos nuestra debida diligencia e investigación, y rápidamente encontramos un primitivo en línea para un controlador JDBC con puerta trasera (¡muchas gracias por tu trabajo, Airman604!). Al encadenar esto con nuestro código de recorrido HTTP, pudimos automatizar la carga de un controlador de base de datos y activar código arbitrario. El servicio Server Backup Manager SE se ejecuta como root, y con eso, habíamos comprometido por completo el servidor de respaldo.
Además, como usuario administrador, podíamos ver información del sistema, incluida la versión del sistema operativo/kernel, las especificaciones del hardware e incluso descargar “Registros para soporte técnico”, que incluían archivos de configuración del servidor, registros, la clave de suscripción del producto, almacenes de claves de credenciales y claves privadas del servidor.
A lo largo de este esfuerzo, exploramos la API REST de ZK y nos familiarizamos con otros aspectos del paquete de software que podían manipularse (incluido un genial huevo de pascua con el código Konami 😉). Una vez más, encadenando estas funciones, desarrollamos una prueba de concepto para ejecutar comandos y código arbitrario no solo en el propio servidor de respaldo, sino también en todos los hosts y dispositivos registrados y gestionados por el Server Backup Manager.
Más fuertes juntos
Inmediatamente después de desarrollar la PoC de ejecución remota de código, contactamos a ConnectWise para informarles que esta vulnerabilidad tenía implicaciones más graves de lo que se creía inicialmente (agradecimiento especial a un campeón de la comunidad y nuestro gran amigo Jason Slagle de CNWR, quien ayudó a coordinar la comunicación y a conectarnos con las personas indicadas en ConnectWise).
Nos reunimos con el equipo de ConnectWise el 20 de octubre y demostramos nuestra prueba de concepto, explicando cómo encajaban las piezas. Preguntamos sobre la posibilidad de un parche y cómo podríamos colaborar para ayudar a mejorar juntos el panorama de seguridad.
ConnectWise garantizó que un parche estaba en camino, ya que se habían estado comunicando directamente con ZK para una actualización de seguridad personalizada para Java 7. El aviso oficial de seguridad de ConnectWise explica que los SBM de ConnectWise Recover se actualizaron automáticamente a la versión más reciente de Recover (v2.9.9). Las instancias específicas de R1Soft deben actualizar manualmente el server backup manager a la versión SBM v6.16.4, según la wiki de actualización de R1Soft y las notas de la versión oficial. Huntress confirmó que el parche de seguridad SBM v6.16.4 corrige con éxito nuestra propia prueba de concepto en nuestro entorno de pruebas local.
Huntress se puso en contacto y trabajó con socios internos dispuestos a colaborar en las pruebas y validación de nuestra prueba de concepto. Este esfuerzo se trató con sincera cautela y cuidado, y estamos muy agradecidos por el generoso permiso, la transparencia y la generosidad de cada socio.
Indicadores de compromiso
Nuevamente, al momento de escribir esto, ni Huntress ni ConnectWise han descubierto evidencia de explotación activa. Mientras desarrollábamos la prueba de concepto, Huntress no identificó ningún indicador para la omisión inicial de autenticación. Sin embargo, se observaron los siguientes indicadores relacionados con el controlador JDBC malicioso y la ejecución posterior del agente:
- El archivo de registro del servidor (/usr/sbin/r1soft/log/server.log) indica que se subió un nuevo controlador de base de datos y que se enviaron comandos a los agentes individuales. Nota: los comandos que se ejecutan no se registran. Además, mientras ejecutábamos nuestro exploit, también observamos una excepción de Java y un seguimiento de pila en los registros. El siguiente extracto de registro incluye el mensaje de excepción, pero no el seguimiento de pila.
- Los registros del agente (C:\Program Files\Server Backup Agent\log\cdp.log) indican que se recibieron comandos del servidor. Ten en cuenta que, lamentablemente, esto podría no ser un indicador explícito de compromiso, ya que podría tratarse de un comportamiento normal.
- Cabe destacar que el servidor Server Backup Manager SE no registra las solicitudes HTTP de forma predeterminada... pero si el administrador tiene un proxy delante del servidor que registra las solicitudes y captura las URL solicitadas, podrías ver actividad que envía repetidamente datos a /zkau/upload y/o un parámetro de consulta nextURI (que nunca debería usarse). Esto activa la vulnerabilidad inicial de ZK.
Es importante tener en cuenta que la vulnerabilidad ascendente de ZK no solo afecta a R1Soft, sino a cualquier aplicación que utilice una versión sin parchear del framework ZK. El acceso que un atacante puede obtener al usar esta vulnerabilidad de omisión de autenticación es específico de la aplicación que se explota; sin embargo, existe un riesgo serio de que otras aplicaciones se vean afectadas de forma similar a R1Soft Server Backup Manager. Huntress está trabajando de cerca con nuestros socios de DIVD para continuar con la búsqueda más amplia y ayudar a proteger otras aplicaciones ZK que están en riesgo.
Cronología completa
- Mayo de 2022: Markus Wulftange, de Code White GmbH, revela la omisión de autenticación de ZK
- Julio de 2022: Florian Hauser, de Code White GmbH, intenta reportarlo a ConnectWise
- 14 de octubre de 2022: Florian Hauser adelanta capturas de pantalla de la omisión de autenticación inicial en Twitter
- 16 de octubre de 2022: los investigadores de seguridad de Huntress recrean la prueba de concepto de la omisión de autenticación
- 17 de octubre de 2022: los investigadores de seguridad de Huntress amplían el exploit para lograr la ejecución remota de código
- 18 de octubre de 2022: Jason Slagle presenta a los investigadores de seguridad de Huntress a ConnectWise por correo electrónico
- 20 de octubre de 2022: los investigadores de seguridad de Huntress se reúnen con ConnectWise para demostrar la RCE
- 28 de octubre de 2022: ConnectWise publica un aviso de seguridad y un parche
- 31 de octubre de 2022: se publica el informe de Huntress
