El Poder en los Usuarios avanzados

Publicado por primera vez en TechNet en mayo 01, 2006

Colocar las cuentas de usuario de Windows en el grupo de seguridad de Usuarios avanzados es un enfoque común que adoptan las organizaciones de TI para que los usuarios accedan a un entorno de privilegios mínimos y, al mismo tiempo, evitar los muchos problemas de correr realmente como un usuario limitado. El grupo de Usuarios avanzados puede instalar software, administrar la configuración de energía y zona horaria e instalar controles ActiveX, acciones que se niegan a los usuarios limitados.
Lo que muchos administradores no se dan cuenta, sin embargo, es que este poder viene al precio de una verdadera seguridad de usuario limitado. Muchos artículos, incluido este artículo de Microsoft Knowledge Base y esta entrada de blog del especialista en seguridad de Microsoft Jesper Johansen, señalan que un usuario que pertenece al grupo de Usuarios avanzados puede elevarse fácilmente a administradores con privilegios completos, pero no pude encontrar una descripción detallada de los mecanismos de elevación a los que se refieren. Por lo tanto, decidí investigar.
Antes de poder iniciar la investigación, tuve que definir el problema. En ausencia de un defecto de seguridad, como un desbordamiento de búfer, la escalada de privilegios solo es posible si una cuenta puede configurar código arbitrario para ejecutarse en el contexto de una cuenta con más privilegios. Las cuentas predeterminadas que tienen más privilegios que los Usuarios avanzados incluyen a los Administradores y la cuenta del sistema Local, en la que se ejecutan varios procesos de servicio de Windows. Por lo tanto, si un miembro de Usuarios avanzados puede modificar un archivo ejecutado por una de estas cuentas, configurar uno de sus ejecutables para cargar una DLL arbitraria o agregar un inicio automático de ejecutable a estas cuentas, puede obtener privilegios administrativos completos.
Mi primer paso fue ver qué archivos y directorios a los que el grupo de Usuarios Avanzados tiene acceso de escritura, pero que los usuarios limitados no tienen. Los sistemas que consideré eran Windows 2000 Professional SP4, Windows XP SP2 y Windows Vista. No voy a molestarme en mirar sistemas de servidores porque el escenario de usuarios avanzados más común es en una estación de trabajo.
El método de fuerza bruta para ver qué objetos del sistema de archivos pueden modificar los Usuarios avanzados requiere visitar cada archivo y directorio y examinar sus permisos, algo que claramente no es práctico. La utilidad Cacl de línea de comandos que Windows incluye vuelca descriptores de seguridad, pero nunca me he molestado en aprender el Lenguaje de Descripción de Descriptores de seguridad (SDDL) y analizar la salida requeriría escribir un script. La utilidad AccessEnum que escribió Bryce parecía prometedora y también puede ver la seguridad del Registro, pero está dirigida a mostrar posibles debilidades de permisos, no los accesos disponibles para cuentas particulares. Además, sabía que también tendría que examinar la seguridad aplicada a los servicios de Windows.

Llegué a la conclusión de que tenía que escribir una nueva utilidad para el trabajo, así que creé AccessChk . Se pasa a AccessChk un nombre de cuenta o grupo y una ruta de acceso al sistema de archivos, clave de registro o nombre de servicio de Windows, y se informa de los accesos efectivos que la cuenta o el grupo tiene para el objeto, teniendo en cuenta las membresías de grupo de la cuenta. Por ejemplo, si la cuenta de Mark tenía acceso a un archivo, pero Mark pertenece al grupo de desarrolladores al que se le deniega explícitamente el acceso, AccessChk mostrará a Mark como sin acceso.
Para facilitar la lectura de la salida, AccessChk imprime ‘W’ junto al nombre del objeto si una cuenta tiene permisos que le permitan modificar un objeto, y ‘ R ‘ si una cuenta puede leer los datos o el estado del objeto. Varios conmutadores hacen que AccessChk recurra a subdirectorios o subclaves de registro y el conmutador –v le informa de los accesos específicos disponibles para la cuenta. Un interruptor que agregué específicamente para buscar objetos para los que una cuenta tiene acceso de escritura es –w.
Armado con esta nueva herramienta que estaba listo para comenzar a investigar. Mi primer objetivo era una instalación de VMware de Windows XP SP2 que no tuviera aplicaciones instaladas que no fueran las herramientas de VMware. El primer comando que ejecuté fue:
accesschk –ws “usuarios avanzados” c:\windows
Muestra todos los archivos y directorios bajo el directorio \ Windows que el grupo Usuarios avanzados puede modificar. Por supuesto, muchos de los archivos de \Windows forman parte del sistema operativo o de los servicios de Windows y, por lo tanto, se ejecutan en la cuenta del sistema local. AccessChk informó que los Usuarios avanzados pueden modificar la mayoría de los directorios en \Windows, lo que permite a los usuarios miembros crear archivos en esos directorios. Por lo tanto, un miembro del grupo de Usuarios avanzados puede crear archivos en los directorios \Windows y \Windows\System32, que es un requisito común de las aplicaciones heredadas mal escritas. Además, los Usuarios avanzados deben poder crear archivos en el directorio\Windows \ Archivos de programa descargados para poder instalar controles ActiveX, ya que Internet Explorer los guarda en ese directorio. Sin embargo, simplemente crear un archivo en estos directorios no es una ruta para la elevación de privilegios.
A pesar de que los Usuarios avanzados pueden crear archivos debajo de \Windows y la mayoría de sus subdirectorios, Windows configura permisos de seguridad predeterminados en la mayoría de los archivos contenidos en estos directorios para que solo los miembros del grupo Administradores y la cuenta del Sistema Local tengan acceso de escritura. Las excepciones incluyen los archivos de fuentes (.fon), muchos archivos de registro del sistema (.log), algunos archivos de ayuda (.chm), imágenes y clips de audio (.jpg, .gif y .wmv) y archivos de instalación (.inf), pero ninguno de estos archivos se puede modificar o reemplazar para obtener privilegios administrativos. Los controladores de dispositivo en \Windows \ System32 \ Drivers permitirían una fácil escalada, pero los Usuarios avanzados no tienen acceso de escritura a ninguno de ellos.

Vi un número de .exe’s y .dll está en la lista, así que los examiné en busca de posibles exploits. La mayoría de los ejecutables para los que los Usuarios avanzados tienen acceso de escritura son utilidades interactivas o se ejecutan con privilegios reducidos. A menos que pueda engañar a un administrador para que inicie sesión en el sistema de forma interactiva, estos no se pueden usar para elevar. Pero hay una excepción evidente: ntoskrnl.exe:

Así es, los usuarios avanzados pueden reemplazar o modificar el archivo del sistema operativo principal de Windows. Sin embargo, cinco segundos después de que se modifique el archivo, la Protección de archivos de Windows (WFP) lo reemplazará con una copia de seguridad que recuperará, en la mayoría de los casos, de \Windows\System32\Dllcache. Los usuarios avanzados no tienen acceso de escritura a los archivos en Dllcache, por lo que no puede subvertir la copia de seguridad. Sin embargo, los miembros del grupo de Usuarios avanzados pueden eludir el WFP escribiendo un programa sencillo que reemplaza el archivo, descarga los datos modificados en el disco y, a continuación, reinicia el sistema antes de que WFP actúe.
Verificé que este enfoque funciona, pero la pregunta seguía siendo cómo se puede usar esta vulnerabilidad para elevar el privilegio. La respuesta es tan fácil como usar un desensamblador para encontrar la función que Windows usa para la comprobación de privilegios, SeSinglePrivilegeCheck y parchear su punto de entrada en la imagen del disco para que siempre devuelva TRUE , que es el código de resultado que indica que un usuario tiene el privilegio que se está comprobando. Una vez que un usuario se ejecuta en un núcleo modificado de esta manera, parecerá tener todos los privilegios, incluidos el Controlador de carga, la Toma de Propiedad y el Token de Creación, por nombrar solo algunos de los privilegios que pueden aprovechar fácilmente para tomar el control administrativo completo de un sistema. Aunque Windows XP de 64 bits evita la manipulación del núcleo con PatchGuard, pocas empresas se ejecutan en Windows de 64 bits.
Reemplazando Ntoksrnl.sin embargo, exe no es la única forma de acceder a privilegios administrativos a través del directorio \Windows. Al menos una de las DLL para las que los permisos predeterminados permiten la modificación por parte del Usuario avanzado, Schedsvc.dll, se ejecuta como un servicio de Windows en la cuenta del sistema local. Schedsvc.dll es la DLL que implementa el servicio Programador de tareas de Windows. Windows puede funcionar correctamente sin el servicio, por lo que los usuarios avanzados pueden reemplazar la DLL con una DLL arbitraria, como una que simplemente agrega su cuenta al grupo local de Administradores. Por supuesto, el PMA también protege este archivo, por lo que reemplazarlo requiere el uso de la técnica de derivación del PMA que he descrito.

