
PoC para Acronis Lectura Arbitraria de Archivos - CVE-2022-45451
El controlador de escaneo antimalware "ngscan" de Acronis sufre de un control de acceso incorrecto / inadecuado aplicado al puerto de comunicación del filtro. El controlador minifilter admite las siguientes características que pueden ser explotadas:
El análisis del controlador ngscan.sys comenzó descompilando el controlador con Ida Pro. El investigador observó que, aunque se creó un objeto de dispositivo, no se crearon enlaces simbólicos para interactuar con el controlador mediante DeviceIoControl.
Por lo tanto, el análisis continuó observando las capacidades del Filter Communication Port.
Durante la inicialización, el controlador crea cinco (5) puertos de comunicación para admitir la interacción con otros procesos.

Fig. 1: Rutina que admite la creación de hasta cinco (5) puertos de comunicación de filtro (FCP)
Esta función fue observada siendo llamada, inicializando cada uno de los 5 FCP con un dacl predeterminado, siendo el último FCP creado con un dacl NULL.

Fig. 2: Creación de FCP con DACL predeterminado/NULL
El análisis continuó observando las funciones CreateNotifyCallback y MessageNotifyCallback especificadas por el controlador de filtro. Estas funciones de devolución de llamada se invocan cada vez que un proceso abre una conexión y envía un mensaje al puerto de comunicación.

La inspección inicial de MessageNotifyCallback mostró que el búfer del mensaje entrante debe cumplir los siguientes requisitos:
Una vez que las comprobaciones han pasado, se extrae un número de función del InputBuffer y se utiliza en los siguientes casos switch para seleccionar qué función ejecutar con la entrada proporcionada.

Fig. 3: Subconjunto de funciones admitidas por MessageNotifyCallback
Al inspeccionar cada una de las funciones admitidas, se mostraron dos funciones de interés para un posible abuso que conduzca a la lectura arbitraria de archivos.

Fig. 4: Funciones que admiten la creación de un contexto de escaneo y devuelven el manejador de archivo del contexto de escaneo (Líneas 206, 233)
Aunque la funcionalidad exacta de un "contexto de escaneo" no se conoce por completo, el análisis mostró que se puede crear un contexto de escaneo de archivo para cualquier archivo especificado en el InputBuffer del usuario. Una vez que se crea un contexto de escaneo, el ID del contexto de escaneo se devuelve al usuario en el búfer de salida.

Fig. 5: Rutina Create Scan Context que devuelve los datos del contexto de escaneo al usuario

Fig. 6: Datos enviados al controlador minifilter solicitando acceso al archivo de registro SAM protegido (\??\C:\Windows\System32\config\SAM)

Fig. 7: Respuesta del controlador minifilter que incluye el ID de contexto de escaneo (0x3aaf)
Una vez que se creó un contexto de escaneo y se recuperó el ID, se puede abrir un manejador al archivo para el cual fue creado el contexto de escaneo en la aplicación solicitante, enviando nuevamente un mensaje al puerto de comunicación.

Fig. 8: Recuperación del manejador de archivo del contexto de escaneo creado
La función designada como CreateFileReturnHandle0 solo se llamaba si la función anterior SearchScanContextsByID devolvía un contexto de escaneo válido.
P. ej., solo si el proceso solicitante proporcionaba un ID de contexto válido que fue creado previamente llamando a la función de creación de escaneo mencionada anteriormente.
El programa solicitante abrió con éxito un manejador al archivo privilegiado al proporcionar el ID de contexto de escaneo a la función especificada en la Figura 8 (Figura 4, Línea 233).

Fig. 9: Recuperación exitosa del manejador de archivo para el archivo SAM
Usando processhacker, se confirmó el acceso al manejador de archivo visualizando los manejadores del proceso solicitante:

Fig. 10: Proceso que contiene el manejador del archivo SAM

Fig. 11: Acceso de lectura concedido al manejador obtenido
Una exploración adicional de las funciones admitidas mostró el control de tres claves de registro que podrían aprovecharse para obtener ejecución de código.

Fig. 12: Funciones que admiten la apertura de manejadores a claves de registro

Fig. 13: Apertura de las claves de registro que especifican la dll de monitoreo de hooks a inyectar en un proceso

Fig. 14: Función OpenKey que demuestra la capacidad de modificar una clave de registro con datos controlados por el usuario
No se determinaron las circunstancias para la inyección de dll con fines de hooking por parte de la suite Acronis, aunque si el monitoreo de hooks está habilitado, se cree que la dll especificada por las claves de registro x64HookLib y x86HookLib se inyectaría en un proceso designado.

Fig. 15: x64HookLibKey que especifica la dll de hooking C:\ProgramData\Acronis\NGMP\shared\acr_protect.x64.dll