- O
Claroty Team82 e a Check Point Research (CPR) colaboraram para verificar a
segurança do popular kit de desenvolvimento de software QuickBlox (SDK) e
da interface de programação de aplicativos (API).
- A
estrutura de desenvolvimento da QuickBlox é executada sob uma linha de
aplicativos populares de bate-papo e vídeo em setores críticos, como finanças
e telemedicina.
- Juntos,
descobrimos vulnerabilidades críticas que podem colocar em risco as
informações pessoais de milhões de usuários.
- O
Claroty Team82 e a CPR também demonstram explorações de prova de conceito
contra aplicativos que executam o QuickBlox SDK e a API.
- Explicamos
vários ataques singulares que podem permitir que o agente da ameaça, por
exemplo, acesse intercomunicadores inteligentes e abra portas remotamente,
ou vaze dados de pacientes de aplicativos de telemedicina.
- A
QuickBlox trabalhou em estreita colaboração com o Claroty Team82 e a CPR
para abordar a nossa revelação, e corrigiu as vulnerabilidades por meio de
um novo design de arquitetura segura e uma nova API.
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.
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.
Recursos de bate-papo e vídeo da QuickBlox (Fonte:
QuickBlox)
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.
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, notamos 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 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.
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 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.
Exemplo de um usuário QuickBlox, contendo o Rozcom User ID
(ID do edifício + número de telefone)
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.
Formulário de login da Rozcom.
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.
Resultado desta API, retornando o código de autenticação 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.
Acesso remoto ao feed de vídeo de um intercomunicador
Rozcom.
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.
Base
de usuários do aplicativo [REDACTED].
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.
Claroty - capacita as organizações a protegerem sistemas
ciberfísicos em ambientes industriais, de saúde e de negócios: a Internet das
Coisas (XIoT).
Nenhum comentário:
Postar um comentário