Encaminhamento de privilégio local do cliente Windows do Steam 0 dia

Venho pesquisando vulnerabilidades há muitos anos e, ao que parece, já vi muitas, mas há uma parte do trabalho com a qual não me acostumo e não consigo entender. É uma relutância absoluta dos fornecedores em aceitar informações sobre vulnerabilidades e problemas. Entendo que é muito desagradável quando eles mostram diretamente que você cometeu um erro e, provavelmente, não um. É desagradável confirmar publicamente em fontes abertas que houve problemas, que os funcionários não trabalharam. Mas não entendo por que as informações de vulnerabilidade precisam ser rejeitadas.


Então, o herói da nossa história é o Steam from Valve. E a vulnerabilidade de escalonamento de privilégios, que permite que qualquer usuário execute comandos em nome do NT AUTHORITY \ SYSTEM.

Vulnerabilidade

A vulnerabilidade em si é bastante simples. O Steam instala o serviço "Serviço ao Cliente Steam" para o seu trabalho. Dê uma olhada no descritor do serviço SDDL :

O:SYG:SYD:(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;RPWP;;;BU)

Aqui estamos interessados ​​na parte (A ;; RPWP ;;; BU). Nesse caso, essa entrada significa que qualquer usuário do grupo Usuários pode iniciar e parar o serviço.
Vamos ver o que o serviço faz na inicialização. Não é muito interessante, mas existem algumas operações que parecem incomuns - o serviço lista o conteúdo da seção HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam \ Apps e define alguns direitos para todas as subseções.



Gostaria de saber que tipo de direitos são exibidos? Criamos uma chave de teste, iniciamos o serviço (log do procmon acima) e vemos o que é certo. Aqui também foi descoberto que a seção HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam possui direitos de acesso total para todos os usuários herdados de todas as subchaves. Nasce uma hipótese de que os mesmos direitos serão definidos para todas as subseções do HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam \ Apps por meio de uma chamada para RegSetKeySecurity . Mas e se houver um link simbólico no registro e a ramificação HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam \ Apps \ test apontará, por exemplo, para HKLM \ SOFTWARE \ test2 ?

Verificamos e observamos que os direitos no caso de um link simbólico estão registrados para o ramo de registro de destino.



Verificamos os direitos do ramo de destino e vemos no formulário SDDL (pulando desinteressante):

(A;ID;KA;;;BU)(A;OICIIOID;GA;;;BU)

De forma verbal, isso significa acesso total (leitura e gravação) a todos os usuários. Esses são os direitos que o serviço Steam prescreveu para a filial.

Agora que o primitivo foi preparado para obter controle sobre quase qualquer ramificação do registro, é fácil lançar PoC. Eu escolhi a ramificação HKLM \ SYSTEM \ ControlSet001 \ Services \ msiserver - corresponde ao serviço "Windows Installer", que também pode ser iniciado pelo usuário, mas o serviço funcionará com os privilégios NT AUTHORITY \ SYSTEM. Depois de obter controle sobre a ramificação HKLM \ SYSTEM \ ControlSet001 \ Services \ msiserver, alteramos o caminho para o executável na chave ImagePath e iniciamos o serviço msiserver. Nosso arquivo executável é iniciado com as permissões mais altas possíveis - NT AUTHORITY \ SYSTEM.

Coletamos tudo o que está escrito acima no código e obtemos uma escalação de privilégios simples em qualquer computador com Windows em que o Steam esteja instalado.

Relatório de vulnerabilidade

Enviei um relatório de vulnerabilidade para a Valve através do Hackerone.

Aqui a primeira surpresa estava me esperando - antes de transferir a vulnerabilidade diretamente para a Valve, tive que convencer a equipe de hackers de que realmente tinha um relatório de vulnerabilidade, pois a Valve usava a função "Gerenciado pelo HackerOne" . Eu não me importo - eu tenho PoC, que chama o console em nome de NT AUTHORITY \ SYSTEM - evidência no rosto. E eu recebo uma negação no relatório. O motivo indica que meu relatório está fora do escopo da pesquisa, porque "Ataques que exigem a capacidade de soltar arquivos em locais arbitrários no sistema de arquivos do usuário". (um ataque requer a capacidade de localizar arquivos em caminhos arbitrários do sistema de arquivos). Minha reação: "Eu nem sequer tenho uma operação de sistema de arquivos, mas uma falha por esse motivo, sério?"

Estou escrevendo um comentário sobre isso e outro funcionário chega, que, no entanto, se compromete a verificar a vulnerabilidade. Confirma e passa a válvula. Viva, o objetivo é alcançado. Ou não ...?

O tempo passa e o relatório é novamente marcado como não aplicável. Razões: “Ataques que exigem a capacidade de soltar arquivos em locais arbitrários no sistema de arquivos do usuário” e “Ataques que exigem acesso físico ao dispositivo do usuário” (o ataque requer acesso físico ao dispositivo do usuário). Então percebi que os ataques de escalonamento de privilégios simplesmente não eram interessantes para a Valve.


Desde que 45 dias se passaram desde o relatório, decidi divulgar publicamente os detalhes da vulnerabilidade, embora não tenha certeza de que isso incentive os desenvolvedores do Steam a fazer alterações.

Pequenas estatísticas: a vulnerabilidade foi testada no Windows 8 x64, Windows 8.1 x64 e Windows 10 x64. Não conheço os recursos da numeração de versões do software Steam, portanto, corrigirei a versão dos componentes de serviço:

• SteamService.dll (5.16.86.11, assinado pela Valve 14/06/2019)
• SteamService.exe (5.16.86.11, assinado pela Valve 14/06/2019)

Linha do tempo:

15 de junho - relatório de vulnerabilidade enviado.
16 de junho - Rejeitado: "Ataques que exigem a capacidade de soltar arquivos em locais arbitrários no sistema de arquivos do usuário".
16 de junho - redescoberto com comentários.
2 de julho - confirmado pelo funcionário da HackerOne, transferido para a Valve.
20 de julho - Rejeitado: "Ataques que exigem a capacidade de soltar arquivos em locais arbitrários no sistema de arquivos do usuário.", "Ataques que exigem acesso físico ao dispositivo do usuário".
7 de agosto - Este artigo foi publicado.

Um pouco de especulação

Estou muito decepcionado. Uma empresa séria que escreve palavras pomposas de que a segurança é importante abre o computador para o acesso máximo a todos os programas que você executa.

É bastante irônico descobrir que um lançador, que é realmente projetado para executar programas de terceiros no seu computador, permite que eles obtenham discretamente privilégios máximos. Você tem certeza de que um jogo gratuito criado por um desenvolvedor desconhecido se comportará honestamente? Acredita que, com um desconto de 90%, você não receberá um mineiro escondido? Obviamente, algumas ameaças permanecerão durante o trabalho sem direitos de administrador, mas os altos direitos de programas maliciosos podem prejudicar significativamente os nervos - desativando o antivírus, corrigindo-o para inicializações do sistema, alterando quase todos os arquivos e usuários.

Devido à popularidade do Steam, o número de vítimas em potencial é muito grande. Em 2015, o número de contas Steam ativas foi estimado em 125 milhões. Sim, nem todos os usuários do Steam têm sistema operacional Windows, mas a maioria deles tem certeza, e alguns usuários têm várias contas "ativas" na mesma máquina. Mas a magnitude do problema ainda é impressionante.
Ou talvez tudo isso seja deixado de propósito? Talvez o Steam seja uma espécie de backdoor legal? É impossível estabelecer exatamente isso, mas vamos comparar os fatos:

1. Existe uma vulnerabilidade que é fácil de explorar (e, a julgar pelas mensagens no Twitter , não por uma).
2. É bem fácil de identificar - não tenho certeza de ter sido o primeiro a encontrá-lo, mas pelo menos o primeiro a descrevi publicamente.
3. Relutância em aceitar um relatório sobre essas vulnerabilidades e outras semelhantes (o escopo é especialmente escolhido para que a escalada de privilégios caia fora dele).

Eu realmente não gosto de tudo isso. Não vou pedir que você remova o Steam, mas proponho ter muito cuidado com o que ele faz. Sua segurança está em risco.

Bônus

O fato é que, no processo de elaboração deste artigo, ocorreu um evento bastante interessante, em relação ao qual decidi complementar a linha do tempo.

20 de julho - depois de rejeitar o relatório, avisei h1 que divulgaria publicamente os detalhes da vulnerabilidade após 30 de julho.
2 de agosto - outro funcionário da h1 é relatado em um relatório fechado e diz que eles não me permitem divulgar.

Este artigo foi preparado para publicação em 30 de julho (essa data foi escolhida à taxa de 45 dias após o envio do relatório), mas foi atrasada. E assim, duas semanas depois da minha mensagem de 20 de julho, aparece uma pessoa que me diz: “não damos permissão para divulgar a vulnerabilidade”. De fato, acontece: marcamos seu relatório como inapropriado, encerramos a discussão, não consideramos necessário lhe explicar nada e simplesmente não queremos que você o publique. Não há uma única palavra da Valve. Não, pessoal, isso não vai funcionar. Você não respeitou o meu trabalho, não respeitarei o seu - não vejo razão para não publicar este relatório para todos. Provavelmente serei banido do h1 por causa disso, mas não ficarei chateado.

UPD Acontece ontem (6 de agosto) A atualização do Steam foi lançada. Não, não consertou nada.
Versão do arquivo: 5.27.59.20 signature de 08/08/2019.

Após divulgação

Continuamos a atualizar a linha do tempo:

7 de agosto (após a publicação) - o relatório sobre h1 foi redescoberto. Recebi uma carta, cuja essência é difícil de encaixar em poucas palavras, mas o mais importante é que alguns argumentos convincentes precisam ser levados à conclusão de que as consequências da vulnerabilidade são significativas. Havia "A válvula não vai consertar algo que eles determinaram ser N / A". Essas palavras confirmaram mais uma vez minha convicção de que estou certo ao conduzir uma divulgação pública de detalhes.

7 de agosto - Matt Nelson escreve que a vulnerabilidade que ele relatou é exatamente a mesma que a minha. O que confirma minha tese sobre a facilidade de encontrá-la. Ele abre seu PoC .


9 de agosto - O Steam Beta recebe uma atualização em que uma das linhas é “Exploração de escalonamento de privilégios corrigida usando links simbólicos no registro do Windows”. Há suspeitas de que a correção possa ser contornada, mas por enquanto estocamos pipoca.

13 de agosto - O Steam recebe uma atualização em que uma das linhas é “Exploração de escalação de privilégios corrigida usando links simbólicos no registro do Windows”. Parece que o serviço não expõe direitos no registro, portanto, podemos assumir que ele foi corrigido.

15 de agosto - o pesquisador mostrou que o patch pode ser contornado , a vulnerabilidade ainda é relevante. Atalho - você pode retornar a versão anterior (antes do patch) do serviço.

20 de agosto - A Valve me proibiu em seu programa no H1. O resto do H1 está disponível para mim.

Este artigo em inglês.