Nas séries anteriores
Há pouco tempo, falei sobre duas vulnerabilidades do Steam:
CVE-2019-14743 e
CVE-2019-15316 . Havia toda uma história sobre como tentei registrá-los, não consegui, fui banida e somente após a divulgação pública e a ajuda da comunidade consegui obter resultados. A Valve fingiu pedir desculpas e desbanir-me no HackerOne, então decidi transferir a próxima vulnerabilidade por meio desse serviço. Na terceira vez (
deveria haver uma piada óbvia sobre o Half-Life 3 ), tudo correu com mais ou menos sucesso.
Descrição da vulnerabilidade
A vulnerabilidade permite criar arquivos com conteúdo parcialmente controlado (ou adicionar conteúdo parcialmente controlado aos arquivos existentes). A versão do serviço vulnerável é 5.31.28.21 (dados do arquivo SteamService.exe). Primeiro, descreverei como explorar a vulnerabilidade e depois descreverei as possíveis consequências.
Etapa 1. Ambiente
Você deve encerrar o aplicativo Steam e interromper o Serviço de Cliente Steam, se estiver em execução. Na maioria das vezes, usuários sem direitos de administrador não podem iniciar e parar nenhum serviço. Mas especificamente para este serviço, a Valve definiu direitos que permitem a todos os usuários parar e iniciá-lo.
Crie uma pasta em qualquer lugar acessível ao usuário (por exemplo, "C: \ test"). Nesta pasta, você precisa copiar os arquivos Steam.exe e steamclient.dll da pasta de origem do Steam (por padrão, é "C: \ Arquivos de Programas (x86) \ Steam"). Crie uma subpasta de logs vazia ("C: \ test \ logs").
Agora vamos corrigir o registro: na ramificação "HKLM \ Software \ wow6432node \ valve \ steam", altere o valor do parâmetro "InstallPath" para "C: \ test \ 1 \ ..". Geralmente, para usuários não administradores, as ramificações do registro no HKLM não são graváveis, mas não neste caso. Ao instalar o Valve, eles definem esses direitos para sua filial dentro do HKLM, de modo que todas as ações estejam disponíveis para todos os usuários ("Controle total" para o grupo "Usuários").
Etapa 2. Vamos fazer um pequeno teste
Inicie o serviço de cliente Steam. Depois que parar (isso acontecerá automaticamente após alguns segundos), verifique o conteúdo da pasta “C: \ test \ logs” - encontramos o arquivo “service_log.txt” lá. O conteúdo do log será algo como isto:
08/27/19 13:45:01 : ERROR: SteamService: Invalid file signature C:\test\1\..\bin\SteamService.dll
Observe que o caminho "C: \ test \ 1 \ .." é equivalente ao caminho "C: \ test"; portanto, o Windows usou o segundo para trabalhar e o primeiro entrou na mensagem. Exclua o arquivo "service_log.txt" e continue.
Etapa 3. Adicione mais texto.
Um fato interessante: quando o Windows trabalha com caminhos que contêm "\ ..", ele automaticamente simplifica esses caminhos. Não verificando as pastas temporárias.
Por exemplo, o caminho "C: \ 1 \ <test> \ .." será convertido em "C: \ 1", apesar de colchetes angulares não poderem ser usados no nome da pasta.
Na primeira etapa, registramos o caminho no registro, agora adicionaremos quebras de linha a ele. Isso pode ser feito escrevendo um código simples, mas também na interface regedit. Basta abrir a ramificação do registro "HKLM \ Software \ wow6432node \ valve \ steam" e selecionar "Modificar dados binários .." no menu de contexto do parâmetro "InstallPath". Algo como um editor hexadecimal aparecerá onde você poderá fazer as edições necessárias.
Realizaremos outro lançamento de teste do serviço e verificaremos o resultado de nossas ações.
Após o teste, você deve excluir novamente o arquivo "service_log.txt".
Etapa 4. Redirecione o arquivo criado
Usuários sem direitos de administrador não podem criar links simbólicos de um arquivo para outro. Mas há um foco: você pode combinar outros tipos de links disponíveis para usuários sem direitos de administrador para obter um efeito próximo a um link simbólico de arquivo para arquivo.
Primeiro, crie um ponto de nova análise NTFS (outro nome para o ponto de montagem NTFS) da pasta "C: \ test \ logs" para "\ RPC Control \". "\ RPC Control \" não é uma pasta comum no sentido usual, não pode ser visualizada, por exemplo, no explorer. Este é um diretório de objetos do sistema, dentro do qual, por exemplo, são nomeados mutexes, eventos e outros objetos semelhantes. Por que o redirecionamento via ponto de nova análise NTFS funciona para ela não é claro, provavelmente o objetivo é usar as mesmas abstrações para pastas no sistema de arquivos e nos diretórios de objetos. No diretório de objetos, você pode criar um link simbólico para um arquivo sem direitos de administrador. Crie um link simbólico no formato "\ RPC Control \ service_log.txt" <-> "C: \ Path \ to \ file".
Como resultado, todas as chamadas para "C: \ test \ logs \ service_log.txt" serão redirecionadas para o arquivo "C: \ Path \ to \ file". Para criar esse redirecionamento, existem dois requisitos básicos - a pasta na qual o ponto de nova análise NTFS é criado deve estar vazia e também deve ser gravável para o usuário. Para cumprir a primeira condição, após cada teste excluímos o arquivo “service_logs.txt”, a segunda condição é garantida pelo fato de termos criado a pasta de origem em um local controlado pelo usuário.
Existe um utilitário especial que cria esses pares de links simbólicos - CreateSymlink e está disponível para download no
GitHub . Uso de utilidade:
CreateSymlink.exe <> <>
No nosso caso, será:
CreateSymlink.exe "C:\test\logs\service_log.txt" "C:\\\"
Juntando tudo, concluímos que, quando o Serviço Cliente do Steam for iniciado, um arquivo será criado ao longo do caminho especificado ao criar o link simbólico, e esse arquivo conterá o conteúdo que podemos controlar (bem, exceto a primeira e a última linha). Se especificarmos o caminho para um arquivo existente, o conteúdo será anexado ao final do arquivo. Tudo isso será feito em nome do Serviço do Cliente Steam com privilégios NT AUTHORITY \ SYSTEM.
Impacto
Agora vou listar os possíveis efeitos dos menos importantes e ascendentes.
- Dos
Se o objetivo do link simbólico for definir "C: \ Windows \ System32 \ config \ SAM" ou "C: \ Windows \ System32 \ config \ SECURITY", é improvável que o sistema operacional seja capaz de inicializar após uma reinicialização. - Redirecionamento de usuário na Internet
Defina a meta do link simbólico "C: \ Windows \ system32 \ drivers \ etc \ hosts" e adicione uma linha como "127.0.0.1 google.com" lá.
Resultado:
- EoP horizontal
Um aumento horizontal de privilégios é uma alteração nos direitos nos quais obtemos acesso não a direitos mais altos, mas a direitos do mesmo nível, mas em relação a outros objetos, por exemplo, aos direitos de outros usuários.
Defina a meta do link simbólico “C: \ ProgramData \ Microsoft \ Windows \ Menu Iniciar \ Programas \ StartUp \ run.bat” e adicione uma linha como “start C: \ test \ 1.exe”.
Todos os arquivos da pasta C: \ ProgramData \ Microsoft \ Windows \ Menu Iniciar \ Programas \ StartUp são executados pelos usuários quando eles fazem logon. Assim, um usuário pode forçar outro usuário a executar o código. No arquivo bat, todas as linhas serão executadas sucessivamente. O primeiro e o último simplesmente não farão nada, mas o comando implementado "start C: \ test \ 1.exe" funcionará.
Com a introdução desse comando, há uma sutileza - os caracteres "\" serão levados em consideração durante a normalização do caminho, portanto, para a operação correta, será necessário adicionar mais "\ .." ao caminho no registro. - EoP vertical
A escalação de privilégios verticais é uma escalação usual, por exemplo, de um usuário sem direitos de administrador para NT AUTHORITY \ SYSTEM.
Muitas vezes você pode encontrar um software que executa scripts de texto com altos direitos. Podemos adicionar comandos a esses scripts e executar nosso código com altas permissões. Como não encontrei esses scripts em um sistema operacional limpo, não é possível demonstrar essa exploração. Mas, como exemplo, posso especificar arquivos bat que são criados pelo NVIDIA e VmWare ou scripts de logon para o sistema operacional no domínio.
Além disso, para aprimorar, você pode verificar a capacidade de criar arquivos xml, arquivos ini com um formato quebrado. Infelizmente, existem muitas opções - criação de tarefas para o TaskSheduler, trabalho com downloads de manifestos e outras bibliotecas e muitas outras. Parece-me que os resultados descritos acima já são suficientes para entender os resultados da vulnerabilidade.
Linha do tempo
Para concluir a imagem, darei uma linha do tempo chata sobre essa vulnerabilidade.
26/08 -
Foi encontrada uma vulnerabilidade.
27 de agosto - unban on h1, publicou um relatório.
12.09 - uma correção foi lançada .
Conclusões
É aqui que eu termino as postagens de pesquisa do Steam - 3 vulnerabilidades encontradas com uma análise bastante superficial, isso não é suficiente. Para ir mais fundo, você precisa de mais tempo e desejo. Infelizmente, a atitude da Valve e a incompetência dos funcionários da HackerOne são barreiras muito fortes.
Quero agradecer mais uma vez a todos os leitores que ajudaram a tornar o Steam mais seguro. Agradeço à Valve por corrigir as vulnerabilidades e refutar minhas teorias da conspiração. Agradeço à HackerOne por fornecer a plataforma, apesar de basicamente me impedirem de comunicar as vulnerabilidades à Valve.
Este artigo em inglês.