Vulnerabilidade no Avast Secure Browser possibilita escalação de privilégios no Windows

Exploração abusa do recurso de hardlinks, que representa o conteúdo de arquivos no sistema NTFS

Tempest Security
Mar 11 · 4 min read

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:

HardLinks

De acordo com a , 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 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 .

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

A exploração

Primeiramente, foi realizada uma inspeção com o AccessEnum (parte do ) 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 ) 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

Report Timeline:

  • 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 a todo apoio fornecido

SideChannel-BR

Notícias e análises sobre segurança da informação…

Tempest Security

Written by

Empresa líder no mercado brasileiro de segurança da informação e combate a fraudes digitais, atuando desde o ano 2000.

SideChannel-BR

Notícias e análises sobre segurança da informação produzidas pela equipe e por amigos da Tempest Security Intelligence

More From Medium

More on Vulnerability from SideChannel-BR

More on Vulnerability from SideChannel-BR

A Saga do Cypher Injection

Also tagged Avast

More from Tempest Security

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade