CVE-2020-0753-and-CVE-2020-0754

Writeup e POC para CVE-2020-0753, CVE-2020-0754 e seis vulnerabilidades DOS não corrigidas do Windows

Exploração de bug de condição de corrida no sistema de arquivos - análise de CVE-2020-0753 e CVE-2020-0754

O serviço de Relatório de Erros do Windows corrigiu 2 bugs de Elevação de Privilégio na última Patch Tuesday, os dois bugs foram atribuídos como CVE-2020-0753 e CVE-2020-0754. Ambos os bugs aproveitam um bug de condição de corrida nas operações do sistema de arquivos do serviço. No entanto, esses dois bugs não são tão fáceis de explorar devido a pequenas janelas de corrida e locais incertos de queda de arquivos. Aqui compartilhamos nossas técnicas para explorá-los.

A causa raiz dos dois bugs de corrida é fornecida em nossos relatórios, a causa real pode ser expressa como Previsível é Vulnerável. Quando o serviço WER processa arquivos temporários, ele manipula o local do arquivo C:\ProgramData\Microsoft\Windows\WER\Temp, que é um diretório com permissões de leitura/escrita para Usuários Autenticados. Isso significa que um usuário normal de médio-IL pode sobrescrever um arquivo criado pelo serviço WER e até transformá-lo em um link do sistema de arquivos para danificar/excluir outros arquivos que eles não poderiam tocar.

Para manter as operações de arquivo seguras, o serviço WER depende de uma api padrão chamada GetTempFileNameW e a envolveu com wersvc.dll->UtilGetTempFile, esta api ajudará o WerSvc a gerar um nome de arquivo aleatório desocupado na forma de "WER****.tmp", a parte aleatória do nome do arquivo é gerada com um número hexadecimal de 4 bytes, de 0000-FFFF, se um número já foi usado para criar um arquivo, a api usará outro nome de arquivo aleatório.

A estratégia claramente tem uma falha se alguém criar 65535 arquivos nomeados de WER0000.tmp a WERFFFE.tmp, a api escolherá um número aleatório e testará o nome do arquivo para ver se existe, como WERA560.tmp, descobrirá que o arquivo já existe, e assim continuará testando de WERA560.tmp até WERFFFF.tmp, enquanto o teste continua, uma janela de preparação aparece porque encontramos uma maneira de fazer o WerSvc travar na chamada GetTempFileNameW por 4-5 segundos, o que é uma grande lacuna de tempo. Enquanto isso, forçamos o serviço a criar um arquivo temporário com nome fixo, que é WERFFFF.tmp.

Após o serviço criar o arquivo temporário chamado WERFFFF.tmp, a api fecha automaticamente o handle que mantém para o arquivo e retorna o nome do arquivo para o serviço para operações adicionais no arquivo, esta é exatamente a posição que introduz o bug. Três condições são atendidas:

1. O arquivo criado pelo serviço está em uma posição controlável pelo usuário normal.
2. O serviço fecha todos os handles do arquivo
3. O serviço usará o arquivo posteriormente (escrever ou excluir)

Aqui o serviço escreverá conteúdo no arquivo e o excluirá. Tanto a escrita quanto a exclusão causarão elevação de privilégio ao aproveitar links do sistema de arquivos e certas técnicas de exploração.

Para transformar o bug em exclusão arbitrária de arquivos, aproveitamos criativamente várias junções de diretório para concluir a exploração. Nosso exploit contém as seguintes etapas:

• colocamos todos os WER***.tmp em $pwd\1\, e fazemos uma junção $pwd\2\ -> $pwd\1\;
• criamos um processo para acionar continuamente esta função com o caminho $pwd\2\. e criamos o outro processo para executar continuamente o comando SetOplock $pwd\1\WERFFFF.tmp;
• Assim que o Oplock for acionado, fazemos uma junção $pwd\2\ -> \RPC CONTROL\, e então criamos um symlink de objeto \RPC CONTROL\WERFFFF.tmp -> $target e \RPC CONTROL\WERFFFF.tmp.etl -> $target
• Liberamos o oplock, o arquivo alvo será excluído com privilégio de sistema.

A exploração detalhada e o poc são fornecidos em WERReport-CVE-2020-0753.

Ao explorar a falha em GetTempFileNameW, obtemos um local previsível onde o serviço operará; ao usar junções de sistema de arquivos em vários níveis, tornamos a condição de corrida confiavelmente explorável.

Enquanto isso, notamos que esse tipo de bug de corrida também pode causar possível problema de substituição de arquivo, então é provável que leve a bugs de Elevação de Privilégio sob certas circunstâncias.

De corrupção arbitrária de arquivo com controle parcial à elevação de privilégio

Para explicar por que a corrupção arbitrária de arquivo (se você puder controlar uma parte muito pequena do conteúdo do arquivo: menos de 63 bytes) pode ser transformada em EoP, precisamos prestar atenção ao mecanismo de funcionamento do Windows Defender.

O Windows Defender possui um banco de dados de assinaturas de malware. Se algum arquivo contiver alguma assinatura de malware, o Defender o considerará um malware e o excluirá. No entanto, esse recurso resulta em uma superfície de ataque adicional. Por exemplo, no WCTF2019, @icchy do tokyowesterns projetou um desafio de CTF para Windows chamado "Gyotaku The Flag", que usou esse recurso como um oráculo para vazar informações.

