En qué consiste y cómo mitigar la última elevación de privilegios en Windows 8.1

A estas alturas, ya muchos sabréis que Google ha descubierto cómo elevar privilegios en Windows 8.1 y, una vez comunicado el problema a Microsoft, ha esperado 90 días. Tras ese tiempo y sin parche, ha hecho públicos todos los detalles. Veamos los detalles y cómo protegerse.

El UAC

Ya se ha hablado bastante de UAC, pero lo repasamos brevemente. Es un concepto “extraño”. Microsoft promovía deliberadamente el uso de la cuenta de administrador en versiones pre-Vista. Harto de la situación, quiso que el usuario se acostumbrase a tener que usar una cuenta no privilegiada y “elevar” para las tareas más delicadas. Eso requería dos cuentas en el sistema o un sistema similar a “sudoers”, pero pensó que todo eso resultaría demasiado complejo para el usuario común. Así que creó UAC… que era un administrador, que en realidad todo el tiempo se comportaba como usuario. Tenía los dos tokens de seguridad y para usar el de mayor privilegio, debía pedir permiso. En Vista, pedía “demasiadas veces” permiso, así que se quejaron los usuarios. En Windows 7, se introdujo el concepto de “autoelevación” de ciertos programas para reducir el número de “clics” necesarios para realizar tareas. Se estableció por defecto esa opción más “insegura” que en Vista… y así sigue en Windows 8, aunque mejorado.

El fallo

En la versión 8.1 existe una llamada de sistema llamada NtApphelpCacheControl en el archivo ahcache.sys. Se trata de cachear datos de compatibilidad de la aplicación para no tener que cargarlos cada vez que se crea un nuevo proceso de ella. Los usuarios pueden leer pero no modificar entradas de caché nuevas. Esto está reservado para los administradores, y se comprueba en la función AhcVerifyAdminContext.

En ella existe un problema. No comprueba bien si realmente el token del usuario que llama es de administrador, porque lo lee utilizando PsReferenceImpersonationToken y luego comparando el SID del usuario con el SID de SYSTEM del sistema. Al no comprobar bien por quién se hace pasar el token, es posible tomar prestado un token de un proceso que funcione bajo SYSTEM y eludir esta comprobación. Los investigadores de Google han creado una prueba de concepto que utiliza en este caso el servicio BITS (Servicio de transferencia inteligente en segundo plano), que se ejecuta como SYSTEM. Probablemente se puede usar cualquier proceso, as�� que deshabilitar este servicio, aparte de impedir que funcione Windows Update cuando toque, no servirá de mucho excepto para que esta prueba de concepto en concreto no sea válida.

La prueba de concepto

La prueba de concepto publicada utiliza también ComputerDefaults.exe (es una herramienta nativa de Windows para asociar programas por defecto). Podría ser cualquiera que usase la “autoevaluación” de UAC. Como en Windows 7 se introdujeron los programas que autoelevan, también podría ser vulnerable, pero la estrategia quizás debería ser diferente y no lo han comprobado a fondo.

Para encontrar programas de sistema que utilicen autoElevate, simplemente podríamos hacer:

findstr “autoElevate” c:WindowsSystem32*.exe

Buscar programas que “autoelevan” en el sistema

Y muestra el contenido de su manifiesto. Aunque lo parezca, no es un fallo de UAC, no lo elude. Se basa en UAC para demostrar que su estrategia de autoelevación puede usarse como trampolín “fácil”. Después de dejar 90 días a Microsoft para solucionarlo, no lo han hecho, y por tanto han publicado todos los detalles. ¿Es realmente tan complejo de solucionar? Como curiosidad relacionada, UAC por defecto también tiene un problema conocido que permite elevar privilegios en Windows 7, y nunca ha sido resuelto. Está descrito aquí.

El problema es reproducible fácilmente, y hemos modificado ligeramente la prueba de concepto para que ejecute un cmd.exe como administrador en vez de la calculadora.

Resultado de la elevación con la prueba de concepto. De un cmd se pasa a un cmd como administrador, sin pasar por UAC

¿Cómo protegerse?

Puesto que no hay parche aún, una forma de mitigar el efecto de la prueba de concepto es la que siempre debió haber sido: aumentar el nivel de seguridad de UAC para que los programas con “autoElevate” no “autoeleven” privilegios. Esto se debería estar haciendo desde los tiempos de Windows 7. Simplemente consiste elevar la palanca de configuración de UAC. Los efectos secundarios serán volver al modo “Windows Vista” y que el sistema “pregunte” más a menudo si se quiere usar el token de administrador. Nada grave.

Elevar la seguridad de UAC. Imprescindible en Windows 7 y recomendable en Windows 8

Incluso mejor, no usar UAC, sino usuarios separados: un administrador y un usuario. Este es probablemente el escenario más habitual en entornos corporativos y por lo que esta prueba de concepto quizás no sea tan “eficaz” en ellos.

Pero cuidado, hemos dicho que esto no es una evasión “pura” de UAC, por tanto elevar la seguridad de UAC sirve para eludir la prueba de concepto pública en 8.1 y para que UAC tenga sentido en Windows 7.

¿Y si se utilizan usuarios separados? Pues los descubridores dicen que tienen otra prueba de concepto basada en el mismo fallo, no pública, válida para 8.1 de 32 bits y que permite a cualquier usuario convertirse en SYSTEM independientemente de cómo esté configurado UAC.  De hecho, usaron UAC en la PoC inicial simplemente por demostrar el problema sin invertir mucho más esfuerzo. Esta PoC “avanzada” resultaría mucho más seria pero no la han hecho pública, aunque quizás han dado las pistas necesarias para que un atacante pueda empezar a investigar el asunto. Mientras, para los “atacantes” que se limiten a intentar usar la prueba de concepto ya publicada, con elevar UAC se estará un poco más seguro. Aunque ciertos motores están ya detectando la PoC para bloquearla, igualmente esto solo detendrá a los atacantes menos hábiles. En cualquier caso, parece que Microsoft lo solucionará en cuanto pueda, y de raíz.

Sergio de los Santos

ssantos@11paths.com 

@ssantosv