Falhas no QuickBlox expõem bases de usuários em aplicativos de chat e vídeo

Arquitetura de autenticação com segredos embutidos em aplicativos permitia obter sessões de aplicação, consultar usuários e, em cenários encadeados, assumir contas em intercomunicadores e telemedicina.

Componente	Plataforma QuickBlox usada como SDK e API para autenticação, gerenciamento de usuários, chat, mensagens, arquivos, voz e vídeo em aplicativos móveis e web.
Vetor	Extração de chaves de aplicação embutidas em clientes móveis ou web para solicitar sessão de aplicação e consultar recursos da API QuickBlox com permissões de nível de aplicação.
Impacto	Consulta de bases de usuários de aplicações que dependiam da configuração padrão ou de identificadores sequenciais; em aplicativos específicos, o encadeamento com falhas próprias permitiu controle de intercomunicadores e acesso a dados de telemedicina.
Prioridade	Migrar clientes e backend para a nova arquitetura e API segura do QuickBlox, restringir permissões de sessão de aplicação e remover dependência de segredos estáticos no cliente.
Artefatos	Credenciais de integração como Application ID, Authorization Key, Authorization Secret e Account Key, além de sessões QB-Token e identificadores de usuário sequenciais.
Cenários	Aplicativo de intercomunicador Rozcom com CVE-2023-31184 e CVE-2023-31185, e uma plataforma de telemedicina não nomeada que ainda não havia migrado para a nova API no momento da publicação.

Resumo técnico

O problema central está na forma como aplicações integradas ao QuickBlox obtinham uma sessão inicial de aplicação antes da autenticação do usuário. Para criar essa sessão, o cliente precisava conhecer dados de integração como Application ID, Authorization Key, Authorization Secret e Account Key. Como clientes móveis e web são distribuídos aos próprios usuários, esses valores acabavam presentes no aplicativo, ainda que por vezes ofuscados, criptografados ou carregados dinamicamente. Essa decisão transformava segredos de autenticação em material recuperável por análise estática, engenharia reversa ou instrumentação dinâmica, criando uma fronteira frágil entre o aplicativo público e a API de backend.

Com uma sessão de aplicação válida, a configuração padrão do QuickBlox permitia consultar informações sensíveis da base de usuários em várias aplicações, além de criar contas controladas pelo invasor em determinados cenários. Mesmo quando proprietários reduziam parte dessas permissões em configurações internas, a combinação entre conta fraudulenta, IDs sequenciais e rotas de consulta por identificador ainda permitia recuperar registros específicos e percorrer intervalos de usuários. O risco não era limitado ao framework isolado: quando aplicações de negócio reutilizavam identificadores previsíveis, senhas estáticas, códigos de autenticação persistentes ou APIs próprias mal protegidas, a exposição da base QuickBlox servia como ponto de apoio para assumir contas e acessar funções sensíveis.

Fluxo técnico

A integração típica começava com a criação de uma aplicação no painel QuickBlox. O painel gerava credenciais usadas pelo cliente para solicitar um QB-Token por uma rota de sessão, como /session.json. Esse token inicial tinha contexto de aplicação e, em seguida, o usuário final fazia login sobre a sessão existente para que a sessão passasse a carregar permissões do usuário autenticado. A fragilidade nasce da etapa anterior ao login: se todo usuário precisa primeiro obter uma sessão de aplicação, o cliente precisa conter os dados necessários para essa solicitação. Na prática, qualquer pessoa com acesso ao binário ou ao pacote do aplicativo podia tentar recuperar esses dados de integração.

Depois de obter a sessão de aplicação, a API podia expor listagens e detalhes de usuários conforme as permissões habilitadas. Em aplicações nas quais a configuração padrão permanecia ativa, a consulta de usuários permitia levantar informações pessoais associadas ao serviço. Em ambientes com a listagem restringida, a criação de uma conta controlada e a consulta individual por identificadores sequenciais mantinham um caminho de enumeração, porque o espaço de IDs podia ser percorrido por faixas. A falha, portanto, combina segredo embutido, autorização excessiva para sessão de aplicação e identificadores previsíveis, sem exigir a descoberta de uma vulnerabilidade de memória, execução remota de código ou comprometimento prévio do servidor QuickBlox.

