No mês passado, a Microsoft lançou um aviso para o CVE-2020-1317, que descreve uma vulnerabilidade de escalonamento de privilégios na Política de Grupo. O descobridor da vulnerabilidade deu mais detalhes sobre o assunto no site Cyberark. A natureza desse problema é interessante e vale a pena ser compreendida. Durante anos, a Política de Grupo teve essa dicotomia embutida em seu design. Nomeadamente, a necessidade de fornecer políticas por utilizador a utilizadores sem privilégios, através de um mecanismo que é executado como um processo privilegiado - nomeadamente o motor da Política de Grupo. A Microsoft tratou esta questão de várias formas. Por exemplo, a política de Modelos Administrativos por utilizador foi entregue a um conjunto de duas chaves de registo em HKEY_CURRENT_USER que, por acaso, estavam autorizadas de forma a que um utilizador não pudesse escrever nelas, apesar de poder escrever em praticamente qualquer outra chave nesta colmeia. Mas, no caso desse CVE, havia algumas falhas evidentes. A primeira delas foi detalhada no post do blogue da Cyberark. Nomeadamente, as Preferências do GP sempre tiveram o conceito de ficheiros de histórico. Esses arquivos foram criados para basicamente desfazer o estado de determinadas Preferências do GP quando essas configurações não se aplicavam mais. Estes ficheiros de histórico eram essencialmente cópias do ficheiro de definições real que estava armazenado no SYSVOL para o GPO que fornecia as definições e estavam armazenados no perfil do utilizador em %appdata%LocalMicrosoftGroup Policy, como pode ver aqui:
Leitura relacionada
A localização deste ficheiro foi a chave para esta vulnerabilidade privesc. Os arquivos em si são armazenados no perfil do usuário em uma área que um usuário regular, sem privilégios, tem todos os direitos. No entanto, os ficheiros são escritos aqui sempre que uma nova configuração GPP é processada, ou a configuração é alterada, pelo motor GP, que é executado como localSystem. Então, nós temos um processo localSystem escrevendo dados para o espaço do usuário sem privilégios, e é aqui que a diversão começa.
Para essa exploração em particular, o autor usou links simbólicos do Object Manager para redirecionar qualquer arquivo XML GPP arbitrário para um local em c:windowsystem32, onde ele pode ser explorado por um outro processo para essencialmente abrir um processo em execução como localSystem. Os detalhes do código de escalonamento real para localSystem não são mostrados, mas o uso de links simbólicos OM (e a exploração de outros tipos de links simbólicos do Windows), é descrito neste excelente vídeo de James Forshaw, que também tem um exemplo de código para criar esses links aqui. Basta dizer que, para explorar isso, um invasor só precisa excluir o arquivo que o GPP deixou em seu perfil de usuário e substituí-lo por um link simbólico OM. O GPP Engine então aparecerá, alegremente rodando como sistema local, e essencialmente escreverá um novo arquivo XML para qualquer que seja o destino especificado em c:windowssystem32. Podem então escrever o conteúdo que quiserem nesse ficheiro e explorá-lo a partir daí. É muito inteligente.
Caminhos alternativos de exploração e o patch
Quando vi pela primeira vez essa exploração descrita, perguntei-me em voz alta se os arquivos de histórico do GPP eram o único lugar onde isso poderia ser explorado. Eu sabia que o meu bom amigo, o ficheiro de arquivo do registo (ntuser.pol), era outro destes ficheiros GPO por utilizador que eram mantidos no perfil do utilizador e graváveis pelo utilizador, mas actualizados pelo Motor GP. Assim, era lógico assumir que este ficheiro também podia ser explorado da mesma forma que os ficheiros de histórico das Preferências GP. Assim, quando olho para um sistema Windows depois de aplicar a correcção para esta vulnerabilidade, noto algumas coisas interessantes. Em primeiro lugar, a forma como a Microsoft resolveu o problema foi mover os ficheiros de histórico do GPP para fora do perfil do utilizador e para a pasta protegida %programdata% (especificamente em %programdata%MicrosoftGroup PolicyUsers). Esta pasta não pode ser escrita por utilizadores normais, o que ajuda a evitar a utilização de ligações simbólicas na versão anterior. O caminho completo para o ficheiro é um pouco estranho, como pode ver aqui:
A estrutura de pastas é por utilizador (ou seja, o caminho da pasta SID), depois por GPO (o GUID da GPO) e, por fim, por utilizador novamente (outra pasta SID), o que parece um pouco excessivo, mas tenho a certeza de que tinham uma razão para isso 🙂
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.
Agora, de acordo com o autor deste exploit, a Microsoft levou quase um ano para corrigir isso. Posso imaginar perfeitamente que seja esse o caso. Dado que, entre todas as áreas das Preferências do GP e todas as áreas que utilizam o ntuser.pol, incluindo os Modelos de Administração, AppLocker, Firewall do Windows, Política de Chaves Públicas e provavelmente algumas que me estão a escapar, pode ter havido potencialmente muito código para percorrer para garantir que a movimentação desses ficheiros não quebrava tudo. Eu não ficaria surpreso se alguma quebra ainda aparecesse em algum canto obscuro da política antes que tudo isso acabasse. No entanto, este foi um exploit interessante, tornado ainda mais interessante por algumas verrugas de 20 anos que o GP trouxe para a festa.
Interessado em saber mais sobre como gerir a Política de Grupo com a segurança em mente? Assista ao nosso webinar que resume os quase quatro anos de investigação que realizei sobre as várias formas como os atacantes estão a explorar a Política de Grupo. Mais importante ainda, irei explicar os principais passos que pode seguir para defender o seu ambiente de GP e, consequentemente, o seu ambiente Windows, contra abusos. Espero ver-vos lá.
