Ya he hablado recientemente en una nota sobre esta nueva funcionalidad en Windows Vista, y algunas de las complicaciones que a mi particularmente me trajo y como desactivarlo, ahora Microsoft en la revista TechNet se publico una nota muy muy completa al respecto que me gustaria compartirla con ustedes.

Saludos, Roberto Di’Lello.

El control de cuentas de usuario (UAC) es a menudo una característica mal comprendida en Windows Vista. En mi serie de TechNet Magazine de tres partes acerca de los cambios del núcleo de Windows Vista, disponible en línea en la dirección technetmagazine.com, no hablé de UAC porque sentía que se merecía su propio artículo.En este artículo hablo de los problemas que UAC resuelve y describo la arquitectura y la implementación de las tecnologías de sus componentes. Entre estas tecnologías se incluyen la refactorización de las operaciones que anteriormente requerían derechos administrativos, la virtualización ligera para ayudar a los programas a ejecutarse correctamente sin derechos administrativos, la capacidad de los programas de solicitar explícitamente derechos administrativos y el aislamiento de los procesos administrativos de los procesos no administrativos que se ejecutan en el mismo escritorio de usuario.

Objetivo de UAC

UAC sirve para permitir a los usuarios ejecutar operaciones con derechos de usuario estándar, en contraposición con los derechos administrativos. Los derechos administrativos ofrecen a los usuarios la capacidad de leer y de modificar cualquier parte del sistema operativo, como por ejemplo, el código y los datos de otros usuarios, e incluso el propio Windows^®. Sin derechos administrativos, los usuarios no pueden modificar de manera accidental (o deliberadamente) la configuración del sistema, el malware no puede modificar la configuración de seguridad del sistema ni deshabilitar software antivirus y los usuarios no pueden poner en peligro la información confidencial de otros usuarios en equipos compartidos. La ejecución con derechos de usuario estándar puede, por tanto, reducir las llamadas al departamento de soporte técnico urgentes en entornos corporativos, mitigar la repercusión del malware, mantener la ejecución sin problemas de los equipos domésticos y proteger los datos confidenciales de los equipos compartidos.

UAC tuvo que tratar varios problemas para que fuera práctica la ejecución con una cuenta de usuario estándar. En primer lugar, antes de Windows Vista™, el modelo del uso de Windows ha sido uno en que se suponían derechos administrativos. Los programadores de software suponían que sus programas podrían tener acceso y modificar cualquier archivo, clave de Registro o configuración del sistema operativo. Incluso cuando Windows NT^® incorporó seguridad y diferenció entre accesos concedidos a cuentas de usuario estándar y administrativas, se guiaba a los usuarios a través de un proceso de configuración que les animaba a usar la cuenta de administrador integrada o una que fuera miembro del grupo Administradores.

El segundo problema que UAC tuvo que tratar fue que los usuarios a veces necesitan derechos administrativos para realizar operaciones como, por ejemplo, instalar software, cambiar la hora del sistema y abrir puertos en el firewall.

La solución de UAC para estos problemas es ejecutar la mayoría de las aplicaciones con derechos de usuario estándar, obviar la necesidad de los derechos de administrador todo el tiempo y animar a los programadores de software a crear aplicaciones que se ejecuten con derechos de usuario estándar. UAC alcanza estos objetivos al requerir derechos administrativos con menor frecuencia, habilitar las aplicaciones heredadas para que se ejecuten con derechos de usuario estándar, haciendo que sea adecuado para los usuarios estándar el acceso a los derechos administrativos cuando los necesitan, y habilitar incluso a los usuarios administrativos para que ejecuten como si fueran usuarios estándar.

Ejecución como usuario estándar

Durante una auditoría completa de todas las operaciones administrativas durante el desarrollo de Windows Vista se identificaron muchas que se podrían habilitar para los usuarios estándar sin poner en peligro la seguridad del sistema. Por ejemplo, incluso las corporaciones que adoptaron cuentas de usuario estándar para sus sistemas de escritorio de Windows XP no pudieron quitar a sus usuarios que viajan del grupo Administradores por la única razón de que Windows XP no diferencia entre cambiar la zona horaria y cambiar la hora del sistema. Un usuario de equipo portátil que desea configurar la zona horaria local para que sus citas se muestren correctamente en su calendario cuando viaja debe tener el privilegio “Cambiar la hora del sistema” (denominada internamente SeSystemTimePrivilege) que, de forma predeterminada, sólo se concede a administradores.

La hora se usa normalmente en protocolos de seguridad como Kerberos, pero la zona horaria sólo afecta a la manera en la que se muestra la hora, de modo que Windows Vista agrega un privilegio nuevo, “Cambiar la zona horaria” (SeTimeZonePrivilege) y lo asigna al grupo Usuarios, como se ve en la figura 1. Esto hace posible que en muchas corporaciones los usuarios de equipo portátil trabajen bajo cuentas de usuario estándar.

Windows Vista también permite a los usuarios estándar configurar los valores WEP cuando se conectan a redes inalámbricas, crean conexiones VPN, cambian la configuración de administración de energía e instalan actualizaciones críticas de Windows. Además, incorpora la configuración de directivas de grupo que permite a los usuarios estándar instalar controladores de impresora y otros dispositivos aprobados por administradores de TI e instalar controles ActiveX^® de los sitios aprobados por el administrador.

