MS15-011 e MS15-014: Fortalecimento e Integridade das Políticas de Grupo

Por swiat  

Lançamos em 10 de Fevereiro de 2015,  os  boletins  MS15-011 e MS15-014 que fortalecem as  diretiva de grupo e reforçam o acesso à rede  contra vulnerabilidades que podem ser utilizadas para fazer a execução remota de código (RCE) no domínio das redes. A atualização MS15-014 resolve um problema de atualização de Diretiva de Grupo que pode ser usado para desativar a assinatura do Server Message Block (SMB) global dos requisitos do cliente, ignorando uma característica de segurança incorporada ao produto. MS15-011  adiciona novas funcionalidades, reforçando o acesso ao arquivo de rede para bloquear o acesso de atacantes,  quando a diretiva de grupo é atualizada nas máquinas clientes. Essas duas atualizações são importantes melhorias que ajudarão a proteger sua rede de domínio.

Qual é o risco , ou seja, qual é o cenário de um ataque?

Vamos dar uma olhada em um dos típicos cenários de ataque como descrito no diagrama abaixo. 

Este é um exemplo de uma "coffee shop" em cenário de ataque, onde o invasor tenta fazer mudanças a um “Switch”  de  uma rede compartilhada em um local público e pode direcionar o tráfego dos clientes a um sistema controlado pelo invasor.

    1. Neste cenário, o atacante tem observado o tráfego na Switch e verificou que uma determinada máquina está tentando fazer o download de um arquivo localizado no diretório UNC: \\exemplo,10.0.0.100 \Share\Login.bat .
    1. Na máquina do invasor, um “share”  é definido para que corresponda exatamente ao diretório UNC do arquivo solicitado pela vítima: \\ * \Share\Login.bat.
  1. O invasor criou  o conteúdo do login.bat para executar um código malicioso no sistema designado. Dependendo do serviço solicitado o Login.bat, poderá ser executado como usuário local ou como uma conta do sistema na máquina da vítima.

    1. Em seguida, o invasor modifica a tabela ARP da Switch local para garantir que o tráfego destinado ao servidor de destino 10.0.0.100 agora seja direcionado através de máquina do invasor.
    1. Quando a máquina da vítima seguinte solicita o arquivo, o invasor da máquina irá retornar a versão mal-intencionada do Login.bat.

Este cenário demonstra também que este ataque não pode ser usado amplamente em toda a internet – um invasor precisa  atingir um sistema específico ou grupo de sistemas que solicita os arquivos com este exclusivo UNC.

Quais são as vulnerabilidades nesta Política de Grupo?

Uma execução remota de código (RCE)  existia na vulnerabilidade da  Diretiva de Grupo que foi  aplicada ao conectar-se a um domínio. Simultaneamente, uma vulnerabilidade existia pelo qual a diretiva de grupo pode falhar em recuperar a diretiva de segurança válida e aplicar uma diretiva de grupo padrão, potencialmente menos segura, em vez da política que era intencionada. Isto poderia, por sua vez, ser usado para desativar assinatura SMB no domínio forçando a diretiva imposta. 

O que corrigimos no MS15-014?

O risco de evasão de assinatura do SMB foi consertando,  corrigindo como a Diretiva de Grupo se comportaria quando ela falha em recuperar uma política de segurança atual e válida. Depois de aplicar a correção, a Diretiva de Grupo deixará de aplicar as políticas  padrões e, ao contrário, utiliza a  última boa política de grupo que foi usada com sucesso para se  recuperar da  política de segurança que falhou.

 

O que reforçamos (hardening) no  MS15-011?

Ao mesmo tempo que a assinatura SMB protege contra ataques “Man-In-The-Middle “, como as vulnerabilidades acima na Diretiva de Grupo também é possível desativá-la. Mas o mais importante, o cliente SMB não exige a assinatura SMB por padrão, então é possível direcionar o tráfego de domínio relacionados, especialmente o tráfego não criptografado, para máquinas controladas  do atacante e usar conteúdo malicioso para as vítimas. Para bloquear este tipo de ataques  adicionamos a capacidade de reforçar o acesso UNC dentro da rede de domínio.

Universal Naming Convention (UNC) É uma notação padronizada que o Windows utiliza para acessar recursos de arquivos; na maior parte dos casos, estes recursos estão localizados em um servidor remoto. UNC permite que o sistema de acesso a arquivos usando o padrão no formato: \ \n <hostname> \ <sharename> \ <objectname>, por exemplo, \\contoso.com\fileshare\passwords.txt, sem exigir que o aplicativo ou o  usuário entendam as principais tecnologias de transporte utilizado para fornecer acesso ao arquivo.

