Vulnerabilidad crítica: SysAid CVE-2023-47246

El 8 de noviembre de 2023, SysAid publicó un aviso en el que indicó que su software de servidor on-prem tenía una vulnerabilidad previamente no revelada y que tienen conocimiento de explotación pública activa. Días antes, Microsoft había notificado a SysAid sobre este problema y había atribuido estos compromisos a TA505 “Lace Tempest”, a menudo conocido como la banda de ransomware cl0p.

Huntress investigó intrusiones recientes dentro de los entornos de nuestros socios, notificó a las organizaciones afectadas y recreó la cadena de ataque con un exploit de prueba de concepto para desarrollar nuevas capacidades de detección para nuestra plataforma de seguridad administrada.

Actualmente, la última versión de SysAid Server 23.3.36 es el parche y la actualización recomendados, y te recomendamos encarecidamente instalarlos lo antes posible.

Esta vulnerabilidad crítica se designó con el identificador CVE-2023-47246. El adversario cl0p es el mismo actor de amenazas que aprovechó el software MOVEit Transfer durante el fin de semana de Memorial Day de este año.

La vulnerabilidad

El boletín de seguridad original de SysAid se refiere a esta vulnerabilidad como una “vulnerabilidad de path traversal previamente desconocida que provoca la ejecución de código dentro del software on-prem de SysAid.” El boletín de seguridad no incluye detalles técnicos sobre esta vulnerabilidad ni cómo explotarla, pero sí incluye indicadores técnicos de compromiso para el problema de seguridad.

Específicamente, hace referencia a la posibilidad de que los atacantes suban y accedan a webshells en archivos WAR y otras cargas útiles en el webroot del servidor web Apache Tomcat de SysAid. También hace referencia a la ruta completa de una webshell ubicada enC:\Program Files\SysAidServer\tomcat\webapps\usersfiles\en un servidor comprometido.

Si bien el informe original no incluía detalles técnicos de explotación, el equipo de investigación de Huntress logró crear una prueba de concepto totalmente armada. La explotación de esta vulnerabilidad se describe con más detalle en la sección Prueba de concepto de explotación de esta publicación de blog.

El impacto

Huntress solo está rastreando 14 servidores en toda nuestra base de socios con el software SysAid instalado. Lamentablemente, estos servidores ejecutan una amplia gama de números de versión distintos: algunos tan recientes como el 23.3.34, un puñado en el rango anual de versiones 16.x o 17.x, y algunos tan antiguos como las versiones 7.5.0 y 7.0.0 (P. D.: ¡actualiza, por favor!)

Observamos que solo una de estas instancias estaba activamente comprometida con el exploit de día cero.

Figura 1: Detección de proceso de PowerShell codificado

Esta organización se vio afectada por primera vez el 30 de octubre, donde observamos la ejecución del mismo código PowerShell posterior a la explotación sugerido en el aviso de SysAid. Nuestros detectores identificaron la invocación inusual de PowerShell (un proceso secundario generado bajo java.exe), pero no quedó claro hasta la divulgación pública de CVE-2023-47246 que esto estaba relacionado con esta amenaza.

En el momento de esta explotación, hubo dos invocaciones de PowerShell relevantes: el primer evento decodificado en Base64 y desofuscado se puede encontrar aquí:


Esto coincide con la etapa original descrita por SysAid y Profero:

  • Almacena las rutas del sistema de archivos para el directorio raíz de aplicaciones web de Tomcat, así como la carpeta userfiles creada por el adversario, como variables
  • Enumera los procesos en ejecución con tasklist, y usa expresiones regulares para identificar cualquier proceso que comience con “Sophos” y que incluya .exe en el nombre del ejecutable
  • Si se encuentra algún proceso que coincida con este criterio, este código de PowerShell elimina artefactos y sale, para evitar la detección.
  • Vale la pena destacar que este código no usa su privilegio para matar el proceso, simplemente detiene su rutina.
  • Si ningún proceso coincide con este criterio, invoca un archivo user.exe que el actor de amenazas colocó dentro de su directorio de preparación userfiles.
  • Cabe destacar que esto incluye un argumento de línea de comandos y un parámetro de una cadena hexadecimal de 64 caracteres. No vimos esto mencionado en el informe de SysAid ni en el de Profero, pero probablemente sea un número de identificación de la víctima, o una clave única usada por el ejecutable (GraceWire)
  • Espera un segundo, y elimina el stager userfiles.war y los artefactos user.exe

A continuación, observamos la ejecución del segundo fragmento de PowerShell (decodificado en Base64 y embellecido):