¿Qué ocurre con las aplicaciones de línea de negocio y consumidor que no se ejecutan correctamente en cuentas de usuario estándar? Si bien algunos programas de software requieren legítimamente derechos administrativos, muchos programas almacenan innecesariamente datos de usuario en ubicaciones globales del sistema. Microsoft recomienda que los instaladores de aplicaciones globales que esperan ejecutar con derechos administrativos creen un directorio en el directorio %Archivos de programa% para almacenar los archivos ejecutables de la aplicación y los datos auxiliares y creen una clave en HKEY_LOCAL_EQUIPO\Software para la configuración de su aplicación. Cuando se ejecuta una aplicación, se puede ejecutar en diferentes cuentas de usuario y, por tanto, debería almacenar datos de usuario específicos en el directorio % AppData % por usuario y guardar la configuración por usuario en el perfil de Registro del usuario en HKEY_CURRENT_USER\ Software. Las cuentas de usuario estándar no tienen acceso de escritura al directorio %Archivos de programa% ni HKEY_LOCAL_MACHINE\Software pero, debido a que la mayoría de los sistemas de Windows son de un único usuario y la mayoría de los usuarios han sido administradores hasta Windows Vista, las aplicaciones que guardan incorrectamente datos de usuario y configuración en estas ubicaciones funcionan de todos modos.

Windows Vista permite que estas aplicaciones heredadas se ejecuten en cuentas de usuario estándar a través de la ayuda del sistema de archivos y de la virtualización del espacio de nombres del Registro. Cuando una aplicación modifica una ubicación global del sistema en el Registro o el sistema de archivos y hay un error en dicha operación porque se deniega el acceso, Windows redirecciona la operación a un área por usuario; cuando la aplicación lee desde una ubicación global del sistema, Windows comprueba primero los datos en el área por usuario y, si no hay ninguno presente, permite el intento de lectura desde la ubicación global.

Para esta virtualización, Windows Vista trata un proceso como heredado si es de 32 bits (frente a 64 bits), no se ejecuta con derechos administrativos y no tiene un archivo de manifiesto que indique que se escribió para Windows Vista. No se virtualiza ninguna operación cuyo origen no sea un proceso clasificado como heredado según esta definición, incluidos los accesos al recurso compartido de archivos de red. El estado de virtualización de un proceso se almacena como un indicador en su token, que es la estructura de datos del núcleo que realiza el seguimiento del contexto de seguridad de un proceso, incluida su cuenta de usuario, las pertenencias a grupos y los privilegios.

Puede consultar el estado de virtualización de un proceso si agrega la columna Virtualización a la página Procesos del Administrador de tareas. La figura 2 muestra que la mayoría de los componentes de Windows Vista, incluido el Administrador de ventanas del escritorio (Dwm.exe), el subsistema en tiempo de ejecución del cliente-servidor (Csrss.exe) y el Explorador, tienen la virtualización deshabilitada porque tienen un manifiesto de Windows Vista o se ejecutan con derechos administrativos y, por tanto, no admiten la virtualización. Internet Explorer^® (iexplore.exe) tiene la virtualización habilitada porque puede alojar varias secuencias de comandos y controles ActiveX, y debe suponer que no se escribieron para funcionar correctamente con derechos de usuario estándar.

 Las ubicaciones del sistema de archivos que están virtualizadas para procesos heredados son %Archivos de programa%, %ProgramData% y %SystemRoot%, excluyendo algunos subdirectorios específicos. Sin embargo, cualquier archivo con una extensión ejecutable, entre las que se incluyen .exe, .bat, .scr, .vbs, entre otras, se excluye de la virtualización. Esto significa que los programas que se actualizan desde una cuenta de usuario estándar tienen un error en lugar de crear versiones privadas de sus archivos ejecutables que no son visibles para un administrador que ejecuta un programa de actualización global. Para agregar extensiones adicionales a la lista de excepciones, especifíquelas en la siguiente clave del Registro y reinicie el equipo:

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesLuafvParametersExcludedExtensionsAdd

Use un tipo de cadena múltiple para delimitar varias extensiones y no incluya un punto inicial en el nombre de extensión.

Las modificaciones a los directorios virtualizados por procesos heredados se redireccionan al directorio raíz virtual del usuario, %LocalAppData%\VirtualStore. Por ejemplo, si un proceso virtualizado que se ejecuta en mi sistema crea C:\Windows\Application.ini, el archivo que se crea realmente es C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini. El componente Local de la ruta de acceso resalta el hecho de que los archivos virtualizados no serán itinerantes con el resto del perfil cuando la cuenta tiene un perfil móvil.

Si navega por el Explorador hasta un directorio que contiene archivos virtualizados, el Explorador muestra un botón con la etiqueta Archivos de compatibilidad en su barra de herramientas, tal como se muestra en la figura 3. Al hacer clic en el botón, navegará hasta el subdirectorio de VirtualStore correspondiente para mostrarle los archivos virtualizados.