Ya había identificado varios vectores de elevación, pero continué mi investigación mirando el acceso de los Usuarios avanzados al directorio \Archivos de programa, donde encontré permisos predeterminados similares a los del directorio \Windows. Los usuarios avanzados pueden crear subdirectorios en \Archivos de programa, pero no pueden modificar la mayoría de los componentes de Windows preinstalados. De nuevo, las excepciones, como Windows Messenger (\Archivos de programa \ Messenger\Msmgs.exe) y Windows Media Player (\Archivos de programa\Windows Media Player\Wmplayer.eje) se ejecuta de forma interactiva.
Eso no significa que \Program Files no tenga agujeros potenciales. Cuando examiné la salida más reciente, vi que los usuarios avanzados pueden modificar cualquier archivo o directorio creado en archivos \Program posteriores a los creados durante la instalación de Windows base. En mi sistema de prueba \ Archivos de programa \ Vmware \ Vmware Tools \ Vmwareservice.exe, el archivo de imagen para el servicio Vmware Windows que se ejecuta en la cuenta del sistema Local, era un archivo de este tipo. Otro ejemplo algo irónico es Microsoft Windows Defender Beta 2, que instala su ejecutable de servicio en \Archivos de programa \ Windows Defender con la configuración de seguridad predeterminada. Reemplazar estos archivos de imagen de servicio es una ruta rápida a los privilegios de administrador y es incluso más fácil que reemplazar archivos en el directorio \ Windows porque WFP no se entromete con los reemplazos.
A continuación, dirigí mi atención al Registro ejecutando este comando:
accesschk –swk “usuarios avanzados” HKLM
La lista de salida era enorme porque los Usuarios avanzados tienen acceso de escritura a la gran mayoría de la clave HKLM\Software. El primer área que estudié para posibles elevaciones fue la clave HKLM\System, porque el acceso de escritura a muchas configuraciones debajo de ella, como el servicio de Windows y las claves de configuración de controladores en HKLM\System\CurrentControlSet\Services, permitiría una subversión trivial de la cuenta del Sistema Local. El análisis reveló que los Usuarios avanzados no tienen acceso de escritura a nada significativo bajo esa clave.
La mayoría de las áreas de escritura de usuarios avanzados bajo la otra rama principal de HKLM, Software, relacionadas con Internet Explorer, Explorer y sus asociaciones de archivos, y configuración de administración de energía. Los usuarios avanzados también tienen acceso de escritura a HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Run, lo que les permite configurar ejecutables arbitrarios para que se ejecuten cada vez que alguien inicia sesión de forma interactiva, pero explotar esto requiere que un usuario con privilegios administrativos inicie sesión en el sistema de forma interactiva (lo que, dependiendo del sistema, puede que nunca suceda o que suceda con poca frecuencia). Y al igual que para el directorio \Archivos de programa, los Usuarios avanzados tienen acceso de escritura predeterminado a subclaves que no son de Windows de HKLM\Software, lo que significa que las aplicaciones de terceros que configuran rutas de código ejecutables en sus claves de registro de todo el sistema podrían abrir agujeros de seguridad. VMware, la única aplicación instalada en el sistema, no lo hizo.

El área de exploración restante fue Windows services. Los únicos permisos de servicio que AccessChk considera accesos de escritura son SERVICE_CHANGE_CONFIG y WRITE_DAC. Un usuario con SERVICE_CHANGE_CONFIG puede configurar un ejecutable arbitrario para que se inicie cuando se inicie un servicio y, dado WRITE_DAC, puede modificar los permisos de un servicio para otorgarse acceso a SERVICE_CHANGE_CONFIG. AccessChk reveló lo siguiente en mi sistema Windows XP SP2 de stock:

A continuación, ejecuté PsService para ver la cuenta en la que se ejecuta el servicio DcomLaunch:

Por lo tanto, los miembros del grupo de Usuarios avanzados pueden simplemente cambiar la ruta de la imagen de DComLauncher para apuntar a su propia imagen, reiniciar el sistema y disfrutar de privilegios administrativos.
Puede haber otros servicios que introduzcan vulnerabilidades en su seguridad. Los permisos predeterminados que Windows establece en los servicios creados por aplicaciones de terceros no permiten a los Usuarios avanzados el acceso de escritura, pero algunas aplicaciones de terceros pueden configurar permisos personalizados para que puedan hacerlo. De hecho, en mi producción, la instalación de Windows XP de 64 bits AccessChk revela un agujero que no solo los usuarios avanzados pueden usar para elevarse, sino que los usuarios limitados también pueden:

Ahora había terminado la fase principal de mi investigación y acabo de confirmar lo que todos han estado diciendo: un miembro determinado del grupo de Usuarios avanzados puede hacerse administrador completo con bastante facilidad utilizando exploits en el sistema operativo y los creados por aplicaciones de terceros.
Mi último paso fue ver cómo el enfoque de Microsoft para la cuenta de Usuarios Avanzados ha evolucionado con el tiempo. Este artículo de Microsoft Knowledge Base de 1999 documenta la famosa vulnerabilidad de elevación del salvapantallas que existía en Windows NT 4, pero Microsoft cerró ese agujero antes del lanzamiento de Windows 2000. El artículo de KB también muestra que Microsoft aparentemente no estaba al tanto de otras vulnerabilidades que probablemente existían. Windows 2000 SP4 también incluye agujeros, pero en realidad es un poco más seguro que la configuración predeterminada de Windows XP SP2: Los usuarios avanzados no tienen acceso de escritura a Ntoskrnl.exe o el archivo de imagen del Programador de tareas, pero en lugar de acceso de escritura al servicio DComLauncher pueden subvertir el servicio WMI, que también se ejecuta en la cuenta del Sistema Local.
Windows XP SP1 agregó más debilidades a los usuarios avanzados, incluido el acceso de escritura a archivos críticos del sistema como Svchost.exe, el proceso de alojamiento de servicios de Windows, y servicios adicionales, WMI y SSDPSRV, con permisos explotables. Varios servicios incluso permitieron que usuarios limitados se elevaran como se describe en este artículo de Microsoft KB de marzo de este año.
El nuevo sistema operativo de Microsoft, Windows Vista, cierra todas las vulnerabilidades que he descrito neutralizando a los Usuarios Avanzados para que se comporte de manera idéntica a los Usuarios limitados. Por lo tanto, Microsoft ha cerrado la puerta a los Usuarios avanzados para obligar al personal de TI a proteger sus sistemas al mover a los usuarios a cuentas de usuarios limitados o a cuentas administrativas donde deben reconocer el control del usuario final sobre sus sistemas.
La conclusión es que, si bien Microsoft podría corregir las vulnerabilidades que encontré en mi investigación, no pueden evitar que las aplicaciones de terceros introduzcan otras nuevas y, al mismo tiempo, preservar la capacidad de los usuarios avanzados para instalar aplicaciones y controles ActiveX. La lección es que, como administrador de TI, no debe engañarse pensando que el grupo de Usuarios avanzados es un compromiso seguro en el camino hacia la ejecución como usuario limitado.

Originalmente escrito por Mark Russinovich el 1/5/2006 11:01: 00 AM
Migrado desde el original Sysinternals.com/Blog