Desta forma, o cliente UNC do Windows,  utiliza tecnologias de arquivos de rede como SMB e WebDAV, através de uma sintaxe de caminho familiar do arquivo. Caminhos UNC são utilizados no Windows em tudo, desde impressoras a compartilhamentos de arquivos, proporcionando ao atacante uma superfície ampla para explorar o ataque. Para tratar adequadamente essa fraqueza na UNC, tivemos que melhorar a UNC para permitir que um servidor  se para autentique a um cliente, permitindo assim que a máquina cliente confie no conteúdo proveniente do sistema de destino e assim seja protegido de compartilhamentos de arquivos maliciosos.

 

Como é feito o reforço (hardening)?

Quando um aplicativo ou serviço tenta acessar um arquivo em um caminho UNC, de vários provedores, o (Multiple UNC Provider (MUP) ) que é responsável para enumerar todos os provedores UNC instalados e selecionando um deles para satisfazer todos os pedidos de I/O para caminho UNC especificado. Em uma típica instalação de cliente Windows, o MUP, tenta o protocolo SMB (Server Message Block) em primeiro lugar, mas se o provedor do UNC  não é capaz de estabelecer uma conexão SMB com o servidor, em seguida, o MUP, tenta o próximo Provedor UNC e assim por diante, até que um deles seja capaz de estabelecer uma conexão (ou se não houver provedores UNC restantes, neste caso o pedido falharia). 

Na maioria dos cenários, a segurança do servidor é de extrema importância: o servidor armazena dados confidenciais, portanto, protocolos de transferência de arquivos são projetados de tal forma que o servidor valida a identidade do cliente e executa verificações de acesso adequadas antes de permitir que o cliente leia ou grave arquivos.

O limite de confiança quando a Diretiva de de Grupo se aplica à políticas no computador e / ou usuário é completamente invertida: os dados sensíveis é a configuração do cliente e o servidor remoto tem a capacidade de alterar a configuração do cliente através de transmissão de arquivos e / ou scripts em políticas.  Quando a Diretiva de Grupo está recuperando os dados do servidor de política, é importante que o cliente execute verificações de segurança para validar a identidade do servidor e impedir a manipulação de dados entre o cliente e o servidor (para além das verificações de segurança normais realizadas pelo servidor para validar as credenciais). Também é importante que MUP só envie as solicitações de arquivos de política de grupo para provedores UNC que suportam estas verificações do lado do cliente, de modo a evitar que os controles sejam ignorados quando o provedor SMB UNC é incapaz de estabelecer uma conexão com o servidor.

Diretiva de Grupo não é necessariamente o único serviço para o qual essas verificações extras de segurança do lado do cliente são importantes. Qualquer aplicativo ou serviço que recupera dados de configuração de um caminho UNC, e / ou automaticamente executa programas ou scripts localizados em caminhos UNC poderia se beneficiar destas verificações de segurança adicionais. Como tal, nós adicionamos novo recurso, o reforço do acesso ao UNC (UNC Hardened Access), juntamente com a correspondente definição de política de grupo no qual MUP pode ser configurado para exigir propriedades de segurança adicionais ao acessar caminhos UNC configurados.

Quando o reforço do acesso ao UNC é configurado, o MUP trata os pedidos  de caminho UNC de uma forma ligeiramente diferente. 

Cada vez que o MUP recebe um pedido para criar ou abrir um arquivo em um caminho UNC, ele avalia as configurações atuais de política de grupo o reforço do acesso ao UNC (UNC Hardened Access) para determinar quais propriedades de segurança são necessárias para o caminho UNC solicitado. O resultado desta avaliação é utilizado para duas finalidades:

  1. O MUP UNC considera apenas os prestadores de serviços que têm indicado apoio a todas as propriedades exigidas de segurança. Os prestadores de serviços de UNC que não suportam todas as propriedades de segurança necessárias através da  configuração  de reforço do acesso UNC requerido, esta será simplesmente ignorada.

  2. Uma vez que um Provedor de UNC é selecionado pelo o MUP, as propriedades de segurança exigidas são passados para o Provedor UNC via criação de um parâmetro extra. Fornecedores UNC que optarem por  UNC de acesso fortalecido devem respeitar as propriedades de segurança exigidos indicados no ECP; Se o Provedor de UNC selecionado é incapaz de estabelecer uma conexão com o servidor de forma que satisfaça estes requisitos (por exemplo, devido à falta de suporte do servidor), em seguida, o Provedor de UNC selecionado vai falhar o pedido.