La figura 4 muestra cómo el controlador de filtros de virtualización de archivos UAC (%SystemRoot%\System32\Drivers\Luafv.sys) implementa la virtualización del sistema de archivos. Debido a que se trata de un controlador de filtros del sistema de archivos, ve todas las operaciones del sistema de archivos pero sólo implementa la funcionalidad para operaciones desde procesos heredados. Puede ver que cambia la ruta del archivo de destino para un proceso heredado que crea un archivo en una ubicación global del sistema, pero no lo hace para un proceso que ejecuta una aplicación de Windows Vista con derechos de usuario estándar. El proceso heredado cree que la operación se realiza correctamente cuando realmente ha creado el archivo en una ubicación completamente accesible para el usuario, pero los permisos predeterminados en el directorio de Windows deniegan el acceso a la aplicación escrita para Windows Vista.

La virtualización del Registro se implementa de manera algo diferente a la virtualización del sistema de archivos. Entre las claves del Registro virtualizadas se incluyen la mayor parte de la rama HKEY_LOCAL_MACHINE\Software, pero hay numerosas excepciones como, por ejemplo, las siguientes:

HKLMSoftwareMicrosoftWindows HKLMSoftwareMicrosoftWindows NT HKLMSoftwareClasses

Sólo se virtualizan las claves que están modificadas comúnmente por aplicaciones heredadas pero que no presentan problemas de compatibilidad ni interoperabilidad. Windows redirecciona las modificaciones de claves virtualizadas por una aplicación heredada a la raíz virtual del Registro de un usuario en HKEY_CURRENT_USER\Software\Classes\VirtualStore. La clave se encuentra en el subárbol Classes del usuario, %LocalAppData%\Microsoft\Windows\UsrClass.dat que, como cualquier otro elemento de datos de archivo virtualizado, no será itinerante con un perfil de usuario móvil.

En lugar de mantener una lista fija de ubicaciones virtualizadas como lo hace Windows para el sistema de archivos, el estado de virtualización de una tecla se almacena como un indicador, REG_ KEY_DONT_VIRTUALIZE, en la propia clave. La utilidad Reg.exe puede mostrar el indicador así como los otros dos indicadores relacionados con la virtualización, REG_KEY_ DONT_SILENT_FAIL y REG_KEY_ RECURSE_FLAG, como se ve en la figura 5. Cuando se define REG_KEY_DONT_SILENT_FAIL y la clave no está virtualizada (REG_KEY_DONT_VIRTUALIZE está definida), a una aplicación heredada a la que se denegaría acceso para realizar una operación en la clave se le concede en su lugar cualquier acceso que el usuario tiene a la clave en lugar de las que la aplicación ha solicitado. REG_KEY_RECURSE_FLAG indica si las nuevas subclaves heredan los indicadores de virtualización del principal en lugar de únicamente los indicadores predeterminados.

En la figura 6 se muestra cómo el Administrador de configuración implementa la virtualización del Registro y administra el Registro en el núcleo del sistema operativo, Ntoskrnl.exe. Al igual que con la virtualización del sistema de archivos, se redirecciona un proceso heredado que crea una subclave de una clave virtualizada a la raíz virtual del Registro del usuario pero a un proceso de Windows Vista se le deniega el acceso por permisos predeterminados.

Además del sistema de archivos y de la virtualización del Registro, algunas aplicaciones requieren ayuda adicional para ejecutarse correctamente con derechos de usuario estándar. Por ejemplo, una aplicación que prueba la cuenta en la que se ejecuta para la pertenencia al grupo Administradores puede funcionar, pero no se ejecutará si no se encuentra en dicho grupo. Por tanto, Windows Vista define varias correcciones de compatibilidad (shim) de aplicaciones para que dichas aplicaciones funcionen de todos modos. Las correcciones de compatibilidad (shim) que se aplican a las aplicaciones heredadas para el funcionamiento con derechos estándar se muestran en la figura 7. Los profesionales de TI corporativos pueden usar herramientas como el kit de herramientas de compatibilidad de aplicaciones (ACT, disponible en technet.microsoft.com/windowsvista/aa905066.aspx) y su utilidad Standard User Analyzer (SUA) o LUA Buglight de Aaron Margosis para identificar los requisitos de correcciones de compatibilidad (shim) para su aplicaciones de línea de negocio. Asignan correcciones de compatibilidad (shim) a una aplicación mediante el Administrador de compatibilidad, que también forma parte del ACT y, a continuación, implementan la base de datos de compatibilidad resultante (archivo .sdb) a sus escritorios mediante la directiva de grupo. Tenga en cuenta que, si fuera necesario, se puede deshabilitar la virtualización por completo para un sistema que usa una configuración de directiva de seguridad local.

Efectos de la virtualización

Puede cambiar el estado de la virtualización de un proceso si selecciona Virtualización del menú contextual que aparece al hacer clic con el botón secundario en el Administrador de tareas. En la figura A se muestra el comportamiento de un símbolo del sistema cuando cambia su estado de virtualización. Empieza con la virtualización deshabilitada porque tiene un manifiesto de Windows Vista. Debido a que se ejecuta con derechos de usuario estándar, no puede crear un archivo en el directorio \Windows pero, después de que se virtualiza mediante el Administrador de tareas, parece que crea el archivo correctamente. Cuando su virtualización vuelve a su estado deshabilitado, no encuentra el archivo, que en realidad está en el almacén virtual del usuario.

