MS15-011 y MS15-014: Endurecimiento de las Directivas de grupo

  • Article

Por swiat

Publicamos MS15-011 y MS15-014 que endurecen la Directiva de grupo y corrige las vulnerabilidades de acceso a redes que se pueden utilizar para lograr la ejecución de código remoto (RCE) en redes de dominio. La actualización MS15-014 soluciona un problema en la actualización de la Directiva de grupo que se puede utilizar para deshabilitar los requisitos de Firmas SMB globales del lado del cliente, pasando por alto una característica de seguridad existente integrada en el producto. MS15-011 añade nueva funcionalidad, endureciendo el acceso de archivos de red al bloquear el acceso a usos compartidos no confiables controlados por el atacante cuando se actualiza la Directiva de grupo en las máquinas cliente. Estos dos cambios son mejoras importantes que le ayudarán a proteger su red de dominio.

¿Cuál es el riesgo?, es decir, ¿cuál es el escenario de un ataque?

Veamos uno de los escenarios típicos de ataque como se indica en el siguiente diagrama.

Este es un ejemplo de un escenario ataque tipo "cafetería", donde un atacante intentaría realizar cambios en un switch de red compartida en un lugar público y puede dirigir el tráfico de los clientes a un sistema controlado por éste.

  1. En este escenario, el atacante ha observado el tráfico del switch y encontró que una máquina específica está intentando descargar un archivo ubicado en la ruta de acceso UNC: \\10.0.0.100\Share\Login.bat .

  2. En el equipo del atacante, un uso compartido se ha establecido que coincide exactamente con la ruta UNC del archivo solicitado por la víctima: \\*\Share\Login.bat.El atacante modifica entonces la tabla ARP en el switch local para asegurar que el tráfico destinado al servidor de destino 10.0.0.100 se desvíe ahora a su máquina.

    1. El atacante ha elaborado los contenidos de Login.bat para ejecutar código arbitrario y malicioso en el sistema de destino. Dependiendo del servicio que solicite Login.bat, esto podría ser ejecutado como el usuario local o como la cuenta del SISTEMA en la máquina de la víctima.

  4. Cuando la máquina de la víctima solicita el archivo, la máquina del atacante devolverá la versión maliciosa de Login.bat.

Este escenario también ilustra que este ataque no se puede utilizar ampliamente en Internet - un atacante necesita dirigirse a un sistema o grupo de sistemas que soliciten archivos con este UNC único.

¿Cuáles fueron las vulnerabilidades de la Directiva de grupo?

Existía una vulnerabilidad RCE en la forma en que la Directiva de grupo recibe y aplica los datos de políticas cuando se conecta a un dominio. Al mismo tiempo, existía una vulnerabilidad por lo que la Directiva de grupo podía dejar de recuperar las políticas de seguridad válidas y, en su lugar, aplicar unas predeterminadas, potencialmente menos seguras. Esto podría, a su vez, utilizarse para desactivar las políticas de Firma de SMB aplicadas en el dominio.

¿Qué arreglamos en MS15-014 ?

El riesgo de incumplimiento de la Firma SMB se fijó mediante la corrección de la forma en que la Directiva de grupo se comportaría cuando no se pueden recuperar políticas actuales y válidas de seguridad. Después de aplicar la revisión, la Directiva de grupo ya no tomará los valores predeterminados y, en su lugar, aplicará las últimas políticas buenas conocidas si falla una recuperación de la política de seguridad.

¿Qué nos endurecimos bajo MS15-011 ?

Mientras la Firma SMB proteja contra ataques Man-in-the-Middle, con las vulnerabilidades antes mencionadas en la Directiva de grupo, es posible desactivarla. Pero lo más importante, el Cliente SMB no requiere la Firma SMB de forma predeterminada por lo que es posible dirigir el tráfico de dominios relacionados, sobre todo el tráfico sin cifrar, a las máquinas controladas por atacante y servir contenido malicioso a las víctimas en respuesta. Para bloquear este tipo de ataques hemos añadido la capacidad de endurecer el acceso a la ruta UNC dentro de la red de dominio.