Até aplicativos de terceiros e serviços podem aproveitar este novo recurso sem mais alterações de código; basta adicionar os detalhes  necessários de configuração de Diretiva de Grupo. Se um fornecedor UNC é capaz de estabelecer uma conexão para o servidor especificado que satisfaça as propriedades de segurança exigidas, em seguida, o aplicativo/serviço será capaz de dar conta do serviço normalmente; se não o pedido de abertura falha, evitando acesso inseguro ao servidor remoto.

Consulte o site http://support.microsoft.com/kb/3000483 para obter mais detalhes sobre a configuração do recurso de reforço ao acesso UNC.

Considere o seguinte cenário:

    • Contoso mantém um domínio no Active Directory chamado corp.contoso.com com dois controladores de domínio (DCs) chamado dc1.corp.contoso.com e dc2.corp.contoso.com.
    • Um notebook é connectado ao referido domínio.
    • A Diretiva de Grupo é configurada para aplicar um Objeto de Diretiva de Grupo (GPO) a  um computador portátil que é configurado com acesso reforçado de acesso ao  UNC: \\ * \NETLOGON e \\ * \SYSVOL, tais que todos os acessos a esses caminhos exigem tanto a autenticação mútua como a  integridade.
    • A Diretiva de Grupo é configurada para aplicar uma GPO para o computador portátil que executa o script localizado em \\corp.contoso.com\NETLOGON\logon.cmd cada vez que o usuário fizer logon na máquina.

