O Avast Secure Browser (ASB) é um navegador que possui características de segurança e de privacidade integradas. Desenvolvido pela Avast, pode ser encontrado gratuitamente em sua página oficial.

O analista de segurança do time de consultoria, Silton Santos, descobriu recentemente uma vulnerabilidade que atinge o processo de atualização do ASB, resultando em escalação de privilégios.

Em resumo, existia um processo privilegiado responsável pelas atualizações do ASB que realizava uma operação de gravação em um arquivo e, em sequência, redefinia suas permissões para controle total, tornando-o acessível por qualquer usuário. Portanto, essa operação foi redirecionada com a utilização de um hardlink para um arquivo arbitrário. Com isso, o processo privilegiado passou a operar com o arquivo redirecionado, consequentemente redefinindo também as suas permissões.

Para um melhor entendimento técnico da exploração, será abordado primeiramente o conceito de hardlink e suas peculiaridades:

De acordo com a documentação da Microsoft, hardlinks são links simbólicos que fazem referência a uma representação do conteúdo de arquivos no sistema NTFS através de outros diretórios no mesmo volume.

Esse tipo de link pode ser facilmente criado utilizando a ferramenta mklink (presente nas versões atuais dos sistemas operacionais Windows) através do parâmetro /H. Existem alguns requisitos para criação de hardlinks utilizando o mklink:

  1. O usuário necessita de privilégios de gravação no arquivo de destino;
  2. O usuário necessita de privilégio de gravação no diretório em que será criado o hardlink.

O requisito 1 eliminaria a possibilidade de utilização de hardlinks em explorações que impactam em uma escalação de privilégios, tendo em vista que, se o usuário já possui permissão de gravação no arquivo de destino, bastaria apenas sobrescrevê-lo com o conteúdo desejado.

Felizmente, James Forshaw do Google Project Zero descobriu que, no momento em que o arquivo é aberto pela função NTOpenFile, utilizada durante a implementação da API CreateHardLink — responsável pela criação de hardlinks — o valor FILE_WRITE_ATTRIBUTES é enviado como atributo do objeto, identificando assim a necessidade de privilégio de gravação durante a criação do link. Porém, James também detectou que, no momento que a função NTOpenFile é chamada, é possível suprimir o envio da flag FILE_WRITE_ATTRIBUTES, o que viabiliza a criação do hardlink com permissão apenas para leitura. Para maiores detalhes sobre a exploração deste comportamento, vide o artigo BetWeen Rock and hard link.

Além disso, o Project Zero disponibilizou em seu Github um pacote de ferramentas que implementa, entre outras coisas, a ação descrita acima.

Primeiramente, foi realizada uma inspeção com o AccessEnum (parte do Sysinternals) nos diretórios relativos ao Avast Secure Browser com a finalidade de encontrar arquivos excessivamente permissivos, conforme ilustrado na imagem abaixo:

Figura 1: Detecção do arquivo Update.ini que é excessivamente permissivo.

Como demonstrado na Figura 1, um dos arquivos excessivamente permissivos é o Update.ini, localizado no diretório C:\ProgramData\AVAST SOFTWARE\Browser\Update. Na figura, também é possível notar que qualquer usuário possui controle total sobre o arquivo Update.ini.

Tomando como base esse diretório, foram criados alguns filtros com o ProcMon (também parte do Sysinternals) que possibilitaram monitorar qualquer operação por parte de um processo privilegiado com o arquivo Update.ini. Como pode ser constatado na Figura 2, é possível notar um processo chamado AvastBrowserUpdate.exe realizando algumas operações no arquivo Update.ini:

Figura 2: Identificação das interações do AvastBrowserUpdate.exe com o arquivo Update.ini.

O próximo passo foi substituir o arquivo Update.ini por um hardlink que aponta para o arquivo C:\Program Files\Avast Software\Browser\Update\1.5.245.0\psmachine.dll e iniciar o processo de atualização. Dessa maneira, as permissões da DLL psmachine.dll foram redefinidas para controle total a qualquer usuário (como observado na figura 3).

Figura 3: Permissões do arquivo Update.ini antes e depois da exploração.

Por fim, para concluir o processo de exploração de escalação de privilégios, foi substituído o conteúdo da DLL por um que retornasse uma shell personificada com o usuário NT AUTHORITY\SYSTEM.

Figura 5: Shell personificada com o usuário privilegiado

  • 23/08/2019 — Responsible disclosure iniciado com o Avast;
  • 26/08/2019 — Iniciada a análise da vulnerabilidade;
  • 15/10/2019 — Vulnerabilidade é confirmada pela Avast que inicia correção;
  • 20/12/2019 — Avast informa que está realizando as verificações finais e que a publicação do patch está prevista para 20/01/2020;
  • 20/12/2019 — Avast agradece todo apoio fornecido e solicita nome para realizar um agradecimento público;
  • 20/01/2020 — Avast comunica que existe um release público com a vulnerabilidade corrigida;
  • 21/01/2020 — Avast publica agradecimento a todo apoio fornecido