Si has estado siguiendo este blog, sabrás que hace unos 2 años y medio, empecé a hablar sobre el precario papel de la Política de Grupo en la postura de seguridad de la empresa típica. Muchas, si no la mayoría, de las tiendas AD utilizan GP para realizar el endurecimiento de la seguridad en sus escritorios y servidores Windows. Esto incluye todo, desde ajustar la configuración del sistema operativo hasta desactivar NTLMv1 o manipular el Control de cuentas de usuario (UAC), pasando por controlar quién puede iniciar sesión en qué equipos y qué grupos de AD tienen acceso privilegiado a qué escritorios y servidores. Todo esto se almacena en GPO que, por defecto, son "legibles en todo el mundo" por cualquier usuario autenticado. Ahora bien, este hecho es cierto desde hace mucho tiempo -en realidad desde el año 2000, cuando se lanzaron AD y GP-, pero sólo se ha hecho más visible como un problema potencial de InfoSec en los últimos años, en gran parte gracias a herramientas como Bloodhound, PowerView y Grouper, que ponen al descubierto el hecho de que esta información se puede utilizar para realizar todo tipo de travesuras.
Desde entonces, me he centrado en gran medida en el lado defensivo de la ecuación, y principalmente en las recomendaciones para reducir la legibilidad de los GPO relacionados con la seguridad para evitar que un atacante descubra fácilmente la postura de seguridad de una organización. Sin embargo, más recientemente he pasado algún tiempo pensando en las oportunidades para un uso más destructivo de los GPO, aprovechando la configuración existente dentro de los GPO editables para realizar diversas tareas malignas dentro de un entorno. Dado que los GPO suelen afectar a la mayoría, si no a todos, los usuarios y equipos de una organización, son un mecanismo de distribución de malware muy eficaz, como ya ilustré en una entrada de blog hace algún tiempo. Estos tipos de ataques que inyectan configuraciones maliciosas en un GPO se basan en la capacidad del atacante para obtener permisos de escritura en un GPO, concretamente en la parte SYSVOL del GPO donde la mayoría (pero no todas) las extensiones del lado del cliente (CSE) de GP almacenan sus configuraciones. Por supuesto, también es necesario entender el formato de configuración del área de política que desea afectar con el fin de secuestrarlo, y por una vez, la forma en que Microsoft abordó el desarrollo de CSEs es una ventaja aquí, ya que casi cada área de política utiliza un esquema diferente y estructura de datos para almacenar su configuración. Un punto para la incoherencia arquitectónica.
Tres maneras de causar problemas
Como he estado pensando en GP y sus debilidades, he llegado a la conclusión de que hay (al menos) tres vías principales para que un atacante utilice GP para sus nefastos propósitos. A saber,
- Aprovechar el acceso de lectura excesivamente permisivo en los GPO para conocer la postura de seguridad de una organización: quién tiene acceso privilegiado a dónde, etc. Como ya he mencionado, he escrito mucho sobre este tema en mi blog y he ofrecido sugerencias para mitigarlo.
- Aprovechar el acceso de escritura excesivamente permisivo en los GPO para inyectar configuraciones maliciosas en los GPO existentes. Hablo de esto más adelante en la sección titulada "Delegación de GPO". El cmdlet New-GPOImmediateTaskde PowerView es un ejemplo perfecto de este enfoque para inyectar una tarea programada en un GPO y ejecutar código arbitrario.
- Aprovechar las rutas externas a las que se hace referencia en los GPO y que tienen un acceso de escritura demasiado permisivo. Esta es una variación de #2 y realmente me di cuenta del poder de esta idea mientras probaba y colaboraba con @mikeloss en su excelente utilidad Grouper2 mencionada anteriormente. Grouper2 busca cosas "interesantes" en las GPOs, que pueden incluir desde políticas de Grupos Restringidos que otorgan acceso privilegiado a Contraseñas GPP persistentes hasta, más interesante para mí, referencias a ejecutables externos, scripts o instaladores. Paso más tiempo hablando de estas rutas externas más adelante en la sección titulada "Rutas externas", pero @mikeloss realmente merece el crédito por despertarme a esta.
Delegación de GPO
Hablemos más sobre el punto 2 anterior. La forma en que funciona la delegación de GPO es que usted otorga a los usuarios, equipos o grupos, diferentes niveles de acceso a un GPO, por lo general en GPMC desde la pestaña "Delegación" en un GPO dado, o usando PowerShell, y esos permisos (que incluyen Lectura, Lectura-Aplicación, "Editar Configuración" y "Editar Configuración, Eliminar y Modificar Seguridad") se estampan en el correspondiente objeto Contenedor de Directiva de Grupo (GPC) basado en AD y la carpeta con nombre GUID en la Plantilla de Directiva de Grupo (GPT) (es decir, SYSVOL). Obviamente, los permisos de AD no se corresponden 1-1 con los permisos del sistema de archivos NTFS, pero si observa ambas partes de un GPO en el Editor de ACL, verá permisos muy similares (véase más abajo).
Así que, como atacante, debes ser capaz de obtener acceso de escritura a la GPT (o en algunos casos a la GPC) de una GPO determinada para comprometerla. Esto no es imposible, obviamente, especialmente si el atacante es capaz de elevarse a un rol de administrador que podría tener permisos de edición en un GPO. Pero, desde la perspectiva de un defensor, subraya la importancia de tener un control estricto sobre sus delegaciones de GPO. Los permisos de edición o creación de GPO deben delegarse a un pequeño número de administradores de sistemas, y esos responsables de seguridad deben ser tratados como administradores de "Nivel 0", dado el impacto potencial que puede tener un cambio malicioso de GPO en todo el entorno. Más preocupante aún, si un atacante obtiene acceso de escritura a, por ejemplo, la GPT, entonces puede ser muy difícil detectar estos cambios maliciosos si el atacante está modificando los archivos de configuración directamente, en lugar de pasar a través de herramientas establecidas de gestión de cambios de GPO como GP Editor. Esencialmente, tienes que buscar cambios en el sistema de archivos en la GPT para poder detectar la mayoría de estos cambios no deseados, pero dado que los cambios legítimos de GPO generarán notificaciones de cambio de GPT, también tienes que ser capaz de tamizar tanto los cambios maliciosos como los válidos de GPO para encontrar los que pueden darte dolores de cabeza. La buena noticia es que si un atacante tiene que añadir una nueva configuración de área de políticas (es decir, tiene que llamar a un CSE que no sea el que ya se ha implementado) a un GPO, sus posibilidades de ser detectado aumentan. Esto se debe a que, para que un cliente (servidor o estación de trabajo) procese una nueva configuración de área de política de GPO, deben producirse varios cambios en la GPC (por ejemplo, el incremento de versionNumber y la adición correcta de CSE ExtensionGUIDs a la GPC) para que el cliente sea consciente de dicha configuración, y esto hace que sea más difícil para un administrador con una cantidad decente de auditoría de GP, no darse cuenta de la manipulación. En cuanto a las áreas de políticas que están más maduras para este tipo de manipulación, echa un vistazo al excelente post de @_wald0 "A Red Teamer's Guide to GPOs and OUs" para ver algunos ejemplos de rutas de políticas que pueden ser manipuladas con buen efecto. Este punto también aboga por mantener las GPO que implementan áreas de políticas altamente "explotables", extra bloqueadas. En resumen: ¡bloquee quién puede editar esos GPO!
Vías exteriores
Esto me lleva a mi última fascinación (#3 arriba), que es el uso de referencias de "rutas externas" en GPOs para evitar la limitación impuesta por los administradores en #2 arriba. ¿Qué quiero decir con rutas externas? Bueno, en realidad cualquier referencia que se encuentra en un GPO, que apunta a un ejecutable, script, paquete MSI u otro archivo que "hace algo" cuando se llama, que existe fuera de la normal GPC y GPT (Sysvol) lugares. ¿Por qué son interesantes? Porque, incluso si estás bloqueando el acceso de escritura a los GPOs como sugerí en el #2, podrías potencialmente tener scripts, ejecutables y paquetes MSI esparcidos por los servidores de archivos de toda tu red, con diferentes grados de control de acceso, que están siendo llamados y ejecutados por esos mismos GPOs bloqueados que pensabas que eran tan seguros. Así que un atacante que no consiga acceso de escritura a una GPO, puede usar su acceso de lectura (como en el punto 1 anterior) para buscar estas rutas externas referenciadas e intentar reemplazar esos scripts, exes y MSIs con sus propias versiones maliciosas (esta tarea es de hecho lo que Grouper2 hace mucho más fácil). La próxima vez que ese GPO sea procesado por un cliente, ese archivo malicioso será ejecutado alegremente por el GPO, que no se enterará de nada. Ejemplos de áreas de políticas que típicamente pueden hacer referencia a rutas externas (es decir, rutas fuera de la GPC y GPT) incluyen:
- Guiones de inicio/apagado y de inicio/cierre de sesión
- Instalación del software GP (archivos MSI)
- Preferencias GP Tareas Programadas
- Preferencias GP Impresoras (con Impresoras TCP/IP, puede especificar una ruta externa para que el cliente descargue los controladores de impresora, ¡genial!)
- Accesos directos de Preferencias GP, para accesos directos que existen en ubicaciones de ejecución automática como Inicio
- Archivos de Preferencias GP, donde tiene archivos que pueden ser copiados desde ubicaciones externas arbitrarias a ubicaciones de ejecución automática u otras ubicaciones de archivos locales "fácilmente ejecutables".
Para ser sincero, probablemente haya más lugares de este tipo escondidos en GP (y sigo buscando...). Los anteriores son los más obvios.
Entonces, ¿por qué hay que preocuparse por estas rutas externas? Bueno, piénsalo: el problema de evitar la manipulación no deseada de los GPO, como se describe en el punto 2 anterior, es limitado. Sólo tienes que preocuparte de la delegación en esos GPOs para mantener el control de ese tipo de comportamiento. Pero, cuando tienes GPOs que hacen referencia a código ejecutable en archivos compartidos externos, ¡ahora tienes que extender tu ámbito de preocupación a CADA UNA DE ESAS UBICACIONES DE ARCHIVOS! ¿Cuántos de ustedes pueden estar seguros de la gestión de permisos en archivos compartidos aleatorios dentro de su entorno (por no hablar de sus GPOs)? Entonces, si un GPO está llamando a un archivo ejecutable o instalador que existe en algún recurso compartido inseguro, sus GPO ahora se convierten en vehículos de distribución inadvertidos para cualquier basura aleatoria con la que un atacante pueda reemplazar esos ejecutables. Y por supuesto, ya que no hay comprobación CRC u otra comprobación de validez hecha dentro de GP, estás a merced de cualquier archivo que esté allí (una mitigación a esto es el hecho de que no todas las áreas de política ejecutan automáticamente sus cargas útiles todo el tiempo. Por ejemplo, si una máquina ya ha recibido un despliegue de software a través de la política de Instalación de Software, no volverá a desplegar ese MSI malicioso en circunstancias normales. Pero cualquier máquina nueva, por supuesto, recibirá el paquete malicioso).
¿Cuál es el resultado final de esto? ¡¡¡¡Además de asegurar sus delegaciones de GPO, primero, averigüe dónde están sus referencias de rutas externas dentro de su entorno, y luego ASEGURE SUS RUTAS EXTERNAS!!!!
Resumen
Esperemos que esto proporcione algunos elementos de reflexión adicionales en torno a la protección de su entorno GP, y por lo tanto todo su entorno Windows. Si usted está confiando en GP hoy para configurar sus sistemas de Windows, no puedo enfatizar lo suficiente lo importante que es, desde una perspectiva de InfoSec, asegurar que esos GPOs estén abotonados, y cualquier cosa externa que ellos llamen, sea tratada como 'dentro del mismo dominio de preocupación' e igualmente abotonada. Así que para resumir los puntos de acción aquí:
- Bloquee el acceso de lectura a los GPO críticos y relacionados con la seguridad para garantizar que no delata su postura de seguridad.
- Bloquee el acceso de escritura a todos los GPO para evitar que se conviertan en un vector de ataque.
- Bloquear el acceso de escritura a todas las rutas externas a las que hacen referencia los GPO.
Darren
