Vigilancia de seguridadHerramientas para administrar ACL
Jesper M. Johansson
En Windows, las listas de control de acceso (ACL) le ofrecen un control muy preciso sobre la capacidad de los usuarios y los procesos para usar recursos tales como archivos y carpetas. La administración de las ACL puede ser una de las tareas más complicadas relacionadas con la protección de la seguridad de los sistemas de los usuarios. Afortunadamente, hay varias utilidades provechosas
que ayudan a automatizar y a simplificar tareas que rodean a los permisos y a las ACL.
La mayoría de los lectores conocen la venerable herramienta cacls.exe que ha estado en todas las versiones de Windows NT® desde que salió por primera vez. Si ejecuta cacls.exe en Windows Vista™, le aparecerá este mensaje:
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Windows\system32>cacls
NOTE: Cacls is now deprecated, please use Icacls.
Además de las actualizaciones a las ACL en Windows Vista (que traté en el número de junio de 2007 de TechNet Magazine; consulte technetmagazine.com/issues/2007/06), Microsoft también ha actualizado algunas de las herramientas que usa para administrar las ACL. Curiosamente, la más significativa de estas actualizaciones son las herramientas de línea de comandos.
Icacls.exe es una novedad en Windows Vista (y también en el nivel inferior en Windows Server® 2003 Service Pack 2). Reemplazará finalmente cacls.exe, que nunca se actualizó por completo para admitir permisos más granulares incorporados con Windows® 2000, haciendo de ésta una actualización que lleva atrasada unos siete años.
Sorprendentemente, a pesar de estar obsoleto, cacls.exe incluye realmente algunas características nuevas. En primer lugar, conoce los puntos de unión y los vínculos simbólicos, y sabe atravesarlos. En segundo lugar, puede imprimir y establecer una ACL usando una cadena de Lenguaje de definición de descriptores de seguridad (SDDL).
Sin embargo, a pesar de las actualizaciones a cacls.exe, realmente desea la funcionalidad disponible en icacls.exe.
Guardado y restauración de las ACL
Un deseo constante, al menos para mí, durante los últimos 10 años, ha sido la capacidad de guardar una ACL de manera que se pueda restaurar en una fecha posterior. Esto resulta ser una de las operaciones más complicadas que se pueden realizar en las ACL. Excepto en determinados casos especiales, no es probable que pudiera volver exactamente al mismo lugar en el que habría estado si no hubiera arruinado las ACL en primer lugar. No obstante, esta funcionalidad puede ser bastante útil.
Antes de que explique cómo guardar o restaurar las ACL, permítame que trate en primer lugar por qué es tan difícil. Supongamos que tiene una jerarquía que contiene datos de usuario para estudiantes en un colegio local. Guarda la ACL el 1 de febrero. El 17 de abril descubre que, de alguna manera, se ha dañado la ACL y va a restaurarla a partir de la copia guardada. ¿Qué complicaciones podría haber con esta operación?
En primer lugar, el nuevo trimestre empezó el 2 de abril. Aproximadamente el 15 por ciento de los estudiantes se recibieron; por consiguiente, sus directorios ya no existen. Así, tiene unas ACL en el archivo de copia de seguridad que no son válidas. Además, ahora hay un grupo de estudiantes nuevos, otro 15 por ciento, que empezaron en el nuevo trimestre. Tienen directorios principales ahora pero ninguna ACL en el archivo de copia de seguridad. ¿Cuáles deberían ser sus ACL? Luego, por supuesto, todavía tiene el 70 por ciento que siguen allí, pero ellos han creado archivos y carpetas nuevas, y han eliminado otras. Puede omitir las eliminadas pero ¿cómo configura las carpetas nuevas que crearon? ¿Qué pasa si un estudiante ha decidido compartir una carpeta con sus amigos el 4 de marzo? ¿Eliminaría ese recurso compartido al restaurar las ACL?
Guardar y restaurar las ACL no es una operación tan sencilla como muchas personas pueden creer. Tiene que hacerlo con cuidado. Es muy posible, incluso probable, que tenga como resultado algún comportamiento indefinido. La restauración de las ACL es definitivamente un último recurso; cuanto más tiempo haya pasado desde que se realizó una copia de seguridad de la misma, mayores probabilidades habrá de que se interrumpa algo cuando la restaure.
No obstante, se desea intentar esta funcionalidad, ejecute icacls.exe con el conmutador /save:
icacls <target> /save acls.bin /t
De este modo, se guardarían las ACL en un archivo denominado acls.bin y que contendrá una línea para cada objeto con una ACL seguida de una línea que especifica la ACL en SDDL. Mediante conmutador /t, el comando funcionará en el objeto especificado y todos los objetos y los contenedores que se encuentren debajo.
La funcionalidad de guardar es una adición bienvenida al kit de herramientas pero tiene algunos defectos. Por ejemplo, sólo guarda la lista de control de acceso discrecional (DACL), no la lista de control de acceso de sistema (SACL). De hecho, si hay una SACL, guarda un valor ficticio que indica esto, pero no guarda realmente ninguna parte de la SACL.
Además, la manera en que se guarda la ACL crea un problema interesante. Antes de abrir la ACL guardada en el editor de texto, recuerde:
no edite la ACL guardada.
Si fuera a abrir el archivo que contiene la ACL guardada en un editor de texto, encontraría que parece ser un archivo de texto con formato Unicode (UTF-16). De hecho, eso es casi exactamente lo que es. Esto le podría hacer pensar que podría editarlo y guardarlo desde un editor de texto. No lo haga.
Si abre el archivo que contiene las ACL guardadas en un editor de texto y lo guarda a continuación, no podrá restaurar las ACL a partir de dicho archivo. Resulta que no es realmente un archivo de texto Unicode después de todo. Este tipo de archivo debe comenzar con 0xfffe de 2 bytes. Si guarda el archivo con un editor de texto, como por ejemplo el Bloc de notas, colocará de hecho ese marcador en el archivo en los 2 primeros bytes. Sin embargo, la herramienta icacls.exe espera que los datos de ACL comiencen en el byte 0 del archivo. Por consiguiente, la herramienta no podrá analizar las ACL del archivo puesto que espera que los dos primeros bytes formen parte de la cadena que especifica el objeto en el que se debe trabajar. Su archivo de copia de seguridad será inutilizable.
Microsoft conoce este problema pero, como se notificó muy tarde en el ciclo de beta para Windows Vista, este defecto no se corrigió antes del lanzamiento. En estos momentos, no sabemos cuándo, ni siquiera si, se corregirá. Así que por ahora, el mejor consejo es no editar sus ACL guardadas. Si tiene que hacerlo, guarde el archivo como un archivo .bin y use un editor hexadecimal, tal como el entorno de desarrollo que prefiera.
Una vez que haya guardado una ACL usando el conmutador /save, la podrá restaurar usando icacls.exe con el conmutador /restore. El comando de restauración en su forma más sencilla usa esta sintaxis:
icacls <directory> /restore acls.bin
El procedimiento de restauración no funciona en archivos. Para ver esto, consulte el script que se muestra en la figura 1. Aquí creo un archivo para guardar señalando icacls.exe en un archivo. A continuación, intento restaurarlo al sustituir /restore por /save. Se produce un error en esto porque el comando de restauración sólo funciona en directorios. Los archivos que se supone que modifica ya están especificados en el archivo acls.bin. Para restaurar la ACL, la señalo hacia el directorio en lugar del archivo. Esto es lo que hago en el último comando donde especifico "." como el objeto en el que se va a trabajar.
Figure 1 Guardado y restauración de las ACL
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files
C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
Tenga en cuenta además que el comando de restauración debe ejecutarse elevado. Puede ejecutar el comando para guardar desde un símbolo del sistema que se ejecuta como un administrador de nivel bajo o incluso un usuario estándar, siempre y cuando tenga el derecho para leer la ACL. Sin embargo, para restaurar la ACL, es necesario que tenga un símbolo (token) administrativo completo y puro.
Sustitución de los SID
Otra característica de mucha utilidad en icacls.exe es la capacidad de reemplazar los permisos para un usuario con permisos para un usuario diferente. Esto se realiza durante la restauración usando el conmutador /substitute. La documentación para el conmutador substitute indica que necesita un SID, pero posteriormente explica que esto realmente puede ser también un nombre de usuario normal. Así, la secuencia que se muestra en la figura 2 funciona.
Figure 2 Sustitución de los SID durante la restauración
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
Como puede ver, termino con la misma ACL que tenía antes, pero el ACE que usaba para especificar permisos para foo ahora los especifica para bar en su lugar.
Cambio de propietario
La herramienta chown ha sido un elemento esencial en los sistemas de Unix durante años. Windows originalmente no tenía ninguna manera integrada de cambiar el propietario de un objeto. Entonces vino la herramienta setowner en el kit de recursos. A continuación, obtuvimos la herramienta takeown.exe en Windows NT 4.0 pero esta utilidad sólo le permitía tomar la propiedad, no concederla a los demás a menos que tuviera su contraseña. Ahora icacls.exe le ofrece la capacidad integrada de establecer el propietario de los objetos en los que tiene permiso para establecer el propietario:
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
Lamentablemente, icacls.exe no le puede mostrar el propietario de un objeto. No hay manera de ver realmente, en la línea de comandos, quién es el propietario de un objeto. Además, si guarda la ACL para un objeto, no se guarda el propietario del objeto.
También hay un error en icacls.exe en que no invoca SeTakeOwnershipPrivilege para cambiar el propietario. Si tiene el derecho de cambiar el propietario de un objeto basado en la ACL, entonces icacls.exe funciona como debería. Sin embargo, un administrador que no tiene permiso para cambiar el propietario basado en la ACL del objeto no podrá usar icacls.exe para ello debido a dicho error. En ese caso, debe usar la herramienta takeown.exe, que invoca SeTakeOwnershipPrivilege, pero sólo puede cambiar el propietario a su cuenta o el grupo Administradores, no a una cuenta arbitraria:
C:\>takeown /f c:\test
SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
Por supuesto, se debe tener en cuenta que la herramienta subinacl, que se puede descargar del Centro de descargas de Microsoft, también tiene un conmutador setowner. En realidad, en muchos casos Subinacl funciona de manera más intuitiva que icacls, pero también es mucho más complicado de usar.
Búsqueda de archivos para un usuario en particular
Icacls tiene otra función útil: puede buscar archivos que tienen permisos para usuarios concretos. Por ejemplo:
C:\windows\system32>icacls “c:\program files” /findsid jesper /t
SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
Esto podría ser de utilidad si intenta averiguar a lo que puede tener acceso un usuario concreto.
Restablecimiento y cambio de ACL
Si una ACL se ha dañado o se ha destruido, icacls.exe tiene una manera de restablecerla para heredar de su padre. Esto es algo que habría sido muy útil durante un problema de seguridad de día cero que llegó en el otoño de 2006. Un método usado para mitigar el problema en un componente de Windows fue denegar el acceso de todos al objeto. Esa parte fue sencilla pero quitar esa entrada de control de acceso (ACE) fue casi imposible usando herramientas integradas en Windows XP y Windows Server 2003. Sin embargo, en Windows Vista, simplemente ejecutaría este comando:
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset
processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
por supuesto, Icacls.exe tiene todas las operaciones estándar de concesión, denegación y eliminación. El único elemento realmente nuevo en esa lista es la eliminación. Mediante este conmutador, puede quitar todos los valores "permitir ACE", todos los "denegar ACE" o ambas opciones para un usuario determinado de un objeto o jerarquía específicos. La figura 3 muestra ejemplos de algunas operaciones de concesión, eliminación y denegación.
Figure 3 Operaciones de conceder, denegar y quitar
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
La capacidad de quitar sólo los valores "denegar ACE" puede ser de utilidad si desea abrir el acceso a un objeto hasta un grupo o usuario en particular.
Configuración de niveles de integridad
Icacls.exe también tiene la capacidad de mostrar y establecer niveles de la integridad. Windows Vista admite la colocación de etiquetas de integridad en objetos. Icacls.exe es la herramienta de línea de comandos que se debe usar para ello:
C:\>icacls c:\test /setintegritylevel high
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Mandatory Label\High Mandatory Level:(NW)
Successfully processed 1 files; Failed processing 0 files
Tenga en cuenta que icacls.exe sólo muestra una etiqueta de integridad si un objeto tiene una establecida explícitamente. La mayoría de los archivos no la tienen, por lo que no es habitual que vea una.
Por último, icacls.exe puede comprobar que un objeto tiene una ACL canónica. Como mencioné anteriormente, se ha sabido que las herramientas de terceros colocan las ACE en orden incorrecto en las ACL. Icacls.exe puede comprobar y corregir esos tipos de problemas, tal como se muestra aquí:
C:\>icacls c:\test /verify
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
IU de ACL
La IU de ACL, o la interfaz de usuario de ACL, se modificó ligeramente de la existente en Windows XP. Las figuras 4 y 5 muestran el cuadro de diálogo de la IU de ACL de Windows XP y Windows Vista, respectivamente.
Figura 4** Cuadro de diálogo de la IU de ACL en Windows XP **
Figura 5** Cuadro de diálogo de la IU de ACL en Windows Vista **
Como puede ver, aquí hay algunos cambios. En primer lugar, el cuadro de diálogo finalmente muestra el objeto en el que está trabajando de manera muy clara, lo cual puede ser de utilidad a la hora de trabajar con varios objetos a la vez. En segundo lugar, hay un hipervínculo a alguna ayuda en la parte inferior. Sin embargo, el cambio más notable se encuentra en la eliminación de los botones Agregar y Quitar, que se reemplazaron por un botón Editar que se presenta en gran medida en apoyo del control de acceso de usuario (UAC) de Windows Vista. Como puede observar por el escudo del botón, el usuario que inició este cuadro de diálogo no tiene permiso para editar la ACL y, por tanto, requerirá la elevación antes de poder editar los permisos. Tenga en cuenta que esto no sería el valor predeterminado si se crea una carpeta en la raíz de la unidad C: y comprueba inmediatamente sus propiedades. Como propietario de la carpeta, tendría permisos implícitos para editar la ACL y el escudo no estaría presente. El escudo indica un Moniker COM, que es un mecanismo usado para iniciar un mensaje de elevación para una parte de un proceso en ejecución. Si hace clic en el botón Editar, obtiene el conocido cuadro de diálogo de elevación, y si hace clic en Continuar en el cuadro de diálogo de elevación, obtiene un cuadro de diálogo que es casi idéntico al que obtiene en Windows XP cuando hace clic en el botón Agregar. La interfaz de usuario de ACL sigue este concepto de doble cuadro de diálogo en varios lugares; obtiene un cuadro de diálogo hasta que eleva, y una vez que lo hace, obtiene el conocido cuadro de diálogo anterior de las versiones anteriores de Windows.
Si hace clic en el botón Opciones avanzadas y, a continuación, en la ficha Autoría, siempre obtendrá un botón de elevación, tal como se muestra en la figura 6. No es posible modificar la auditoría sin elevar, aunque tenga un control total sobre el objeto y sea el propietario. Esto se debe a que la capacidad de modificar una SACL de objeto se rige por el privilegio SE_SECURITY_NAME, conocido como "Administrar registro de seguridad y auditoría" en las herramientas de GUI. Sólo los administradores tienen ese derecho de forma predeterminada. Sin embargo, el privilegio se quita de un administrador en el modo de la aprobación de administración (cuando UAC está habilitado), necesitando la elevación aunque sea administrador.
Figura 6** La modificación de la configuración de la auditoría en Windows Vista requiere siempre elevación **
Una nota final sobre las necesidades de elevación cuando modifica las ACL: todas estas instrucciones dependen de que no se deshabilite UAC. Si deshabilita UAC, se revierte todo el comportamiento a lo que tenía en Windows XP, a excepción de los cuadros de diálogo que tienen un aspecto diferente. Sin embargo, no se requerirá ninguna elevación, siempre y cuando inicie sesión como administrador ya que el símbolo (token) tendrá ahora el SID de administradores todo el tiempo.
Otras herramientas
Icacls.exe es una herramienta muy útil y una importante mejora respecto a cacls.exe, pero sufre todavía de algunos puntos débiles. Quizá lo más notable es que no puede administrar el acceso a ningún objeto que no sean archivos y directorios. Windows Vista realiza cambios escasos a las ACL de otros objetos en comparación con Windows XP, pero todavía hay ocasiones en las que desee administrar las ACL en un servicio, una clave del Registro o incluso un objeto de Active Directory®.
Si usted es un adicto a la línea de comandos, necesita subinacl.exe para hacer esto. Subinacl.exe se encuentra en las herramientas de soporte y también está disponible como una descarga.
De todas formas, tengo que advertirle de que subinacl.exe no es fácil de usar. De hecho, es completamente obtuso a veces. Sin embargo, subinad.exe es una herramienta increíblemente eficaz para administrar el control de acceso. Todos los administradores avanzados necesitan esta herramienta.
ACL del Registro
Al igual que las ACL del sistema de archivos, las ACL del Registro también han experimentado cambios. Sin embargo, los cambios tienen un ámbito mucho más pequeño que el de los cambios al sistema de archivos. La diferencia más obvia en comparación con versiones anteriores de Windows es que, puesto que los Usuarios avanzados ahora son obsoletos, casi todas las ACE de Usuario avanzado han desaparecido. No se supone que los Usuarios avanzados sean más poderosos que cualquier otro usuario. No obstante, un testamento de lo complicado que son realmente las ACL es que no todas las ACE para Usuarios avanzados han realmente desparecido. Lamentablemente, algunas se pasaron por alto.
Mientras mira en las ACL en el Registro, en algunos lugares verá una ACE para un SID denominado RESTRICTED. Esto no es una novedad para Windows Vista, pero es un SID interesante y poco comprendido. El SID RESTRICTED denota cualquier proceso que presenta un símbolo (token) restringido. Un símbolo (token) restringido se crea usando una característica especial de la API de CreateRestrictedToken. Dicho símbolo (token) tiene uno o más SID restringidos; SID que se usan en una comprobación de acceso independiente. Supongamos que tenemos un proceso que se ejecuta con un símbolo (token) restringido. Si ese proceso intenta obtener acceso a un objeto con una ACE para el SID RESTRICTED, en realidad Windows realiza dos comprobaciones de acceso. La primera es la comprobación de acceso normal. La segunda funciona exactamente como la primera pero se produce únicamente frente a los SID que restringen en el símbolo (token). Se deben superar ambas comprobaciones de acceso.
Actualmente, hay varias ACL que usan el SID RESTRICTED, especialmente en el registro. Una captura de pantalla de dicha ACL se muestra en la figura 7.
Figura 7** Las ACL del Registro incluyen una ACE para RESTRICTED en varios lugares **
En estos momentos, pocos procesos usan la funcionalidad de símbolo (token) restringida, especialmente con respecto a los SID de restricción. Un ejemplo de un proceso que sí lo hace es el proceso del servicio que hospeda el Firewall de Windows, el motor de filtro de base y el servicio de directivas de diagnóstico. También usa un símbolo (token) restringido contra escritura. Según mis conclusiones, sólo nueve servicios usan actualmente los símbolos (token) restringidos contra escritura y RESTRICTED en Windows Vista.
Al igual que con versiones anteriores recientes de Windows, la recomendación con respecto a los permisos del Registro es ir con mucho cuidado. Con la excepción de circunstancias excepcionales y sumamente dirigidas, no modifique permisos en el Registro. Dado el complicado modelo de herencia y las operaciones confidenciales realizadas en el Registro, existe una probabilidad inaceptablemente alta de que se produzca un error grave si modifica las ACL en el Registro sin tener cuidado.
Resumen
Al igual que con la mayoría de las versiones de Windows, hay algunos cambios sutiles en el control de acceso de Windows Vista. Sin embargo, a diferencia de algunas de las otras versiones recientes, en realidad se han producido un gran número de cambios secundarios que, en conjunto, representan un cambio considerable en el comportamiento. El UAC, en concreto, requirió varios cambios, como por ejemplo, las etiquetas de integridad y las modificaciones a la interfaz de usuario de ACL. Además, tenemos la primera gran limpieza de las ACL de la historia documentada.
En muchos sentidos, en realidad las ACL predeterminadas de Windows se simplificaron en Windows Vista, algo que nunca ha sucedido antes. Sin embargo, al igual que en las versiones anteriores, debería ir con mucho cuidado en lo relacionado con el control de acceso hasta que lo comprenda completamente. Esto es especialmente cierto con las versiones nuevas del sistema operativo. Con suerte, mediante las herramientas resumidas en este artículo, podrá hacer que la exploración de las ACL sea mucho menos dolorosa.
Jesper M. Johansson es ingeniero de seguridad principal que trabaja en problemas de seguridad de software y contribuye como editor en TechNet Magazine. Tiene un doctorado en MIS y más de 20 años de experiencia en el ámbito de la seguridad de sistemas. Este artículo está adaptado del nuevo libro de Roger Grimes y Jesper Johansson, Windows Vista Security: Securing Vista Against Malicious Attacks (Wiley, 2007).
© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.