Modo de aprobación del administrador

Aunque los usuarios ejecutan únicamente programas compatibles con derechos de usuario estándar, algunas operaciones todavía requieren derechos administrativos. La inmensa mayoría de las instalaciones de software requieren derechos de administrador para crear directorios y claves de Registro en ubicaciones globales del sistema o para instalar servicios o controladores de dispositivos. La modificación de la configuración global del sistema de aplicaciones y Windows también requiere derechos administrativos, al igual que la característica de control parental de Windows Vista. Sería posible realizar la mayor parte de estas operaciones si se cambia a una cuenta de administración dedicada; pero el inconveniente de hacerlo es que la mayoría de los usuarios permanecería en la cuenta administrativa para realizar sus tareas diarias.

Por tanto, Windows Vista incluye la funcionalidad mejorada “ejecutar como” de modo que los usuarios estándar pueden iniciar procesos de manera conveniente con derechos administrativos. Esta funcionalidad requería ofrecer a las aplicaciones una manera de identificar las operaciones para las que el sistema puede obtener derechos administrativos en nombre de la aplicación según sea necesario, lo cual describiré en breve.

Además, para que los usuarios que actúan como administradores del sistema puedan ejecutar con derechos de usuario estándar, pero sin tener que especificar nombres de usuario y contraseñas cada vez que desean tener acceso a derechos administrativos, Windows Vista presenta el Modo de aprobación de administrador (AAM). Esta característica crea dos identidades para el usuario al iniciar una sesión: una, con derechos de usuario estándar y otra, con derechos administrativos. Puesto que cada usuario de un sistema de Windows Vista es un usuario estándar o ejecuta la mayoría de las veces como usuario estándar en AAM, los programadores deben suponer que todos los usuarios de Windows son usuarios estándar, lo que dará lugar a más programas trabajando con derechos de usuario estándar sin virtualización o correcciones de compatibilidad (shim).

La concesión de derechos administrativos a un proceso se denomina elevación. Cuando la realiza una cuenta de usuario estándar, se denomina elevación de supervisión continua (OTS) porque requiere la entrada de credenciales para una cuenta que es miembro del grupo del administrador, algo que ha completado generalmente otro usuario escribiendo mientras supervisa al usuario estándar. Una elevación realizada por un usuario de AAM se denomina elevación de consentimiento porque el usuario sólo tiene que aprobar la asignación de sus derechos administrativos.

Windows Vista considera administrador a un usuario si dicho usuario es miembro de cualquier grupo del tipo administrador que se incluye en la lista de la figura 8. Muchos de los grupos incluidos en la lista se usan sólo en sistemas unidos por un dominio y que no conceden directamente derechos administrativos locales a los usuarios pero les permiten modificar la configuración para todo el dominio. Si un usuario es miembro de cualquiera de esos grupos, pero no del grupo Administradores real, el usuario obtiene acceso a sus derechos administrativos mediante elevaciones OTS en lugar de mediante elevaciones de consentimiento.

Cuando inicia sesión un usuario que pertenece a uno de los grupos incluidos en una lista, Windows Vista crea un token que representa la versión del usuario estándar de la identidad administrativa del usuario. Al nuevo token se le quitan todos los privilegios asignados al usuario excepto los incluidos en una lista de la figura 9, que son los privilegios de usuario estándar predeterminados. Además, cualquiera de los grupos de tipo administrador está marcado con el indicador USE_FOR_DENY_ONLY en el nuevo token. La figura 10 muestra Sysinternals Process Explorer (una herramienta de administración de procesos que se puede descargar desde la dirección microsoft .com/technet/sysinternals) y que muestra los privilegios y las pertenencias a grupos de un proceso que se ejecuta con derechos administrativos a la izquierda y sin derechos de administrador a la derecha. (Para impedir un uso involuntario, el modelo de seguridad de Windows requiere que se habilite un privilegio con el indicador deshabilitado para poder usarlo).

Un grupo con el indicador deny-only únicamente se puede usar para denegar al usuario el acceso a un recurso, nunca admitirlo, solucionando una carencia en la seguridad que se podría crear si, en cambio, el grupo se eliminase por completo. Por ejemplo, si un archivo tenía una lista de control de acceso (ACL) que denegó todo el acceso al grupo Administradores pero concedió algún acceso a otro grupo al que pertenece el usuario, a éste se le concedería acceso si el grupo de administradores estuviera ausente del token, ofreciendo a la versión de usuario estándar de la identidad del usuario una mayor acceso que a su identidad de administrador.

Los sistemas independientes, que son típicamente equipos domésticos, y los sistemas unidos por un dominio tratan el acceso de AAM por usuarios remotos de manera diferente debido a que los equipos conectados por un dominio pueden usar grupos administrativos de dominio en sus permisos de recursos. Cuando un usuario tiene acceso a un recurso compartido de archivos de un equipo independiente, Windows solicita la identidad de usuario estándar del usuario remoto pero en los sistemas unidos por un dominio, Windows respeta todas las pertenencias a grupos de dominio del usuario al solicitar la identidad administrativa del usuario.

