Llegamos a ustedes gracias a:



Alertas de Seguridad

Atacantes pueden usar una falla en Group Policy

Para apoderarse de los sistemas Windows de la empresa

[10/06/2020] Microsoft arregló 129 vulnerabilidades que abarcan toda su gama de productos de software, desde Windows y Office hasta Visual Studio, Azure DevOps y Microsoft Apps para Android. Once de esas fallas son críticas y deben ser corregidas inmediatamente, pero una vulnerabilidad en particular podría ser fácilmente pasada por alto, y podría permitir a los hackers con acceso local tomar el control total de los sistemas Windows de la empresa.

El problema, identificado como CVE-2020-1317, afecta a uno de los mecanismos más básicos para gestionar centralmente la configuración de las computadoras y usuarios de Windows en entornos de Active Directory: Group Policy. Lo que es más importante, la falla es antigua y existe en todas las versiones de Windows para escritorios y servidores a partir de Windows Server 2008. Microsoft lo califica como importante y lo describe como tal:

"Existe un aumento de la vulnerabilidad de los privilegios cuando Group Policy comprueba el acceso de forma incorrecta. Un atacante que explotara con éxito esta vulnerabilidad podría ejecutar procesos en un contexto elevado. Para explotar la vulnerabilidad, un atacante tendría primero que iniciar sesión en el sistema y luego ejecutar una aplicación especialmente diseñada para tomar el control del sistema afectado".

El aviso de la compañía no tiene otra información aparte de eso, pero según los investigadores de CyberArk que descubrieron la vulnerabilidad, es bastante grave.

Cómo un atacante puede explotar la vulnerabilidad de Group Policy

La configuración de Group Policy se almacena en los sistemas Windows como Group Policy Objects (GPO) y el administrador del dominio puede distribuirlos a través de la red desde el controlador de dominio. Sin embargo, las actualizaciones de Group Policy no son instantáneas de forma predeterminada y normalmente tardan en propagarse por la red, por lo que Windows incluye una herramienta llamada GPUpdate.exe que los usuarios pueden ejecutar para solicitar actualizaciones de GPO desde el controlador de dominio en lugar de esperarlas.

"Curiosamente, una actualización de Group Policy puede ser solicitada manualmente por un usuario local no privilegiado", dijeron los investigadores de seguridad de CyberArk en una entrada de blog. "Por lo tanto, si logra encontrar un error en el proceso de actualización de Group Policy, puede activarlo usted mismo cuando quiera, facilitando así un posible ataque".

Las actualizaciones de Group Policy se manejan a través de un servicio llamado GPSVC que se ejecuta bajo el proceso svchost.exe, que maneja muchos servicios en Windows. Como era de esperar, este servicio se ejecuta con los mayores privilegios posibles, en el contexto del SISTEMA DE AUTORIDADES DE NT.

Las actualizaciones de Group Policy pueden vincularse a una máquina, un sitio, un dominio o una unidad organizativa y el servicio las guardará en un archivo llamado Applied-Object.xml, al que luego se le cambiará el nombre por el tipo de objeto al que se aplica la directiva. Por ejemplo, una política sobre impresoras se traduciría a Printers\Printers.xml. Los investigadores descubrieron que las actualizaciones de GPO vinculadas a una unidad organizativa -que se dirigen a todos los usuarios y computadoras del dominio- se guardan en una ubicación de la computadora bajo el directorio %localappdata% al que puede acceder cualquier usuario local.

Además, al realizar esta operación el servicio no cambia su contexto y privilegios al usuario local que solicitó la actualización, lo que se conoce como suplantación de identidad del usuario en el lenguaje de la API de Windows, sino que realiza la operación de escritura de archivos con privilegios de LocalSystem. Por lo tanto, este mecanismo prevé una situación en la que un usuario sin privilegios puede utilizar GPUpdate.exe para desencadenar operaciones de escritura de archivos con privilegios de LocalSystem en un directorio al que tenga acceso.

El último paso en la cadena de explotación es que el usuario cree un enlace simbólico que vincule la ubicación del archivo objetivo que será escrito -por ejemplo, Printers.xml- a un archivo del sistema ubicado en un directorio protegido de Windows como C:\Windows\System32\ donde viven muchos archivos ejecutados por el núcleo del sistema operativo. Esto significa que cuando el GPSVC intente escribir el archivo Printers.xml en la ubicación accesible para el usuario, en realidad será dirigido a escribir un archivo en C:\Windows\System32\N, lo cual puede hacer porque opera con privilegios de sistema.

Los investigadores de CyberArk describen los pasos como tales:

  • Listar los GUIDs de Group Policy que tiene en C:\N-Usuarios-Aplicaciones de Datos Locales de Microsoft\N-Historia.
  • Si tiene múltiples GUIDs, compruebe qué directorio se actualizó recientemente.
  • Entre en ese directorio y en el subdirectorio, que es el SID del usuario.
  • Mire el último directorio modificado. Esto variará en su entorno. En mi caso, fue el directorio de la impresora.
  • Borre el archivo, Printers.xml, dentro del directorio Printers.
  • Cree un punto de montaje NTFS para el Control RPC + un enlace simbólico de Administrador de Objetos con Printers.xml que apunte a C:\NWindows\N-System32 lo que sea.dll.
  • Abra su terminal favorito y ejecute gpupdate.

La razón por la que la capacidad de los usuarios sin privilegios de escribir archivos en directorios del sistema operativo protegido es peligrosa, es porque puede ser utilizada para el llamado ataque de secuestro DLL. El directorio C:\Windows\System32\Nes una de las primeras ubicaciones que muchas aplicaciones o el SO buscan cuando quieren cargar una DLL en particular. Si un usuario malintencionado puede colocar una DLL con un nombre específico y un código malintencionado en ese directorio, será ejecutada por un servicio o aplicación con privilegios de LocalSystem, lo que dará a ese código un control total sobre el equipo.

El valor de las fallas de escalada de privilegios

Las vulnerabilidades de escalada de privilegios no suelen recibir calificaciones de gravedad crítica porque, para explotarlas, los atacantes deben tener ya un acceso limitado a la computadora local. Sin embargo, los atacantes pueden acceder a un sistema de muchas maneras, incluyendo correos electrónicos de phishing con archivos adjuntos maliciosos, descargas desde el disco duro, explotando las vulnerabilidades en cualquier aplicación. Por eso es una práctica básica de seguridad que los usuarios de un sistema Windows tengan privilegios limitados y que las aplicaciones que ejecuten tengan privilegios limitados, el menor privilegio posible que necesiten para operar.

Debido a las mejoras en la arquitectura de seguridad de los sistemas operativos modernos y a los esfuerzos de los desarrolladores por reducir su superficie de ataque, es bastante raro encontrar una vulnerabilidad que pueda ser explotada remotamente sin autenticación en una red o en Internet y que dé lugar directamente a un acceso completo al sistema. La mayoría de los ataques de hoy en día utilizan cadenas de explotación que combinan múltiples vulnerabilidades, y las fallas de escalada de privilegios son una pieza importante de esas cadenas, el último paso antes de que el atacante obtenga el control de todo el sistema.

Desafortunadamente, las vulnerabilidades de escalada de privilegios siguen siendo comunes y esta es una de las más de 60 fallas de este tipo encontradas por los investigadores de CyberArk a través de productos de los principales proveedores como parte de un proyecto de investigación de un año de duración. En Windows, las fallas de escalamiento de privilegios se encuentran comúnmente en los controladores del núcleo y de terceros, pero también en varios servicios del sistema, como en este caso.

"Este tipo de errores son muy comunes", señala Eran Shimony, investigador de CyberArk Labs. "Durante nuestro proyecto de investigación, muchas de las vulnerabilidades que encontramos eran de naturaleza similar, lo que significa que los desarrolladores no son totalmente conscientes de este tipo de vulnerabilidades, pero son fáciles de evitar, así que sería maravilloso que lo hicieran".

Abordar la vulnerabilidad de GPO requirió que Microsoft corrigiera la forma en que la Group Policy comprueba el acceso, lo cual probablemente no fue algo fácil considerando que es un mecanismo fundamental para la administración de Windows. CyberArk informó por primera vez del problema a Microsoft en junio del año pasado, por lo que la compañía tardó un año en publicar una actualización. Eso también podría deberse a que tuvo que desarrollar parches para todos los sistemas operativos afectados que están fuera del soporte regular, pero para los cuales los clientes todavía podrían tener suscripciones extendidas de actualizaciones de seguridad, incluyendo Windows Server 2008, Windows Server 2012 y Windows 7.