Esto prepara más código de PowerShell para ejecutarse dentro de una cadena multilínea. Nuevamente almacena rutas de sistema de archivos relevantes en variables, pero luego define expresiones regulares que se usan para eliminar evidencia de la explotación.  Estas variables $log4jPattern y $tcPattern incluyen componentes opcionales que se buscan dentro de los archivos de registro del servidor SysAid o los registros de Tomcat, los cuales luego son eliminados por la función cleanLL, que elimina cualquier entrada de registro con esas cadenas.

Si bien puede ser un truco ingenioso para que el adversario borre sus huellas, esto también deja algunas pistas que ayudan a explicar cómo se ejecuta este exploit. Exploraremos esto con más detalle en la sección Prueba de concepto de explotación a continuación.

Este código de limpieza de registros se ejecuta en un bucle while después de algunos comandos de espera para asegurar que los archivos se eliminen, y luego sale del bucle. En última instancia, todo esto se invoca mediante el clásico cmdlet Invoke-Expression.

Superficie de ataque

Una consulta en Shodan para el título predeterminado de los servidores SysAid devuelve más de 230 instancias accesibles en internet público. Una consulta distinta en Shodan para cualquier referencia a SysAid en el HTML de la página analizada devuelve poco menos de 900 resultados.

Figura 2: Resultados de Shodan para cualquier instancia de SysAid en el cuerpo del HTML analizado

Si bien esto no demuestra la explotabilidad de cada uno de estos servidores públicos, sí muestra la prevalencia de esta tecnología en internet. Aunque estas consultas muestran que SysAid no suele estar expuesto a internet, podría estarlo en algunos casos, y les recomendamos a nuestros lectores identificar si sus servidores SysAid son accesibles públicamente.

Prueba de concepto de explotación

El equipo de Huntress Research pudo crear una prueba de concepto armada para explotar la vulnerabilidad de path traversal y escritura de archivos. Por el momento, no estamos publicando esta prueba de concepto.

La vulnerabilidad existe en el método doPost dentro de la clase com.ilient.server.UserEntry de SysAid. Al inyectar un path traversal en el parámetro accountID y proporcionar un webshell en formato WAR comprimido con zlib como cuerpo de la solicitud POST, un atacante puede controlar dónde se escribe este webshell en el servidor vulnerable. Luego, el atacante puede solicitar el webshell navegando a la URL donde ahora reside para obtener acceso al servidor.

Figura 3: Carga exitosa del webshell y ejecución de código contra el servidor SysAid

El equipo de Huntress Research identificó el componente vulnerable descompilando los archivos de clase de Java y examinando el diferencial del parche entre la versión 23.3.35 y la 23.3.36. La última versión del software contiene la siguiente verificación en el método doPost de la clase UserEntry:

Figura 4: el nuevo mensaje de error en la salida descompilada de la versión parcheada

Este nuevo mensaje de error implica la existencia de una vulnerabilidad de path traversal relacionada con la variable a2. Esta variable se construye a partir de la variable convertParameter, que a su vez se asigna desde el parámetro accountID de la solicitud POST, como se muestra en la línea 385 del siguiente fragmento de código:

Figura 5: los parámetros de la solicitud POST entrante en la clase UserEntry

El parámetro accountID construye la ruta donde se escribirá el archivo cargado. Al inyectar este parámetro con un path traversal, podemos ajustar dónde se escribe este archivo. En la línea 421, se crea un nuevo archivo en la ubicación especificada por la cadena a2. Después de crear el archivo, los bytes del inflaterInputStream de la solicitud POST entrante se escriben en esta ubicación:

Figura 6: la creación de un nuevo archivo según los parámetros del POST

Al controlar la ubicación del archivo y los bytes que se escriben, podemos escribir los bytes de un archivo WAR malicioso en el directorio raíz del servidor web. Luego podemos acceder a este archivo WAR navegando o solicitando el URI del archivo WAR para obtener acceso al servidor.

Nuestra prueba de concepto recreada coincide con los indicadores observados en los boletines originales del equipo de Microsoft Threat Intelligence y de SysAid.

Huntress ha agregado detecciones para la actividad reportada en este blog. Si quieres que alguien más vigile tu espalda mientras trabajas en aplicar el parche, no dudes en iniciar una prueba gratuita con nosotros para que nuestro SOC, disponible 24/7, esté atento por ti.

Agradecimiento especial a Matt Kiely, John Hammond, Caleb Stewart, Dave Kleinatland, Harlan Carvey, Joe Slowik, Matt Anderson, Jamie Levy y muchos otros por sus contribuciones a este informe.

Indicadores de compromiso

También te podría interesar