Saudações a todos que decidiram ler meu novo artigo sobre análise de vulnerabilidade. Na última vez, em uma curta série de três artigos, falei sobre vulnerabilidades do Steam (
1 ,
2 e
3 ). Neste artigo, falarei sobre as vulnerabilidades de um produto similar - Origin, que também é um iniciador de jogos. As vulnerabilidades descobertas foram numeradas CVE-2019-19247 e CVE-2019-19248.
Desta vez, não haverá jogo com banana anban. A história da comunicação com a divisão de segurança da Electronic Arts Inc foi inicialmente em nível profissional. Quando fui contatado, eles me deram um número de registro, os relatórios foram cuidadosamente examinados e confirmados. Nenhum dos meus e-mails foi ignorado e, para um pouco de discussão, uma confusão foi organizada. A manutenção desses relatórios foi muito simples para mim, pela qual agradeço a Adrian Stone, Elise Murphy e outros funcionários da EA que trabalharam com meus relatórios.
Postagem e
aviso de segurança do blog .
Agora para as vulnerabilidades. Eu encontrei duas vulnerabilidades como "escalonamento de privilégios" (lpe - escalonamento de privilégios locais ou eop - escalonamento de privilégios) no cliente Windows Origin. Esse tipo de vulnerabilidade permite que qualquer usuário do Windows obtenha mais direitos do que os originalmente emitidos pelo administrador. Nesse caso, estamos falando de dois aprimoramentos "típicos" - de qualquer usuário ao NT AUTHORITY \ SYSTEM (uma conta com permissões máximas no sistema operacional). A primeira vulnerabilidade é bastante entediante, portanto, na próxima seção, descreverei brevemente. Mas o segundo foi bastante interessante, na seção dela vou lhe dizer exatamente como eu a procurei.
CVE-2019-19248
Esta vulnerabilidade consiste em duas partes:
- Criando uma pasta em um caminho arbitrário (com direitos de acesso total);
- Use a cláusula 1 para obter privilégios NT AUTHORITY \ SYSTEM.
Agora, sobre o primeiro ponto em mais detalhes:
Preparação do ambiente
É necessário fechar o cliente Origin e interromper o Serviço do Cliente Origin (em teoria, o serviço em si será interrompido se você fechar o cliente, apenas por precaução).
Para a pasta "C: \ ProgramData \ Origin", os direitos são "Acesso Completo", o que nos permite excluir completamente seu conteúdo.
Link Building
Agora crie alguns links. O primeiro link será do tipo Ponto de Nova Análise NTFS (Ponto de Montagem NTFS) - o tipo de links apontando de pasta para pasta: “C: \ ProgramData \ Origin” <-> “\ RPC Control”. Para criar pontos de nova análise, não precisa de direitos de administrador. Só é necessário que a pasta de origem esteja vazia e o usuário tenha permissões de gravação (elas foram limpas na última etapa, os direitos foram verificados lá). "\ RPC Control" não é uma pasta no sistema de arquivos, mas um tipo especial de pasta - um diretório de objetos. Você não pode vê-lo com um explorador comum, mas pode fazer um ponto de nova análise, aparentemente devido às abstrações comuns usadas nas entranhas do Windows.
Agora criaremos o link simbólico usual "\ RPC Control \ CatalogCache" <-> "C: \ Path \ To \ Target \ Folder". No sistema de arquivos, a criação de links simbólicos sem direitos de administrador é proibida, mas esta regra não se aplica aos diretórios de objetos. Portanto, nosso link será criado com sucesso. Como resultado de uma combinação desses dois links, as chamadas para "C: \ ProgramData \ Origin \ CatalogCache" serão redirecionadas para "C: \ Path \ To \ Target \ Folder".
Leia mais sobre esses links
aqui . No mesmo repositório,
você pode baixar utilitários para trabalhar com links.
Lançamento
Na última etapa, execute o cliente. No início de seu trabalho, ele lançará o "Serviço de origem do cliente" e, descobrindo que não há nenhuma pasta "C: \ ProgramData \ Origin \ CatalogCache", ele tentará criá-lo. Como resultado da navegação pelos links simbólicos, ele criará “C: \ Path \ To \ Target \ Folder” e concederá a essa pasta os direitos de “Acesso Total”.
O que era necessário para ser obtido no primeiro ponto de operação. Vamos para o segundo.
A operação de criar uma pasta em um caminho arbitrário
Aqui você pode trabalhar de várias maneiras.
Simples e razoavelmente confiável é criar a pasta "C: \ Windows \ system32 \ LogonUI.exe.local". “LogonUI.exe” (um aplicativo em execução no NT AUTHORITY \ SYSTEM, é responsável pela operação da tela de seleção do usuário e da tela de bloqueio) graças ao mecanismo “.local-redirection” (“dotlocal redirection”), ele carregará a biblioteca a partir dela no caminho “C: \ Windows \ system32 \ LogonUI.exe.local \ amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.648_none_fb45a0e93062a6d2 \ comctl32.dll. " Em geral, o mecanismo em si é bastante comum, portanto pode ter muitos objetivos.
Uma maneira longa, porém interessante, é subtrair o hash da senha do administrador por meio de fraudes especiais. Mais detalhes
aqui .
Total
A vulnerabilidade é explorada com bastante facilidade, você só precisa trabalhar um pouco no segundo ponto - encontre o alvo e escreva uma dll adequada. Além disso, Matt Nelson também relatou essa vulnerabilidade, e seus escritos podem ser encontrados
aqui .
CVE-2019-19247
Essa é uma das minhas vulnerabilidades favoritas. Ele mostra com que cuidado você precisa se relacionar com a criptografia usada.
Tudo começou com o fato de eu ter instalado o jogo através do Origin. De alguma forma, tudo correu muito bem - alguns cliques e após alguns minutos de download do jogo podem ser iniciados. Não imediatamente, mas eu entendi qual era o problema: o jogo foi instalado no caminho "C: \ Arquivos de Programas \ Nome_do_Jogo", mas não fez uma única pergunta pelo UAC. Eu rapidamente verifiquei os direitos, tudo era padrão - um usuário comum não podia escrever em "C: \ Arquivos de Programas". Um pouco mais de pesquisa e descobri que o jogo não é "prescrito" pelo próprio cliente Origin, mas pelo serviço de atendimento ao cliente Origin.
Comecei a fazer suposições sobre como o cliente transmite informações para o serviço, a fim de verificar se algo pode ser explorado.
O método de transmissão de informações acabou sendo simples - um pipe nomeado. Aprendi sobre isso nos logs de instalação - em texto simples, foi indicado que o canal OriginClientService estava aceitando comandos para trabalhar com arquivos e pastas.
IDA aberto, carregou o cliente lá.
* trabalho realizado na AID: 1 *Muito rapidamente, descobri que os comandos eram enviados ao canal em geral em forma de texto. Nas proximidades, encontrei uma lista de comandos e, sem mais delongas, enviei um comando do tipo "copiar" C: \ test \ payload.dll "" C: \ Windows \ pwn.dll "para o canal. Antecipando um resultado rápido, verifico a pasta “C: \ Windows” e não encontro nada de novo nela. Mas há algo novo nos logs - algumas palavras sobre o fato de o cliente no canal não ter passado na verificação da assinatura digital.
IDA aberto, carregou o serviço lá.
* trabalho realizado na AID: 2 *Eu descobri que as equipes não são esperadas de ninguém. Ao conectar a um tubo, o serviço verifica quem está conectado a ele. O processo pid é extraído da conexão, o caminho para o arquivo executável é extraído do pid, a assinatura é verificada quanto à exatidão e é emitida pela EA.
Soa som, mas não o suficiente. Você pode pegar o "Origin.exe" (arquivo executável do cliente), copiá-lo em algum lugar da sua pasta. Coloque algumas dll da lista de importação "Origin.exe" nesta pasta. Por exemplo, version.dll surgiu. Eu chamei essa abordagem de "injeção reversa de DLL": em uma injeção regular de DLL, copiamos a DLL para o arquivo exe, mas agora fizemos o oposto. Eu escrevo rapidamente dll proxy para version.dll, adicione código ao enviar o comando para o pipe. A carga útil ainda não foi copiada. Lemos os logs - "o que significa, o comando não pode ser descriptografado!?". Eu pulei a criptografia.
IDA aberto, carregou o cliente lá.
* trabalhos realizados na IDA: 3, desvio de assinatura: 1 *Como o cliente envia comandos criptografados em seu trabalho usual, eu posso. Lá eu olhei, depois olhei, o resultado é o seguinte: Criptografia AES, inicializando um vetor constante, a chave é lida no arquivo. Nós praticamente copiamos esta peça e a IDA no código, compilamos, verificamos. Novamente nada. Mas os logs novamente fornecem informações úteis - você não pode especificar Arquivos de Programas como o caminho de destino.
IDA aberto, carregou o serviço lá.
* trabalho realizado no IDA: 4, desvio de assinatura: 1, desvio de criptografia: 1 *Portanto, é verdade que existem verificações para obter um comando de que os arquivos não podem ser copiados em qualquer lugar. E caminhos com "\ .. \" não podem ser escritos. Olhamos o que outras equipes são.
Trabalhando com o registro - há novamente muitas restrições. Mas iniciar arquivos parece interessante. Pelo menos as verificações não são particularmente visíveis. Edite o código, envie o comando "ExecuteProcess" C: \ test \ payload.exe "". Bem, você entende ... Nada.
Os logs novamente falam sobre a assinatura. Oh, nós já vencemos. Indicamos no código que chamamos nosso Origin.exe copiado para carregar nossa DLL proxy novamente, mas com direitos de sistema. Adicione verificações e inicie o console. Começamos e o console com os direitos NT AUTHORITY \ SYSTEM aparece - finalmente tudo funcionou.
* trabalho realizado no IDA: 4, desvio de assinatura: 2, desvio de criptografia: 1 *Portanto, você precisa reiniciar, executar uma execução final e ainda admirar o console com direitos máximos. Reinicie, verifique e ... nada. Como assim? Apenas funcionou.
Os diagnósticos mostram que o Serviço de Cliente de Origem não foi iniciado, por isso estou iniciando-o. Mas isso não começa. Mais precisamente, ele inicia, mas fecha imediatamente. Inicio o cliente Origin e o serviço é iniciado normalmente. Depois disso, a exploração funcionará corretamente novamente. Seria possível parar por aí, mas esse não é o meu caminho - eu quero fazer a exploração funcionar completamente.
IDA aberto, carregou o serviço lá.
* trabalho realizado no IDA: 5, assinatura manual: 2, criptografia manual: 1 *Acontece que, na inicialização, verifica com quais parâmetros o serviço foi iniciado. Não há nada diretamente interessante lá. Base64 do pid criptografado do processo cujo arquivo é verificado pela assinatura. Parece complicado, mas já contornamos a criptografia e a assinatura também. Estamos escrevendo algum código e uma exploração completa está pronta.
Total
A exploração está funcionando. O trabalho foi realizado no IDA: 5 vezes, assinatura de desvio: 3 vezes, desvio de criptografia: 2 vezes.
Conclusão
Vulnerabilidades corrigidas: os desenvolvedores da EA introduziram um modo restrito de operação especial para o cliente, que estabelece sérias restrições ao trabalho com pastas e pipes do Origin.
Vulnerabilidades da linha do tempo:
1 de abril de 2019 : relatório de relatório de vulnerabilidade com pipe;
7 de abril de 2019 : enviando um relatório de vulnerabilidade com uma pasta arbitrária;
... MUITAS LETRAS (contei 40) ...
10 de dezembro de 2019 : divulgação acordada.
Obrigado a todos pela atenção, desejo a você os mesmos agentes de segurança.
Este artigo em inglês.