Servicio del instalador de ActiveX en Windows Vista

Siempre es la misma historia. Para mejorar sustancialmente la seguridad, tiene que renunciar a alguna libertad o flexibilidad. Si el entorno es como la mayoría de las organizaciones, tiene un fuerte deseo de reforzar el sistema operativo de escritorio con el fin de ofrecer una entorno informático más seguro para los usuarios finales. Los administradores de TI suelen enfocar la tarea de proteger el escritorio al emplear una combinación de configuración de directivas de seguridad, permisos de usuario, listas de control de acceso de archivo y Registro (ACL) y restricciones de servicio del sistema.

Un obstáculo común en el desarrollo de un entorno de escritorio seguro es cómo mitigar las amenazas que rodean los controles ActiveX® malintencionados a la vez que se ofrece un nivel adecuado de compatibilidad de aplicaciones en el entorno. Esto ha sido un desafío con sistemas operativos de escritorio durante muchos años. Afortunadamente, el nuevo Servicio de instalador de controles ActiveX (AxIS) de Windows Vista™ se dirige a las preocupaciones específicas de la administración de controles ActiveX en entornos corporativos. AxIS ofrece una manera sencilla y controlable para los usuarios estándar, a los que normalmente no se les permitirá instalar controles ActiveX, para instalarlos desde sitios web aprobados. El control de directivas de grupo sobre AxIS permite a los administradores de TI determinar qué controles pueden instalar los usuarios, independientemente de qué permisos disponen.

En este artículo, echamos un vistazo a los desafíos administrativos que rodean los controles ActiveX, cómo se trataron estos problemas en versiones anteriores de Windows® y cómo AxIS de Windows Vista ofrece una manera exclusiva y eficaz de administrar la instalación de controles ActiveX.¿Qué es un control ActiveX?

Un control ActiveX es un fragmento de código ejecutable (normalmente un archivo OCX empaquetado dentro de un archivo de Cabinet) que el usuario instala e invoca mediante Internet Explorer®. Los desarrolladores web crean controles ActiveX para agregar funcionalidad a sus aplicaciones web que no pueden obtener fácilmente con HTML estándar o un script sencillo.

Una característica principal de los controles ActiveX es su sencillo modelo de implementación de “descargar y ejecutar”. Los controles ActiveX se instalan y se invocan mediante la etiqueta de objeto HTML, que tiene un atributo denominado CODEBASE que indica a Internet Explorer (usando una dirección URL) dónde obtener el control si no se encuentra ya instalado en el equipo del usuario. En ese caso, Internet Explorer descarga el paquete de instalación asociado, realiza la comprobación de confianza en el objeto y pide al usuario el permiso de instalación mediante la barra de información de Internet Explorer (que se muestra en la figura 1). Durante la instalación, el control se registra y lo invoca la página de representación. Una vez instalado, cualquier usuario estándar puede invocar el control. Este sencillo mecanismo de distribución y ejecución pretende ofrecer a los desarrolladores una manera sencilla de distribuir sus componentes a los usuarios de su aplicación web. El problema con este método de distribución es que los usuarios estándar no pueden instalar directamente controles ActiveX porque se requieren privilegios administrativos para completar la instalación.

Figura 1 Barra de información de instalación de control ActiveX

Cuando los controles ActiveX se presentaron por primera en Internet Explorer 4.0, Internet parecía un lugar mucho menos amenazante. Hoy en día, el código ejecutable distribuido por la Web puede representar una amenaza considerable, así que Windows sólo permite a los usuarios con derechos locales de administrador que instalen controles ActiveX, y entonces sólo si la instalación se aprueba según la configuración de directivas. Una vez que un administrador instala un control ActiveX, cualquier usuario del sistema puede invocarlo. Este comportamiento lo facilita un conjunto de ACL de archivos y Registro en Windows. Mientras que esto impide que los usuarios estándar instalen controles ActiveX, no mitiga los riesgos para los administradores locales y usuarios estándar (con permisos predeterminados modificados) que los instalan.

Si bien la protección predeterminada en Windows (que permite únicamente privilegios administrativos para realizar la instalación) trata los controles ActiveX en el nivel individual, no trata la manera de administrarlos a través de una organización grande. Un desafío común en los entornos corporativos es cómo permitir el uso de controles ActiveX de confianza para la organización de TI a la vez que se mitigan las posibles amenazas ofrecidas a través de controles externos y que no son de confianza. Al final y al cabo, la decisión de instalar un control ActiveX concreto, correcto o incorrecto, se deja a menudo a un usuario individual, en función de sus derechos. Para contrarrestar las amenazas, algunas organizaciones bloquean todos los controles ActiveX, mientras que otras permiten la instalación de usuario final pero intentan administrar cualquier software malintencionado que se instale.

Otra manera de evitar la instalación de controles incorrectos es aplicar los derechos restringidos del usuario estándar y que el administrador de TI preinstale todos los controles necesarios en la plataforma de escritorio. Esto es eficaz si los controles ActiveX en uso son relativamente estáticos por naturaleza, se modifican usando un proceso de versión programado junto con actualizaciones de escritorio o si la organización usa un mecanismo de distribución de software como, por ejemplo, un servidor de administración de sistemas. Sin embargo, la administración continua, las necesidades siempre cambiantes de los desarrolladores de aplicaciones internas y las dependencias en controles externos continuarán siendo un desafío con estos métodos.

En situaciones en las que los usuarios tienen privilegios administrativos, el problema es diferente; implica impedir que estos usuarios instalen controles que no se han aprobado. En estos casos, se supone el derecho del usuario final a instalar controles ActiveX puesto que el usuario tiene privilegios administrativos. (Tenga en cuenta que tener a los usuarios finales ejecutándose como administradores locales es una postura que representa un alto riesgo para la organización y no se recomienda para la mayoría de los entornos corporativos.)

Una solución es tener un servidor interno de descarga de componentes de Internet que hospeda los controles aprobados. Esta solución requiere la modificación de la cadena CodeBaseSearchPath en el Registro del cliente. Normalmente, cuando se encuentra una etiqueta de objeto que contiene el atributo CODEBASE en la página HTML solicitada, los clientes de Windows se dirigen a las ubicaciones especificadas en los datos de CodeBaseSearchPath. De forma predeterminada, esta cadena del Registro contiene la palabra clave CODEBASE y direcciones URL de Internet para la galería de controles ActiveX. Para implementar un servidor de descarga de componentes de Internet, tiene que reemplazar los datos predeterminados en CodeBaseSearchPath por la dirección URL del servidor interno donde se hospedarán los controles aprobados por la organización. Al igual que el enfoque anterior, esta solución requiere una administración continua y lleva el costo y la complejidad de hospedar un servidor interno para controles ActiveX.

Hay otras soluciones, como por ejemplo, la modificación de la zona URLActions de Internet Explorer, la especificación de los controles aprobados por el administrador a través de la directiva de grupo y el bloqueo de la instalación de todos los controles en el perímetro a través de reglas de firewall. Sin embargo, como puede ver, todos estos enfoques tienen sus problemas y muchos se abandonan finalmente debido a la falta de flexibilidad. Lo que es peor, algunas de estas soluciones todavía requieren que el usuario tenga derechos administrativos. Al final, estas modificaciones intentan tratar las partes del problema, como por ejemplo, el control (o el bloqueo) de donde proceden los controles ActiveX, de donde se pueden invocar, etc.; sin embargo, estas soluciones no mitigan el problema fundamental de que los usuarios sin derechos de administrador no pueden instalar controles ActiveX.

¿Qué puede hacer AxIs?

AxIS de Windows Vista permite al administrador corporativo administrar controles ActiveX a la vez que mantiene una postura de fuerte seguridad teniendo a los usuarios en ejecución como usuario estándar con la configuración predeterminada del sistema de archivos. AxIS ofrece opciones de directiva de grupo para configurar los orígenes de confianza de controles ActiveX y un proceso de agente para instalar controles de esos orígenes de confianza en nombre de usuarios estándar. La ventaja clave es que puede mantener una postura de seguridad no administrativa en estaciones de trabajo de usuario junto con el control administrativo centralizado. AxIS depende del administrador de TI para identificar orígenes de confianza (normalmente direcciones URL de Internet o intranet) de controles ActiveX. Cuando una etiqueta de objeto dirige Internet Explorer para que invoque un control, AxIS lleva a cabo los pasos siguientes:

      -Comprueba que el control está instalado. De no ser así, debe ser instalado antes del uso.
      -Examina la configuración de la directiva de AxIS para comprobar si el control procede de un origen de confianza. La comprobación específica coincide con el nombre de host de la dirección URL especificada en el atributo CODEBASE de la etiqueta de objeto frente a la lista de ubicaciones de confianza especificadas en la directiva.
      -Descarga e instala el control en nombre del usuario.

Si el nombre de host de la dirección URL de origen no está incluido en una lista en la configuración de directiva de AxIS, se invocará la pregunta normal del Control de cuentas de usuario (UAC), requiriendo los derechos administrativos para completar la instalación. Además, AxIS registrará un evento con Id. 4097 en el registro de eventos de aplicación de AxInstallService de origen que resume la instalación del control ActiveX intentada, junto con la ruta de acceso de descarga específica al control. En la figura 2 se muestra un ejemplo del evento 4097. El administrador corporativo puede usar los datos de esta entrada de registro de eventos para modificar la directiva de grupo, permitiendo que AxIS instale el control en visitas posteriores al sitio web.

