Importantes falhas de segurança na estrutura de vídeo e bate-papo do QuickBlox expõem milhões de dados confidenciais

Os serviços de bate-papo e vídeo em tempo real disponíveis em aplicativos de telemedicina, finanças e dispositivos IoT inteligentes usados por milhões de pessoas contam com a popular estrutura QuickBlox. A QuickBlox disponibiliza aos desenvolvedores de aplicativos móveis e de web um SDK e APIs para fornecer não apenas recursos de gerenciamento de usuários, bate-papo públicos e privados em tempo real, por exemplo, mas também funcionalidades de segurança que garantem a conformidade com HIPAA (regulamentação de saúde dos Estados Unidos) e GDPR (regulamentação de proteção de dados da União Europeia). 

O Claroty Team82, em colaboração com a Check Point Research (CPR), divisão de inteligência de ameaça da Check Point® Software Technologies Ltd, uma fornecedora líder de soluções de cibersegurança global, conduziu um projeto de pesquisa para verificar a segurança do QuickBlox SDK. Juntos (Claroty Team82 e CPR), descobriram algumas das principais vulnerabilidades de segurança na arquitetura da plataforma QuickBlox que, se exploradas, podem permitir que os cibercriminosos acessem dezenas de milhares de bancos de dados de usuários de aplicativos e coloquem milhões desses registros em risco.

Recursos de bate-papo e vídeo da QuickBlox (Fonte: QuickBlox)

Neste relatório, os especialistas demonstrarão explorações contra múltiplos aplicativos, que executam o QuickBlox SDK sob uma linha de aplicativos, especificamente contra apps de intercomunicação inteligente e telemedicina. Ao encadear as vulnerabilidades que identificaram com outras falhas nos aplicativos visados, eles encontraram maneiras singulares de realizar ataques que permitiram a eles abrir portas remotamente, por meio de apps de intercomunicação e também vazar informações de pacientes de uma importante plataforma de telemedicina.

O Claroty Team82 e a CPR trabalharam próximos com a QuickBlox para resolver todas as vulnerabilidades descobertas. A QuickBlox se comprometeu com a correção ao projetar uma nova arquitetura e API seguras e incentivar seus clientes a migrarem para a versão mais recente.

Arquitetura QuickBlox

QuickBlox é uma plataforma de chat e vídeo chamada para o desenvolvimento de aplicativos iOS, Android e web. Ele fornece uma API para autenticação, gerenciamento de usuários, bate-papo e mensagens, gestão de arquivos, etc, e um SDK fácil de usar que permite recursos de voz e vídeo. Portanto, não é nenhuma surpresa que os especialistas se depararam com  a QuickBlox, pela primeira vez, enquanto pesquisavam especificamente um aplicativo para dispositivo móvel de intercomunicação que dependeria de tal estrutura. Isso os levou ao caminho da pesquisa tanto na estrutura QuickBlox, quanto em vários aplicativos que a utilizam.

Antes de entender as vulnerabilidades descobertas no QuickBlox, os especialistas dizem que devemos entender como um desenvolvedor integra a estrutura em seu aplicativo. Primeiro, os desenvolvedores devem criar uma conta na QuickBlox (Link). Então, um novo aplicativo é criado usando o painel da QuickBlox, que irá gerar as seguintes credenciais para o aplicativo: 

• ID do aplicativo
• Chave da autorização
• Segredo da autorização
• Chave da conta.

Com essas informações, o aplicativo pode solicitar um QB-Token que será usado em outras solicitações de API. O token fornecido é um token de nível de aplicativo, que possui funcionalidade limitada.

Solicitando um Token QB no nível de aplicativo, por meio de uma rota de API /session[.]json

Uma vez que o aplicativo recupere o QB-Token, ele permite que os usuários efetuem o log in por cima desta seção, para que a seção tenha o contexto do usuário conectado. Isso é feito fornecendo a seção do aplicativo e as credenciais do usuário. Agora a seção está totalmente autenticada e autorizada com as permissões do usuário.

No entanto, esta forma de autenticação expõe uma grande falha: uma seção de aplicativo é necessária para criar uma seção de usuário. Isso significa que cada usuário deve obter uma seção do aplicativo, o que requer conhecimento dos segredos do aplicativo, especificamente ID do aplicativo, chave da autorização, segredo da autorização e chave da conta. Para torná-lo tecnologicamente aplicável, os desenvolvedores de apps precisavam garantir que essas chaves secretas fossem acessíveis a todos os usuários. Ao examinar os aplicativos que usam QuickBlox, os especialistas notaram que a maioria deles optou por simplesmente inserir os segredos do aplicativo no app.

Uma amostra de credenciais de aplicativo da documentação do QuickBlox.

Quando eles notaram pela primeira vez que a documentação oficial orienta os clientes a adicionar segredos (AUTH_KEY, AUTH_SECRET) aos seus aplicativos, eles se sentiram desconfortáveis. Nunca é uma boa ideia esconder tokens de autenticação secreta em aplicativos, porque eles são considerados informações públicas e podem ser facilmente extraídos usando vários métodos, desde engenharia reversa até uma análise dinâmica com Frida.

Vulnerabilidades do QuickBlox

Depois de entenderem a arquitetura da QuickBlox, eles decidiram vasculhar sua API e examinar o que podiam acessar, usando informações “públicas”: chaves secretas do aplicativo. Descobriram algumas vulnerabilidades críticas na API da QuickBlox, que podem permitir que possíveis invasores vazem o banco de dados dos usuários de muitos aplicativos populares.

Por padrão, as configurações da QuickBlox permitem que qualquer pessoa, com uma seção no nível de aplicativo, consiga informações confidenciais e permissões, como:

• Uma lista completa de todos os usuários, usando a rota da API /users[.]json
• Informações do usuário PII por ID, usando a rota da API /ID[.]json – incluindo nome, e-mail, telefone etc.
• Criar novos usuários, usando o /users[.]json

Isso significa que qualquer pessoa que conseguir extrair as configurações estáticas da QuickBlox no aplicativo poderá recuperar as informações pessoais do usuário, abaixo, de todos os usuários do app e também poderá criar múltiplas contas controladas por invasores.

Exemplo de informações do usuário obtidas de um aplicativo, usando o QuickBlox.

Embora as configurações padrão da API permitam todos os itens acima (obter a lista completa de usuários, recuperar informações do usuário e criar novos usuários), os proprietários do app podem limitar o acesso à API no nível do aplicativo, usando um menu interno de configurações.

Capturas de tela das configurações disponíveis da privacidade do usuário da QuickBlox.

Embora isso ofereça alguma mitigação para as vulnerabilidades que eles descobriram, encontraram outra maneira de vazar todo o banco de dados do aplicativo. Ao criar uma conta de usuário não autorizada, é possível que os invasores vazem informações específicas do usuário acessando /ID[.]json, em que ID é o ID do usuário sequencial. Como a QuickBlox usa IDs sequenciais, simplesmente forçando brutalmente um intervalo limitado, é possível vazar todas as informações do usuário de um app. No entanto, a partir de uma verificação que realizaram em relação a essa configuração de privacidade em todos os aplicativos que pesquisaram e recuperaram as chaves, descobriram que apenas alguns optaram por desativar essa API.

Impacto

Para entender o escopo completo do problema, os especialistas decidiram explorar quais tipos de aplicativos estão usando o Quickblox SDK e qual seria o risco potencial se os invasores extraíssem os tokens secretos. Usando vários métodos, como Google dorking, pesquisas no BeVigil, e outros mecanismos de pesquisa, conseguiram encontrar e extrair tokens QB de dezenas de aplicativos diferentes. Aqui está uma lista parcial:

Extrair chaves não foi tão simples, quanto procurar no código. Em alguns casos, as chaves foram encriptadas, enquanto em outros, o código foi fortemente ofuscado. Em alguns casos extremos, elas foram dinamicamente recebidas encriptadas a partir de um servidor remoto. No entanto, independentemente do aplicativo, qualquer app exigiria a chave secreta e, de alguma forma, a usaria com um servidor QuickBlox. O máximo que os desenvolvedores podem fazer é colocar obstáculos para complicar a recuperação da chave do aplicativo; que sempre estará acessível aos invasores, independentemente de levar cinco minutos para extraí-la ou duas horas.

Depois de extrair os tokens de cada aplicativo, os especialistas tentaram entender como os invasores poderiam aproveitar o seu ataque com base nos recursos do app e/ou outras vulnerabilidades na plataforma. Encontraram muitos vetores de ataque interessantes; aqui eles explicarão dois cenários – solução de intercomunicação baseada em nuvem e um aplicativo de telemedicina.

Explorando a plataforma IoT de intercomunicação – ROZCOM

“O primeiro vetor de ataque que exploraremos envolve encontrar e examinar vulnerabilidades em uma plataforma IoT baseada em nuvem, usada para gerenciar intercomunicadores inteligentes vendidos pela Rozcom – um fornecedor com sede em Israel, que vende intercomunicadores para uso residencial e comercial. 

As soluções da empresa incluem intercomunicadores de vídeo, que permitem aos usuários verem quem está tentando acessar um prédio ou apartamento, que se conecta ao sistema de gerenciamento baseado em nuvem da Rozcom, por meio de sua plataforma. Todas essas conexões e recursos podem ser acessados ??por meio do aplicativo móvel da Rozcom. 

Encontramos múltiplas vulnerabilidades na arquitetura Rozcom que nos permitiram baixar todos os bancos de dados dos usuários e realizar ataques completos de controle de contas. Como resultado, fomos capazes de controlar todos os dispositivos de intercomunicação Rozcom, dando-nos controle total e permitindo-nos acessar as câmeras e microfones do dispositivo, grampear seu feed, abrir portas gerenciadas pelos dispositivos e muito mais.

A Rozcom, por um ano e meio, ignorou nossas tentativas de divulgar nossas descobertas em particular com a Equipe Israelense de Resposta a Emergências Cibernéticas (IL-CERT) atuando como coordenadora. IL-CERT em 4 de maio alocou e publicou CVE-2023-31184, CVE-2023-31185 para as duas vulnerabilidades que descobrimos.

Arquitetura Rozcom 

A Rozcom usa muitos identificadores para os seus ativos. Primeiro, cada edifício tem um número de identificação único de 10 dígitos (por exemplo: 171XXXX708), usado para identificar entre diferentes edifícios na plataforma. Ao contrário dos IDs de compilação, que são construídos a partir de números “aleatórios”, os usuários são identificados usando a seguinte estrutura: ID DO EDIFÍCIO + NÚMERO DE TELEFONE (por exemplo 171XXXX708 5511981234567). Isso significa que o ID do usuário é realmente construído a partir de dois identificadores diferentes que devem ser mantidos em segredo.