Acceso útil a los derechos administrativos

Hay varias maneras para que el sistema y las aplicaciones identifiquen una necesidad de derechos administrativos. Una que aparece en la IU del Explorador es la opción de acceso directo y la entrada de menú contextual “Ejecutar como administrador”. Estos elementos incluyen un icono con forma de escudo que debería colocarse en cualquier botón o elemento de menú que daría lugar a una elevación de derechos cuando esté seleccionado. Al elegir la entrada “Ejecutar como administrador”, el Explorador llama a la API de ShellExecute con el verbo “runas”.

La inmensa mayoría de los programas de instalación requiere derechos administrativos, de modo que el cargador de imágenes, que empieza el inicio de un archivo ejecutable, incluye el código de detección del instalador para identificar probables instaladores heredados. Parte de la heurística que usa es tan sencilla como detectar si la imagen tiene las palabras configuración, instalación o actualización en su nombre de archivo o información de versión interna; las más sofisticadas implican la exploración de secuencias de byte en el archivo ejecutable que son comunes a utilidades de terceros de contenedor de instalación.

El cargador de imágenes también llama a la biblioteca de compatibilidad de aplicaciones (appcompat) para ver si el archivo ejecutable de destino requiere derechos de administrador. La biblioteca mira en la base de datos de compatibilidad de aplicaciones para ver si el archivo ejecutable tiene los indicadores de compatibilidad RequireAdministrator o RunAsInvoker asociados a él.

La manera más común de que un archivo ejecutable solicite derechos administrativos es incluir una etiqueta requestedElevationLevel en su archivo de manifiesto de aplicación. Los manifiestos son archivos XML que contienen información complementaria acerca de una imagen. Se presentaron en Windows XP como una manera de identificar las dependencias en los ensamblados de Microsoft .NET Framework y DLL en paralelo. La presencia del elemento trustInfo en un manifiesto (que se puede consultar en el volcado de cadenas extraído de Firewallsettings.exe a continuación), indica un archivo ejecutable que se escribió para Windows Vista y los nidos del elemento requestedElevationLevel incluidos. El atributo del nivel del elemento puede tener uno de los tres valores siguientes: asInvoker, highestAvailable y requireAdministrator.

<trustInfo xmlns=”urn:schema-microsoft-com:asm.v3”> <security> <requestedPrivileges> <requestedExecutionLevel Level=”requireAdministrator” uiAccess=”false”/> </requestedPrivileges> </security> </trustInfo>

Los archivos ejecutables sin ninguna necesidad de derechos administrativos, como Notepad.exe, especifican el valor asInvoker. Algunos archivos ejecutables esperan que los administradores siempre deseen el máximo acceso, de manera que usen el valor highestAvailable. A un usuario que ejecuta un archivo ejecutable con dicho valor se le pedirá elevar sólo si ejecuta en AAM o si se considera un administrador según las reglas definidas anteriormente y debe elevar para tener acceso a sus derechos administrativos. Regedit.exe, Mmc.exe y Eventvwr.exe son ejemplos de aplicaciones que usan highestAvailable. Por último, requireAdministrator siempre produce una solicitud de elevación y se usa por cualquier archivo ejecutable que tenga un error al operar sin derechos administrativos.

Las aplicaciones de accesibilidad especifican “true” para el atributo uiAccess con el fin de controlar la entrada de ventana de procesos elevados y también deben estar firmadas y en una de las distintas ubicaciones seguras, entre las que se incluyen %SystemRoot% y %Archivos de programa%, para obtener dicho poder.

Una manera sencilla de determinar los valores especificados por un archivo ejecutable es ver su manifiesto con la utilidad Sysinternals Sigcheck, tal como se muestra a continuación:

sigcheck –m <executable>

La ejecución de una imagen que solicita derechos administrativos hace que el Servicio de información de aplicaciones (también conocido como AIS, incluido en %SystemRoot%\System32\Appinfo.dll), que se ejecuta dentro de un proceso de host de servicio (%SystemRoot%\System32\Svchost .exe), inicie Consent.exe (%SystemRoot%\System32\Consent.exe). El consentimiento captura un mapa de bits de la pantalla, le aplica un efecto de atenuación, conmuta a un escritorio al que sólo se tiene acceso por la cuenta del sistema local, pinta el mapa de bits como el segundo plano y muestra un cuadro de diálogo de elevación que contiene información acerca del archivo ejecutable. La visualización en un escritorio independiente impide que cualquier malware presente en la cuenta del usuario modifique el aspecto del cuadro de diálogo.

Figura 11 Cuadros de diálogo de elevación de OTS

Si una imagen es un componente de Windows firmado digitalmente por Microsoft y la imagen se encuentra en el directorio del sistema Windows, el cuadro de diálogo muestra una banda azul en la parte superior, tal como se muestra en la figura 11. La banda gris (el cuadro de diálogo intermedio) es para las imágenes firmadas digitalmente por alguien ajeno a Microsoft y la banda naranja (el cuadro de diálogo inferior) es para imágenes sin firmar. El cuadro de diálogo de elevación muestra el icono, la descripción y el editor de la imagen para las imágenes firmadas digitalmente. Para las imágenes sin firmar, sólo muestra un icono genérico, el nombre del archivo y “Editor no identificado”. Esto hace que para el malware sea más difícil imitar el aspecto de software legítimo. El botón Detalles de la parte inferior del cuadro de diálogo se expande para mostrar la línea de comandos que se pasará al archivo ejecutable si se inicia. El cuadro de diálogo de consentimiento de AAM, que se muestra en la figura 12, es similar pero, en lugar de pedir credenciales de administrador, tiene los botones Continuar y Cancelar.

