Microsoft Windows y el control de acceso, al desnudo

En el estudio se desmitifica el funcionamiento del sistema operativo Windows a la hora de controlar el acceso a sus recursos y se explica cómo algunos comportamientos han provocado vulnerabilidades no sólo en el sistema operativo, sino en conocidos programas comerciales.

Estos investigadores han usado la programación lógica para implementar lo que han llamado MulVAL (Multihost, Multistage, Vulnerability Analysis) una herramienta que han utilizado para analizar profundamente el control de acceso de los sistemas Windows XP. Mediante la información recopilada desde distintas fuentes del sistema (el registro, sistema de ficheros…) el modelo implementado elabora una especie de “mapa” por el que se revelan varias posibles fórmulas y distintas vías de ataque, todas destinadas a elevar los privilegios de un usuario local en el sistema. Con esta herramienta, entre otras, se han encontrado hasta 20 formas distintas de escalar privilegios desde cuentas del grupo “usuarios avanzados” a administradores. Aunque los usuarios avanzados poseen bastantes privilegios sobre la máquina, no llegan a los totales poderes del administrador.

En el estudio se habla también de forma clara y sencilla sobre los potenciales peligros de la implementación incorrecta de las listas de control de acceso a los objetos Windows y se plantean fórmulas por las que se puede llevar a un usuario del sistema a poder ejecutar cualquier tipo de código con los permisos del administrador o de cuentas reservadas del sistema con altos privilegios.

Si Unix tiene un modelo simple de control de acceso basado en tres privilegios (además del bit UID) que se dan a distintos objetos del sistema (ficheros, directorios…), el sistema de Windows es mucho más complejo. Se arrastra una lista de control de acceso de hasta 30 permisos diferentes para operaciones sobre unos 15 tipos distintos de objetos, todo ello con la posibilidad de negar o permitir explícitamente el privilegio. Esto permite afinar en extremo los permisos, pero también puede suponer un verdadero galimatías para un administrador o para un programador que quiera desarrollar una herramienta que interactúe con los objetos del sistema, pues deben documentarse profusamente y comprender la compleja estructura de permisos.

Aunque los permisos en Windows están bien documentados y detallados, resulta muy común observar cómo los creadores de software profesionales a menudo no evalúan correctamente el impacto que puede llegar a tener la instalación de su programa en un sistema sin haber afinado correctamente los permisos que han elegido para sus aplicaciones. La consecuencia es que mucho software comercial puede llevar a la elevación de privilegios por parte de usuarios en sistemas compartidos, y de hecho ya se han dado casos concretos.

Hace poco, a principios de febrero de 2006, se han identificado errores de permisos en ficheros y directorios en varios productos Adobe tales como Adobe Photoshop CS2, Illustrator CS2, y Adobe Help Center. El grupo “Todos” tenía permiso de escritura en 170 archivos (ejecutables y librerías) de productos Adobe. Un atacante podría sustituirlos por código malicioso en local y esperar a que el administrador los ejecutara para poder arrancar ese código con mayores privilegios. La configuración estándar de AOL, entre otros, también permitía a un usuario invitado ejecutar código con los permisos de cualquier otro usuario (incluso los de “Local System”), simplemente manipulando claves de registro. Los permisos de las ramas de registro, según apunta el estudio, pueden suponer también habitualmente un problema de seguridad.

La herramienta que desarrollaron estos investigadores ha ayudado a descubrir muchos problemas de permisos tanto en software comercial como en componentes del sistema. El caso de los servicios es especialmente significativo. Al existir tantas formas y combinaciones posibles de permisos, los desarrolladores optan por distintas vías (por no existir una convención única) para implementar la funcionalidad de un servicio propio que correrá en sistemas Windows. Cada servicio tiene un descriptor de seguridad que especifica a qué usuarios se les permite configurar o arrancar o parar un servicio. Algunos fabricantes no aplican correctamente el modelo de control de acceso de Windows en sus servicios y por ejemplo, otorgan indiscriminadamente el permiso “SERVICE CHANGE CONFIG” que permite modificar el ejecutable ligado al servicio. Microsoft recomienda que este permiso sea sólo dado a los administradores, pero en su documentación no avisa explícitamente de que este permiso también permite no sólo modificar el ejecutable sino especificar quién lo hará, de forma que si, a través de cualquier programa instalado se posee este privilegio, se puede ejecutar potencialmente cualquier fichero bajo cualquier cuenta del sistema.

Por ejemplo, el grupo “Todos” tenía este permiso de configuración activado en el servicio “Macromedia Licensing Service” que instalaban varios productos de Macromedia. Afortunadamente este problema fue solucionado en junio de 2005. Existen otros agujeros menos graves en servicios de fabricantes ajenos a Microsoft, pero en el estudio no se dan detalles a la espera de que puedan ser solventados.

No sólo a través de servicios de terceros es posible elevar privilegios. Por ejemplo, según el estudio, varios servicios de Windows XP, tales como “Servicio de descubrimientos SSDP” y “Host de dispositivo Plug and Play universal” tenían hasta hace poco ese privilegio (“SERVICE CHANGE CONFIG”) activado por defecto para el grupo “Usuarios Autenticados”. Cualquier usuario con cuenta en el sistema pertenece a ese grupo, por lo que potencialmente cualquier usuario podía modificar el ejecutable que arrancaba estos servicios y la cuenta bajo la que iba a ejecutarse. Se permitía así, indirectamente, la instalación de un troyano o software dañino modificando la configuración del servicio y esperando a que fuese reiniciado. Esto fue solucionado por Microsoft en agosto de 2004, aunque el peligro estaba presente desde casi dos años antes. Otros servicios del sistema se descubrieron vulnerables y también fueron parcheados posteriormente.

El problema se basa en que las aplicaciones que instalamos necesitan normalmente muchos menos privilegios de los que realmente poseen para acceder a los datos con los que operan. Encontrar el conjunto de permisos estrictamente necesarios para que funcione una aplicación bajo condiciones lo más asépticas posibles de seguridad, es objeto de otro estudio liderado en 2005 por Shuo Chen, y titulado “A black-box tracing technique to identify causes of least-privilege incompatibilities”. En él se explica una técnica para encontrar en los programas los mínimos privilegios posibles y necesarios que le son necesarios para funcionar.

En definitiva, con la herramienta desarrollada por Sudhakar Govindavajhala y Andrew W. Appel, se permite facilitar la tarea del estudio de los controles de acceso a sistemas Windows, algo, como se ha visto, delicado. Como la herramienta puede considerarse potencialmente peligrosa, no se ha hecho pública, aunque sí se recomienda a los administradores usar herramientas análogas de estudio y modificación de permisos, tales como SubInACL de Microsoft, y estudiar con ellas cuidadosamente los permisos de los ficheros y objetos del sistema.

Tanto en entornos domésticos como corporativos, gran parte de los problemas de seguridad de Windows vienen por el hecho de usar el sistema en modo administrador. Entender los permisos y controles de acceso es fundamental para limitar el impacto de los fallos de seguridad del software, pero parece ser que Microsoft, en este sentido, no termina de entenderse con los usuarios ni con los programadores de aplicaciones. No hay razón para pensar que los desarrolladores de Adobe, Macromedia o AOL han sido los únicos que han cometido errores y es seguro que otros fallarán en los mismos términos. Estudios como los expuestos demuestran que un cambio de rumbo y una mayor concienciación por ambas partes en este sentido harían de Windows un sistema operativo más seguro.