Com a configuração acima, quando um usuário fizer o login com êxito no laptop e o laptop tem qualquer acesso à rede, a Diretiva de Grupo vai tentar executar o script localizado em \\corp.contoso.com\NETLOGON\logon.cmd, mas por trás dos bastidores, a MUP só permitirá que o script  seja executado se o arquivo pode ser aberto e transmitido com segurança:

  1. A MUP recebe um pedido para abrir o arquivo no \\corp.contoso.com\NETLOGON\logon.cmd.

  2. A MUP nota o  caminho  UNC solicitado corresponde \\ * \NETLOGON e caminhos que correspondam ao \\ * \NETLOGON que estejam configurados para exigir a autenticação mútua e integridade. Os prestadores de serviços UNC que não suportam o acesso reforçado ao UNC ou  ou indicam que eles não suportam autenticação mútua e a integridade, então estes são ignorados.

  3. O cliente Servidor de Arquivos Distribuído (Distributed File Server Namespace (DFS-N) detecta que a solicitação do caminho UNC é um DFS-N e inicia o processo de reescrever o caminho UNC (todos os pedidos DFS-N serão submetidos à mesma propriedade segurança e requisitos identificados pelo MUP no passo 2):

    1. O cliente DFS-N usa o DC Locator service e/ou DFS-N DC Referral para pedidos (dependendo da versão do sistema operacional) para identificar o nome de um DC do domínio (ex.: dc1.corp.contoso.com).

    2. O DFS reescreve o caminho por meio do DC selecionado (por exemplo: \\ corp.contoso.com\NETLOGON\logon.cmd se torna \ dc1.corp.contoso.com\NETLOGON\logon.cmd). Uma vez que é necessário autenticação mútua e a meta é esperada por ser um DC, o DFS utiliza um serviço  especial  chamado Kerberos Service Principal Name (SPN)  para verificar se o nome recuperado na etapa anterior é na verdade o nome de um DC (se o nome não é um DC, a autenticação Kerberos vai falhar devido a um SPN desconhecido)

    3. Se há outros links DFS-N no caminhos UNC, o cliente DFS continua a iteração substituindo os caminhos para os links  DFS-N com os caminhos de alvos disponíveis até que ela tenha um caminho UNC que não tenha qualquer links DFS-N remanescentes.

  1. O último caminho UNC é transferido de volta ao MUP para selecionar um caminho  ao provedor UNC para processar o pedido. O MUP seleciona o fornecedor SMB UNC desde que os DCs utilizem SMB para compartilhar os shares NETLOGON e SYSVOL.

  2. O provedor SMB UNC estabelece uma sessão autenticada com o servidor SMB (se uma sessão autenticada já não estiver presente).  Se a sessão autenticada não é mutuamente reconhecida (por exemplo autenticação foi realizada utilizando-se o protocolo NTLM), então provedor SMB UNC não atenderia o pedido para abrir login.cmd como autenticação mútua e necessidade identificada no passo 2.

  3. O provedor permite as assinaturas SMB UNC a todas as solicitações relacionadas ao login.cmd, porque o  SMB informou o MUP que a integridade é necessária para este pedido. Todas as tentativas de sabotagem nas solicitações  ou respostas SMB, invalida as assinaturas dos pedidos/respostas, permitindo assim que o lado do receptor detecte as alterações não autorizadas e as solicitações de SMB irão falhar.

    Neste cenário, o lado do cliente exige uma autenticação mútua de ponta a ponta e a integridade protege o laptop da execução de um script de login localizado em um servidor malicioso através dos seguintes verificações de segurança:

    • A exigência de autenticação mútua garante que a conexão não seja redirecionada para um servidor SMB inesperado (e potencialmente mal-intencionado) quando um cliente SMB fizer tentativas de estabelecer uma conexão com o caminho UNC solicitado.
    • O requisito de integridade ativa a assinatura SMB, mesmo se o cliente SMB não requeira assinatura SMB para todos os caminhos por padrão. Isso protege o sistema contra a  manipulação de dados que possa ocorrer na linha e que pode ser usado para alterar o conteúdo do script sessão.cmd como ela é transmitida entre selecionados DCs e o laptops.
    • Os requisitos para a autenticação mútua e a integridade garante que o caminho reescrito final selecionado pelo cliente DFS-N corresponde a um caminho permitido pela configuração DFS-N e que spoofing e / ou ataques de manipulação não podem fazer com que o cliente DFS-N reescreva um caminho UNC solicitado para um caminho UNC hospedado por um servidor inesperado (e potencialmente malicioso).

Sem essas proteções do lado do cliente, ARP, DNS, DFS-N, ou solicitações SMB enviadas através de política de grupo em redes não confiáveis podem potencialmente causar o serviço de política de grupo para executar um script logon.cmd do Servidor SMB errado.

Como faço para configurar e proteger meus usuários?

Uma vez que a atualização está incluída como parte do boletim MS15-011 , siga as instruções http://support.microsoft.com/kb/3000483 para garantir que seus sistemas estejam devidamente protegidos. MS15-014 irá instalar e fornecer proteção sem nenhuma configuração adicional.

 Uma nota sobre o CVD e a correção de problemas difíceis

Em muitos aspectos, este "conserto de segurança " é melhor  descrito como uma nova funcionalidade no Windows. Adicionando algo desta escala representa um desafio único para resposta de segurança. Vulnerabilidades de software normalmente são mais estritamente limitados tanto em investigação como em remediação – e é a resposta mais estruturada para abordar esse escopo. Entre os benefícios da Coordinated Vulnerability Disclosure (CVD) está permitir uma maior flexibilidade e colaboração mais profunda entre os pesquisadores para terem tempo necessário para oferecer as soluções de segurança mais completas para os clientes. Neste caso, abordamos uma vulnerabilidade que exigiu um escopo muito maior em engenharia para oferecer uma solução.

A maioria das vulnerabilidades reportadas ao MSRC são bugs em um único componente, que são investigados, compreendidos e corrigidos dentro do padrão de tempo de resposta aceito pela  indústria. A criação da nova funcionalidade no reforço do UNC, no entanto, foi necessária uma arquitetura totalmente nova que aumentou o tempo de desenvolvimento e exigiu testes extensivos. Graças a CVD, bem como a estreita colaboração com os pesquisadores de segurança que relataram a vulnerabilidade, a Microsoft teve tempo suficiente para construir a correção certa para uma questão complicada. Se os pesquisadores de segurança não estivessem dispostos a se abster da divulgação até a que nossa correção estivesse pronta, os clientes estariam correndo riscos.
 
Microsoft oferece o seu apreço à comunidade CVD e um agradecimento especial aos jornalistas sobre a questão, o que resultou  no Reforço do  UNC (UNC Hardening): Jeff Schmidt de JAS Global Advisors, Dr. Arnoldo Muller-Molina de simMachines, A Corporação da Internet para Nomes e Números Atribuídos (ICANN) e Luke Jennings da MWR Labs

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