Analistas do time de consultoria da Tempest detectaram recentemente uma vulnerabilidade no Avira AntiVirus em sua versão para sistemas operacionais Windows que, caso explorada, pode causar a elevação de privilégios neste sistema. A falha está presente em um arquivo da ferramenta chamado SwuConfig.json que, por padrão, conta com permissões de controle e acesso abertas a todos os usuários do Windows.
Utilizando como vetor um tipo de objeto presente em sistemas operacionais chamado links simbólicos, os pesquisadores puderam explorar as permissões atribuídas ao arquivo para implantar uma DLL maliciosa no diretório System32 do Windows.
Links simbólicos são um tipo especial de objeto que contém uma referência a outro arquivo ou diretório. No Windows, existem diversos tipos de links simbólicos, mas para melhor compreensão da exploração aqui descrita, iremos restringir o conceito a apenas dois tipos, o Object Manger Symbolic Link e o NTFS Mount Point (ou Junções NTFS).
Object Manager Symbolic Link
O Object Manager é um componente do Windows responsável por centralizar e gerenciar os objetos internos deste sistema operacional, inclusive os do tipo link simbólico.
Um exemplo de Object Manager Symbolic Link são as letras das unidades de volume; a unidade C: de um computador Windows nada mais é do que um link simbólico para o dispositivo “device\HarddiskVolume1”. A imagem abaixo mostra a relação entre o dispositivo HarddiskVolume1 e o seu link simbólico “C:\” no Object Manager.
A criação, alteração ou exclusão destes links simbólicos com referência para dispositivos podem ser realizadas por qualquer usuário (independentemente de seus privilégios) através de uma API chamada DefineDosDevice, representada abaixo:
BOOL DefineDosDeviceW ( DWORD dwFlags, LPCWSTR lpDeviceName, LPCWSTR lpTargetPath );
Na pesquisa, observou-se que o argumento IpDeviceName, presente na API, não realiza uma checagem quanto ao nome/letra do driver (característica que é fundamental na exploração desta falha). Por exemplo, é possível especificar, ao invés de uma letra, um caminho (ex: “GLOBALROOT\RPC Control\Link”), de modo que um objeto (“Link”, no caso do exemplo) seja adicionado ao namespace “\RPC Control” ao invés do namespace original (DosDevice ou GLOBAL??), conforme demonstrado no código a seguir.
int main() { DefineDosDeviceW( DDD_NO_BROADCAST_SYSTEM | DDD_RAW_TARGET_PATH, L”Global\\GLOBALROOT\\RPC Control\\Link”, L”\??\\C:\\ProgramData\\Link”); }
O resultado deste comando seria o seguinte
NTFS Mount Point ou Junções NTFS
Um outro link simbólico do Windows envolvido na pesquisa são as Junções NTFS (NTFS Mount Points) que possuem a função de criar um ponto de montagem para outros diretórios; por exemplo, um diretório localizado em “C:\Windows\System32\sysprep\” poderia ser acessado através de uma junção localizada em “C:\Users\teste\Desktop\Link”.
Os únicos requisitos para criação destas junções são: permissão de leitura no diretório referenciado (“C:\Windows\System32\sysprep\”) e de gravação no diretório onde a junção será armazenada (“C:\Users\teste\Desktop\Link”).
Um item de destaque neste processo são os Reparse Points (uma “coleção de dados definidos pelo usuário — cujo formato é entendido pelo aplicativo que armazena os dados — e um filtro do sistema de arquivos, usado para interpretar os dados e processar o arquivo”; conforme documentação da Microsoft).
Implementados na criação das junções NTFS, Reparse Points podem ser definidos na criação de um diretório; contudo, o diretório deverá estar vazio, pois do contrário, a criação da junção será inviabilizada, posto que não é permitida a criação de diretórios ou arquivos dentro de um diretório que já contenha Reparse Points.
Explorando a falha no Avira com o uso de links simbólicos
A falha descoberta pela equipe de consultoria está presente no Avira Software Update, desenvolvido para atualizar automaticamente todos os programas instalados no computador sempre que houver atualizações disponíveis, a fim de “manter a segurança do sistema”.
A imagem 3 ilustra o momento em que o serviço chamado Avira.SoftwareUpdater com privilégios de SYSTEM manipula arquivos em um diretório totalmente acessível pelo usuário e, na imagem 4, é possível observar como o arquivo SwuConfig.json (disponível em C:\ProgramData\Avira\SoftwareUpdater\) também é totalmente acessível por qualquer usuário do sistema.
Para viabilizar a exploração desta vulnerabilidade é necessário criar dois tipos de links simbólicos, primeiramente deve-se criar um Object Manager Symbolic Link , com o nome SwuConfig.json apontando para o arquivo C:\windows\system32\api-ms-win-core-fibers-l1–1–1.DLL. Na sequência é necessário criar uma junção dentro de C:\ProgramData\Avira com o nome SoftwareUpdater. Como existe um diretório com este nome, ele deverá ser renomeado antes da exploração para que a junção seja criada sem erro.
Esta junção NTFS deverá conter algumas manipulações em seu reparse point para que o Object Manager Symbolic Link com o nome SwuConfig.json seja consultado.
Para a criação simultânea destes dois links simbólicos utilizamos a ferramenta CreateSymLink.
Na imagem 5 vemos a criação do link simbólico dentro do Object Manager.
Após a criação dos links simbólicos, é preciso aguardar que o Avira tente criar novamente o SwuConfig.json — o que acontecerá após uma nova execução do Software Updater. A imagem 6 mostra o arquivo já criado com todas as permissões possíveis no diretório escolhido.
Uma vez que o controle sobre o arquivo api-ms-win-core-fibers-l1–1–1.DLL é total, é possível sobrescrever seu conteúdo por uma DLL maliciosa a fim de executar código arbitrário. Na próxima execução do serviço de update do Avira, ele irá importar esta DLL maliciosa herdando a permissão do processo que a importou— NT AUTHORITY\SYSTEM— (imagem 7).
Segundo os pesquisadores da Tempest, o estudo representa um alerta para a existência de processos que possuem privilégio elevado no sistema, especificamente no momento em que precisam manipular arquivos ou diretórios criados em pastas comuns a todos os usuários.
A depender de como a atribuição dessas permissões são realizadas, estes processos podem ser utilizados como ferramenta para a escrita arbitrária de arquivos maliciosos.
Por sua vez, estes arquivos maliciosos podem ser utilizados para a viabilizar a exploração de vulnerabilidades como DLL Hijacking, Unquoted Path e outras.
Report Timeline
- 12 Abr 2019 — Requisição de um CVE-ID iniciada.
- 15 Abr 2019 — Responsible disclosure iniciado com o fabricante.
- 16 Abr 2019 — O fabricante requisitou mais detalhes sobre a exploração. Email enviado contendo mais informações.
- 21 Abr 2019 — CVE assinado (reservado) CVE-2019–11396.
- 21 Abr 2019 — Email enviado ao fabricante solicitando uma atualização do status de correção.
- 23 Abr 2019 — O fabricante conseguiu reproduzir a vulnerabilidade e trabalha para a corrigir. Novo email enviado sobre o tempo necessário para a correção.
- 29 Abr 2019 — O fabricante diz que o time de desenvolvimento já começou o processo de correção, porém não foi divulgada uma data para sua liberação
- 21 May 2019 — A vulnerabilidade foi corrigida e o fabricante informou que o release seria feito em 1 semana.
- 28 May 2019 — O fabricante informa que a vulnerabilidade havia sido corrigida e que o update encontrava-se publico.
- o4 Jun 2019 — Email enviado para o fabricante informando que a vulnerabilidade não foi corrigida, apesar do informativo sobre o patch de correção.
- 18 Jun 2019 — Avira informa que a vulnerabilidade foi corrigida.
- 19 Jun 2019 — Email enviado para o fabricante explicando que a vulnerabilidade ainda persiste.
- 03 Jul 2019 — Avira responde que havia identificado o real problema e ia tentar corrigir novamente.
- 08 Jul 2019 — O fabricante corrigiu a vulnerabilidade.