Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CVE-2022-45451 — PoC para Acronis Lectura Arbitraria de Archivos - CVE-2022-45451 | Kitploit
Herramientas/GitHubGitHub/alfarom256/cve-2022-45451
Escalada de PrivilegiosAnálisis de VulnerabilidadesAnálisis de CódigoExplotaciónAnálisis de Binarios
GitHubalfarom256/cve-2022-45451

CVE-2022-45451

PoC para Acronis Lectura Arbitraria de Archivos - CVE-2022-45451

Ver Repositorio
1867hace 3 añosAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

Introducción

Especificaciones del sistema:
  • Windows 10 1809 x64 EN
Objetivo:
  • Acronis Home Cyber Protect
  • Acronis Cyber Protect

Descripción de la vulnerabilidad

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:

  • Lectura arbitraria de archivos
  • Modificación de claves de registro sensibles (no explotada, condiciones de activación desconocidas) que podría conducir a la ejecución local de código

Lectura arbitraria de archivos

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:

  • el primer DWORD debe coincidir con un valor de cabecera esperado "TrMs" (Línea 37)
  • el segundo DWORD debe contener la longitud de los contenidos del mensaje (nota: esto es diferente y distinto de InputBufferLength)
  • la longitud del contenido del mensaje debe ser menor o igual que el tamaño total del búfer de entrada menos el tamaño de la cabecera del mensaje
    • La cabecera del mensaje se compone de la cabecera y el tamaño, y otro valor desconocido que totaliza 0xC (12) bytes

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

Posible inyección de código

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

Descargar herramienta