Si un usuario rechaza una elevación, Windows devuelve un error de acceso denegado al proceso que empezó el inicio. Cuando un usuario acepta una elevación al especificar credenciales de administrador o al hacer clic en Continuar, AIS llama a CreateProcessAsUser para iniciar el proceso con la identidad administrativa apropiada. Aunque AIS sea técnicamente el padre del proceso elevado, AIS usa nuevo soporte en la API de CreateProcessAsUser que establece el Id. de proceso principal de dicho proceso al del proceso que lo inició originalmente (consulte la figura 13). Ese es el motivo por el que los procesos elevados no aparecen como hijos del proceso de alojamiento de servicio de AIS en herramientas como Process Explorer que muestra árboles del proceso.

Aunque los cuadros de diálogo de elevación aparezcan en un escritorio seguro independiente, de forma predeterminada, los usuarios no tienen ninguna manera de comprobar que están visualizando un cuadro de diálogo legítimo y no uno presentado por malware. Eso no supone un problema para AAM porque el malware no puede obtener derechos administrativos con un cuadro de diálogo de consentimiento falso. Sin embargo, el malware podría esperar la elevación OTS de un usuario estándar, interceptarlo y usar un cuadro de diálogo de caballo de Troya para capturar las credenciales de administrador. Con dichas credenciales pueden obtener acceso a la cuenta del administrador e infectarla.

Por este motivo, las elevaciones de OTS no son nada recomendables en entornos corporativos. Para deshabilitar elevaciones de OTS, y así reducir las llamadas al servicio de soporte técnico, ejecute el editor de directivas de seguridad local (Secpol.msc) y configure “Control de cuentas de usuario: comportamiento del indicador de elevación para los usuarios estándar” en “Rechaza solicitudes de elevación automáticamente”.

Los usuarios de equipos domésticos conscientes de la seguridad deben configurar las elevaciones de OTS para requerir una secuencia de aviso de seguridad (SAS) que el malware no pueda interceptar ni simular. Para configurar SAS, ejecute el Editor de directivas de grupo (Gpedit.msc), navegue hasta Configuración del equipo | Plantillas administrativas | Componentes de Windows | Interfaz de usuario de credenciales, y habilite “Requerir ruta de acceso de confianza para la entrada de credenciales”. Después que hacerlo, deberá presionar Ctrl+Alt+Supr para tener acceso al cuadro de diálogo de elevación.

Aislamiento de los procesos elevados

Windows Vista coloca una barrera alrededor de los procesos elevados para protegerlos de la ejecución de malware que se ejecuta en el mismo escritorio con derechos de usuario estándar. Sin una barrera, el malware podría controlar una aplicación administrativa enviándole entradas de ventana y mouse sintetizadas mediante mensajes de ventana. Y, aunque el modelo de seguridad de Windows estándar impide que la ejecución de malware en un proceso con derechos de usuario estándar modifique un proceso elevado que se ejecute como un usuario diferente, no impide que la ejecución de malware como la versión de derechos estándar de un usuario administrativo abra los procesos elevados del usuario, inyectándoles código, e iniciando subprocesos en ellos para ejecutar el código inyectado.

El escudo de Windows Vista para mensajes de ventana se denomina aislamiento de privilegios en la interfaz de usuario (UIPI). Se basa en el nuevo mecanismo de integridad de Windows que Windows Vista usa también como barrera alrededor de procesos elevados. En este nuevo modelo de seguridad, todos los procesos y los objetos tienen niveles de integridad, y la directiva de integridad de un objeto puede restringir los accesos que de otro modo se concederían a un proceso mediante el modelo de seguridad de control de acceso discrecional (DAC) de Windows.

Los niveles de integridad (IL) están representados por identificadores de seguridad (SID), que también representan usuarios y grupos, donde el nivel está codificado en el identificador relativo del SID (RID). En la figura 14 se muestra el nombre para mostrar, el SID y la versión hexadecimal del RID del SID para los cuatro IL principales. Los números hexadecimales revelan intervalos de 0x1000 entre cada nivel que permite el uso de los niveles intermedios por las aplicaciones de accesibilidad de IU así como el crecimiento futuro.

En la figura 15 se incluye una lista las directivas de IL de objeto y los tipos de acceso que restringen, que corresponden a los accesos genéricos definidos para un objeto. Por ejemplo, No-Write-Up impide que un proceso de IL inferior obtenga cualquiera de los accesos representados por los accesos de GENERIC_WRITE. La directiva predeterminada para la mayoría de los objetos, entre los que se incluyen archivos y claves de registro, es No-Write-Up, que impide que un proceso obtenga acceso de escritura a objetos que tengan un IL superior a él mismo, incluso si la lista de control de acceso discrecional (DACL) del objeto concede al usuario dicho acceso. Los únicos objetos con una directiva diferente son los objetos de proceso y subproceso. Su directiva, No-Write-Up más No-Read-Up, detiene un proceso que se ejecuta en un IL inferior para que no inyecte código ni lea datos, tales como contraseñas, fuera de un proceso que tenga un IL superior.