Figura 2 Evento 4097 AxInstallService

AxIS es un componente opcional que se incluye con los SKU Business, Enterprise y Ultimate de Windows Vista, y se puede habilitar a través de una opción desatendida o a través del cuadro de diálogo Panel de control (Programas | Programas y características | Activar o desactivar las características de Windows), tal como se muestra en la figura 3. Una vez habilitado, AxIS avanza por los pasos resumidos anteriormente cada vez que Internet Explorer solicita un control.

Figura 3 Habilitación de AxIS en el Panel de control

La capacidad de adjuntar tareas a eventos en Windows Vista ofrece una manera sencilla para que un administrador reciba una notificación del servicio de AxIS, como cuando la instalación de un control ActiveX está bloqueada. Es importante tener en cuenta que no siempre se puede suponer que el control ActiveX se instalará desde el mismo nombre de host de dirección URL que el usuario final que tiene acceso desde su sitio web. Por este motivo, la información que proporciona el evento AxInstallService 4097 (instalación intentada) se puede demostrar increíblemente útil en la identificación del host desde el que se intenta instalar el control.

Con la información que obtiene del evento, puede configurar la ubicación de confianza en la directiva de grupo. La configuración de AxIS en la directiva de grupo o local se encuentra en los valores de configuración del equipo (como puede ver en la figura 4). Los sitios de instalación aprobados para la configuración de directivas de controles ActiveX le permiten especificar direcciones URL de host de ubicaciones de confianza (consulte la figura 5). La configuración de sitio aprobada requiere dos fragmentos de información, desde donde se puede instalar el control ActiveX y el comportamiento de la instalación.

Figura 4 Configuración del Editor de objetos de directiva de grupo

Figura 5 Sitios de instalación aprobados por AxIS

En primer lugar, como se mencionó anteriormente, se requiere una dirección URL de host para indicar la ubicación de confianza del control. A diferencia de las soluciones anteriores, que requerían saber el CLSID del control (que a menudo cambia cuando los desarrolladores modifican los controles), AxIS permite la instalación de cualquier control desde la ubicación de confianza, con lo que se reduce la carga administrativa general. El segundo fragmento de información es una cadena delimitada por comas de cuatro valores; cada uno de los cuales dicta el comportamiento de la experiencia de descarga del control ActiveX. Los valores especifican cuatro propiedades: TPSSignedControl, SignedControl, UnsignedControl y ServerCertificatePolicy. Las primeras dos propiedades (TPSSignedControl y SignedControl) pueden tener uno de estos tres valores: 0, 1 ó 2. Estos valores son similares a los valores encontrados en la configuración de URLAction. Un valor de 0 impide la instalación del control, un valor de 1 hace que al usuario se le pida permiso para instalar y un valor de 2 hace que el control se instale en silencio en nombre del usuario. Los controles sin firmar no se pueden instalar en silencio y por tanto el valor de UnsignedControl sólo puede ser 0 ó 1. Tenga en cuenta que si no se especifica ninguna directiva, se usan los valores predeterminados de 2, 1 y 0.

La propiedad final especifica el comportamiento de la instalación según la configuración de certificado del control de configuración firmada. Como la mayoría de los sitios SSL, los certificados deben superar un conjunto de pruebas de seguridad para asegurarse de que el certificado es válido. Las propiedades de certificado no válido son a veces la realidad de la implementación del control ActiveX firmado del mundo real. A través de su configuración, AxIS permite a los administradores mitigar la información no válida que se presenta a veces con certificados en una base de dirección URL por dirección URL. La propiedad final está representada como una combinación de máscaras de bits de los valores mostrados en la figura 6.

Figura6 Tabla valores AxIS

La configuración predeterminada es 0, lo que significa que deben superarse todas las comprobaciones de seguridad antes de que AxIS complete la instalación. La combinación de la configuración de host y estos cuatro valores se especifican en la configuración de directiva, tal como se ve en la figura 7.

Figura 7 Direcciones URL de host de AxIS aprobadas

Conclusión

AxIS le permite configurar la directiva de grupo para controlar qué usuarios de controles ActiveX pueden instalar sin requerir privilegios administrativos o configuraciones complejas. El control en este nivel podría ser un desafío en versiones anteriores de Windows y las soluciones disponibles anteriormente a menudo se incluían con limitaciones graves o aumento en la sobrecarga de administración. AxIS ofrece a las organizaciones otra herramienta para el método de privilegio mínimo para los derechos de usuario finales en sistemas de escritorio, permitiendo la implementación de un modelo de usuario estándar donde los usuarios finales no requieren privilegios administrativos. Windows Vista devuelve el control al administrador de TI al disponer de la elección de qué controles ActiveX son de confianza dentro del entorno corporativo determinado por la organización, no el usuario final.

Fuente artículo: Microsoft