ACTUALIZACIÓN: Lee nuestro análisis completo de CVE-2024-1709 y CVE-2024-1708 y la guía de detección aquí.
El 19 de febrero de 2024, ConnectWise publicó un aviso relacionado con la divulgación de dos vulnerabilidades que afectan su software ScreenConnect. ConnectWise etiquetó este aviso con una gravedad de "Crítica" y una prioridad de "1 - Alta".
El equipo de Huntress pudo reproducir y convertir en arma con éxito la vulnerabilidad para CWE-288 Omisión de autenticación mediante una ruta alternativa de canal. La prueba de concepto (POC) para esta vulnerabilidad se recreó con facilidad y requirió un conocimiento técnico y recursos mínimos. Dado esto, Huntress publicó de inmediato una entrada sobre esta vulnerabilidad y su posible impacto. Si bien Huntress recomienda encarecidamente actualizar de inmediato cualquier software de ConnectWise a la versión 23.9.8, a continuación se presenta una guía de detección para la defensa en profundidad.
Al ejecutar la POC, Huntress examinó el archivo User.xml ubicado en: C:\Program Files (x86)\ScreenConnect\App_Data\. El contenido de este archivo puede incluir lo siguiente:
<?xml version="1.0"?>
<Users xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<User>
<CreationDate>[IMPACT-TIMESTAMP]</CreationDate>
<Email>[email protected]</Email>
<IsApproved>true</IsApproved>
<IsLockedOut>false</IsLockedOut>
<LastActivityDate>0001-01-01T00:00:00</LastActivityDate>
<LastLockoutDate>0001-01-01T00:00:00</LastLockoutDate>
<LastLoginDate>0001-01-01T00:00:00</LastLoginDate>
<LastPasswordChangedDate>[IMPACT-TIMESTAMP]</LastPasswordChangedDate>
<PasswordAttemptWindowStartTime>0001-01-01T00:00:00>/PasswordAttemptWindowStartTime>
<InvalidPasswordWindowAttemptCount>0</InvalidPasswordWindowAttemptCount>
<InvalidPasswordAbsoluteAttemptCount>0</InvalidPasswordAbsoluteAttemptCount>
<Name>Administrator</Name>
<PasswordHashHistory>
<base64Binary>[REDACTED-BASE64]</base64Binary>
</PasswordHashHistory>
<Roles>
<string>Control Administrator</string>
</Roles>
</User>
</Users>
Ten en cuenta que las marcas de tiempo 0001-01-01T00:00:00 indican que aún no hay un valor coherente todavía. Cuando se acaba de crear un usuario nuevo, todavía no tiene un LastLoginDate ni un LastActivityDate.
Para que quede claro, este archivo User.xml se modificará cada vez que cualquier usuario realice cualquier actividad. Esto se verificó mediante Process Monitor, que mostró que este archivo User.xml se sobrescribía después de cada intento exitoso. Esto dificulta la identificación definitiva de la explotación, pero, lamentablemente, en nuestra investigación encontramos opciones limitadas de registro y artefactos forenses en un servidor de ScreenConnect. Si el usuario recién creado llegara a iniciar sesión, las marcas de tiempo, por supuesto, se actualizarían. Si las marcas de tiempo no están en cero, esto indicaría que el usuario efectivamente inició sesión en la instancia recientemente.
Es importante señalar que el archivo <random_value>.xml en C:\Windows\Temp\ScreenConnect\23.9.7.8804\ se crea en el disco, pero se elimina de inmediato. El GUID en el nombre del archivo parece ser único para cada instancia. Sin embargo, estos archivos se pueden recuperar mediante análisis forense de disco, lo que puede ayudarte a recuperar actividades previas del atacante.
Al configurar la política de auditoría avanzada de un servidor para registrar un evento exitoso Windows Event ID 4663 y con una SACL configurada en el directorio, podemos ver cuándo se modifica el archivo.
Este evento se puede reenviar a un SIEM, y con el contenido del archivo User.xml en sí, tenemos un mayor nivel de contexto para examinar si ha ocurrido un ataque.
Los artefactos mencionados anteriormente se pueden revisar con fines de DFIR/caza de amenazas si un atacante aprovechó este exploit contra un sistema objetivo, para ver si se creó una cuenta fuera de los procedimientos operativos normales. Sin embargo, los artefactos por sí solos podrían no ser suficientes para una indicación definitiva ni ofrecer suficiente contexto para el análisis y la clasificación que confirme que se aprovechó el exploit.
Además de los artefactos mencionados en este blog, también observamos evidencia de la ejecución del exploit dentro de los registros de IIS. Por ahora, nos abstendremos de mostrar el contenido de estas entradas de registros de IIS hasta que hayamos visto explotación activa, ya que hacerlo revelaría nuestra estrategia a los atacantes.
¡Feliz caza!
Mantente atento para más detalles a medida que esto se desarrolle.
Agradecimiento especial a John Hammond, Caleb Stewart, Dave Kleinatland, Andrew Schwartz, Jason Phelps, Jai Minton, Tim Kasper, Andrew Kaiser, Jason Slagle, Jamie Levy, y a muchos otros por sus contribuciones a este artículo.
