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

Writeup e POC para CVE-2020-0753, CVE-2020-0754 e seis vulnerabilidades DOS 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 a CVE-2020-0753 e CVE-2020-0754. Ambos os bugs exploram uma condição de corrida nas operações de sistema de arquivos do serviço. No entanto, esses dois bugs não são tão fáceis de explorar devido às pequenas janelas de corrida e locais incertos de queda de arquivo. Aqui compartilhamos nossas técnicas para explorá-los.

A causa raiz dos dois bugs de corrida é apresentada 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ão de leitura/gravação para Usuários Autenticados. Isso significa que um usuário normal de IL média pode sobrescrever um arquivo criado pelo serviço WER, e até mesmo transformá-lo em um link do sistema de arquivos para danificar/excluir outros arquivos que ele não poderia tocar.

Para manter as operações de arquivo seguras, o serviço WER depende de uma API padrão chamada GetTempFileNameW e a encapsula com wersvc.dll->UtilGetTempFile. Essa API ajuda o WerSvc a gerar nomes de arquivo aleatórios não ocupados na forma de "WER****.tmp".

A parte aleatória do nome do arquivo é gerada com um número hexadecimal de 4 bytes, de 0000 a 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 com nomes de WER0000.tmp até WERFFFE.tmp, a API escolherá um número aleatório e testará o nome do arquivo para ver se existe, como WERA560.tmp. Ela descobrirá que o arquivo já existe e continuará testando de WERA560.tmp até WERFFFF.tmp. Durante o teste contínuo, aparece uma janela de preparação porque encontramos uma maneira de fazer o WerSvc travar na chamada GetTempFileNameW por 4 a 5 segundos, o que é uma grande janela de tempo. Enquanto isso, forçamos o serviço a criar um arquivo temporário com um nome fixo, que é WERFFFF.tmp.

Após o serviço criar o arquivo temporário chamado WERFFFF.tmp, a API automaticamente fecha o identificador (handle) que mantinha para o arquivo e retorna o nome do arquivo ao serviço para operações posteriores 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 identificadores para o 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 explorar links do sistema de arquivos e certas técnicas de exploração.

Para transformar o bug em exclusão arbitrária de arquivos, usamos criativamente múltiplas junções de diretório para finalizar a exploração. Nosso exploit contém os seguintes passos:

• Colocamos todos os WER***.tmp em $pwd\1\ e criamos a junção $pwd\2\ -> $pwd\1\;
• Criamos um processo para acionar continuamente essa função com o caminho $pwd\2\ e outro processo para executar continuamente o comando SetOplock $pwd\1\WERFFFF.tmp;
• Uma vez que o Oplock é acionado, criamos a junção $pwd\2\ -> \RPC CONTROL\ e depois criamos o link simbólico \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 estão disponíveis em WERReport-CVE-2020-0753.

Ao explorar a falha em GetTempFileNameW, obtivemos um local previsível onde o serviço operará; ao fazer uso de múltiplos níveis de junção do sistema de arquivos, tornamos a condição de corrida explorável de forma confiável.

Enquanto isso, notamos que esse tipo de bug de corrida também pode causar possível sobrescrita de arquivos, o que provavelmente leva a bugs de Elevação de Privilégio sob certas circunstâncias.

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

Para explicar a razão pela qual a corrupção arbitrária de arquivos (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 tem um banco de dados de assinaturas de malware. Se algum arquivo contiver alguma assinatura de malware, o Defender o considerará 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 do Windows chamado "Gyotaku The Flag", que usa 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 arquivos com controle parcial do conteúdo do arquivo. Podemos simplesmente escrever uma assinatura de malware em um arquivo e acionar uma varredura padrão do 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 IL média) simplesmente acionando a operação de varredura duas 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.

• Passo 1:

Corrompa o arquivo alvo com um bug, colocando uma string de recurso reconhecível pelo Windows Defender nele.

• Passo 2:

Acione o Windows Defender para examinar o arquivo alvo, fazendo com que ele seja isolado.

• Passo 3:

Acione a varredura novamente; o arquivo alvo é excluído.

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

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

Seis vulnerabilidades DOS corrigidas no Microsoft OneDrive

O Microsoft OneDrive é o pacote de aplicativos que fornece 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 das 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 do fato de que 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 declaradas acima são fornecidas com relatório completo e programa POC. Embora a maioria dos bugs cause corrupção arbitrária de arquivos 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 a reinstalação do Windows. Portanto, atendem ao padrão do tipo de bug de Negação de Serviço do 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, tornando a Elevação de Privilégio possível.

Créditos das Vulnerabilidades

Fangming Gu

Zhiniang Peng da Qihoo 360 Core Security

Linha do Tempo

02 de fevereiro de 2020: Vulnerabilidades reportadas

08 de fevereiro de 2020: O MSRC investigou e respondeu sobre os 6 bugs no OneDrive que submetemos. A conclusão deles foi não corrigir devido a muita interação do usuário necessária / muito difícil de 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 que a tarefa agendada seja executada. Portanto, esse cenário é típico.

11 de fevereiro de 2020: O MSRC respondeu: Como você obtém o arquivo específico na máquina do usuário? E você está colocando cada permutação desse arquivo naquela pasta? Ele 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 configurar um oplock. Então você pode obter todo o {pid}, {hora}, {data}. Portanto, não há necessidade de interação do usuário.

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

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

22 de fevereiro de 2020: Detalhes publicados

Atualização de Status: Todas as 6 vulnerabilidades receberam correção na Patch Tuesday de março de 2020.