La Convención de nomenclatura universal (UNC) es una notación estandarizada que Windows utiliza para acceder a los recursos de archivos; en la mayoría de los casos, estos recursos se encuentran en un servidor remoto. UNC permite acceso al sistema a los archivos utilizando el formato de ruta estándar: \\<hostname>\<sharename>\<objectname> , por ejemplo, \\contoso.com\fileshare\passwords.txt, sin requerir que la aplicación o usuario entienda la tecnología de transporte subyacente utilizada para proporcionar acceso al archivo. De esta manera, el cliente UNC en Windows abstrae las tecnologías de archivos de redes, como SMB y WebDAV, detrás de una sintaxis familiar de la ruta de archivo. Las rutas UNC se utilizan en Windows en todo, desde impresoras a archivos compartidos, proporcionando a un atacante una superficie amplia para explorar y atacar. Para abordar adecuadamente esta debilidad en UNC, teníamos que mejorar UNC para permitir que un servidor se autentifique ante un cliente, lo que permite que la máquina cliente confíe en el contenido procedente del sistema de destino y quede protegida de recursos compartidos de archivos maliciosos.

¿Cómo la hemos endurecido?

Cuando una aplicación o servicio intenta acceder a un archivo en una ruta UNC, el Proveedor de UNC múltiples (MUP) es responsable de la enumeración de todos los Proveedores de acceso UNC instalados y seleccionar uno para satisfacer todas las solicitudes de I/O en las rutas UNC especificadas. En una instalación típica del cliente Windows, MUP trataría el protocolo Bloquear los mensajes del servidor (SMB) en primer lugar, pero si el Proveedor SMB UNC no puede establecer una conexión SMB al servidor, entonces MUP trataría con el siguiente Proveedor UNC y así sucesivamente hasta que uno pueda establecer una conexión (o no haya proveedores UNC restantes, en cuyo caso la solicitud fallaría). 

En la mayoría de los escenarios, la seguridad del servidor es de suma importancia: almacena datos confidenciales, por lo que los protocolos de transferencia de archivos están diseñados de tal manera que el servidor valide la identidad del cliente y realice controles de acceso adecuados antes de permitir al cliente leer o escribir en archivos. El límite de confianza cuando la Directiva de grupo aplica políticas en equipos y/o usuarios es completamente al revés: los datos sensibles son la configuración del cliente y el servidor remoto tiene la capacidad de cambiar la configuración del cliente mediante la transmisión de archivos y/o scripts de políticas. Cuando la Directiva de grupo recupera datos desde el servidor de políticas, es importante que el cliente realice controles de seguridad para validar la identidad del servidor y evitar la manipulación de datos entre el cliente y el servidor (además de los controles de seguridad normales realizados por el servidor para validar las credenciales del cliente). También es importante que MUP sólo envíe las peticiones de archivos de la Directiva de grupo a Proveedores UNC que apoyen estos controles del lado del cliente, a fin de evitar que los controles sean anuladas cuando el proveedor SMB UNC no pueda establecer una conexión con el servidor. 

La Directiva de grupo no es necesariamente el único servicio para el que estos controles de seguridad adicionales del lado del cliente son importantes. Cualquier aplicación o servicio que recupere los datos de configuración de una ruta UNC, y/o automáticamente ejecute programas o scripts ubicados en rutas UNC, podrían beneficiarse de estos controles de seguridad adicionales. Como tal, hemos añadido una nueva característica, el Acceso fortalecido a UNC, junto con una configuración de la Directiva de grupo correspondiente en la que MUP se puede configurar para requerir propiedades adicionales de seguridad al acceder a las rutas UNC configuradas. 

Cuando se configura el Acceso fortalecido a UNC, MUP inicia la tramitación de solicitudes de la ruta UNC de una manera ligeramente diferente: 

Cada vez que MUP recibe una solicitud para crear o abrir un archivo en una ruta UNC, evalúa la configuración actual del Acceso fortalecido a UNC de la Directiva de grupo para determinar qué propiedades de seguridad se requieren para la ruta UNC solicitada. El resultado de esta evaluación se utiliza para dos propósitos: 

  1. MUP sólo considera Proveedores UNC que han manifestado el soporte a todas las propiedades de seguridad requeridas. Cualquier Proveedor UNC que no brinde soporte a todas las propiedades de seguridad requeridas en la configuración del Acceso fortalecido a UNC para la ruta UNC solicitada simplemente se salta.
  2. Una vez que un Proveedor de UNC se selecciona por MUP, las propiedades de seguridad requeridas se pasan a ese Proveedor de UNC vía la Creación de un parámetro extra (ECP). Los Proveedores UNC que optan por un Acceso fotalecido a UNC deben respetar las propiedades de seguridad necesarias indicadas en ECP; si el Proveedor de UNC seleccionado no puede establecer una conexión con el servidor de una manera que satisfaga estos requisitos (por ejemplo, debido a la falta de soporte de servidor), entonces el Proveedor de UNC seleccionado debe fallar la solicitud.