O cenário Rozcom mostra o risco de encadeamento. A aplicação de intercomunicador usava o QuickBlox para sessões multimídia entre dispositivo, aplicativo móvel e nuvem, e armazenava no usuário QuickBlox um identificador composto por ID do prédio e número de telefone. A exposição da base permitia obter esses dois valores. Em seguida, APIs próprias da plataforma aceitavam esses identificadores para retornar detalhes de prédio e, por outra falha, um código de autenticação que não se comportava como uso único, permanecendo válido entre sessões. A combinação desses elementos permitia autenticação em nome de usuários e acesso a funções do intercomunicador, incluindo abertura de portas e interação com áudio e vídeo do dispositivo.

No cenário de telemedicina, o impacto veio da mistura entre as permissões do QuickBlox e decisões inseguras do aplicativo integrado. O aplicativo permitia comunicação por chat e vídeo entre pacientes e médicos, mas criava usuários QuickBlox com o UserID da aplicação e uma senha estática codificada de forma diferente para perfis de paciente e médico. Com as chaves QuickBlox extraídas do cliente, era possível autenticar na API, levantar a base de usuários e, depois, entrar no contexto QuickBlox de contas de pacientes ou profissionais. O resultado incluía acesso a dados relacionados à plataforma de atendimento, histórico e registros médicos disponíveis naquele ambiente, além da possibilidade de comunicação em tempo real como outro usuário.

Superfície afetada

A superfície exposta inclui qualquer aplicativo iOS, Android ou web que use o SDK ou as APIs QuickBlox para chat, vídeo, autenticação, mensagens, gerenciamento de usuários ou arquivos, especialmente quando mantém chaves de aplicação no cliente e depende das permissões padrão da API. O risco é maior quando o identificador QuickBlox carrega dados de negócio reutilizáveis fora do chat, como telefone, ID de prédio, ID de paciente, login interno ou qualquer chave que também seja aceita por APIs próprias do fornecedor. Nesses casos, a base QuickBlox deixa de ser apenas um diretório de mensagens e passa a funcionar como mapa para outros sistemas.

A exposição também alcança aplicações que tentaram dificultar a recuperação das chaves sem alterar o modelo de confiança. Ofuscação de código, criptografia local ou entrega dinâmica dos segredos a partir de servidor remoto aumentam o custo de análise, mas não eliminam o fato de que o cliente precisa usar o segredo para conversar com o QuickBlox. Se o valor chega ao dispositivo e participa de uma requisição, ele pode ser observado no processo, no tráfego descriptografado pelo próprio aplicativo ou em memória durante a execução. A correção real exige reduzir a autoridade desses dados e deslocar decisões sensíveis para uma camada controlada pelo operador da aplicação.

Em Rozcom, os problemas próprios receberam os identificadores CVE-2023-31184 e CVE-2023-31185. A plataforma de telemedicina citada não foi nomeada porque ainda não havia migrado para a nova API no momento da publicação. Esses dois casos não significam que todos os clientes QuickBlox tinham o mesmo nível de impacto, mas demonstram como um desenho de autenticação frágil em um serviço comum pode amplificar falhas locais em aplicações de setores muito diferentes.

• Aplicações que embutem Authorization Key, Authorization Secret, Account Key ou identificadores equivalentes em clientes distribuídos ao usuário.
• Ambientes com permissões de sessão de aplicação capazes de listar usuários, consultar detalhes por ID ou criar contas sem mediação suficiente do backend próprio.
• Aplicações que usam IDs sequenciais, senhas estáticas, códigos de autenticação persistentes ou identificadores de negócio dentro do perfil QuickBlox.

Hunting e telemetria

A investigação defensiva deve começar pela separação entre tráfego legítimo do aplicativo e uso anômalo da API QuickBlox. Sessões de aplicação que consultam volumes elevados de usuários, percorrem identificadores em sequência ou criam contas em padrões incomuns merecem análise. Em aplicações móveis, a equipe deve revisar builds publicados e pacotes distribuídos para confirmar se chaves QuickBlox ou strings relacionadas a AUTH_KEY, AUTH_SECRET, Application ID e Account Key estão presentes no artefato final. A presença desses valores no cliente não prova exploração, mas confirma que o modelo de exposição descrito é aplicável.