Aqui, aproveitamos esse recurso do Windows Defender para excluir arquivos arbitrários se tivermos uma corrupção arbitrária de arquivo com controle parcial do conteúdo do arquivo. Podemos simplesmente escrever uma assinatura de malware em um arquivo e acionar uma verificação padrão pelo Windows Defender; o arquivo será colocado na área de isolamento do Defender, que pode ser excluída por um usuário normal (ou seja, um usuário não administrador de médio-IL) simplesmente acionando a operação de verificação 2 vezes.

Portanto, um bug de corrupção arbitrária de arquivo pode ser transformado em exclusão arbitrária de arquivo, desde que uma string de assinatura de malware possa ser colocada no arquivo alvo usando o bug.

• Etapa 1: Corrompa o arquivo alvo com um bug, coloque uma string característica reconhecível pelo Windows Defender nele.
• Etapa 2: Acione o Windows Defender para verificar o arquivo alvo, fazendo com que o arquivo seja isolado.
• Etapa 3: Acione a verificação novamente, o arquivo alvo é excluído.

Ao aproveitar a técnica, adquirimos uma exclusão arbitrária de arquivo com a ajuda do Defender.

A exclusão arbitrária de arquivo pode ser explorada com muito mais facilidade para obter privilégios adicionais.

Seis vulnerabilidades DOS não corrigidas no sistema de arquivos do Microsoft OneDrive

O Microsoft OneDrive é o pacote de aplicativos que fornece o serviço de Armazenamento em Nuvem Pessoal, este aplicativo foi integrado ao Windows como uma opção de instalação padrão desde o Windows 8. Durante nossa pesquisa, 6 vulnerabilidades nas tarefas agendadas de manutenção do OneDrive foram encontradas e submetidas ao MSRC.

---

Aqui está uma tabela de vulnerabilidades que vamos expor nas tarefas agendadas relevantes do Microsoft OneDrive:

Todos os 6 bugs são causados pelo serviço que lida incorretamente com hardlinks e symlinks, ao operar em locais que o usuário normal pode controlar. Durante a exploração desses bugs, uma dificuldade surge porque o nome do arquivo geralmente contém um pid do processo atual ou um timestamp marcando quando o arquivo é operado. Ambos podem ser resolvidos configurando um oplock em um arquivo dll único que o serviço tentará carregar quando for acionado para executar, onde temos a capacidade de obter tudo o que precisamos para prever o nome do arquivo que o serviço tentará operar posteriormente. Um exemplo de POC é fornecido no diretório FileSyncConfigTemp_hardlink.

Impactos das Vulnerabilidades

Todas as 6 vulnerabilidades mencionadas acima são fornecidas com relatório completo e programa poc, embora a maioria dos bugs cause corrupção arbitrária de arquivo em primeiro lugar, esse tipo de bug ainda causa travamento do sistema (ao sobrescrever arquivos críticos de configuração do sistema), e todos eles exigiriam reinstalação do Windows. Assim, atendendo ao padrão do tipo de bug de Negação de Serviço do Sistema Windows.

Além disso, esse tipo de bug pode realmente causar Elevação de Privilégio em certos contextos. Discutimos a técnica de exploração que pode aproveitar um problema de sobrescrita arbitrária de arquivo para alcançar a primitiva de exclusão arbitrária de arquivo, portanto, a Elevação de Privilégio é alcançável.

Créditos das Vulnerabilidades

Fangming Gu

Zhiniang Peng da Qihoo 360 Core Security

Linha do Tempo

02 de fevereiro de 2020: Vulnerabilidades relatadas

08 de fevereiro de 2020: MSRC investigou e respondeu sobre os 6 bugs no OneDrive que submetemos, sua conclusão é não corrigir devido a Muita interação do usuário necessária/muito difícil construir um exploit confiável.

08 de fevereiro de 2020: Nós respondemos: Não há necessidade de interação do usuário. Você só precisa esperar a tarefa agendada ser executada. Portanto, este cenário é típico.

11 de fevereiro de 2020: MSRC respondeu: Como você obtém o arquivo específico na máquina do usuário? E você está colocando todas as permutações desse arquivo nessa pasta? Precisa corresponder exatamente a Data/Hora/PID? É por essas razões que parece exigir muito esforço do usuário.

11 de fevereiro de 2020: Nós respondemos: Nosso poc é uma versão simplificada. Para reduzir o esforço de prever o nome do arquivo. Na realidade, você só precisa definir um oplock. Então você pode obter todos os {pid},{hora},{data}. Portanto, não há necessidade de interação do usuário.

12 de fevereiro de 2020: Perguntando se podemos publicar o writeup para essas 6 vulnerabilidades.

13 de fevereiro de 2020: MSRC respondeu: Você pode postar um writeup.

22 de fevereiro de 2020: Detalhes publicados

Embora o hardlink já tenha recebido uma correção nas compilações do Windows Insider Preview, não foi corrigido na versão de lançamento mais recente do Windows. E parece não haver plano de backport para todos os sistemas operacionais suportados :( . E recusar corrigir essas vulnerabilidades não parece uma ação responsável.