Sistemas de Integridad en Windows Vista I: Windows Service Hardening (primera parte)

 

Retomamos de nuevo la seguridad en Windows Vista tratando esta vez sobre los sistemas de integridad «Integrados» en este sistema operativo. Es decir, vamos a ahondar un poquito más en que es lo que ha puesto tan nerviosas a empresas Antivirus como Symantec a parte de técnologias como el Firewall de Seguridad Avanzada de Windows Vista, el UAC o ASLR.

 

En próximos Posts hablaremos de tecnologías de integridad como MIC, UIPI, o el servicio TrustedInstaller, de momento, por hoy, nos conformaremos con acercarnos a las notables mejoras de seguridad de los Servicios de Windows: el conjunto de funcionalidades recogidas dentro de WSH (Windows Service Hardening), que vienen a ser las mismas siglas que «Windows Scripting Host» para los entendidos.

 

Limitaciones de los Servicios en Windows XP:

Windows XP (sistema muy defendido por los opositores a Windows Vista) sufría de carencias de seguridad en la manera de trabajar de los servicios, pese a las grandes mejoras realizadas en este ámbito con respecto a Windows 2000. Con todo eso, aun me toca oir a algún Tecnicoless (perdona Maligno por tomar prestado el término) que Windows 2000 es mejor que Windows XP…  En fin, anécdotas aparte, lo cierto es que nos encontrábamos limitados a la hora de trabajar con los servicios de XP, algo que los distintos tipos de malware no dudan en aprovechar.

 

Por ejemplo si en Windows XP queremos impedir el acceso a un recurso específico (como una clave del registro) a un servicio, debemos crear una cuenta de usuario y asignársela al servicio a modo de «cuenta de servicio», algo que además trae problemas al obligarnos a gestionar una política de control de contraseñas para mantener la seguridad de los servicios afectados.

 

Otro ejemplo de las limitaciones de XP es cuando deseamos que un servicio tenga acceso a un recurso al que el usuario «LocalService» no puede acceder, en estos casos nos vemos obligados a usar la cuenta de elevados privilegios «LocalSystem» o bien a crear una cuenta de servicio específica para acceder al recurso, con lo que volvemos al supuesto anterior.

 

Para complicar aun más la cosa, en Windows XP, cuando le asignamos a un servicio una cuenta con las que ejecutarse, ya sea una cuenta de servicio, o las cuentas LocalSystem, LocalService o NetworkService, automáticamente, dicho servicio obtiene todos los privilegios otorgados a la cuenta asignada, con lo cual el servicio obtiene un mayor nivel de acceso al equipo de lo que realmente deseamos, algo que posteriormente puede ser usado por los diferentes tipos de Malware para, por ejemplo, realizar una elevación de privilegios.

 

Windows Vista ha solucionado estos problemas gracias a Windows Service Hardening como describiré a continuación.

 

La solución: Windows Vista y Windows Service Hardening:

Vamos a estudiar desde el punto de vista práctico estas mejoras de seguridad de Windows Vista, para ello vamos a hacer uso de las siguientes herramientas de las cuales no viene mal ir familiarizándonos.

 

Comando SC: Es un comando extendido de edición y consulta de servicios (integrada en Windows Vista).

Process Explorer: Herramienta de SysInternals para obtener información extendida de procesos en ejecución. Esta herramienta la podéis descargar por separado en

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

o bien descargarlo como parte del Suite de SysInternals (paquete de utilidades cuya descarga es muy recomendable) 

http://technet.microsoft.com/en-us/sysinternals/0e18b180-9b7a-4c49-8120-c47c5a693683.aspx

 

Las mejoras tecnológicas referentes a la seguridad en los Servicios de Windows Vista deben pasar obligatoriamente por tres grandes áreas:

  • Aislar los procesos de usuario de los servicios
  • Conseguir que una mayor cantidad de servicios trabajen con bajos privilegios
  • Solucionar las limitaciones presentadas por Windows XP

 

Aislamiento de servicios: Id de sesión 0

Aislar los servicios de los procesos de usuario es una solución óptima para mantener la seguridad de los sistemas, dado que, por un lado dificultamos que un proceso de usuario tome control sobre un servicio, y por otro lado dificultamos que un Servicio infectado interactue directamente con las cuentas de usuario buscando por ejemplo engañar a este para que intruduzca una contraseña en un formulario invocado para tal fín.

 

