CVE-2022-45451

Introdução

Especificações do Sistema:

• Windows 10 1809 x64 PT-BR

Alvo:

• Acronis Home Cyber Protect
• Acronis Cyber Protect

Descrição da Vulnerabilidade

O driver de verificação anti-malware "ngscan" da Acronis sofre de controle de acesso incorreto/inadequado colocado na porta de comunicação do filtro. O driver minifilter suporta os seguintes recursos que podem ser explorados:

• Leitura arbitrária de arquivos
• Modificação Sensível de Chave de Registro (não explorado, condições de gatilho desconhecidas) que pode levar à execução local de código

Leitura Arbitrária de Arquivos

A análise do driver ngscan.sys começou descompilando o driver com o Ida Pro. O pesquisador notou que, embora um objeto de dispositivo tenha sido criado, nenhum link simbólico foi criado para interagir com o driver usando DeviceIoControl. Assim, a análise continuou observando as capacidades da Porta de Comunicação do Filtro. Durante a inicialização, o driver cria cinco (5) portas de comunicação para suportar a interação de outros processos.

Fig. 1: Rotina que suporta a criação de até cinco (5) portas de comunicação de filtro (FCP)

Esta função foi observada sendo chamada, inicializando cada um dos 5 FCPs com um dacl padrão, sendo o último FCP criado com um dacl NULL.

Fig. 2: Criação de FCP com DACL Padrão/NULO

A análise continuou observando as funções CreateNotifyCallback e MessageNotifyCallback especificadas pelo driver de filtro. Essas funções de retorno de chamada são invocadas sempre que um processo abre uma conexão e envia uma mensagem para a porta de comunicação.

A inspeção inicial do MessageNotifyCallback mostrou que o buffer da mensagem recebida deve atender aos seguintes requisitos:

• o primeiro DWORD deve corresponder a um valor de cabeçalho esperado "TrMs" (Linha 37)
• o segundo DWORD deve conter o comprimento do conteúdo da mensagem (nota: isso é diferente e distinto do InputBufferLength)
• o comprimento do conteúdo da mensagem deve ser menor ou igual ao tamanho total do buffer de entrada menos o tamanho do cabeçalho da mensagem
  • O cabeçalho da mensagem é composto pelo cabeçalho e tamanho, e outro valor desconhecido totalizando 0xC (12) bytes

Uma vez que as verificações foram aprovadas, um número de função é extraído do InputBuffer e usado nos casos switch a seguir para selecionar qual função executar com a entrada fornecida.

Fig. 3: Subconjunto de funções suportadas pelo MessageNotifyCallback

Inspecionando cada uma das funções suportadas, duas funções foram identificadas como de interesse para potencial abuso levando à leitura arbitrária de arquivos.

Fig. 4: Funções que suportam a criação de um contexto de verificação e retornam o identificador de arquivo do contexto de verificação (Linhas 206, 233)

Embora a funcionalidade exata de um "contexto de verificação" não seja totalmente conhecida, a análise mostrou que um contexto de verificação de arquivo pode ser criado para qualquer arquivo especificado no InputBuffer do usuário. Uma vez que um contexto de verificação é criado, o ID do contexto de verificação é retornado ao usuário no buffer de saída.

Fig. 5: Rotina de Criação de Contexto de Verificação retornando dados do contexto de verificação ao usuário

Fig. 6: Dados enviados ao driver minifilter solicitando acesso ao arquivo de registro SAM protegido (\??\C:\Windows\System32\config\SAM)

Fig. 7: Resposta do driver minifilter incluindo o ID do contexto de verificação (0x3aaf)

Uma vez que um contexto de verificação foi criado e o ID recuperado, um identificador para o arquivo para o qual o contexto de verificação foi criado pode ser aberto no aplicativo solicitante, enviando novamente uma mensagem para a porta de comunicação.

Fig. 8: Recuperação do identificador de arquivo do Contexto de Verificação Criado

A função designada como CreateFileReturnHandle0 só era chamada se a função anterior SearchScanContextsByID retornasse um contexto de verificação válido. Por exemplo, apenas se o processo solicitante fornecesse um ID de contexto válido que foi previamente criado chamando a função de criação de verificação mencionada. O programa solicitante abriu com sucesso um identificador para o arquivo privilegiado fornecendo o ID do contexto de verificação para a função especificada na Figura 8 (Figura 4, Linha 233).

Fig. 9: Recuperação bem-sucedida do identificador de arquivo para o arquivo SAM

Usando o processhacker, o acesso ao identificador de arquivo foi confirmado visualizando os identificadores do processo solicitante:

Fig. 10: Processo contendo identificador para o arquivo SAM

Fig. 11: Acesso de leitura concedido ao identificador obtido

Potencial Injeção de Código

Uma exploração adicional das funções suportadas mostrou o controle de três chaves de registro que podem ser aproveitadas para obter execução de código.

Fig. 12: Funções que suportam a abertura de identificadores para chaves de registro

Fig. 13: Abertura das chaves de registro especificando a dll de monitoramento de hook para injetar em um processo

Fig. 14: Função OpenKey demonstrando a capacidade de modificar uma chave de registro com dados controlados pelo usuário

As circunstâncias para injeção de dll para hook pelo conjunto Acronis não foram determinadas, embora se o monitoramento de hook estiver ativado, acredita-se que a dll especificada pelas chaves de registro x64HookLib e x86HookLib seria injetada em um processo designado.

Fig. 15: x64HookLibKey especificando a dll de hook C:\ProgramData\Acronis\NGMP\shared\acr_protect.x64.dll

Condição de Corrida Permitindo Leitura Arbitrária Limitada de Arquivos

O processo de abrir um contexto de verificação foi omitido na análise para a Leitura Arbitrária de Arquivos. Um processo pode, em vez de criar um contexto de verificação, forçar IDs de contexto de verificação emitindo repetidamente solicitações para a função GetScanContextByID, percorrendo valores de ContextID até que um ou mais contextos de verificação válidos sejam encontrados.