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 que pueden neutralizar los controles de seguridad, ocultar procesos y actividad de red, mantener el sigilo y mucho más”, dijo el investigador de SafeBreach, Alon Leviev. dicho en un informe compartido con The Hacker News.
Los últimos hallazgos se basan en un análisis anterior que descubrió dos fallas de escalada de privilegios en el proceso de actualización de Windows (CVE-2024-21302 y CVE-2024-38202) que podría utilizarse como arma para revertir un 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 denominada Windows Downdate, que, según Leviev, podría usarse para secuestrar el proceso de actualización de Windows y crear degradaciones totalmente 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) ataqueslo que les permite degradar los módulos propios, incluido el propio kernel del sistema operativo.
Posteriormente, Microsoft abordó 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 ideado por Leviev aprovecha la herramienta de degradación para degradar el parche de omisión DSE “ItsNotASecurityBoundary” en un sistema Windows 11 completamente actualizado.
Su límite de seguridad no era documentado por primera vez por el investigador de Elastic Security Labs Gabriel Landau en julio de 2024 junto con PPLFault, describiéndolos como una nueva clase de error con nombre en código False File Immutability. Microsoft lo solucionó a principios de mayo.
En pocas palabras, aprovecha una condición de carrera para reemplazar una verificada. archivo de catálogo de seguridad con una versión maliciosa que contiene una firma de código de autenticación para un controlador de kernel sin firmar, tras lo cual el atacante solicita al kernel que cargue el controlador.
El mecanismo de integridad del código de Microsoft, que se utiliza para autenticar un archivo utilizando la biblioteca en modo kernel. ci.dllluego analiza el catálogo de seguridad fraudulento para validar la firma del controlador y cargarlo, otorgando efectivamente 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 el parche implementado 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, vale la pena señalar que la configuración predeterminada es VBS sin bloqueo de interfaz de firmware extensible unificada (UEFI). Como resultado, 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 una contraparte no válida. En ultima instancia, los pasos de explotacion que debe seguir un atacante se encuentran a continuacion:
- Desactivar VBS en el Registro de Windows o invalidar SecureKernel.exe
- Degradar ci.dll a la versión sin parchear
- Reiniciar la máquina
- Explotación de la omisión de DSE de ItsNotASecurityBoundary para lograr la ejecución de código a nivel de kernel
El único caso en el que falla es cuando VBS se activa con un bloqueo UEFI y un indicador “Obligatorio”, el último de los cuales provoca una falla en el arranque cuando los archivos VBS están dañados. El modo Obligatorio se habilita manualmente mediante un cambio de registro.
“La configuración Obligatoria impide que el cargador del sistema operativo continúe arrancándose en caso de que el hipervisor, el kernel seguro o uno de sus módulos dependientes no se cargue”, Microsoft notas en su documentación. “Se debe tener especial cuidado antes de habilitar este modo, ya que, en caso de cualquier fallo de los módulos de virtualización, el sistema se negará a arrancar.”
Por lo tanto, para mitigar completamente el ataque, es esencial que VBS esté habilitado con el bloqueo UEFI y el indicador Mandatorio configurado. En cualquier otro modo, hace posible que un adversario desactive la función de seguridad, realice la degradación de DDL y logre una omisión de DSE.
“La conclusión principal […] es que las soluciones de seguridad deberían intentar detectar y prevenir procedimientos de degradación incluso para componentes que no cruzan límites de seguridad definidos”, dijo Leviev a The Hacker News.