Una evasión de la firma de controladores en Windows permitiría instalar rootkits de kernel
(bleepingcomputer.com)- Incluso si Windows aparenta tener los parches más recientes, si se toma control del proceso de Windows Update se puede volver a componentes antiguos del kernel, lo que puede derivar en la evasión de Driver Signature Enforcement y en el despliegue de rootkits de kernel
- El investigador de SafeBreach, Alon Leviev, demostró en BlackHat y DEFCON un ataque de downgrade/rollback de versión, y la toma de control de Windows Update sigue sin estar completamente corregida
- Un atacante con privilegios de administrador puede, incluso en Windows 11 totalmente actualizado, cambiar ci.dll por una versión sin parchear y así permitir la carga de controladores de kernel sin firma
- Virtualization-based Security depende del bloqueo UEFI y de la configuración del registro, por lo que en configuraciones sin la bandera Mandatory las modificaciones al registro o el reemplazo de archivos críticos pueden convertirse en una vía de evasión
- Microsoft está desarrollando una actualización de seguridad para retirar archivos antiguos del sistema VBS, pero la fecha de publicación no está clara debido a la investigación de versiones afectadas, las pruebas de compatibilidad y la prevención de regresiones
Ataque de downgrade que neutraliza el estado de parcheo más reciente
- Un atacante puede controlar el proceso de Windows Update para volver a introducir componentes vulnerables antiguos en un sistema que parece estar al día
- El sistema operativo seguirá viéndose como si estuviera completamente parcheado, pero en la práctica volverá a quedar expuesto a vulnerabilidades ya corregidas
- Entre los objetivos del downgrade se incluyen DLL, controladores y el NT kernel
- Alon Leviev publicó la herramienta Windows Downdate, mostrando que es posible crear downgrades personalizados
Evasión de Driver Signature Enforcement y riesgo de rootkits
- Leviev mostró que, incluso después del endurecimiento de la seguridad del kernel, sigue siendo posible evadir Driver Signature Enforcement(DSE)
- Si se logra evadir DSE, un atacante puede cargar controladores de kernel sin firma
- Estos controladores pueden usarse para desplegar malware tipo rootkit que desactive controles de seguridad y dificulte la detección de intrusiones
- Leviev llama a su método
"ItsNotASecurityBoundary" DSE bypass- Este método adopta la forma de un downgrade del exploit ItsNotASecurityBoundary
- Dicho exploit aprovecha una clase de vulnerabilidades de Windows de falsa inmutabilidad de archivos (false file immutability) identificada por Gabriel Landau de Elastic, lo que permite la ejecución arbitraria de código con privilegios de kernel
Reemplazo de ci.dll y condición de reinicio
- En una nueva investigación, Leviev mostró que un atacante con privilegios de administrador puede abusar del proceso de Windows Update para evadir la protección DSE incluso en Windows 11 completamente actualizado
- La clave está en reemplazar ci.dll, que impone DSE, por una versión sin parchear que ignora la firma de controladores
- Una vez que el componente se degrada a una versión vulnerable, se requiere reiniciar el sistema como parte de un proceso de actualización aparentemente normal
- Leviev publicó una demostración en la que revierte mediante downgrade el parche de DSE en un sistema Windows 11 23H2 totalmente parcheado y luego explota ese componente
Vías de evasión cuando la configuración de VBS es débil
- Leviev también aborda formas de desactivar o evadir Virtualization-based Security(VBS) de Microsoft
- VBS crea un entorno aislado para proteger los recursos obligatorios y los activos de seguridad de Windows
- Entre los elementos protegidos están skci.dll, el mecanismo de integridad de código del kernel de seguridad, y las credenciales autenticadas de usuario
- Por lo general, VBS depende de protecciones como el bloqueo UEFI y la configuración del registro
- Si VBS no está configurado con la bandera “Mandatory”, que representa el nivel máximo de seguridad, puede desactivarse modificando claves específicas del registro
- Si VBS solo está activado parcialmente, se pueden reemplazar archivos críticos de VBS como SecureKernel.exe por versiones alteradas para interferir con su funcionamiento
- Ese estado puede abrir una ruta hacia la evasión “ItsNotASecurityBoundary” y el reemplazo de ci.dll
Respuesta de Microsoft y vacíos pendientes
- Aunque ya se abordaron CVE-2024-21302 y CVE-2024-38202, usados en los ataques de downgrade presentados en BlackHat y DEFCON, el problema de la toma de control de Windows Update sigue pendiente
- Microsoft consideró que este problema no cruza un límite de seguridad definido, y determinó que obtener ejecución de código de kernel con privilegios de administrador no constituye una violación de un límite de seguridad
- Leviev enfatizó que, hasta que Microsoft corrija el problema, las soluciones de seguridad deben monitorear y detectar ataques de downgrade
- Microsoft afirmó que está desarrollando activamente mitigaciones para bloquear este riesgo
- La empresa está trabajando en una actualización de seguridad para retirar archivos antiguos del sistema VBS sin parchear
- Ese proceso incluye investigar todas las versiones afectadas, desarrollar la actualización y realizar pruebas de compatibilidad
- Para proteger a los clientes y minimizar interrupciones operativas, se deben evitar fallas de integración o regresiones
- Debido a la complejidad del problema, no está claro cuándo se entregará la actualización
- En una actualización del 27 de octubre se aclaró que el ataque requiere privilegios de administrador, y se añadió información para reducir la confusión sobre la idea de que Microsoft no estuviera tomando medidas de mitigación
1 comentarios
Opiniones de Hacker News
MS dice que UAC no es un límite de seguridad, pero eso se refiere al problema de que algunos usuarios escalen a privilegios de administrador.
Pero en este caso, pasar de administrador al kernel tampoco sería un límite de seguridad, y al mismo tiempo la aplicación obligatoria de firmas de drivers sí es una función de seguridad.
Aquí precisamente se está eludiendo esa función, y aun así dicen que no se cruzó ningún límite de seguridad; me gustaría que lo explicaran de forma coherente.
UAC es para usuarios que ya pertenecen al grupo de administradores, no una función para que “algunos usuarios se conviertan en administradores”.
El límite de seguridad está alrededor del usuario estándar, no del usuario administrador.
Puede no gustarte, pero si quieres un límite de seguridad, basta con no poner al usuario en el grupo Administrators.
En general, creo que los desacuerdos suelen venir de diferencias en las definiciones o de diferencias en los sistemas de valores.
En este caso, Microsoft valora minimizar este problema, y si eso está en lo más alto de sus prioridades, sus decisiones pueden parecer coherentes bajo ese criterio.
Las diferencias de definición son relativamente fáciles de resolver. Por ejemplo, al diseñar un sistema de software, todos pueden hablar en términos de patrones de diseño, pero si cada uno entiende A como A′ o A″ de forma distinta, puede generarse una gran confusión.
Lo mismo aplica al software open source administrado por empresas.
La verdadera pregunta es por qué la gente dedica su energía intelectual a hacer investigación de seguridad gratis para Microsoft en vez de mejorar Linux de escritorio.
UAC y sudo se parecen más a ventanas de consentimiento de cookies a nivel de sistema operativo, y creo que sería mejor eliminar los tres.
Habría que abandonar los mecanismos de elevación de privilegios basados en usuarios como UAC/sudo y, como en Android e iOS, poner las apps en sandbox en lugar de los usuarios.
También es interesante que, tanto en Windows como en Linux, una cuenta local con permisos normales en realidad se comporta casi como si tuviera privilegios equivalentes a root.
En Linux se entrena a la gente a anteponer sudo a las tareas del sistema, y en Windows se la entrena a aceptar los prompts de UAC.
Me pregunto cuándo fue la última vez que sudo le dijo “no” a alguien por una razón distinta a escribir mal la contraseña.
UAC es un UI administrado por el sistema, mientras que sudo es simplemente un programa, así que UAC es un poco mejor en el sentido de que un atacante podría reemplazar sudo con un alias malicioso del shell y robar la contraseña.
En la configuración predeterminada, sería más cómodo para el usuario y más acorde con el estado real de seguridad eliminar sudo y UAC, y no fingir que existe un límite de seguridad sólido entre root y la cuenta local del usuario principal.
Incluso en la terminal se puede usar pkexec en vez de sudo.
En lugar de ejecutar comandos arbitrarios como root, las aplicaciones pueden usar acciones predefinidas como
org.freedesktop.udisks2.filesystem-mount, y mostrarle al usuario, con un mensaje localizado, qué intenta hacer la app para que decida si lo permite.El administrador del sistema también puede configurar ciertas acciones, como las actualizaciones de flatpak, para que no requieran autenticación, o por el contrario bloquear por completo determinadas acciones.
Creo que parte de la premisa de que el usuario que hizo la instalación debe controlar el sistema. Después de todo, podría no haberlo instalado.
sudo, al igual que UAC, no es un mecanismo para decirle “no” a una persona. Ambos están hechos para que una persona diga “no” cuando el administrador intenta realizar una tarea administrativa inesperada.
Quien no tenga privilegios de administrador pero necesite realizar una tarea de ese tipo debe obtener la aprobación del administrador.
Si no es un sistema de una sola persona, quien configura la máquina debería crear una cuenta limitada para el uso cotidiano.
No suelo necesitar convertirme en root, y cuando hace falta normalmente es para hacer varias tareas seguidas.
Creo que sudo es útil en computadoras multiusuario, como equipos propiedad de una empresa y administrados por ella, cuando el administrador quiere permitir a ciertos usuarios solo algunas operaciones privilegiadas limitadas.
La razón principal para usar siempre una cuenta que no sea root es más evitar errores que la seguridad: evitar borrar o sobrescribir archivos sin querer.
Por eso, tener que ingresar la contraseña de vez en cuando para cambiar de rol me parece suficientemente justificado.
Eso sí, no existe el truco de “presiona ctrl+alt+delete para confirmar”.
Windows tiene la ventaja de que no hace falta escribir scripts para todo.
Si quieres, puedes envolver todas las herramientas con
runas/System.Management.Automation.PSCredential, pero en la mayoría de los casos no hace falta.Parece una arquitectura en la que el kernel, al abrir un archivo, revisa todos los handles de archivo abiertos para verificar bloqueos obligatorios en conflicto y así aplicar las reglas de uso compartido de archivos, pero no revisa los mapeos de memoria con permisos en conflicto.
Es un error, pero la corrección parece relativamente simple.
Curiosamente, Linux acaba de eliminar los últimos vestigios del bloqueo obligatorio. Ahora escribir sobre un ejecutable cargado ya no produce EBUSY.
Es interesante que la misma función sea, en un sistema operativo, una parte que soporta el peso de la infraestructura de seguridad, y en otro, un resto legacy que hay que eliminar.
No soy experto en seguridad y solo entiendo lo básico, pero siento que me estoy perdiendo algún modelo conceptual.
Me pregunto por qué Windows es tan fácil de hackear.
Windows es un objetivo rentable, especialmente porque es el sistema operativo de escritorio más desplegado en entornos empresariales, así que se invierte mucho tiempo y dinero en vulnerarlo.
No se invirtió lo suficiente en crear una plataforma de cómputo realmente segura.
Una plataforma de seguridad ideal debería ofrecer builds reproducibles sobre una infraestructura verificable públicamente, como fdroid; virtualizar dentro de un sandbox todas las aplicaciones no confiables; e implementar un modelo de privilegios mínimos.
Hoy estamos en el peor estado posible de seguridad. En todos los rings se ejecuta código inseguro cuya identidad se desconoce y que probablemente no se probó lo suficiente: desde el ME de la CPU y componentes UEFI hasta drivers de terceros del sistema operativo.
SeL4 tiene un kernel completamente verificado, pero todavía no virtualiza.
Buena parte del malware para Windows depende en algún momento de drivers de kernel de terceros vulnerables.
En cambio, en Linux los módulos de kernel de terceros son raros y se ven con malos ojos, y en macOS están directamente prohibidos.
Y es demasiado fácil convencerlo de ejecutar cualquier cosa con privilegios elevados.
Recién se abordó en 2022, después de que el analista de CERT Will Dormann preguntara por qué era así.
Ahora se actualiza con regularidad, pero de verdad es increíble https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...
En este caso estoy de acuerdo, hasta cierto punto, con la postura de Microsoft.
Un administrador puede hacer cosas arbitrarias en la computadora; no es nada nuevo.
No sé si hay algún matiz que eleve la gravedad.
También vale la pena leer el artículo de Raymond Chen que resume este tipo de ataques.
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
Si alguien ya puede reemplazar DLL arbitrarias del sistema, entonces ya se cumplen las condiciones previas para que funcione este “exploit”, y para ese momento todo está perdido.
La capacidad de eludir la firma de drivers probablemente sea una de las menores preocupaciones.
El ataque parece sospechosamente simple.
Consiste en engañar al proceso de actualización para que instale un componente de kernel antiguo con vulnerabilidades conocidas.
Incluso sin ser experto, uno pensaría que Microsoft ya debería haber previsto esto y tener algo como una lista de bloqueo o un mecanismo de revocación; me da curiosidad.
La clave es si la causa raíz es un problema de diseño del sistema operativo, o si fue una falla de proceso por no registrar un hash roto o malo en el lugar correcto.
Si es lo segundo, es mucho más fácil de arreglar, pero como siempre, el boletín de seguridad algo maquillado parece insinuar lo primero.
Me cuesta creer que Microsoft lo refute cuando hay una demo.
Esa cuenta de Vimeo tiene muchos otros hallazgos de seguridad. Por ejemplo, había uno donde WhatsApp ejecuta un script de Python; me pregunto si es real o una estafa.
Tienen el criterio de que “se considera que los procesos y usuarios administradores forman parte de la base de cómputo confiable (TCB) de Windows, por lo que no están fuertemente aislados del límite del kernel” [0].
También hay otro caso reciente.
https://arstechnica.com/security/2024/03/hackers-exploited-w...
[0] https://www.microsoft.com/en-us/msrc/windows-security-servic...
Me acuerdo de lo que sufrimos todos en [1] cuando Microsoft empezó a exigir firma de drivers en Windows.
Estábamos creando un driver de inspección profunda de paquetes para [2], y a primera vista el proceso parecía incluso más estricto que la aprobación de apps de la Apple Store, además de que la documentación no era nada clara.
Pensando en los recursos que las empresas invirtieron para cumplir con los requisitos de Microsoft, que esto se haya abusado de esta manera se siente como un gran retroceso.
Las vulnerabilidades siempre existen, pero me habría dado más tranquilidad que alguien hubiera encontrado esto antes.
Aplausos para Alon Leviev y SafeBreach por descubrirlo.
[1] https://www.nektra.com/
[2] https://www.verizon.com/business/en-nl/products/security/man...
Que algo “sea posible al obtener ejecución de código en el kernel como administrador” al final es una afirmación bastante común: un usuario root puede instalar un rootkit.
No hay que olvidarse de ponerle un nombre llamativo. Ah, el investigador ya publicó una herramienta llamada Windows Downdate.
Ya se aseguró sus 0xF minutos de fama, así que bien hecho.
Las cuentas de usuario también son solo objetos dentro del sistema operativo, y se podría diseñar un sistema operativo que imponga reglas específicas a todas las cuentas de usuario aunque limite la cuenta de superusuario.
Por ejemplo, puede haber razones legítimas para proteger ciertos secretos, como hace el TPM, incluso cuando una cuenta de administrador fue comprometida, o para impedir que un administrador rompa el sistema por error y lo deje sin poder arrancar.
Un objetivo más polémico es también hacer cumplir DRM.
Eso es precisamente lo que Microsoft intenta hacer en Windows. El sistema operativo busca impedir que la cuenta de administrador interfiera con el kernel o instale rootkits.
En esta discusión siempre es importante distinguir entre la cuenta de usuario administrador dentro del sistema operativo y la persona “administradora” que tiene acceso físico o de hardware.
0xFcuando habría sido más fácil escribir 15.No está mal, pero es una elección curiosa y me intriga. Me pregunto si fue solo por estilo.
Cuando tengo que usar Windows, siempre asumo que esa computadora ya está comprometida.