Incluso las aplicaciones y servicios de otros fabricantes pueden tomar ventaja de esta nueva funcionalidad sin cambios de código adicionales; añada simplemente los detalles de configuración necesarios en la Directiva de grupo. Si un Proveedor de UNC puede establecer una conexión con el servidor especificado que cumpla con las propiedades de seguridad necesarias, entonces la aplicación/servicio podrá abrir las puertas de forma normal; si no, las manijas de apertura fallarían, impidiendo así el acceso inseguro al servidor remoto.

Consulte https://support.microsoft.com/kb/3000483 para obtener detalles sobre la configuración de la característica del Acceso fortalecido a UNC.

Considere el siguiente escenario:

    • Contoso mantiene un dominio de Active Directory llamado corp.contoso.com con dos Controladores de dominio (DC) con nombre dc1.corp.contoso.com y dc2.corp.contoso.com.
    • Una portátil está unida al dominio antes mencionado.
    • La Directiva de grupo está configurado para aplicar un Objeto de la Directiva de grupo (GPO) a la portátil que configura el Acceso fortalecido a UNC para las rutas \\*\NETLOGON y \\*\SYSVOL, de tal manera que todos los accesos a estas rutas requieren tanto Autenticación como integridad mutuas.
    • La Directiva de grupo está configurada para aplicar un GPO a la portátil que ejecuta el script ubicado en \\corp.contoso.com\NETLOGON\logon.cmd cada vez que un usuario inicia sesión en la máquina.

 

Con la configuración anterior, cuando un usuario inicia sesión con éxito en la portátil y tiene cualquier acceso a la red, la Directiva de grupo intentará ejecutar el script ubicado en \\corp.contoso.com\NETLOGON\logon.cmd, pero tras bambalinas, MUP sólo permitiría al script ejecutarse si el archivo se ha podido abrir y transmitir de forma segura:

  1. MUP recibe una solicitud para abrir el archivo en \\corp.contoso.com\NETLOGON\logon.cmd.

  2. MUP se da cuenta de que la ruta solicitada coincide \\*\NETLOGON y las rutas que coinciden con \\*\NETLOGON están configuradas para requerir tanto Autenticación como integridad mutuas. Los Proveedores UNC que no brindan soporte al Acceso fortalecido a UNC o indiquen que no brindan soporte tanto a la Autenticación como a la integridad mutuas se omiten.

  3. El cliente del Espacio de nombres del servidor de archivos distribuidos (DFS-N) detecta que la ruta UNC solicitada es un espacio de nombres de dominio DFS-N y comienza su proceso de volver a escribir la ruta UNC (todas las solicitudes DFS-N estarán sujetas a los mismos requisitos de propiedades de seguridad identificados por MUP en el paso 2):La ruta final UNC se regresa al MUP y así selecciona un Proveedor de UNC para manejar la petición. MUP selecciona el Proveedor de SMB UNC, ya que DCs utilizan SMB para compartir las acciones NETLOGON y SYSVOL.

    1. El cliente DFS-N utiliza el servicio Localizador de DC y/o solicitudes de Referencia DFS-N DC (dependiendo de la versión del sistema operativo) para identificar el nombre de un DC en el dominio (por ejemplo dc1.corp.contoso.com).
    2. DFS reescribe la ruta con el DC seleccionado (por ejemplo, \\corp.contoso.com\NETLOGON\logon.cmd se vuelve \\dc1.corp.contoso.com\NETLOGON\logon.cmd). Ya que la Autenticación mutua es necesaria y se espera que el objetivo sea un DC, DFS utiliza un Nombre principal de servicio de Kerberos (SPN) especial para verificar que el nombre recuperado en el paso anterior es de hecho el nombre de un DC (si el nombre no es un DC, la autenticación Kerberos fallará debido a un SPN desconocido)
    3. Si hay enlaces adicionales DFS-N en la ruta UNC especificada, el cliente DFS-N continúa la iteración y sustitución de rutas a vínculos DFS-N con rutas a destinos disponibles hasta que tenga una ruta UNC que no tenga ningún vínculo restante DFS-N.

  5. El Proveedor de SMB UNC establece una sesión autenticada con el servidor SMB seleccionado (si una sesión autenticada no está ya presente). Si la sesión autenticada no está autenticada mutuamente (por ejemplo, la autenticación se realiza utilizando el protocolo NTLM), a continuación, el Proveedor SMB UNC fallaría la solicitud de apertura de logon.cmd, ya que no se cumple con el requisito de autenticación mutuo identificado en el paso 2.

  6. El Proveedor SMB UNC permite la Firma SMB en todas las solicitudes relacionadas con logon.cmd, ya que MUP informó a SMB que se requiere la integridad para esta petición. Cualquier intento de manipular los solicitudes o respuestas SMB invalidaría las firmas en las peticiones/respuestas, permitiendo así que el extremo receptor detecte las modificaciones no autorizadas y fallen las solicitudes SMB.

En este escenario, el requisito del lado del cliente de la autenticación e integridad mutuas de extremo a extremo protege la portátil para que no ejecute un script de inicio de sesión localizado en un servidor malicioso mediante los siguientes controles de seguridad:

    • El requisito de Autenticación mutua asegura que la conexión no sea redirigida a un Servidor SMB inesperado (y potencialmente malicioso) cuando el Cliente SMB intenta establecer una conexión con la ruta UNC solicitada.
    • El requisito para la Integridad permite la Firma SMB, incluso si el Cliente SMB no requiere la Firma SMB para todas las rutas predeterminadas. Esto protege al sistema contra una manipulación sobre el alambre que se pueda utilizar para cambiar el contenido del script logon.cmd al transmitirse entre el DC seleccionado y la portátil.
    • Los requisitos combinados tanto para la Autenticación como para la integridad mutua asegura que la ruta reescrita final seleccionada por el Cliente DFS-N coincida con una ruta que permite la configuración del espacio de nombre DFS-N y que los ataques de spoofing y/o suplantación no puedan causar que el Cliente DFS-N reescriba la ruta UNC solicitada a una ruta UNC alojada por un servidor inesperado (y potencialmente malicioso).

Sin estas protecciones del lado del cliente, las solicitudes ARP, DNS, DFS-N o SMB enviadas vía la Directiva de grupo a través de redes no confiables potencialmente podría provocar que el servicio de la Directiva de grupo ejecute el script logon.cmd del Servidor SMB equivocado.

¿Cómo configuro para protegerme a mí o a mis usuarios?

Una vez que se instale la actualización incluida como parte del boletín MS15-011 siga las instrucciones en https://support.microsoft.com/kb/3000483 para asegurar que sus sistemas están protegidos adecuadamente. MS15-014 instalará y proporcionará protección sin ninguna configuración adicional.

Una palabra sobre CVD y la solución de problemas difíciles

En muchos aspectos, esta solución o “fix" de seguridad se describe con mayor precisión como una funcionalidad completamente nueva de Windows. Agregar algo de esta magnitud plantea un desafío único para la respuesta de seguridad. Típicamente, las vulnerabilidades de software están limitadas más estrechamente tanto en investigación y remediación - y la mayor parte de las respuestas se estructuran para hacer frente a ese ámbito. Entre los beneficios de la Divulgación coordinada de vulnerabilidades (ECV) es que proporciona una mayor flexibilidad y una colaboración más estrecha con los investigadores al tomar el tiempo y la perspectiva necesaria para entregar soluciones de seguridad más completas a los clientes. En este caso resolvemos una vulnerabilidad que requiere un mayor alcance en la ingeniería para ofrecer una solución.

La mayoría de las vulnerabilidades reportadas al MSRC son errores en un solo componente, que se investigan, entienden y fijan dentro de los tiempos de respuesta aceptados por la industria. La creación de la nueva funcionalidad del Endurecimiento UNC, sin embargo, requiere una arquitectura totalmente nueva que aumenta el tiempo de desarrollo y requiere extensas pruebas. Gracias a CVD y la estrecha colaboración con investigadores de seguridad apasionados que informaron la vulnerabilidad, Microsoft tuvo tiempo suficiente para construir la solución correcta para un tema complicado. Si los investigadores de seguridad no estuvieran dispuestos a abstenerse de una divulgación hasta que nuestra solución estuviera lista, los clientes se hubieran puesto en riesgo.

 

Microsoft ofrece su reconocimiento a la comunidad de CVD y un agradecimiento especial a los reporteros de este asunto que se ha traducido en el Endurecimiento de UNC: Jeff Schmidt de JAS Global Advisors, Dr. Arnoldo Muller-Molina de simMachines, La Corporación de Internet para la Asignación de Números y Nombres en Internet (ICANN) y Lucas Jennings de MWR Labs.

Original: https://blogs.technet.com/b/srd/archive/2015/02/10/ms15-011-amp-ms15-014-hardening-group-policy.aspx