El aislamiento de servicios en Windows Vista se consigue gracias a los Ids de Sesión. Este sistema en Windows XP era utilizado para el aislamiento y control de procesos ejecutados por usuarios remotos (Remote Desktop  y Terminal Services) y para el servicio de cambio rápido de usuario. Según este sistema al primer usuario en iniciar sesión se le asigna el Id de sesión 0, en cuyo contexto también se ejecutaban los servicios del sistema; a los usuarios que iniciaban sesión posteriormente gracias a «Cambio Rápido de Usuario» o de manera remota gracias a los servicios RDP (Remote Desktop Protocol) se les iba asignando Ids de sesión consecutivos (id 1 para el segundo usuario, Id 2 para el tercero, Id 3 para el cuarto y así sucesivamente).  Mediante este sistema de Ids se impide que un proceso invoque interfaces de usuario (UI) para otros Ids de sesión de manera directa, mejorando la privacidad y la seguridad de cada sesión de usuario.

 

Windows Vista mantiene este sistema de aislamiento, pero añadiendo un cambio muy importante, los servicios del sistema siguen ejecutándose con sesión Id 0, pero el primer usuario que inicia sesión lo hace con Id 1, esto quiere decir que los usuarios y los servicios se ejecutan con Ids distintos, a diferencia de lo que ocurría con XP, a esto hay que añadirle además que los procesos ejecutados con Id 0 no tienen acceso al hardware gráfico, de manera que la única manera de interactuar con el usuario es mediante sistemas alternativos y más seguros como RPC o Named Pipes. En Windows Vista, ningún servicio puede mostrar directamente una interfaz gráfica en pantalla, protegiéndonos por ejemplo de engaños gráficos como cuadros de contraseñas, ventanas falsas etc.

 

Tanto en Windows XP como en Windows Vista podéis ver el Id de sesión con que se ejecutan los procesos desde el administrador de tareas agregando las columnas correspondiente en «Ver > Seleccionar Columnas»

 

 

Servicios con bajos privilegios

Conseguir que una mayor cantidad de servicios trabajen con bajos privilegios supone estar mejor protegidos de posibles bugs y su explotación por parte de un atacante, dado que en el peor de los casos, el atacante solo conseguirá acceso al equipo con los privilegios concedidos al servicio afectado.

 

Para entender correctamente la manera en la que Windows Vista consigue reducir los privilegios a los mínimos necesarios para que un servicio se ejecute tenemos que diferencias dos aspectos:

  • Privilegios de servicio: Equivalen a los típicos privilegios de usuario que podemos editar desde las políticas de grupo (gpedit.msc) como «permitir el inicio de sesión local» o «Apagar el Sistema».
  • Permisos de servicio: Son permisos NTFS aplicables a un servicio para proteger recursos como una clave del registro o una carpeta del Sistema.

 

En Windows Vista los servicios solo aplican los privilegios otorgados explícitamente, pasando por alto aquellos privilegios propios del usuario con que se ejecutan dichos servicios. De esta manera se corrige uno de los problemas que padecía Windows XP y que ya hemos descrito anteriormente: «Los privilegios no necesarios para el funcionamiento del servicio recibidos como consecuencia de ejecutar este con un usuario determinado, ya sea un usuario de servicio o los usuarios especiales LocalService, NetworkService o LocalSystem».

 

De todos modos, por compatibilidad con sistemas anteriores, si no se especifican unos privilegios propios para el servicio, este recibirá automáticamente los del usuario que efectúa la ejecución. Las buenas prácticas de desarrollo exigen el uso de este sistema de privilegios de servicios en Windows Vista, pero siempre estaremos a expensas de que las empresas de software realmente hagan uso de este (Microsoft si hace uso de él como veremos con alguno de sus servicios).

 

A continuación vamos a comprobar, gracias al comando «SC» y a «Process Explorer» este sistema de privilegios, pero antes es recomendable consultar el listado de privilegios existente con su descripción asociada en el siguiente enlace:

http://msdn2.microsoft.com/en-us/library/bb530716(VS.85).aspx

 

Ya conocedores de los privilegios existentes, tampoco está de más echar un vistazo a estos otros Links:

Privilegios otorgados a la cuenta LocalService:

http://msdn2.microsoft.com/en-us/library/ms684188(VS.85).aspx

