Introducción
Bring Your Own Vulnerable Driver (BYOVD) es una técnica de ataque cada vez más popular en la que un actor de amenazas trae un controlador firmado vulnerable conocido junto con su malware, lo carga en el kernel y luego lo explota para realizar alguna acción dentro del kernel que de otro modo no podría hacer. Luego de lograr el acceso al kernel, pueden manipular o deshabilitar el software de seguridad, volcar credenciales que de otro modo serían inaccesibles o modificar el comportamiento del sistema operativo para ocultar su presencia. Joe Desimone y yo cubrimos esto en profundidad, entre otras amenazas del modo kernel, en Black Hat USA 2018. Empleado por actores de amenazas avanzadas durante más de una década, BYOVD se está volviendo cada vez más común en ransomware y malware básico.
Driver Signing Enforcement (DSE), implementado por primera vez en 2007 por Windows Vista x64, fue la primera vez que Microsoft intentó limitar el poder de los administradores. Con DSE en su lugar, los administradores ya no podían cargar instantáneamente ningún código en el kernel. Las restricciones de administración crecieron con el tiempo con el lanzamiento de Boot Guard, Secure Boot y Trusted Boot para proteger la cadena de arranque del malware de administración, que anteriormente podía instalar sus propios cargadores de arranque / bootkits.
Limitando aún más el poder de los administradores, Microsoft implementó recientemente la lista de bloqueo de controladores vulnerables de forma predeterminada, a partir de Windows 11 22H2. Este es un movimiento en la dirección correcta, lo que hace que Windows 11 más seguro de forma predeterminada. Desafortunadamente, el modelo de implementación de la lista de bloqueo puede ser lento para adaptar a las nuevas amenazas, ya que las actualizaciones se implementan automáticamente generalmente solo una o dos veces al año. Los usuarios pueden actualizar manualmente sus listas de bloqueo, pero tales intervenciones nos sacan del territorio de "seguro por defecto".
Límites de seguridad
A la hora de determinar qué vulnerabilidades corregir, el Centro de respuestas de seguridad de Microsoft (MSRC) emplea el concepto de límite de seguridad, que define de la siguiente manera:
Un límite de seguridad proporciona una separación lógica entre el código y los datos de los dominios de seguridad con diferentes niveles de confianza. Por ejemplo, la separación entre el modo kernel y el modo de usuario es un límite de seguridad tradicional y sencillo.
Sobre la base de esta definición, uno podría inclinar a pensar que el malware que se ejecuta en modo de usuario no debería ser capaz de modificar la memoria del kernel. Al fin y al cabo, el límite es "sencillo". Lógicamente, cualquier violación de ese límite debe ser respondida con una acción correctiva, como un parche o una actualización de la lista de bloqueo.
Desafortunadamente, la situación se vuelve más turbia a partir de aquí. Ese documento establece más adelante que administrator-to-kernel no es un límite de seguridad, con la siguiente explicación:
Los procesos administrativos y los usuarios se consideran parte de la Trusted Computing Base (TCB) para Windows y, por lo tanto, no son fuertes [sic] aislados del límite del kernel.
Llegados a este punto, tenemos dos puntos de vista aparentemente contradictorios. Por un lado, MSRC afirma que admin-to-kernel es un límite indefendible y que no vale la pena arreglarlo. Por otro lado, Microsoft está intentando defender este límite con mecanismos como la aplicación de la firma de controladores, el arranque seguro y la lista de bloqueo de controladores vulnerables. Debido a que la defensa está incompleta, MSRC las llama "características de seguridad de defensa en profundidad".
De manera similar, MSRC no considera que la conexión de administrador aPPL sea un límite de seguridad, sino que la clasifica como una característica de seguridad de defensa en profundidad. Más sobre esto en la siguiente sección.
En el resto de este artículo se hará referencia a MSRC y Microsoft por separado. Si bien MSRC es parte de Microsoft, Microsoft es una entidad mucho más grande que MSRC; no deben ser equiparados.
Explotación de vulnerabilidades
En septiembre de 2022, presenté VULN-074311 ante MSRC, notificándoles de dos vulnerabilidades de día cero en Windows: una de administrador a PPL y otra de PPL a kernel. Proporcioné el código fuente de ambos exploits. La respuesta indicó de manera concisa que entendían las vulnerabilidades y se negaron a tomar más medidas, como se indica a continuación:
La investigación describe un ataque de varios pasos que aprovecha una omisión de PPL para obtener la ejecución del código del kernel. Tenga en cuenta que todos los ataques propuestos requieren privilegios administrativos para realizar y, por lo tanto, el problema informado no cumple con nuestro estándar de servicio inmediato. No esperamos ninguna otra acción y procederemos a cerrar el caso.
En este lenguaje, "servicio" significa "parcheo". Su respuesta es coherente con la política mencionada anteriormente y su tratamiento histórico del límite entre el administrador y el kernel. Su comportamiento también es consistente: pasaron más de 11 meses y todavía no han parcheado ninguna de las vulnerabilidades. Me parece fascinante que Microsoft esté dispuesto a bloquear los controladores que pueden modificar la memoria del kernel, pero MSRC no está dispuesto a atender las vulnerabilidades que pueden hacer lo mismo.
Cuando anuncié mi charla 2023 Black Hat Asia, PPLdump Is Dead. Long Live PPLdump, en Twitter cinco meses luego del reporte de MSRC, el equipo de Windows Defender se puso en contacto rápidamente para obtener más información. Parece que MSRC cerró el caso sin informar al equipo de Defender, cuyos productos dependen de PPL para proteger cientos de millones de máquinas Windows, sobre una omisión de PPL. No se debe permitir que este tipo de falta de comunicación continúe.
Utillaje llave en mano
EDRSandBlast es una herramienta que emplea controladores vulnerables como arma para eludir el software AV y EDR. Puede modificar la memoria del kernel para eliminar los ganchos instalados por AV y EDR, cegándolos temporal o permanentemente a la actividad maliciosa en el sistema.
Como comenté en mi charla de Black Hat Asia, MSRC demostró de facto que no están dispuestos a atender las vulnerabilidades de administrador a PPL y de administrador a kernel y que se requiere la existencia de herramientas llave en mano en GitHub para motivar a Microsoft a actuar. Esto me llevó a lanzar el exploit PPLFault de administrador a PPL y la cadena de exploits de administrador a kernel GodFault como herramientas fáciles de usar en GitHub. Para abreviar, a continuación los llamaremos "vulnerabilidad PPL" y "vulnerabilidad del kernel", respectivamente.
Con este mismo espíritu de "herramientas llave en mano", para resaltar la inconsistencia de bloquear controladores vulnerables conocidos y, al mismo tiempo, negar a parchear las cadenas de exploits del administrador al kernel, estoy lanzando una versión de EDRSandBlast que integra PPLFault para demostrar el mismo resultado, sin controladores vulnerables. Puedes verlo aquí desactivando el controlador de Windows Defender. Mi objetivo al publicar esto es motivar a MSRC a tratar las vulnerabilidades PPL y del kernel con mayor urgencia.
Mitigación
Lancé un pequeño controlador del kernel junto con PPLFault y GodFault llamado NoFault que rompe el exploit PPL. Hasta que se arregle Windows, los proveedores de antimalware pueden emplear este código para mitigar la vulnerabilidad PPL. Incorporamos la protección de NoFault en la última versión de Elastic Endpoint/Defend - actualiza a 8.9.0+ si aún no lo hiciste. Una solución completa podría ser hacer que el administrador de memoria aplique hashes de página para todas las imágenes ejecutables cargadas en PPL, una característica que ya se emplea para procesos protegidos completos.
GodFault no es la primera herramienta que explota la vulnerabilidad del kernel. ANGRYORCHARD lo usó por primera vez con la vulnerabilidad PPL KnownDLLs ahora parcheada. Desde entonces, la vulnerabilidad PPL se corrigió, pero la del kernel no. Pude reutilizar fácilmente la vulnerabilidad del kernel en GodFault: son solo unas pocas líneas de código. Si esto no se soluciona, cualquier exploit futuro de PPL se podrá encadenar inmediatamente al kernel. Tenga en cuenta que NoFault rompe la cadena de exploits del kernel al impedir la ejecución de código PPL requerido, pero no corrige la vulnerabilidad del kernel en sí.
Discusión
Hacer que EDRSandBlast sea sin controladores es solo un ejemplo de las cosas que se pueden hacer con este tipo de exploits. Los exploits de administrador a kernel habilitan un menú completo de capacidades de malware que normalmente son imposibles en el modo de usuario, que incluyen:
- Deshabilite la telemetría del modo kernel, incluidos los procesos, subprocesos, administradores de objetos, sistema de archivos y devoluciones de llamada del Registro. EDRSandBlast hace algunos de estos.
- Deshabilitar los registradores ETW del kernel
- Terminar y/o inyectar malware en los procesos antimalware de PPL
- Omita LSA RunAsPPL para volcar credenciales o manipular Credential Guard
- Lectura y escritura de la memoria de los procesos de trabajo de VM blindados, que se ejecutan como PPL
- Ejecute malware con mayores privilegios que el antimalware, de modo que no se pueda analizar ni finalizar desde el modo de usuario
- Implementar el comportamiento del rootkit, como ocultar procesos, archivos y claves del Registro
- Obtenga acceso completo de lectura y escritura a la memoria física
Estas capacidades impulsadas por el kernel, a menudo habilitadas por BYOVD, son empleadas de manera regular por los delincuentes para derrotar y degradar los productos de seguridad, lo que les permite dañar a las personas y las compañías. Las vulnerabilidades de PPL y kernel habilitan estas mismas capacidades, por lo que MSRC debe atenderlas de manera proactiva antes de que los actores de amenazas abusen de ellas, no después.
No quiero subestimar la dificultad del problema: defender el kernel contra los administradores es difícil y requerirá un esfuerzo continuo a medida que se encuentren nuevos desvíos. No se resolverá, sino que se tratará de una carrera armamentista difícil y continua. Afortunadamente, Microsoft adoptó recientemente una nueva filosofía de "ya no evitar las cosas difíciles" (enlace con marca de tiempo). Abordar este tipo de vulnerabilidades es una "cosa difícil" que afecta a la seguridad de Windows hoy en día y sobre la que Microsoft puede hacer algo al mismo tiempo que avanza hacia su visión de un futuro sin administración. Son una compañía grande y bien financiada, llena de personas inteligentes, capaces de abordar múltiples problemas a la vez.
Conclusión
Microsoft creó la lista de bloqueo de controladores vulnerables para evitar que los administradores manipulen el kernel, pero no hicieron nada sobre una cadena de exploits de administrador a kernel que se informó hace más de 11 meses. Al eliminar el requisito de controlador vulnerable de EDRSandBlast a través de GodFault, espero demostrar que los exploits de administrador a kernel pueden ser tan peligrosos como los controladores vulnerables y que MSRC debe tomarlos en serio. Dado el objetivo de seguridad predeterminada de Windows 11 y el hecho de que la lista de bloqueo de controladores vulnerables ahora está habilitada de forma predeterminada, MSRC debe reconsiderar su política de indiferencia hacia PPL y exploits del kernel.