Windows asigna a cada proceso un IL que coloca en el token del proceso junto con los SID de los grupos a los que pertenece el usuario que ejecuta el proceso. En la figura 16 se incluye una lista con los ejemplos de los procesos asignados a diferentes IL. Los procesos suelen heredar el IL de su padre pero un proceso también puede iniciar otro proceso en un IL diferente, como lo hace AIS cuando inicia un proceso elevado. Es posible ver los niveles de integridad del proceso con la utilidad Whoami integrada si se especifica la opción /all, o bien mediante Sysinternals Process Explorer o AccessChk. Process Explorer puede mostrar los IL del proceso con la adición de la columna de nivel de integridad.

Cada objeto asegurable tiene un IL explícito o implícito. El proceso, el subproceso y los objetos de token siempre tienen un IL explícitamente asignado que suele ser el mismo que el IL almacenado en el token del proceso correspondiente. La mayoría de los objetos no tienen IL explícito y, por tanto, se vuelven de manera predeterminada a un IL de medio. Los únicos objetos creados con un IL distinto al medio son los objetos creados por un proceso que se ejecuta en el IL bajo, que por tanto tiene un IL bajo. Puede usar la herramienta iCacls integrada (%SystemRoot%\System32\iCacls.exe) para ver los IL de archivos y la utilidad Sysinternals AccessChk para ver los ILs de archivos, claves de Registro, servicios y procesos. La figura 17 revela que el IL de un directorio que necesita ser accesible por Internet Explorer de modo protegido es bajo.

Si un objeto tiene un IL explícito, se almacena en una entrada de control de acceso (ACE) de un tipo nuevo para Windows Vista, la ACE de etiqueta, en la lista de sistema de acceso (SACL) del descriptor de seguridad del objeto (consulte la figura 18). El SID de la ACE corresponde al IL del objeto y los indicadores de ACE codifican la directiva de integridad del objeto. Antes de Windows Vista, las SACL almacenaban únicamente las ACE de auditoría, que requieren el privilegio “Administrar registro de seguridad y auditoría” (SeSecurityPrivilege), pero la lectura de una ACE de etiqueta sólo requiere acceso de permisos de lectura (READ_CONTROL). Para que un proceso modifique el IL de un objeto, debe tener acceso de Cambiar el propietario (WRITE_OWNER) para el objeto y un IL que sea igual o mayor que el objeto, y el proceso sólo puede establecer el IL como su propio IL o inferior. El nuevo privilegio “Modificar la etiqueta de un objeto” (SeRelabelPrivilege) ofrece a un proceso la capacidad de cambiar el IL de cualquier objeto al que el proceso tiene acceso e incluso elevar el IL por encima del IL propio del proceso, pero de forma predeterminada no se asigna dicho privilegio a ninguna cuenta.

Cuando un proceso intenta abrir un objeto, se produce la comprobación de integridad antes de la comprobación de DACL de Windows estándar en la función SeAccessCheck del núcleo. Dadas las directivas de integridad predeterminadas, un proceso sólo puede abrir un objeto para acceso de escritura si su IL es igual o mayor que el IL del objeto y la DACL también concede al proceso los accesos que desea. Por ejemplo, un proceso de IL bajo no puede abrir un proceso de IL medio para acceso de escritura, incluso aunque el DACL conceda el acceso de escritura del proceso.

Con la directiva de integridad predeterminada, los procesos pueden abrir cualquier objeto, a excepción de los objetos de proceso y subproceso, para acceso de lectura siempre que la DACL del objeto les conceda acceso de lectura. Eso significa que un proceso que se ejecuta en IL bajo puede abrir archivos accesibles para la cuenta de usuario en la que se ejecuta. Internet Explorer de modo protegido usa IL para ayudar a impedir que el malware lo infecte al modificar la configuración de la cuenta de usuario, pero no impide que el malware lea documentos del usuario.

Los objetos de proceso y subproceso son excepciones porque su directiva de integridad también incluye No-Read-Up. Eso significa que el IL de un proceso debe ser igual o superior al IL del proceso o subproceso que desea abrir y la DACL debe concederle los accesos que desea para que uno abierto sea correcto. Suponiendo que las DACL admitan el acceso deseado, la figura 19 muestra los accesos que los procesos que ejecutan en medio y bajo tienen a otros procesos y objetos.

El subsistema de mensajería de Windows también respeta los niveles de integridad para implementar UIPI al impedir que un proceso envíe todos los mensajes de ventanas informativas, salvo algunos, a las ventanas que son propiedad de un proceso con un IL superior. Eso no permite que los procesos de usuario estándar controlen la entrada en las ventanas de procesos elevados o que rompan un proceso elevado enviándole mensajes con formato incorrecto que desencadenen desbordamientos de búfer internos. Los procesos pueden elegir admitir que mensajes adicionales pasen la guardia al llamar a la API de ChangeWindowMessageFilter. UIPI también bloquea enlaces de ventana para que no afecten a las ventanas de procesos de IL superior de manera que el proceso de un usuario estándar no pueda registrar las pulsaciones de tecla que el usuario escribe en una aplicación administrativa, por ejemplo.

Límites de elevaciones y seguridad

Es importante ser consciente de que las elevaciones de UAC son comodidades y no límites de seguridad. Un límite de seguridad requiere que la directiva de seguridad dicte qué puede pasar a través del límite. Las cuentas de usuario son un ejemplo de límite de seguridad en Windows porque un usuario no puede tener acceso a los datos que pertenecen a otro usuario sin tener el permiso de dicho usuario.

Debido a que las elevaciones no son límites de seguridad, no hay garantía de que un malware que se ejecute en un sistema con derechos de usuario no ponga en peligro un proceso elevado para obtener derechos administrativos. Por ejemplo, los cuadros de diálogo de elevación sólo identifican el archivo ejecutable que se elevará; no dicen nada acerca de lo que hará cuando se ejecute. El archivo ejecutable procesará los argumentos de la línea de comandos, cargará archivos DLL, abrirá archivos de datos y se comunicará con otros procesos. Cabe la posibilidad de que cualquiera de esas operaciones podría admitir que malware pusiera en peligro el proceso elevado y obtuviera así derechos administrativos.

Reproducción en un recinto de IL bajo

Internet Explorer de modo protegido se ejecuta en IL bajo para crear una barrera alrededor del malware que quizá infecte a su proceso. Esto impide que malware cambie la configuración de la cuenta del usuario y se instale en una ubicación de inicio automático. Puede usar la utilidad Sysinternals PsExec, junto con el conmutador -l, para iniciar los procesos arbitrarios en el IL bajo para explorar el recinto. En la figura B se muestra cómo un símbolo del sistema que se ejecuta en IL bajo no puede crear un archivo en el directorio temporal del usuario, que tiene un IL medio, pero puede hacerlo en el directorio temporal de Internet Explorer, que tiene un IL bajo.

Los procesos de AAM elevados son especialmente susceptibles de verse puestos en peligro porque se ejecutan en la misma cuenta de usuario que los procesos de derechos estándar del usuario de AAM y comparten el perfil del usuario. Muchas aplicaciones leen la configuración y cargan las extensiones registradas en el perfil de un usuario, ofreciendo oportunidades para que se eleve el malware. Por ejemplo, los cuadros de diálogo de control comunes cargan las extensiones de Shell configuradas en la clave de Registro de un usuario (bajo HKEY_CURRENT_USER), de manera que el malware puede agregarse como una extensión para cargarse en cualquier proceso elevado que use dichos cuadros de diálogos.

Incluso los procesos elevados de cuentas de usuario estándar pueden verse en peligro a causa del estado compartido. Todos los procesos que se ejecutan en una sesión de inicio comparten el espacio de nombres interno en el que Windows almacena objetos como, por ejemplo, eventos, exclusiones mutuas, semáforos y memoria compartida. Si el malware sabe que un proceso elevado tratará de abrir y de leer un objeto de memoria compartido específico cuando se inicie el proceso, podría crear el objeto con contenido que desencadene un desbordamiento del búfer para inyectar código en el proceso elevado. Ese tipo de ataque es relativamente sofisticado pero su posibilidad impide que las elevaciones de OTS sean un límite de seguridad.

Lo fundamental es que las elevaciones se presentaron como una comodidad que anima a los usuarios que desean tener acceso a derechos administrativos para que ejecuten con derechos de usuario estándar de manera predeterminada. Los usuarios que desean que las garantías de un límite de seguridad puedan equilibrar la comodidad usando una cuenta de usuario estándar para las tareas diarias y Cambio rápido de usuario (FUS) a una cuenta de administrador dedicada para realizar las operaciones administrativas. Por otro lado, los usuarios que deseen renunciar a la seguridad en favor de la comunidad puede deshabilitar UAC en un sistema en el cuadro de diálogo Cuentas de usuario del Panel de control, pero deben ser conscientes de que esto deshabilita además el Modo protegido de Internet Explorer.

Conclusión

La ejecución como usuario estándar tiene numerosos beneficios, entre los que se incluyen la ayuda para proteger los sistemas de daños accidentales o deliberados, y de proteger los datos y la integridad de los usuarios que comparten un sistema del acceso no autorizado. Las tecnologías y los distintos cambios de UAC tendrán como resultado un cambio principal en el modelo de uso de Windows. Con Windows Vista, los usuarios de Windows pueden realizar por primera vez la mayoría de las tareas diarias y ejecutar la mayor parte del software usando derechos de usuario estándar, y muchas corporaciones pueden ahora implementar cuentas de usuario estándar.

Mark Russinovich es empleado técnico de Microsoft en la división de servicios y plataformas. Es coautor de Microsoft Windows Internals (Microsoft Press, 2004) y orador frecuente en conferencias de programadores y TI. Se unió a Microsoft con la adquisición reciente de la compañía que cofundó, Winternals Software. También creó Sysinternals, donde publicó las utilidades Process Explorer, Filemon y Regmon

Extraído del June 2007 número de TechNet Magazine.