Podría usarse para secuestrar el proceso de actualización de Windows
Se podría utilizar una nueva técnica de ataque para evadir la Implementación de Firma de Controlador (DSE) de Microsoft en sistemas Windows con todos los parches instalados, lo que daría lugar a ataques de degradación del sistema operativo (OS).
"Este bypass permite cargar controladores de kernel no firmados, lo que permite a los atacantes implementar rootkits personalizados que pueden neutralizar controles de seguridad, ocultar procesos y actividad de red, mantener el sigilo y mucho más", dijo en un informe el investigador de SafeBreach, Alon Leviev.
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ían usarse para revertir un software de Windows actualizado a una versión anterior que contenga vulnerabilidades de seguridad sin parchear.
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 para crear versiones inferiores totalmente indetectables, persistentes e irreversibles de componentes críticos del sistema operativo.
Esto puede tener graves ramificaciones, ya que ofrece a los atacantes una mejor alternativa a los ataques Bring Your Own Vulnerable Driver (BYOVD), permitiéndoles degradar 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 de DSE "ItsNotASecurityBoundary" en un sistema Windows 11 completamente actualizado.
ItsNotASecurityBoundary fue 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 el nombre en código False File Immutability. Microsoft lo solucionó a principios de mayo.
En pocas palabras, explota una condición de carrera para reemplazar un archivo de catálogo de seguridad verificado con una versión maliciosa que contiene la firma authenticode para un controlador de kernel no firmado, después de lo cual el atacante solicita al kernel que cargue el controlador.
El mecanismo de integridad de código de Microsoft, que se utiliza para autenticar un archivo mediante la biblioteca de modo kernel ci.dll, luego analiza el catálogo de seguridad fraudulento para validar la firma del controlador y cargarlo, lo que otorga efectivamente al atacante la capacidad de ejecutar código arbitrario en el kernel.
La omisión de DSE se logra haciendo uso de la herramienta de degradación para reemplazar la biblioteca "ci.dll" con una versión más antigua (10.0.22621.1376.) para deshacer el parche implementado por Microsoft.
Dicho esto, existe una barrera de seguridad que puede impedir que dicha maniobra tenga éxito. Si se está ejecutando la seguridad basada en virtualización (VBS) en el host de destino, el escaneo del catálogo lo realiza la DLL de integridad de código de kernel seguro (skci.dll), en lugar de ci.dll.
Sin embargo, cabe señalar que la configuración predeterminada es VBS sin un bloqueo de interfaz de firmware extensible unificada (UEFI). Como resultado, un atacante podría desactivarla 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 por uno no válido. En definitiva, los pasos de explotación que debe seguir un atacante son los siguientes:
Desactivación de VBS en el Registro de Windows o invalidación de SecureKernel.exe
Desactualización de ci.dll a la versión sin parches
Reinicio de la máquina
Explotación de la omisión de DSE 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 una bandera "Obligatorio", la última de las cuales provoca un error de arranque cuando los archivos VBS están dañados. El modo Obligatorio se habilita manualmente mediante un cambio en el registro.
"La configuración obligatoria evita que el cargador del sistema operativo continúe iniciando en caso de que el hipervisor, el kernel seguro o uno de sus módulos dependientes no se puedan cargar", señala Microsoft 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 por completo el ataque, es esencial que VBS esté habilitado con el bloqueo UEFI y la bandera Mandatory establecida. En cualquier otro modo, permite que un adversario desactive la función de seguridad, realice la degradación de DDL y logre una omisión de DSE.
"La principal conclusión 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.
