Retomamos el tema de «Windows Service Hardening» para comprobar otro aspecto de seguridad de Windows Vista: «Los SID de Servicio».
La seguridad en los servicios es uno de los aspectos que más se ha buscado potenciar en Windows Vista dada la importancia que tienen en la estabilidad y funcionalidad del sistema, a la cual ya nos aproximamos en el artículo anterior referente a este mismo tema:
La problemática de restringir el acceso a un servicio en Windows XP
Una de las maneras más sencillas e intuitivas de mejorar la seguridad de cualquier aplicación o sistema es mediante «listas de control de acceso» o ACL en las que se describa que usuario o grupo puede tener acceso a un recurso indicado. Habitualmente el primer sistema de control de acceso que utilizamos son los permisos del sistema de archivos, de esta manera, si no queremos que un servicio sea capaz de acceder a un contenido concreto, solo tenemos que denegar, a nivel de disco, el permiso al usuario mediante el cual se ejecuta el servicio; no obstante esto no siempre es tan sencillo como parece.
La mayoría de los servicios en Windows se ejecutan gracias a los usuarios de bajos privilegios «LocalService» y «NetworkService» y al usuario de elevados privilegios «LocalSystem», de manera que si deseamos denegar el acceso de un servicio a un determinado recurso, y dicha denegación la realizamos para alguna de las cuentas citadas anteriormente, estaremos en realidad restringiendo el acceso a todos los servicios que hagan uso de esa cuenta. La solución pasaría por tanto por la creación de una nueva cuenta de usuario para el servicio al que deseamos denegar el acceso, sin embargo esto puede resultar contraproducente para la seguridad del sistema (y por tanto para la integridad del mismo) dado que los usuarios «NetworkService» y «LocalService» disponen de privilegios más bajos que los de cualquier usuario corriente, debiendo modificar las políticas del sistema si deseamos realizar una equiparación de privilegios.
La solución ideal a esta problemática sería usar los privilegios de «NetworkService» y «LocalService» y además poder establecer ACLs para denegar accesos al servicio deseado en particular sin que otros servicios se vean afectados. El sistema que Windows Vista incorpora para este fin son los «SID de Servicio».
La solución: Los SID de Servicio en Windows Vista
Las ACLs de Windows hacen uso de un identificador de seguridad y de usuario único conocido como SID (Security Identifier), que permite entre otras cosas que cambiemos el nombre y las propiedades de un usuario o grupo sin que por ello estemos interfiriendo en los permisos aplicados a estos. Existen SID bien conocidos de los cuales podéis encontrar una descripción en el siguiente enlace:
http://support.microsoft.com/kb/243330
Para nuestro caso en particular tendríamos lo siguiente:
SID Local System: S-1-5-18
SID LocalService: S-1-5-19
SID NetworkService S-1-5-20
Excepto para cuentas genéricas como las citadas, los SID deben ser únicos para cada sistema y cuenta, de ahí que puedan aparecer problemas de seguridad en la red al realizar una duplicación de un equipo mediante imágenes y que debamos usar herramientas como «Sysprep» o «NewSid» para solucionarlos.
Windows Vista hace uso de los SID para establecer permisos para los Servicios, de manera que se pueda aplicar una configuración de ACLs determinada sin interferir con otros servicios y aplicando a su vez los permisos propios del usuario con el que se ejecuta (LocalService, NetworkService y LocalSystem).
Para comprobar los SID aplicados a cada servicio haremos uso del «comando SC» que ya utilizamos en el anterior post.
Comprobando el SID de un servicio mediante el comando SC:
sc showsid [Nombre del servicio]
Nota: El nombre que debemos indicar en el comando es el nombre corto del servicio, es decir, aquel presentado en el campo «NOMBRE_SERVICIO» al ejecutar «sc query» (por ejemplo «WSearch» es el nombre corto de «Búsqueda de Windows»).
Es importante que introduzcamos correctamente el nombre del servicio dado que «sc showsid» calcula el SID a partir del nombre indicado, de manera que podría devolvernos un valor falso si introducimos el nombre incorrectamente, el hecho de que se calcule el SID a partir del nombre permite que el SID del servicio sea el mismo para cualquier equipo en el que nos encontremos, esto nos permite aplicar permisos mediante Scripts sin necesidad de consultar previamente cual es el SID a usar en ese sistema específico.
Comprobación práctica: Impidiendo el acceso del programador de tareas.
A continuación vamos a realizar una comprobación práctica de todo lo que hemos visto hasta ahora, para ello usaremos el comando «SC» para consultar el SID del servicio y el comando «ICACLS» para establecer los permisos.
El servicio «Programador de Tareas» ejecuta aplicaciones de manera periódica según una programación o eventos concretos, y dicha configuración se ubica en forma de archivos XML en %SystemRoot%System32Tasks. En nuestro caso, a modo de demostración práctica, vamos a prohibir al servicio de programación de tareas el acceso a dicha carpeta para comprobar de primera mano los errores que nos ofrece la aplicación.
La aplicación de este procedimiento causará problemas en el sistema, de manera que no deberíais aplicarlo en un entorno de producción. Si deseáis realizar la práctica os puede valer una máquina virtual de pruebas o cualquier «Virtual Lab» de Windows Vista de la Web de Microsoft.
Lo primero es obtener el SID del servicio, para ello debemos ejecutar lo siguiente desde el CMD:
Obtener nombre corto de servicio:
sc query
Obtener SID de Servicio:
sc showsid
Como me imagino que los curiosos habrán notado ya, no es posible establecer permisos a un SID determinado a través de entorno gráfico, de manera que para poder realizarlo debemos usar la herramienta de línea de comandos «ICACLS», que sustituye al antiguo CACLS de Windows XP que era menos funcional.
Es una buena práctica, comprobar la ayuda del comando ICACLS para comprobar las potentes funcionalidades que ofrece con respecto a su antecesora CACLS (también disponible en Windows Vista), para ello debemos ejecutar «icacls /?». Podéis ver una descripción de sus funciones en el siguiente enlace:
En el caso que nos ocupa debemos ejecutar el siguiente comando para denegar el acceso al servicio de «Programación de Tareas»:
icacls c:windowssystem32tasks /deny *S-1-5-80-4125092361-1567024937-842823819-2091237918-836075745:(F)
Nota: Dado que necesitamos privilegios para cambiar los permisos, deberemos ejecutar el CMD con Privilegios de Administrador, seleccionando la opción «Ejecutar como administrador» del menú contextual.
Una vez denegado el acceso al servicio, para comprobar si realmente se están aplicando los permisos indicados abrimos el complemento «Programador de Tareas» dentro de «Herramientas Administrativas» en el «Panel de Control». Comprobemos el error que nos aparece al abrir el complemento.
Por último, comprobemos mediante el entorno gráfico los cambios en los permisos NTFS que se han aplicado en %systemroot%system32tasks.
Impedir el acceso de escritura a un Servicio:
Por último solo quedaría explicar un último parametro del comando SC: «sc sidtype [nombre de servicio][tipo]» donde «tipo» puede ser «none», «Unrestricted» y «Restricted».
El parametro «Restricted» nos permite restringir el acceso de escritura de un servicio a las ubicaciones donde no se le de permiso de escritura de manera explicita a su SID de servicio, a no ser que los permisos se establezcan para el grupo Todos.
De manera predeterminada un servicio en modo «Unrestricted» o «None» tiene acceso de escritura a las ubicaciones donde LocalService, NetworkService o LocalSystem (según cual de estas cuentas ejecute el servicio) tenga acceso. Los cambios realizados al tipo de SID tienen efecto la proxima vez que se inicia el servicio.
El parametro «None» hace que el servicio se comporte como en Windows XP, omitiendo los permisos que se establezcan para el SID de servicio asociado (los permisos establecidos a través del SID no tendrían efecto).
Podemos consultar si un servicio esta en estado restringido mediante «sc qsidtype [nombre de servicio]».
Comprobación del tipo de SID para el Servicio «Firewall de Windows» :
Bueno, aquí acabamos con el tema del endurecimiento de Servicios de Windows Vista, pero no por ello la comprobación de tecnologías de Integridad, de manera que en futuros post iremos desgranando nuevos aspectos de la Seguridad de Windows Vista, para que podáis valorar vosotros mismos el cambio de perspectiva de este Sistema Operativo.
Me cago en vuestra MADRE!!!!!!!!!!!!
@UNO QUE YO MES
Palomita blanca, palomita azul, todo lo que digas lo serás tú! 😉