Archivos del escritorioDejando detrás al administrador

Wes Miller

Hace más de tres años, empecé a cambiar la cuenta de usuario de mi sistema principal de Windows de cuenta de administrador local a cuenta de usuario local. Había trabajado en Microsoft durante más de siete años y siempre me había ejecutado como un administrador con todos los privilegios. Claro que era muy conveniente, aunque la espantosa falta de seguridad

pone de manifiesto la suerte increíble que tantos de nosotros hemos tenido de no haber sido testigos más a menudo de daños más corrosivos infligidos a un número mayor de sistemas habiéndonos ejecutado como administradores a diario.

A menudo me gustaría que hubiera una manera de obtener una buena estadística de esto, pero tanto mi intuición como la industria me dicen que demasiadas organizaciones (y muchos profesionales de TI también) se ejecutan en la actualidad como administradores locales. En Winternals, cuando empecé a ejecutarme como usuario, fue con la premisa de comprender la dificultad que entrañaba (en calidad de "prosumer") y de ver cómo nuestro producto, Winternals Protection Manager, podría ser útil para las organizaciones tipo. Dado que la mayoría de las organizaciones presentaban (aún lo hacen) un buen porcentaje de usuarios ejecutándose como administradores, nuestro objetivo era habilitar a los administradores para que se ejecutaran como usuarios al tiempo que reducíamos el período de transición (al menos sus puntos más espinosos) a su mínima expresión. Al margen de la tecnología que use, no es fácil transformar el carácter de su organización de "administrador" a "usuario". Sin embargo, es la manera más eficaz de reducir la superficie de ataque dentro de su organización. Plantéeselo como un firewall intrasistema, porque de esto se trata exactamente.

¿Cómo lo conseguimos?

Le propongo un desafío: sienta el dolor

Si aún no ha pensado en transformar a sus administradores en usuarios, debería hacerlo. Y le animo a que empiece el experimento por usted mismo. Pero no lo haga en un equipo secundario; eso se llama hacer trampas. Haga la prueba en su sistema principal, el mismo que usa a diario. También le propondría que haga la prueba incluso sin usar el Control de cuentas de usuario (UAC, User Account Control) si ejecuta Windows Vista®. Cuando uno empieza a predicar las bondades de una iniciativa en su organización para cambiar algo, es recomendable mostrarse como un buen practicante antes de evangelizar. Creo que llegará a la conclusión de que ejecutarse como no administrador no es tan difícil y que con el plus de seguridad que conlleva, podrá cambiar realmente la superficie de ataque de su organización.

Que la mayoría de los usuarios actúen como administradores es una costumbre muy arraigada en la tradición de Windows®. Con las primeras versiones de Windows, antes de Windows NT® 3.1, todos los usuarios interactivos se autorizaban del mismo modo, por lo que, funcionalmente, no había seguridad. Al principio, esto no era terrible, pues significaba que todo el software se instalaba de la misma manera. Se asumía que el usuario era propietario del equipo y que el software se instalaba para todos los usuarios de ese equipo.

Cuando Windows NT apareció por primera vez, no se hizo de inmediato con el mercado de la empresa (no digamos del consumidor). A causa de la compatibilidad que Win32® proporciona entre Windows de 32 bits y Windows NT, la mayoría de los proveedores de aplicaciones no recrearon sus aplicaciones por la infraestructura de seguridad de Windows NT. De hecho, no fue hasta la aparición de Windows 2000 que muchos proveedores de software independiente (ISV, Independent Software Vendor) orientados al consumidor empezaron a prestar atención a Windows NT. Fue Windows XP, por supuesto, el que forzó la situación, ya que puso punto final a la familia 9x de Windows.

Pero las aplicaciones siguieron, asumiendo que cada usuario en el sistema tenía acceso para escribir en Archivos de programa (los usuarios no) de usuarios, HKEY_LOCAL_MACHINE (HKLM) en el Registro (los usuarios no) y HKEY_CLASSES_ROOT (los usuarios no). Los juegos se encuentran a menudo entre los peores ofensores a la hora de asumir el acceso. Consulte el artículo de Matt Clapham sobre este tema en technetmagazine.com/issues/2007/02/Gaming.

Esto es problemático porque la mayoría de las aplicaciones entre sistemas almacenan la configuración de sus archivos y del Registro en esas ubicaciones. Por esta razón, usted necesita poder leer y escribir en esas ubicaciones para instalar las aplicaciones. Desgraciadamente, algunas aplicaciones insisten en escribir en esas claves después de la instalación. Por ejemplo, mi hija tiene un juego que se basa en Flash. La aplicación intenta instalar un jugador personalizado cada vez que se ejecuta, lo que significa que cuando mi hija ejecuta como usuario (no como administrador) la aplicación no se inicia y genera un error fatal. Aunque esto es extremo y se trata de una aplicación de consumidor, la realidad es que muchas aplicaciones que no son de este tipo no encajan bien en el mundo de los usuarios no administrativos. De hecho, si presta atención a mi desafío (consulte la barra lateral, "Le propongo un desafío: sienta el dolor"), descubrirá la intolerancia del propio Windows para ejecutar como usuario.

Si observa la Figura 1, verá el aspecto que tiene en Windows XP la ejecución de IPConfig/release como usuario. Si lo compara con la Figura 2, verá que el mismo comando no es mucho mejor en Windows Vista, pero al menos sabe por qué el comando genera un error. Tenga en cuenta que las herramientas de redes en general se han mejorado para permitir que los usuarios actualicen sus direcciones IP. De forma similar, intentar ejecutar Computer Management (compmgmt.msc) como usuario en cualquiera de las versiones le permite realizar un número limitado de tareas, pero generalmente tiene como resultado situaciones frustrantes e irresolubles, como muestra la Figura 3. Aunque Windows Vista no habilita inicialmente muchas de las herramientas de Computer Management, presenta mensajes más claros de acceso denegado.

Figura 1** Ejecución como usuario en Windows XP **(Hacer clic en la imagen para ampliarla)

Figura 2** Ejecución como usuario en Windows Vista **(Hacer clic en la imagen para ampliarla)

Figura 3** Mensaje engañoso después de ejecutar compmgmt.msc como usuario en Windows XP **(Hacer clic en la imagen para ampliarla)

Por qué es importante

¿Por qué debe importarle? Porque nosotros, como profesionales de TI, deberíamos empezar a facilitar la adaptación de las aplicaciones a los usuarios con menos privilegios, en vez de hacer lo contrario en los casos en que las aplicaciones asumen que el usuario interactivo es propietario del sistema.

Desgraciadamente, las mismas directivas que permiten a los administradores escribir en claves del Registro conceden también acceso completo a cualquier malware que se ejecute en su contexto de usuario para todo destino que no se haya denegado explícitamente a través de las listas de control de acceso (ACL, Access Control List). En el ámbito de UNIX, las personas siguen la regla relacionada con la no ejecución como raíz (el equivalente funcional de la cuenta de administrador de Windows), en su mayor parte porque el ecosistema de software que rompe los límites del modelo de seguridad es insignificante o inexistente.

Aún así, lo mejor que puede hacer es aplicar la misma sabiduría y ejecutar como administrador sólo cuando sea explícitamente necesario; o mejor todavía, ejecute como administrador sólo las aplicaciones individuales. Al hacer esto, se levanta el firewall intrasistema que mencioné anteriormente. De este modo, cuando el malware o el spyware intentan hacer de las suyas, fracasan porque no pueden escribir en las ubicaciones del Registro o del sistema de archivos necesarias para infectar el sistema (como instalar un servicio o un controlador, o hacer una instalación para todos los usuarios). Además, esta acción permite que el software antimalware contenga malware que reconoce, sin poner en peligro el sistema entero primero.

Tenga en cuenta, sin embargo, que los usuarios no son impermeables a los ataques. Aunque esta clase de malware no está muy extendida aún, existe la posibilidad de que el malware tenga éxito a la hora de infectar el contexto de un usuario individual o destruir sus datos. Pero el vector de ataque que dicho software plantea es limitado. Como resultado, el mismo factor que reduce las instancias de malware al mínimo en Linux o Macintosh (el número reducido de víctimas potenciales lo convierte en un caldo de cultivo menos atractivo para los autores de malware) puede ayudar a asegurar la seguridad general de sus usuarios finales (y la suya propia) en la actualidad.

¿Qué podemos decir de los usuarios avanzados?

Cuando estábamos desarrollando Protection Manager, uno de los comentarios que nos llegaba de los clientes era el siguiente: "Ejecutamos Windows XP con todos nuestros usuarios actuando como usuarios avanzados, no administradores, así que estamos seguros". La realidad, sin embargo, es que los usuarios avanzados no están a mucha distancia de los administradores. Hay varias carencias posibles que, con un poco de trabajo, permitirían a un usuario avanzado de Windows XP convertirse en administrador. De hecho, el grupo de usuarios avanzados se eliminó de Windows Vista y Windows Server® 2008. Sólo los sistemas actualizados a partir de versiones anteriores de Windows tendrán un grupo de usuarios avanzados. Con todo, siempre debería evitar el uso del grupo de usuarios avanzados, incluso en Windows XP.

Permisos con pérdidas

Si leyó mi columna de marzo sobre clientes ligeros de Windows (technetmagazine.com/issues/2008/03/DesktopFiles), recordará que me mostré contrario a la reducción de Windows XP para ahorrar espacio. En la misma línea, existe una práctica común para habilitar a los administradores que se encuentran en el período de transición a usuarios que deberá tener en cuenta, pero hágalo con cuidado. Me refiero a la práctica del ajuste de las ACL en el Registro y en el sistema de archivos para que los usuarios puedan escribir en ubicaciones donde habitualmente no les está permitido hacerlo, habilitando así aplicaciones problemáticas.

Obviamente, la mejor elección consiste en obtener una versión actualizada de una aplicación que no requiera dicho cambio, aunque eso no siempre es posible. Si debe cambiar los permisos (es decir, anularlos), proceda con mucho cuidado. Recuerde que el firewall entre un usuario y un administrador está definido en gran medida por los permisos de Registro y de sistema de archivos. Abrirlos reduce la protección y aumenta potencialmente la superficie de ataque planteada por el malware, de modo que actúe con sensatez.

¿Qué podemos decir de UAC?

El debate sobre la transición de administrador a usuario no puede estar completo sin abordar el Control de cuentas de usuario (UAC, User Account Control) en Windows Vista. UAC, al igual que la funcionalidad similar de Mac OS X, le permite ejecutar "como un administrador" sin necesidad de asumir tantos riesgos.

¿Cómo funciona? En la Figura 4, observe lo que Process Explorer muestra acerca de cmd.exe. La instancia de cmd.exe de la derecha se inició sin elevación y conmigo haciendo las veces de administrador. Como consecuencia, aunque el usuario de la derecha sea idéntico al de la izquierda (donde cmd.exe se inició con elevación), la propia aplicación no contiene los privilegios y símbolos (token) necesarios para realizar ninguna tarea que requiera derechos administrativos (lo mismo ocurre con el usuario que ejecuta esa instancia). El funcionamiento de UAC consiste en reducir la superficie de ataque dentro del contexto interactivo de un usuario. El único problema es que algo tiene que decirle a Windows que esta tarea requiere privilegios administrativos y que el usuario está conforme con permitir que la elevación requerida complete la tarea.

Figura 4** Dos instancias de cmd.exe con privilegios diferentes **(Hacer clic en la imagen para ampliarla)

En Windows Vista, las pequeñas protecciones le indican las tareas que requieren elevación (consulte la Figura 5). Estas tareas requerirán elevación siempre que las ejecute, siendo éste uno de los puntos débiles que la prensa ha destacado de Windows Vista. La alternativa, que permite que las credenciales sean más "duraderas", plantea una amenaza potencial para la seguridad que podría usarse para atacar el sistema con más facilidad.

Figura 5** Las protecciones de Windows Vista indican la necesidad de elevación **(Hacer clic en la imagen para ampliarla)

Si UAC está habilitado y sus usuarios ejecutan simplemente como usuarios, se les pedirá un conjunto de credenciales administrativas cuando una aplicación requiera privilegios administrativos. Advierta en este caso que, como cuando usa runas o psexec, la aplicación se ejecuta literalmente en el contexto del usuario que la ha iniciado, a diferencia de lo que ocurre con los administradores en UAC. En ese caso, las tareas se ejecutan en su contexto, pero con privilegios elevados.

¿Ejecuta Windows Vista como usuario?

Mi preferencia personal al ejecutar Windows Vista es hacerlo como usuario, no como administrador con UAC, porque creo que sigue siendo la mejor idea en el caso de la empresa tipo. A fin de cuentas, sus usuarios tienen control absoluto sobre sus sistemas y puede que usted haya reducido las oportunidades para el malware.

Es más, si pretende administrar a sus usuarios con directivas de grupo, antivirus, antimalware u otro software y desea tener un control central sobre si estas tareas se aplican o completan, es vital que se asegure de que sus usuarios finales no son administradores. Si los usuarios son administradores, podrán detener los servicios, agregar o quitar controladores, etc. Por supuesto, un usuario final astuto que ejecute como usuario podrá usar Windows PE para eludir algunos obstáculos de seguridad. BitLocker® puede dificultar esta acción, pero una vez más, recuerde que los usuarios finales con acceso físico pueden hacer lo que quieran a sus equipos siempre que cuenten con el tiempo, el conocimiento y la dedicación necesarios.

