El mes pasado, Microsoft publicó un aviso para CVE-2020-1317 que describe una vulnerabilidad de escalada de privilegios en la directiva de grupo. El descubridor de la vulnerabilidad la detalló en el sitio web Cyberark. La naturaleza de este problema es interesante y merece la pena conocerla. Durante años, Group Policy ha tenido esta dicotomía integrada en su diseño. A saber, la necesidad de ofrecer políticas por usuario a usuarios sin privilegios, a través de un mecanismo que se ejecuta como un proceso privilegiado, es decir, el motor de directivas de grupo. Microsoft ha manejado esto de varias maneras. Por ejemplo, la política de Plantillas Administrativas por usuario se entregaba a un conjunto de dos claves de registro en HKEY_CURRENT_USER que tenían permisos para que un usuario no pudiera escribir en ellas, a pesar de que podían escribir en prácticamente cualquier otra clave de esta colmena. Pero en el caso de esta CVE, había un par de agujeros evidentes. El primero de ellos se detallaba en la entrada del blog de Cyberark. En concreto, GP Preferences siempre ha tenido el concepto de archivos de historial. Estos archivos se crearon esencialmente para deshacer el estado de ciertas preferencias de GP cuando esos ajustes ya no se aplicaban. Estos archivos de historial eran esencialmente copias del archivo de configuración real que se almacenaba en SYSVOL para el GPO que entregaba la configuración, y se almacenaban en el perfil del usuario en %appdata%LocalMicrosoftGroup Policy, como se puede ver aquí:
Lecturas relacionadas
La ubicación de este archivo fue la clave de esta vulnerabilidad privesc. Los archivos en sí se almacenan en el perfil del usuario en un área a la que un usuario normal sin privilegios tiene plenos derechos. Sin embargo, los archivos son escritos aquí cada vez que una nueva configuración GPP es procesada, o la configuración es cambiada, por el motor GP, que a su vez se ejecuta como localSystem. Por lo tanto, tenemos un proceso localSystem escribiendo datos en el espacio de usuario sin privilegios, y aquí es donde comienza la diversión.
Para este exploit en particular, el autor utilizó enlaces simbólicos de Object Manager para redirigir cualquier archivo XML GPP arbitrario a una ubicación en c:windowsystem32, donde puede ser explotado por otro proceso para abrir esencialmente un proceso que se ejecuta como localSystem. Los detalles del código de escalada real a localSystem no se muestran, pero el uso de enlaces simbólicos OM (y la explotación de otros tipos de enlaces simbólicos de Windows), se describe en este excelente video de James Forshaw, quien también tiene código de ejemplo para la creación de estos enlaces aquí. Baste decir que para explotar esto, un atacante sólo tiene que borrar el archivo que GPP dejó en su perfil de usuario, y sustituirlo por un enlace simbólico OM. El GP Engine vendrá entonces, felizmente ejecutándose como sistema local, y esencialmente escribirá un nuevo archivo XML a cualquiera que sea el destino que se especifique en c:windowssystem32. Pueden entonces escribir cualquier contenido que quieran en ese archivo y explotarlo desde allí. Bastante ingenioso.
Vías de explotación alternativas y el parche
Cuando vi por primera vez este exploit descrito, me pregunté en voz alta si los archivos de Historial GPP eran el único lugar donde esto podría ser explotado. Sabía a ciencia cierta que mi buen amigo, el archivo de registro (ntuser.pol), era otro de estos archivos GPO por usuario que se mantenían en el perfil del usuario, y que el usuario podía escribir, pero que el motor de GP actualizaba. Así que era lógico suponer que este archivo también podría ser explotado de la misma manera que los archivos del historial de Preferencias de GP. Así que cuando observé un sistema Windows después de aplicar el parche para esta vulnerabilidad, noté algunas cosas interesantes. En primer lugar, la forma en que Microsoft resolvió esto, fue mover los archivos de historial GPP fuera del perfil de usuario, y en la carpeta protegida %programdata% (específicamente bajo %programdata%MicrosoftGroup PolicyUsers). Esta carpeta no es escribible por los usuarios normales, lo que ayuda a evitar el uso de enlaces simbólicos en la versión anterior. La ruta completa al archivo es un poco raro, como se puede ver aquí:
La estructura de carpetas es por usuario (es decir, la ruta de la carpeta SID), luego por GPO (el GUID de la GPO), luego por usuario de nuevo (otra carpeta SID), lo cual parece un poco excesivo, pero seguro que tenían una razón para ello 🙂 .
The next question I was curious about, was the ntuser.pol file I mentioned above. Sure enough, Microsoft also moved that file to a location in %programdata% as well, albeit in a different folder structure from GPP history files. Namely, under %programdata%MicrosoftGroupPolicyUsers<SID of User>. I thought it was mildly funny that they have two folder structures under the Microsoft folder, one called “Group Policy” and the other called “GroupPolicy”. Oh well. This latter path is also where the per-user Group Policy Cache files are kept. See this article for a review of the Group Policy cache.
Ahora bien, según el autor de este exploit, Microsoft tardó casi un año en solucionarlo. Puedo imaginar absolutamente que este sea el caso. Dado que, entre todas las áreas de Preferencias de GP, y, todas las áreas que utilizan ntuser.pol, incluyendo Plantillas de Administración, AppLocker, Firewall de Windows, Política de Clave Pública, y probablemente algunos que me estoy perdiendo, que podría haber sido potencialmente una gran cantidad de código para ir a través de asegurarse de mover los archivos no romper todo. No me sorprendería si alguna rotura todavía aparece en algún rincón oscuro de la política antes de que todo esto termine. No obstante, se trata de un exploit interesante, que se ha hecho más interesante por algunas verrugas de hace 20 años que GP ha traído a la fiesta.
¿Le interesa saber más sobre la gestión de directivas de grupo teniendo en cuenta la seguridad? Vea nuestro seminario web en el que se resumen los casi cuatro años de investigación que he realizado sobre las distintas formas en que los atacantes explotan las directivas de grupo. Y lo que es más importante, desglosaré los pasos clave que puede dar para defender su entorno de directivas de grupo y, por lo tanto, su entorno de Windows, de los abusos. Espero verle allí.
