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 e GDPR.
- Siga o tecflow no Google News!
- Participe do nosso grupo no Telegram ou Whatsapp!
- Confira nossos stories no Instagram e veja notícias como essa!
- Siga o tecflow no Google Podcast e Spotify Podcast para ouvir nosso conteúdo!
- Anuncie conosco aqui.
O Claroty Team82, em colaboração com a Check Point Research (CPR), conduziu um projeto de pesquisa para verificar a segurança do QuickBlox SDK. Juntos, descobrimos 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.
Neste relatório, demonstraremos 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 identificamos com outras falhas nos aplicativos visados, encontramos maneiras singulares de realizar ataques que nos permitiram 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 migrar para a versão mais recente. Gostaríamos de expressar nossa gratidão e apreço.
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 nos deparamos com a QuickBlox, pela primeira vez, enquanto pesquisávamos especificamente um aplicativo para dispositivo móvel de intercomunicação que dependeria de tal estrutura. Isso nos levou ao caminho da pesquisa tanto na estrutura QuickBlox, quanto em vários aplicativos que a utilizam.
Antes de entendermos as vulnerabilidades que descobrimos no QuickBlox, devemos entender como um desenvolvedor integra a estrutura em seu aplicativo. Primeiro, os desenvolvedores devem criar uma conta na QuickBlox (https://admin.quickblox.com/signup). 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.
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, notamos que a maioria deles optou por simplesmente inserir os segredos do aplicativo no app.
Quando notamos pela primeira vez que a documentação oficial orienta os clientes a adicionar segredos (AUTH_KEY, AUTH_SECRET) aos seus aplicativos, nos sentimos 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 entendermos a arquitetura da QuickBlox, decidimos vasculhar sua API e examinar o que podíamos acessar, usando informações “públicas”: chaves secretas do aplicativo. Descobrimos 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.
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.
Embora isso ofereça alguma mitigação para as vulnerabilidades que descobrimos, encontramos 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 realizamos em relação a essa configuração de privacidade em todos os aplicativos que pesquisamos e recuperamos as chaves, descobrimos que apenas alguns optaram por desativar essa API.
Impacto
Para entender o escopo completo do problema, decidimos 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, conseguimos 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, tentamos entender como os invasores poderiam aproveitar o seu ataque com base nos recursos do app e/ou outras vulnerabilidades na plataforma. Encontramos muitos vetores de ataque interessantes; aqui explicaremos 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 ver 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.
Os usuários podem usar o aplicativo Rozcom para gerenciar os seus dispositivos pessoais de intercomunicação. Usando o aplicativo, eles podem abrir uma porta/portão, iniciar uma seção multimídia com o dispositivo (transmitir vídeo/áudio, e fazer comunicação push-to–talk).
Nos bastidores, a Rozcom está usando a plataforma QuickBlox para lidar com seções multimídia, transferindo vídeo/áudio entre o aplicativo móvel e o dispositivo.
Acontece que a Rozcom optou por usar o ID do usuário, mostrado acima, como o identificador do usuário QuickBlox. E, como poderíamos vazar o banco de dados do usuário QuickBlox, poderíamos obter acesso a todos os usuários da Rozcom, incluindo IDs de edifícios, bem como os números de telefone dos usuários correspondentes.
Controlando todos os intercomunicadores
Nosso próximo passo foi examinar os aplicativos e as APIs em nuvem da Rozcom, para entender melhor o possível vetor de ataque, usando os identificadores que vazamos.
A primeira API que descobrimos permitiu-nos recuperar informação sobre um edifício gerido pela Rozcom, fornecendo o ID do edifício. Acessando a seguinte API: getbuildingdetailpublic?buildingId=BUILDING_ID, poderíamos retornar o endereço completo de cada prédio, bem como o número de apartamentos naquele prédio.
Em seguida, queríamos ver se poderíamos finger ser um usuário. Ao usar o aplicativo, notamos que os usuários podem acessar sua conta digitando o seu número de telefone e recebendo uma senha única, como uma mensagem SMS como autenticador.
No entanto, descobrimos que o dito OTP não é tão único. Em vez disso, o mesmo token OTP é mantido em todas as seções. Geralmente, os usuários não percebem isso, porque só precisam inseri-lo durante o login inicial e o aplicativo salva o token nos bastidores. Em seguida, usando o ID do usuário e o OTP, os usuários se autenticam no aplicativo.
Além disso, por meio da engenharia reversa do aplicativo móvel, descobrimos outra rota de API que poderia ser usada por invasores para vazar o token OTP. Chamando a API da Rozcom com a seguinte função: gettenantauth?cellular=PHONE_UMBER, o servidor de back-end retorna o token OTP do usuário.
Isso significa que o único requisito para recuperar as credenciais de um usuário é o seu número de telefone, que conseguimos vazar usando a vulnerabilidade da QuickBlox. Além disso, o código de autenticação é estático. Portanto, os invasores podem realizar o login facilmente em nome de qualquer usuário e usar a funcionalidade do aplicativo em sua extensão. Isso permite que eles abram a porta/portão, abram streams de vídeo e muito mais; eles agora podem controlar totalmente o dispositivo de intercomunicação remotamente.
Analisando Plataforma [REDACTED] de Telemedicina
A telemedicina é a distribuição de serviços e informações relacionadas à saúde, por meio de informações eletrônicas e tecnologias de telecomunicação. Ela permite o contato entre pacientes e médicos, além de cuidados, conselhos, lembretes, educação, intervenção, monitoramento e admissões, à distância.
Optamos por verificar um aplicativo popular de telemedicina integrado ao QuickBlox SDK, a fim de explorar sua superfície de ataque, abusando das vulnerabilidades da QuickBlox descritas acima. Não estamos divulgando o nome do aplicativo, porque ele ainda não foi atualizado para a nova API da QuickBlox e permanece vulnerável no momento da publicação.
Esta plataforma de telemedicina, em particular, fornece serviços de chat e vídeo, que permitem que os pacientes se comuniquem com os médicos. Ao combinar as vulnerabilidades da QuickBlox com as vulnerabilidades específicas do aplicativo de telemedicina, conseguimos vazar todo o banco de dados do usuário, juntamente com os registros médicos relacionados e o histórico armazenado no app.
Vazamento de PII em Massa
Ao pesquisar o aplicativo Android afetado, conseguimos extrair as chaves incorporadas do app da QuickBlox. Poderíamos então autenticar no servidor da API da QuickBlox, obter um token de autenticação e acesso a um banco de dados de usuários para o aplicativo. Essas etapas não são diferentes de qualquer outro app que usa QuickBlox. No entanto, aqui estamos falando sobre informações do paciente e do médico.
Neste aplicativo de telemedicina, cada usuário escolhe as suas credenciais de UserID e senha usadas pelo app. No entanto, descobrimos por meio de engenharia reversa que o aplicativo [REDACTED] cria um novo usuário QuickBlox com o seu UserID como login e uma senha estática codificada ([REDACTED] para pacientes, e [REDACTED] para médicos).
Isso possibilita o login na QuickBlox em nome de qualquer usuário – médico ou paciente -, e a visualização de todos os seus dados. Isso inclui:
- Informações pessoais
- Histórico médico
- Histórico da conversa
- Arquivos de registros médicos
Além disso, como é totalmente possível passar-se por outra pessoa, por meio desse ataque, qualquer um pode se passar por um médico e modificar as informações ou até mesmo se comunicar em tempo real via bate-papo e vídeo com os pacientes reais na plataforma, em nome de um médico verdadeiro. Este é um cenário muito assustador.
Conclusão
O Claroty Team82 e a Check Point Research colaboraram nesta análise abrangente da API da QuickBlox, que é proeminente em muitos aplicativos de bate-papo e vídeo usados por milhões de pessoas em diferentes setores. Juntos, conseguimos descobrir vulnerabilidades na arquitetura da plataforma da QuickBlox, que poderiam ser exploradas para permitir que invasores acessassem bancos de dados dos usuários dos aplicativos. Milhões de registros de usuários estavam em risco, devido a essas vulnerabilidades.
Nossa pesquisa conjunta levou a várias explorações de prova de conceito contra os aplicativos que executam a API afetada. Demonstramos como a combinação de tokens secretos e senhas embutidos no aplicativo e o uso de um design inseguro de API da QuickBlox pode permitir que cibercriminosos obtenham uma grande quantidade de informações sobre os usuários finais.
Trabalhamos de perto com a QuickBlox para remediar os problemas. A QuickBlox respondeu à nossa divulgação, projetando uma nova arquitetura segura para a sua plataforma e uma nova API. Os seus clientes foram incentivados a migrar para as versões mais recentes de ambos. Mais uma vez, agradecemos à QuickBlox por sua cooperação e resposta rápida para garantir que essas vulnerabilidades sejam abordadas e a privacidade e segurança de seus usuários garantidas.
Faça como os mais de 10.000 leitores do tecflow, clique no sino azul e tenha nossas notícias em primeira mão! Confira as melhores ofertas de celulares na loja parceira do tecflow.