Ejecutar Windows Vista como usuario no es muy distinto de ejecutar Windows XP como usuario. Uso las mismas herramientas (PSExec, RunAs y ahora UAC) para ejecutar tareas como administrador. Lo mejor es que bastantes tareas que requerían privilegios administrativos en Windows XP ya no los necesitan. Por ejemplo, un usuario de Windows Vista puede instalar una impresora local. Los usuarios podían instalar impresoras de red en Windows XP, pero la instalación de una impresora local requería privilegios administrativos. En Windows Vista, siempre que el usuario se encuentre físicamente en el equipo y el controlador de impresora esté en el almacén de controladores, el usuario podrá instalar una impresora y administrar sus trabajos de impresión (consulte go.microsoft.com/fwlink/?LinkId=111534 para obtener más información). Tenga en cuenta que esta funcionalidad está deshabilitada en Windows Server 2008.

Por supuesto, la gente se ríe de la funcionalidad de reloj (o de la falta de la misma) al ejecutar como usuario en Windows XP. Pruebe a hacer doble clic en el reloj como usuario (algo que la gente hace a menudo para consultar la fecha, aunque no se diseñara para tal fin) y obtendrá el error que se muestra en la Figura 6. Con amigos así... En Windows XP, puede modificar la directiva para que los usuarios puedan realizar esta acción, pero en Windows Vista se cambió para que funcionara de ese modo. Con todo, la ejecución como usuario (tanto si usa UAC como si la ejecución se realiza como un usuario formal elevando privilegios como otro usuario) es en general una experiencia más grata en Windows Vista que en Windows XP.

Figura 6** En Windows XP, los usuarios que no son administradores no pueden cambiar la hora. **(Hacer clic en la imagen para ampliarla)

Recuerde los límites

Recuerde que cambiar el estado de los usuarios para que no sean administradores no es la panacea. Los usuarios finales dedicados todavía están ubicados físicamente en sus propios equipos y pueden trabajar diligentemente para aprovecharse de una vulnerabilidad de sus propios sistemas, especialmente si la directiva y los privilegios de usuario les resultan molestos o les impiden realizar su trabajo.

Si sus usuarios ejecutan como administradores, no es muy complicado eludir cualquier directiva de grupo en vigor. Por supuesto, con un poco más de esfuerzo, los usuarios pueden arrancar Windows PE y modificar los permisos para los que normalmente no tendrían privilegios. Sin embargo, si usa BitLocker u otro sistema de cifrado de unidad de disco o volumen, puede impedir esta acción o, al menos, dificultar la consecución de su propósito.

Si su organización no ha comenzado aún la transición para que los usuarios finales ejecuten como usuarios, lo mejor que puede hacer es familiarizarse con las razones por las que usted y su organización deberían invertir tiempo, dinero y esfuerzo para alejarse de un modelo en el que los usuarios ejecutan como administradores.

Claro, es difícil desprenderse de las aplicaciones heredadas, pero si dispone de una aplicación que simplemente no se puede ejecutar como usuario, no es aconsejable aferrarse a ella a costa de la seguridad de su organización. Debería considerar virtualizar la aplicación, es decir, moverla literalmente a un equipo virtual en el que el usuario es un administrador a todos los efectos. Esto hace posible que la aplicación se use del modo necesario, pero le permite proteger el resto del sistema transformando a los administradores en usuarios.

Tenga en cuenta que en mi columna no aparece la palabra "bloqueo" ni ninguno de sus derivados. Muchas personas consideran que la transformación de los administradores en usuarios es parte de una tarea que a menudo se describe con esta palabra. Puede que sean mis orígenes en el campo de la psicología o mi ubicación actual en el mundo del marketing, pero me parece importante no usar palabras que hagan creer a los usuarios finales que están perdiendo sus privilegios (aunque semánticamente sea correcto).

Por contra, céntrese en las ventajas que conlleva para la seguridad de la organización y asegúrese de que tiene un buen plan para los casos extremos en que un usuario específico no pueda ejecutar como usuario o haya una tarea concreta que requiera privilegios de administrador. Tanto si usa un procedimiento manual como el script Run.vbs (que puede encontrar en technetmagazine.com/issues/2007/03/DesktopFiles), como si emplea una solución comercial para hacer la transición (eso le permite ocultar los detalles de sus usuarios finales y hace que las cosas "funcionen"), es importante tomar la senda de los "no administradores" lo antes posible. El evangelista de la ejecución como no administrador es Aaron Margosis, colaborador habitual de TechNet Magazine. Si no está familiarizado con su blog, hágalo cuanto antes. Se trata del mejor sitio para encontrar información detallada sobre este tema (consulte blogs.msdn.com/aaron_margosis). 

Wes Miller es en la actualidad jefe de productos técnicos senior en CoreTrace (www.CoreTrace.com), con base en Austin, Texas. Anteriormente, trabajó en Winternals Software y como Administrador de programas en Microsoft. Si lo desea, puede ponerse en contacto con Wes en la dirección technet@getwired.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.