Se podría utilizar una nueva técnica de ataque para eludir la aplicación de la firma del controlador (DSE) de Microsoft en sistemas Windows completamente parcheados, lo que provocaría ataques de degradación del sistema operativo (SO).
“Esta omisión permite cargar controladores de kernel no firmados, lo que permite a los atacantes implementar rootkits personalizados capaces de anular los controles de seguridad, ocultar procesos y actividad de la red, mantener el sigilo y mucho más”, dijo Alon Leviev, investigador de SafeBreach. dicho en un informe compartido con The Hacker News.
Los últimos hallazgos se basan en un análisis anterior que reveló dos fallas de escalada de privilegios en el proceso de actualización de Windows (CVE-2024-21302 Y CVE-2024-38202) que podría usarse para restaurar software de Windows actualizado a una versión anterior que contenga vulnerabilidades de seguridad sin parches.
El exploit se materializó en forma de una herramienta llamada Windows Downdate, que según Leviev podría usarse para secuestrar el proceso de actualización de Windows y crear actualizaciones completamente indetectables, persistentes e irreversibles en componentes críticos del sistema operativo.
Esto puede tener graves consecuencias, ya que ofrece a los atacantes una mejor alternativa que Bring Your Own Vulnerable Driver (BYOVD) ataquespermitiéndoles degradar módulos propietarios, incluido el propio kernel del sistema operativo.
Luego, Microsoft parchó CVE-2024-21302 y CVE-2024-38202 el 13 de agosto y el 8 de octubre de 2024, respectivamente, como parte de las actualizaciones del martes de parches.
El último enfoque diseñado por Leviev aprovecha la herramienta de degradación para degradar el parche de solución de EHR “ItsNotASecurityBoundary” en un sistema Windows 11 completamente actualizado.
Su límite de seguridad no era documentado por primera vez por Gabriel Landau, investigador de Elastic Security Labs, en julio de 2024 junto con PPLFault, describiéndolos como una nueva clase de errores llamados False File Immutability. Microsoft solucionó esto a principios de mayo.
En pocas palabras, aprovecha una condición de carrera para reemplazar un archivo de catálogo de seguridad con una versión maliciosa que contiene una firma Authenticode para un controlador de kernel sin firmar, después de lo cual el atacante le pide al kernel que cargue el controlador.
Mecanismo de integridad del código de Microsoft, utilizado para autenticar un archivo utilizando la biblioteca en modo kernel ci.dllluego escanea el catálogo de seguridad malicioso para validar la firma del controlador y cargarlo, otorgando al atacante la capacidad de ejecutar código arbitrario en el kernel.
La omisión de DSE se logra utilizando la herramienta de degradación para reemplazar la biblioteca “ci.dll” con una versión anterior (10.0.22621.1376.) para deshacer la solución implementada por Microsoft.
Dicho esto, existe una barrera de seguridad que puede impedir que dicha derivación tenga éxito. Si la seguridad basada en virtualización (VBS) se está ejecutando en el host de destino, el escaneo del catálogo lo realiza la DLL Secure Kernel Code Integrity (skci.dll), a diferencia de ci.dll.
Sin embargo, cabe señalar que la configuración predeterminada es VBS sin bloqueo UEFI (Interfaz de firmware extensible unificada). Por lo tanto, un atacante podría desactivarlo alterando las claves de registro EnableVirtualizationBasedSecurity y RequirePlatformSecurityFeatures.
Incluso en los casos en los que el bloqueo UEFI está habilitado, el atacante podría desactivar VBS reemplazando uno de los archivos principales con un par no válido. En última instancia, los pasos de explotación que debe seguir un atacante son:
- Deshabilite VBS en el Registro de Windows o invalide SecureKernel.exe
- Degradar ci.dll a una versión sin parche
- Reiniciar la máquina
- Aproveche la omisión de DSE ItsNotASecurityBoundary para lograr la ejecución de código a nivel de kernel
El único caso de error es cuando VBS está habilitado con un bloqueo UEFI y un indicador “Obligatorio”, este último provoca un error de arranque cuando los archivos VBS están dañados. El modo obligatorio se habilita manualmente mediante una edición del registro.
“La configuración Obligatoria impide que el cargador del sistema operativo continúe iniciándose si el hipervisor, el kernel seguro o uno de sus módulos dependientes no se carga”, Microsoft Observaciones en su documentación. “Se debe tener especial cuidado antes de activar este modo, porque en caso de fallo de los módulos de virtualización, el sistema se negará a iniciarse”.
Por lo tanto, para mitigar completamente el ataque, es esencial que VBS esté habilitado con el bloqueo UEFI y el indicador obligatorio establecido. En cualquier otro modo, permite a un adversario desactivar la función de seguridad, realizar una degradación de DDL y omitir el DSE.
“El punto principal a recordar […] es que las soluciones de seguridad deberían intentar detectar y prevenir procedimientos de degradación, incluso para componentes que no cruzan los límites de seguridad definidos”, dijo Leviev a The Hacker News.