Em um habr, já existem
notícias sobre essa vulnerabilidade , mas, infelizmente, sem detalhes técnicos. Sugiro que você procure dentro do
arquivo publicado (autor -
SandboxEscaper ).
Sob o cortador está a tradução do documento de descrição no arquivo.
Descrição da vulnerabilidade
O serviço Agendador de tarefas possui uma interface RPC (acessível por meio do transporte ALPC) que suporta o método SchRpcSetSecurity.
Este é o protótipo deste método:
long _SchRpcSetSecurity( [in][string] wchar_t* arg_1,
As tarefas criadas pelo agendador de tarefas criam o diretório / arquivo correspondente em c: \ windows \ system32 \ tasks. Provavelmente, este método se destina a registrar tarefas DACL'a localizadas lá. Mas a gravação ocorrerá após a representação. No entanto, por algum motivo, a implementação do método também verifica a presença de um arquivo .job em c: \ windows \ tasks e grava uma DACL nele
sem representação . Como o usuário (mesmo o usuário do grupo de convidados) pode criar arquivos nesse diretório, podemos simplesmente criar um link físico para qualquer outro arquivo que possamos ler. Usando esse hardlink, podemos forçar o serviço do planejador (executando com privilégios de SYSTEM) a gravar uma DACL arbitrária (consulte o segundo parâmetro SchRpcSetSecurity) em um arquivo de nossa escolha.
Assim: para qualquer arquivo que possa ser lido, você pode alterar a DACL, o que permite substituí-lo completamente.
Exploração de vulnerabilidade
Essa vulnerabilidade nos dá uma primitiva muito forte! O principal problema é que, após a instalação (por padrão), muitos arquivos importantes podem ser modificados apenas pelo usuário TrustedInstaller (mas não pelo usuário SYSTEM).
O arquivo contém um script do PowerShell para listar arquivos que você pode controlar. Apenas execute:
./enumerate.ps1 >output.txtO sistema tem muitos objetivos. Você pode controlar os arquivos de programa e, se o arquivo de destino for usado por um administrador / outro usuário, os arquivos que você substituiu podem ser iniciados com os privilégios necessários.
O segundo problema é que, embora possamos obter controle sobre muitos arquivos, a gravação neles geralmente é impossível, porque essas DLLs já estão carregadas em algum lugar para execução. Tentar escrever uma DACL para um arquivo carregado para execução causará um erro de acesso compartilhado. Mas a vulnerabilidade pode ser usada para outros tipos de arquivos, que podem ser um destino melhor que uma DLL.
Para operação, o arquivo C: \ Windows \ System32 \ DriverStore \ FileRepository \ prnms003.inf_amd64_4592475aca2acf83 \ Amd64 \ printconfig.dll foi selecionado (o nome do diretório pode variar, isso é considerado no PoC). Parece que esse arquivo pertence à impressora XPS e não está carregado no serviço de impressão por padrão (pode acontecer que o arquivo já esteja carregado ... mas, na maioria das vezes, não está).
E quando iniciamos o trabalho de impressão usando a impressora XPS, o serviço carrega essa DLL, que podemos reescrever com antecedência. Esse vetor de ataque (seqüestro) pode ser facilmente aplicado para algo melhor. Posso tentar encontrar as melhores opções ... deixe-me saber.
Nota : Em um laptop antigo, onde o Windows 10 está em execução há vários anos, existem dois diretórios prnms003.inf_amd64_ *. A nova versão não exclui a antiga, o que significa que não há garantia de que o FindFirstFile (usado no PoC) encontre o diretório atual. Portanto, você pode expandir o código substituindo todos os printconfig.dll encontrados ou verificar o atributo do último registro no arquivo e selecionar um mais recente.
Demo
Você também pode encontrar um vídeo com uma demonstração no arquivo: