28 de octubre de 2024Ravie LakshmananVulnerabilidad/Seguridad de Windows Se podría utilizar una nueva técnica de ataque para eludir Driver Signature Enforcement (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 controles de seguridad, ocultar procesos y actividad de red, mantener el sigilo y mucho más”, dijo el investigador de SafeBreach, Alon Leviev, 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ían usarse como arma para revertir un software de Windows actualizado a una versión anterior. que contiene 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 completamente indetectables, persistentes e irreversibles en 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 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. ItsNotASecurityBoundary fue documentado por primera vez por el investigador de Elastic Security Labs, Gabriel Landau, en julio de 2024 junto con PPLFault, y los describió 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 un archivo de catálogo de seguridad verificado 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 ci.dll en modo kernel, luego 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 núcleo. 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 análisis 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 última instancia, los pasos de explotación que un atacante debe seguir se encuentran a continuación: Desactivar VBS en el Registro de Windows o invalidar SecureKernel.exe Degradar ci.dll a la versión sin parches Reiniciar la máquina Explotar la omisión de DSE ItsNotASecurityBoundary para lograr la ejecución de código a nivel de kernel El único El 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”, 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 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 deben 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. ¿Encontró interesante este artículo? Síganos en Twitter  y LinkedIn para leer más contenido exclusivo que publicamos.