No backend da aplicação integrada, a telemetria deve procurar correlação entre consultas QuickBlox e chamadas internas que usem os mesmos identificadores. No caso de intercomunicadores, sinais relevantes incluem logins bem-sucedidos a partir de dispositivos ou redes inéditas, abertura de portas fora do padrão de uso, início de sessões de áudio ou vídeo sem evento físico esperado e consultas repetidas a detalhes de prédio. Em telemedicina, a defesa deve priorizar acessos a contas de médicos e pacientes em horários incomuns, múltiplos perfis acessados por uma mesma origem, criação de sessões de chat ou vídeo sem fluxo normal de agendamento e leitura de registros de saúde associada a autenticações recém-criadas.

Como a técnica depende de credenciais de aplicação e não de exploração ruidosa de memória, a detecção puramente baseada em assinatura tende a ser fraca. O melhor sinal vem de comportamento: enumeração de IDs, repetição de rotas de detalhe, aumento de falhas de autorização, contas novas com baixa interação humana, sessões de aplicação emitidas em volume incompatível com a base instalada e mudanças bruscas na geografia ou no provedor de rede das requisições. Logs de API, trilhas de auditoria de identidade, eventos de chat, telemetria de chamadas de vídeo e registros de ações físicas devem ser analisados em conjunto.

• Picos de chamadas de consulta de usuário, especialmente acessos sequenciais a registros por identificador.
• Sessões QB-Token emitidas a partir de origens não compatíveis com o uso normal do aplicativo ou em volume fora do baseline.
• Criação de contas seguida de consultas amplas à base, sem atividade funcional compatível com usuário real.
• Ações sensíveis após autenticação anômala, como abertura de portas, início de streaming, acesso a prontuário ou comunicação em nome de profissional de saúde.

Mitigação

A prioridade é migrar para a nova arquitetura e API segura do QuickBlox indicada para clientes afetados. A mitigação local por configuração ajuda, mas não deve ser tratada como substituta da correção arquitetural. Proprietários de aplicações devem revisar as permissões disponíveis para sessão de aplicação, bloquear listagem ampla de usuários quando não for indispensável, impedir criação não controlada de contas e eliminar consultas por identificadores previsíveis sem validação de autorização no contexto do usuário real. Também é necessário reavaliar qualquer dado colocado no perfil QuickBlox: telefone, ID interno, ID de prédio, login e metadados médicos não devem funcionar como ponte para outros sistemas sem controles adicionais.

Equipes de engenharia devem remover a dependência de segredos estáticos em clientes distribuídos e interpor backend próprio para operações que exigem autoridade de aplicação. Quando o cliente precisar iniciar chat ou vídeo, o backend deve emitir permissões de escopo mínimo, tempo curto e vínculo forte com o usuário autenticado. Senhas estáticas, códigos de autenticação persistentes e tokens reutilizáveis precisam ser substituídos por mecanismos rotativos, expiráveis e verificáveis. Para aplicações já publicadas, a resposta deve incluir rotação das chaves QuickBlox, invalidação de sessões antigas e revisão de usuários criados durante a janela de exposição.

A contenção deve considerar o sistema integrado, não apenas o SDK. Em intercomunicadores, a validação deve cobrir permissões de abertura remota, acesso a câmera, microfone e push-to-talk, além da associação entre usuário, unidade, prédio e dispositivo físico. Em telemedicina, a revisão deve cobrir contas de médicos, pacientes, sessões de atendimento, mensagens, arquivos e registros médicos acessíveis pelo aplicativo. Sempre que houver indício de enumeração ou autenticação indevida, a organização deve preservar logs, delimitar a janela de atividade, invalidar credenciais afetadas e comunicar as partes responsáveis conforme suas obrigações regulatórias e contratuais.

• Migrar para a API segura mais recente do QuickBlox e validar que todos os clientes publicados usam o novo fluxo.
• Restringir permissões de sessão de aplicação para impedir listagem ampla de usuários, criação indevida de contas e consulta por IDs sem autorização contextual.
• Rotacionar chaves de integração, invalidar sessões antigas e revisar contas criadas ou acessadas durante a exposição.
• Remover senhas estáticas, OTPs persistentes e identificadores de negócio reutilizados como credenciais ou chaves de autorização.
• Correlacionar logs de QuickBlox, backend próprio, identidade, chat, vídeo e ações sensíveis para confirmar ausência de abuso após a correção.