Houve uma discussão nos comentários sobre se isso poderia ser considerado uma vulnerabilidade. Mas fiquei viciado em um comentário do autor:
Isso poderia ser implementado, por exemplo, na forma de uma DLL que, quando chamada por sua API, verificaria a assinatura digital do programa de chamada?
O fato é que, pouco antes disso, pesquisei vários programas que dependiam da verificação de assinaturas digitais da mesma maneira. E essa verificação foi muito fácil de contornar.
A assinatura digital de um arquivo corresponde apenas ao próprio executável, mas um programa em execução não é apenas um executável. Existem várias maneiras de influenciar a operação do programa sem alterar o arquivo executável: você pode substituir as bibliotecas carregadas ou injetar código diretamente na memória.
Eu olhei para o perfil do autor: "Trabalhos em: Doctor Web". Mas e se você procurar ver se os produtos dessa empresa usam a verificação de que o autor está falando? Decidi procurar e, spoiler, encontrei uma vulnerabilidade que permite elevar seus privilégios ao usuário do sistema Dr.Web Security Space for Windows.
Serviço de inteligência
Como não entendo os produtos Doctor Web, peguei o primeiro que podia baixar no site - era o Dr.Web Security Space 12 para Windows. Nas configurações padrão, este produto verifica se há atualizações a cada meia hora. E uma vulnerabilidade foi encontrada no mecanismo de atualização.
A seguir, ofereço um vídeo de operação descrevendo o que acontece no vídeo com referência ao tempo. Também haverá uma descrição do que exatamente era a vulnerabilidade.
Vídeo de operação
A demonstração é executada no Windows 10 x64 de um usuário sem direitos de administrador.
0: 00-0: 12 mostra no console do Windows que o usuário atual não é administrador
0: 12-0: 24 mostra a versão instalada do Dr.Web Security Space
0: 24-0: 29 O arquivo drweb_eop_upd_dll.dll está localizado na pasta na área de trabalho (os códigos-fonte e o arquivo estão anexados ao ticket)
0: 29-0: 34 Mostro que há 3 arquivos na
pasta C: \ ProgramData \ Doctor Web \ Updater \ etc 0: 34-0: 47 Copio a biblioteca drweb_eop_upd_dll.dll na pasta em área de trabalho e uma cópia que chamo version.dll, outra - cryptui.dll
0: 47-0: 56 copio o arquivo C: \ Arquivos de Programas \ Arquivos Comuns \ Doctor Web \ Updater \ drwupsrv.exe para a pasta na área de trabalho, ao lado da DLL ...
0: 56-1: 00 execute o arquivo copiado
O arquivo executável drwupsrv.exe da pasta na área de trabalho carrega o version.dll localizado nas proximidades. Esta biblioteca cria o arquivo C: \ ProgramData \ Doctor Web \ Updater \ etc \ drwupsrv.xml.new. O usuário tem direitos para criar arquivos na pasta C: \ ProgramData e no fundo, portanto, essa é uma operação legal. Se você tentar criar esse arquivo manualmente, é provável que os mecanismos de segurança do Dr.Web impeçam essa operação. Mas em operação, o arquivo é criado em nome do drwupsrv.exe, que provavelmente ignora as verificações internas e o arquivo é criado. De fato, isso é um desvio da própria verificação de assinatura discutida no início do artigo.
1: 00-1: 22 estou demonstrando o arquivo criado e seu conteúdo. De um modo geral, o arquivo tem o mesmo conteúdo que o arquivo C: \ ProgramData \ Doctor Web \ Updater \ etc \ drwupsrv.xml, mas todos os caminhos apontam para uma pasta na área de trabalho (C: \ Users \ Usuário \ Desktop \ dwtest)
1: 22-2 : 00 nada acontece (nesta fase, estou aguardando o processo de atualização do software, que por padrão acontece a cada meia hora e o tempo esperado pode ser encontrado nos logs)
2: 00-2: 14 aparentemente, pegando o arquivo de configuração criado, o atualizador vê que Se não houver arquivos de software Dr.Web na pasta C: \ Users \ User \ Desktop \ dwtest, ele começará a copiar os arquivos de software lá.
Os arquivos copiados incluem o arquivo dwservice.exe, que é iniciado no momento da atualização como o usuário NT AUTHORITY \ SYSTEM. Este arquivo carrega a biblioteca cryptui.dll, que estava na pasta C: \ Users \ User \ Desktop \ dwtest. O código da biblioteca simplesmente inicia o console interativo, visível na tela. Use o comando whoami para garantir que os direitos do sistema sejam obtidos.
Resultado
O relatório de vulnerabilidade foi enviado ao Doctor Web e, aparentemente, os desenvolvedores corrigiram tudo.
Linha do tempo:
15/05/2020 - Entrando em contato com o suporte técnico com uma solicitação para fornecer um contato de segurança.
20/05/2020 - recebo uma resposta de que é possível enviar um relatório nesta chamada
20/05/2020 - transmito um relatório
14/6/2020 - recebo uma resposta que a vulnerabilidade foi corrigida para a versão 12. Aguardando portabilidade para a versão 11.
07/07/2020 - Os desenvolvedores confirmam que as correções foram lançadas.
Este artigo em inglês.