Privilegios otorgados a la cuenta NetworkService:

http://msdn2.microsoft.com/en-us/library/ms684272(VS.85).aspx

Privilegios otorgados a la cuenta LocalSystem:

http://msdn2.microsoft.com/en-us/library/ms684190(VS.85).aspx

 

Como habréis comprobado en los enlaces de arriba, este sistema no es algo nuevo en Windows Vista, solo son los llamados «privilegios de usuario», pero descritos a un nivel más bajo de lo que normalmente estamos acostumbrados, y con la diferencia de que en Windows Vista estos privilegios son editables a nivel de servicio.

 

Comencemos con la práctica: El comando SC

 

SC es un comando existente en XP pero al cual se le han agregado nuevas e interesantes funcionalidades en Windows Vista. Este comando nos sirve para crear, eliminar o consultar el estado de los servicios de Windows. Escribiendo SC podréis ver un listado completo de sus opciones, las cuales podéis ver descritas en el siguiente enlace:

http://technet2.microsoft.com/WindowsServer/en/library/0a658e97-51d5-4109-b461-a474c799964e1033.mspx?mfr=true

 

Windows Vista incluye en el comando SC las opciones showsid, sidtype, qsidtype, privs y qprivs para gestionar y consultar las nuevas opciones de seguridad de sus servicios. Iremos repasando cada una de estas opciones en sucesivos post, por el momento echaremos un vistazo a las opciones privs y qprivs.

 

sc qprivs [nombre del servicio] muestra los privilegios otorgados sobre dicho servicio, es decir, qué es capaz de hacer la cuenta con la que se ejecutan dichos servicios para ese servicio. Por ejemplo podemos ejecutar «sc qprivs spooler» para ver la información de privilegios del servicio de cola de impresión como podéis ver en la imagen posterior.

 

El servicio de cola de impresión se ejecuta como LocalSystem, vamos a ver la diferencia de privilegios entre Vista y XP para un mismo servicio:

 

Privilegios del servicio de cola de impresión en Windows Vista

SeTcbPrivilege, SeImpersonatePrivilege, SeAuditPrivilege, SeChangeNotifyPrivilege, SeLoadDriverPrivilege, SeAssignPrimaryTokenPrivilege

 

Privilegios del servicio de cola de impresión en Windows XP

SeTcbPrivilege, SeImpersonatePrivilege, SeAuditPrivilege, SeChangeNotifyPrivilege, SeLoadDriverPrivilege, SeAssignPrimaryTokenPrivilege, SeCreateGlobalPrivilege, SeCreatePagefilePrivilege, SeDebugPrivilege, SeCreatePermanentPrivilege, SeLockMemoryPrivilege, SeIncreaseBasePriorityPrivilege, SeLockMemoryPrivilege, SeProfileSingleProcessPrivilege, SeTcbPrivilege

 

La diferencia está clara: mientas que Windows Vista establece sus propios privilegios en el servicio, Windows XP hereda los privilegios del usuario LocalSystem, obteniendo una gran cantidad de privilegios innecesarios que posteriormente pueden utilizados con fines maliciosos si el servicio muestra alguna vulnerabilidad.

De todos modos arriba aparece un pequeño «engaño», dado que no es lo mismo ver «los privilegios concedidos a un servicio» que los «privilegios efectivos de un servicio en ejecución». Por supuesto, esto es otra cosa aplicable tansolo a Windows Vista, por ejemplo, en el caso de arriba, a los privilegios del servicio de cola de impresión habría que quitar además el privilegio «SeLoadDriverPrivilege» dado que el usuario System tiene denegado dicho privilegio; es decir: «Se aplica siempre el caso más restrictivo entre los privilegios de servicio y los de usuario», al más puro estilo UAC.

 

Para poder ver los permisos efectivos con los que se ejecuta un proceso disponemos de la herramienta Process Explorer de SysInternals, para ello ejecutamos Process Explorer con privilegios de administrador, nos dirigimos al proceso deseado (en este caso «spoolsv«) y seleccionamos «Properties». Dentro de las propiedades podremos ver diferentes pestañas con información relativa al proceso, a nosotros nos interesa comprobar la descripción del «Token de Seguridad» del proceso, de manera que debemos seleccionar la pestaña «Security». Dentro de esta pestaña, en la mitad inferior, podréis ver los privilegios asignados al proceso para el propietario (Owner) de este, es decir, para el usuario System, de esta manera podreis comprobar que pese a que el comando «sc qprivs spooler» muestra el privilegio «SeLoadDriverPrivilege», en los privilegios asignados al servicio, este privilegio aparece como deshabilitado.

 

