Explorando o mecanismo de subaplicação da SteelSeries para escalonamento de privilégios
Resumo executivo
O pesquisador de segurança da Akamai, Tomer Peled, descobriu recentemente duas vulnerabilidades na aplicação da SteelSeries.
A SteelSeries é uma empresa de hardware que fabrica periféricos de computador e tem mais de 9 milhões de clientes em todo o mundo.
As vulnerabilidades foram atribuídas aos números CVE-2023-31461 e CVE-2023-31462. A SteelSeries agiu rapidamente para corrigir essas vulnerabilidades em maio de 2023.
Essas vulnerabilidades permitem que um invasor execute códigos com privilégios superiores aos obtidos no início e, possivelmente, com privilégios de administrador. Para explorar essas vulnerabilidades, o invasor precisa enviar dois pacotes locais a um servidor IPC em escuta. Então, o servidor executará a carga útil do invasor com privilégios elevados.
A causa raiz dessas vulnerabilidades está no tratamento inseguro de permissões no ouvinte IPC do serviço e na falta de proteção contra path traversal.
O Security Intelligence Group (SIG) da Akamai divulgou de forma responsável as vulnerabilidades às equipes de suporte e engenharia da SteelSeries e as enviou à MITRE para os CVEs atribuídos.
O SIG encontrou o serviço vulnerável em vários data centers que monitoramos, e informamos os clientes sobre o risco e como mitigá-lo.
- Fornecemos uma exploração de prova de conceito (PoC), bem como uma osquery para detectar máquinas com o serviço vulnerável.
Introdução
A SteelSeries é uma empresa de hardware especializada em dispositivos periféricos de computador, como teclados, mouses, fones de ouvido etc. Para personalizá-los, a SteelSeries oferece aos seus usuários uma aplicação – SteelSeries GG – que pode ser baixada de seu website.
Esta aplicação, composta pelo principal módulo SteelSeries GG e várias subaplicações, é um mecanismo que a SteelSeries usa para melhorar a experiência do usuário.
Em nossa pesquisa, encontramos duas maneiras de registrar nossa subaplicação e especificar qual código executar por ela, possivelmente levando à execução de código com permissões mais altas. Nesta publicação do blog, fornecemos os detalhes técnicos das vulnerabilidades, bem como uma PoC de exploração.
Detalhes técnicos
A SteelSeries GG é executada em nível médio de integridade por padrão e, geralmente, no contexto do administrador. Consequentemente, ela pode ser executada em um contexto de alta integridade em determinadas circunstâncias. Esse detalhe, combinado com o fato de que a SteelSeries GG é um processo de escuta (Figura 1), a torna um bom alvo para pesquisa de vulnerabilidade.
Fig. 1: O Process Hacker e o netstat mostram a aplicação SteelSeries GG em escuta
O mecanismo de subaplicação e a API de comunicação entre processos
O mecanismo de subaplicação é usado para gerenciar os recursos opcionais da SteelSeries e melhorar a experiência do usuário. Um exemplo dessa subaplicação é a Sonar, "um conjunto avançado de ferramentas de software de áudio para jogos que dá a qualquer pessoa a capacidade de ajustar o som no jogo, o chat em equipe e o microfone separadamente", conforme definido pela SteelSeries. As subaplicações são executadas em segundo plano e se comunicam com o módulo principal da aplicação por meio de uma API de comunicação entre processos (IPC).
A API de IPC da SteelSeries GG expõe vários tipos de operações que um usuário pode solicitar, incluindo alterações de configuração, ações administrativas, edições de perfil de usuário etc. O mais interessante: a API expõe uma interface para gerenciar subaplicações, da criação e exclusão até a habilitação e desabilitação.
A funcionalidade de roteamento de API (ou seja, como lidar com cada solicitação de API) é implementada usando a biblioteca de código aberto gorilla/mux . Sabendo disso, podemos explorar mais facilmente a superfície de ataque. A função de roteamento em si é muito grande, mas é basicamente apenas uma coleção de declarações if para cada uma das opções de API disponíveis (Figura 2).
Fig. 2: A implementação do roteamento HTTP na SteelSeries GG
Essas chamadas de API estão disponíveis para qualquer pessoa que inicie uma conexão com o servidor de escuta ("SteelSeriesGG.exe") e que não precise de autenticação.
Optei por me concentrar nos gerenciadores de eventos de subaplicações, pois tinham o maior potencial de impacto. Depois de reorganizar o código desmontado no IDA, descobrimos que os gerenciadores de roteamento para subaplicações têm o protótipo visto na Figura 3.
Fig. 3: Protótipo da função do gerenciador no código gorilla/mux
Exploração do mecanismo de subaplicação
Uma das chamadas de API que podemos fazer é criar uma nova subaplicação. Esse processo é feito enviando uma solicitação POST para a rota /subApps com uma carga JSON que contém vários parâmetros, quatro dos quais são de nosso interesse: "name", "executableName", "isEnabled" e "shouldAutoStart".
Usando esses campos, podemos praticamente criar uma nova subaplicação como um usuário sem privilégios, apontá-la para um executável em um local sem privilégios e possivelmente programá-la com cada inicialização de aplicação.
A SteelSeries GG cria o caminho completo para o arquivo executável da subaplicação da seguinte forma:
<StellSeriesGG install location>\Apps\<name>\<executableName>.exe
Como os campos "name" e "executableName" são concatenados dessa maneira, descobrimos que poderíamos tentar um ataque de path traversal. Como parece, a SteelSeries GG não é resistente a path traversals, e a inclusão antes do caminho de "../../../../" foi aceita, como visto na Figura 4.
Fig. 4: Path traversal é aceita durante a criação de uma nova subaplicação
Quando uma subaplicação é criada, as informações sobre ela são armazenadas no banco de dados da SteelSeries GG. Talvez haja outra maneira de controlar subaplicações por meio desse banco de dados? Na verdade, o banco de dados está localizado em um local inseguro. Isso significa que, mesmo sem acesso à API da subaplicação, podemos adicionar uma subaplicação diretamente ao banco de dados. No entanto, os invasores terão que encontrar uma vulnerabilidade para explorar essa falha de projeto, que por si só não é explorável e, portanto, não representa um risco imediato.
Você pode pensar que criar uma subaplicação em um local controlado significa que alcançamos o escalonamento de privilégios (uma vez que executamos um binário a partir desse caminho), mas, ao tentar isso, descobrimos que há outra restrição: a validação do certificado. A SteelSeries certifica-se de que os arquivos executáveis da subaplicação sejam assinados e aprovados. Para executar nossa própria carga útil, teremos que ignorar o processo de verificação.
A função de verificação chama a função WinVerifyTrust e, em seguida, chama uma cadeia de funções WinAPI para comparar determinados campos no certificado com strings codificadas na aplicação.
Essa validação é um pouco difícil de ignorar, mas ainda pode ser obtida de duas maneiras:
Sequestro DLL
TOCTOU (tempo de verificação até o tempo de uso)
O vetor de sequestro de DLL
Com a técnica de sequestro de DLL, podemos contar com o fato de que a SteelSeries confia em vários binários existentes; um deles é o SteelSeriesEngine.exe, que carrega a biblioteca SSEDEVICE.dll. Compilaremos nossa própria biblioteca com o mesmo nome para que ela seja carregada em vez da DLL SSEDEVICE original. As funções exportadas da nossa própria DLL chamarão as funções da DLL genuína.
No entanto, a função chamada no carregamento de nossa DLL implementará nossa lógica mal-intencionada (Figura 5). A técnica é explicada em mais detalhes na publicação do blog de proxy da DLL do itm4n publicação do blog.
Fig. 5: Sequestro de DLL do SSEDEVICE
A animação na Figura 6 mostra o processo de envio do pacote inicial para executar a carga útil do invasor (em nosso caso, abrindo uma instância cmd) com privilégios elevados.
Fig. 6: O processo de enviar o pacote inicial para executar a carga útil do invasor com privilégios elevados
O vetor TOCTOU
Nesse caso, aproveitamos o intervalo de tempo entre a verificação do certificado e a execução real do binário (Figura 7). Em outras palavras, tentamos vencer uma condição de corrida trocando rapidamente o arquivo legítimo por um mal-intencionado usando a ferramenta BaitAndSwitch de James Forshaw. Queremos substituí-lo imediatamente após a verificação do certificado. Dessa forma, a verificação é realizada em um arquivo legítimo, mas um arquivo mal-intencionado não verificado é executado.
Por padrão, o funcionamento das condições de corrida não é garantido. Para estabilizar essa exploração, podemos tentar ganhar mais tempo para a substituição expandir nossa janela de oportunidade.
Fig. 7: Ilustração do vetor TOCTOU
Lembre-se de que a verificação do certificado depende de dois testes: uma chamada para WinVerifyTrust e uma verificação entre vários campos no certificado e uma string codificada na aplicação. Podemos implantar um certificado com esses valores exatos em nosso executável. Esse aprimoramento permite que o invasor vença a condição de corrida mesmo se a troca ocorrer entre os dois testes, pois nosso binário mal-intencionado atende a todos os critérios para o segundo teste.
A animação na Figura 8 mostra o processo de aguardar o início da verificação com BaitAndSwitch para a execução do binário do invasor (neste caso, cmd.exe).
Fig. 8: O processo de aguardar o início da verificação com BaitAndSwitch para a execução do binário do invasor
Detecção e mitigação
Para ajudar na detecção de ativos vulneráveis na rede, fornecemos um osquery para encontrar instâncias da SteelSeries GG e sua versão atualmente instalada:
SELECIONE o nome e a versão dos programas em que o nome É “%SteelSeries%” |
Os clientes da Akamai Guardicore Segmentation podem usar essa consulta com o Insight para localizar aplicações que exigem correções.
A SteelSeries atualiza sua aplicação com cada novo patch. Isso pode reduzir as chances de seus dispositivos serem afetados por essas vulnerabilidades, mas recomendamos que os defensores atualizem sua versão da SteelSeries para uma versão superior a 39.
Conclusão
A SteelSeries é uma grande empresa com uma base de usuários massiva de mais de 9 milhões de clientes em todo o mundo. Qualquer vulnerabilidade em seus produtos é inerentemente impactante. As consequências são agravadas quando consideramos a facilidade de exploração dessas vulnerabilidades e seu efeito na máquina, ou seja, o potencial de se obter a execução de binários no contexto de administrador.
O escopo do impacto não se limita à máquina pertencente ao usuário; as empresas também podem ser afetadas. O laptop de um funcionário que se conecta a um dispositivo vulnerável ou executa uma aplicação vulnerável pode ser conectado posteriormente à rede corporativa e “importar” os riscos para a organização. Por esse motivo, é importante que as empresas considerem a implementação de uma política BYOD (Bring Your Own Device, traga seu próprio dispositivo) e a educação dos funcionários sobre os perigos de usar tais dispositivos.
Verificamos as redes de clientes da Akamai para procurar instâncias da aplicação vulnerável e informamos os clientes relevantes.
Como parte dos nossos esforços contínuos para proteger nossos clientes e a comunidade, continuaremos a analisar as vulnerabilidades de patches e outros sistemas. Para acompanhar a mais recente pesquisa de segurança da Akamai, siga-nos no Twitter.
Cronograma de divulgação
27/04/2023 – Solicitação de CVE enviada à MITRE
01/05/2023 – E-mail enviado ao suporte ao cliente da SteelSeries
02/05/2023 – CVEs atribuídos pela MITRE
03/05/2023 – 04/06/2023 – Conversas com a equipe de engenharia da SteelSeries
31/05/2023 – Correções publicadas
17/07/2023 – Rascunho do blog revisado pela SteelSeries
18/07/2023 – Postagem no blog publicada