Process Explorer funciona tanto en XP como en Windows Vista, así que no esta de más comprobar, de manera práctica la diferencia de privilegios efectivos sobre un servicio, aquí os dejo un par de capturas de pantalla para que le echéis un vistazo.

 

Process Explorer en Windows Vista

 

 

Process Explorer en Windows XP

Por último solo queda añadir que si «sc qprivs» nos sirve para realizar consultas, «sc privs» nos sirve para agregar o quitar privilegios a los servicios, así que ya tenemos otra herramienta con la que juguetear. Por ejemplo imaginemos que deseamos dar al servicio SPOOLER la capacidad de elevar la prioridad de un proceso, para ello debemos realizar lo siguiente:

 

sc privs spooler SeTcbPrivilege/SeImpersonatePrivilege/SeAu

ditPrivilege/SeChangeNotifyPrivilege/SeLoadDriverPrivilege/SeAssignPrimaryTokenP

rivilege/SeAssignPrimaryTokenPrivilege/SeIncreaseBasePriorityPrivilege

(En negrita los privilegios agregados)

 

Comprobamos con qprivs si el resultado ha sido correcto:

 

Nota: Fijaros que hay que separar cada privilegio por «/» y que hay que volver a agregar cada privilegio existente en el servicio ya que por defecto el comando SC los sobrescribe, es decir que si hiciéramos un «sc privs spooler SeIncreaseBasePriorityPrivilege» desaparecerían los privilegios iniciales.

 

Bueno, esto es todo, suficiente por ahora ¿no?, en el próximo post comprobaremos otro aspecto de WSH: «Los SID de servicio». 

 

Creo que ya podemos ir haciéndonos una idea de por qué las empresas antivirus se han puesto tan nerviosas con Windows Vista, y esto solo es una muestra de «una» las tecnologías de seguridad de este sistema operativo.

 

Por cierto, las mejoras que han sufrido los servicios en Windows Vista (y Windows Server 2008) no solo hacen referencia a la seguridad, también han mejorado en estabilidad y rendimiento gracias otros elementos como el nuevo sistema de parada de servicios, el sistema de inicio retrasado, acciones ante errores no críticos o el nuevo entorno de control de cambios de estado. Os dejo algunos enlaces por si la curiosidad os puede y queréis profundizar en estos temas. Un saludo y hasta el próximo post.

 

Enlaces:

MSDN Windows Services Documentation

http://go.microsoft.com/fwlink/?LinkId=71274

Impact of Session 0 Isolation on Services and Drivers in Windows Vista

http://go.microsoft.com/fwlink/?LinkId=71275

NotifyServiceStatusChange

http://go.microsoft.com/fwlink/?LinkId=71279

Service Control Handler Function

http://go.microsoft.com/fwlink/?LinkId=71282

 

3 comentarios sobre “Sistemas de Integridad en Windows Vista I: Windows Service Hardening (primera parte)”

  1. Interesante articulo, pero con respecto a las empresas antivirus creo que están más asuntadas por el hecho de que Microsoft haya sacado su propio antivirus que por la salida de Windows Vista.

  2. Me ha gustado mucho el articulo y además ya tengo cosas con las que trastear un poquito mas en mi sistema. Muchas gracias por sacarnos un poquito mas a cada día del pozo de ignorancia en el que nos hayamos sumisos la gran mayoria con este nuevo sistema operativo.

    Por otro lado y desviandome un poco del tema (no me crucifiques) el powershell se puede descargar de manera gratuita pero no viene completo ¿verdad?, es decir, si lo quieres en su maxima expresión necesitas pagar una licencia por el mismo.

    Un saludo desde la terraza.

  3. PowerShell es gratuito, no obstante existen ampliaciones del mismo (añadiendo nuevos CMDLETS) en otros elementos como EXCHANGE 2007 o los diferentes elementos de SYSYEM CENTER, como MOM o DPM. De todos modos puede que ya hayan empresas y partners que vendan ampliaciones de PowerShell. Un saludo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *